Apache Hadoop於2006年第一次在IT領域亮相，承諾爲組織提供以往商用硬件從來沒能達到的強大數據存儲能力。這一承諾不僅一舉解決了數據集大小的問題，同時也讓我們得以應對更多數據類型——包括物聯網設備、傳感器、服務器以及企業越來越關注的社交媒體生成數據。這種數據量、處理速度以及類型變化的總和，形成了我們當下最爲熟悉的新概念——大數據。
在Hadoop的普及當中，schema-on-read起到了至關重要的作用。企業發現，他們不再需要擔心表內數據以及表間相互連接的繁瑣定義流程——以往這類工作往往需要耗費數月之久，而且在此期間所有數據倉庫都無法接受正常查詢。在Hadoop帶來的美麗新世界中，企業能夠儘可能多地存儲數據，從基於Hadoop的存儲庫（被稱爲數據湖）中獲取數據，並考慮如何進行後續分析。
自此開始，數據湖廣泛出現在企業運營環境當中。這些數據湖由商業大數據版本支持——一般通過單一平臺提供獨立的開源計算引擎。該平臺能夠爲數據湖提供不同的數據分析方式。最重要的是，這一切都屬於開源項目，可供企業免費試用！聽起來前景一片大好啊，怎麼會出問題？
問題出在schema-on-read身上
就像生活中的很多事物一樣，Hadoop受到廣泛好評的核心優勢，也逐漸成爲其致命的弱點。首先，隨着schema-on-write模式限制的解除，數以TB計的結構化與非結構化數據快速流入數據湖。由於Hadoop的數據治理框架與功能還沒有完全成熟，因此企業發現其越來越難以確定數據湖內容以及數據之間的繼承關係。此外，這些數據也沒有做好接受消費的準備。企業開始對數據湖中的數據失去信心，最終數據湖變成了數據沼澤，這也意味着Hadoop當初提出的“構建即可消費”的架構讀取理念遭遇失敗。
Hadoop複雜性與零散的計算引擎
第二，Hadoop各發行版提供衆多開源計算引擎，包括Apache Hive、Apache Spark以及Apache Kafka等等。但事實證明，這種豐富性本身也不完全是好事。一套典型的商用Hadoop平臺當中可能包含多達26種此類引擎。這些計算引擎的操作非常複雜，需要由具備專門技能的人員將其“粘合”在一起。可以想見，市場上沒那麼多符合要求的人選。
關注點錯誤：數據湖還是應用
第三點，也是最重要的一點，數據湖項目開始失敗，這是因爲企業原本希望利用數據湖將所有企業數據存儲在同一中心位置，以供全部開發人員隨意使用。換言之，大家也可以將其視爲一種超級數據倉庫。但實際情況是，數據會對應用程序產生直接影響。因此，Hadoop集羣通常會成爲企業數據流水線中的網關，其負責數據的過濾、處理與轉換，而後將數據導出至其它數據庫及數據市場以便傳遞至下游——這意味着預期應用方式與實際運營體系發生了衝突。因此，數據湖最終成爲另外一組龐大的差異性計算引擎，其運行在不同工作負載之上，且所有負載都共享同一套存儲系統。這令管理工作變得無比艱難，雖然生態系統中的資源隔離與管理工具確實在不斷改進，但仍有很長的道路要走。而這一切複雜性，僅僅只是爲了實現數據報告功能。
在大多數情況下，企業不希望把關注重點從關鍵任務應用程序那邊，轉移至數據湖這種本應充當廉價數據存儲庫與數據轉移通道的方案身上。例如，Apache Hive與Apache Spark是Hadoop數據湖領域使用最廣泛的兩款計算引擎。這兩款引擎都擁有強大的分析能力——要麼負責處理類SQL查詢（Hive），要麼執行類SQL數據轉換並構建預測模型（Spark）。但很明顯，這些數據湖並沒有充分關注應用程序究竟是如何使用數據的。
戰略進展
因此，如果您所在的組織關注Hadoop生態系統的最新進展，並且發現自己很難證明數據湖的實際價值，那麼您應該首先關注運營應用程序，而後再反過來審視自己的數據。
通過對具有數據及智能元素的應用程序進行現代化升級，您終將能夠利用數據預測應用程序中可能發生的未來趨勢，並根據經驗主動做出應對決策，最終獲得卓越的業務成果。下面來看應用程序現代化戰略中的五大基本要素：
- 選擇需要進行現代化的應用程序：我們應該首先選擇一個希望實現現代化的應用程序，而非集中精力關注數據。您可以從衆多定製應用程序當中選擇其一，這類應用往往擁有一大共性——已經落後於市場趨勢，需要提升敏捷水平、智能程度以及實現數據驅動性。在確定了能夠爲組織帶來競爭優勢的應用程序之後，您就可以專注於爲該應用程序提供必要的數據，並判斷是否能夠從數據湖中獲取這些數據。
- 使用橫向擴展SQL實現應用程序現代化：多年以來，SQL一直是企業工作負載中的主力，組織中一般都存在數百位非常熟悉SQL的開發人員、業務分析師以及IT人員。他們能夠輕鬆將原本的SQL應用程序重寫爲底層NoSQL API，且由此產生的時間、費用與風險成本都比較低。我們首先選擇一個平臺，用以保持熟悉的SQL模式以及強大的功能，同時確保應用程序現代化過程中其架構仍然能夠在低成本基礎設施上實現彈性擴展。橫向擴展使得整體集羣能夠承載更多計算負載，且運行速度要遠超集中式系統上的舊有SQL系統。通過橫向擴展，您可以添加更多資源容量，並在工作負載發生變化時隨時做出調整。
- 採用ACID平臺：ACID合規是負責維護數據庫內事務完整性，並幫助用戶執行提交與回滾等操作的機制。它也是爲應用程序操作提供支持的關鍵性功能，可以確保數據庫在發出提交請求之前不會向其他用戶顯示變更後的結果。大家可以首先在數據庫內的單一事務層級中引入ACID能力，這樣能夠避免將所有一致性分支都交由應用程序代碼處理。所有傳統SQL系統都符合ACID標準，數據湖也正是因爲錯誤地放棄了這一標準才使得配套應用程序變得難於編寫。
- 統一分析引擎：根據Gartner公司發佈的文章，我們原先確實有充分的理由將IT基礎設施劃分爲運營（OLTP）與分析（OLAP）這兩大類；但如今情況開始發生變化。ETL帶來的延遲會導致SLA得不到保障。過去，運營與分析負載會相互干擾，所以纔不得不進行拆分。另外，遺留數據平臺的執行往往非常糟糕，我們必須得把運營模式轉換爲更適合分析類工作負載的星形或者雪花模式。由於不再需要ETL，我們可以在運營平臺上以運營模式執行分析任務。通過這種方式，我們能夠確保應用程序始終運行在數據移動需求量最低的平臺上，因此不致引發過高的應用程序延遲。如此一來，我們還能通過報告與儀表板輕鬆將當前數據與昨天或者上週的版本進行對比，從而快速獲得洞察見解。
- 嵌入原生機器學習機制：之所以有必要推動應用程序現代化，主要原因之一就是藉此將AI與ML注入其中，以使應用程序能夠從經濟當中學習、以動態方式適應變化，同時做出即時決策。 爲了實現應用程序智能化，我們必須選擇一套在數據庫層級內置機器學習方案的平臺，以確保各模型能夠隨時利用最新數據進行實驗、訓練與執行。
從本質層面來看，如今的使用場景已經與當初的數據湖使用方式完全不同。通過新方式，能夠利用數據湖資源的應用程序將更快爲業務線提供真實可見的商業價值。
這種方法除了通過應用程序現代化幫助企業建立競爭優勢之外，還能幫助大家繼續保留原有數據湖投資組合。
最後，感興趣的朋友也可以點擊此處獲取本份白皮書副本，其中詳盡闡述了應用程序落後於數字化轉趨勢的五種跡象以及其它細節信息。