數據湖真的已經沒落了嗎？

就在不久前，整個數據世界還在沸沸揚揚地討論如何建立集中式數據存儲，以最大限度地提升數據的可用性，從而達到高級分析的目的。博客們大聲疾呼反對數據湖，支持組織良好的數據庫，開源社區團結在Hadoop生態系統周圍，大數據技術飛速發展。本文就這個情況回顧一下推進數據湖採用的一些假設，並注意一下這些假設的穩定性。

假設1: "數據存儲很貴，因此創建屬於本身的Hadoop數據湖，經濟效益看起來更有吸引力。"

過後看來，這個假設如何？

能夠確定的是，Hadoop中每GB存儲的TCO能夠比傳統RDBMS系統的成本低5%甚至更低。可是，即便是最有經驗的企業也很快了解到運營一個企業集羣有多難。開源軟件的不斷更新，管理環境的技能稀缺，以及生態系統的相對不成熟，都形成了難以管理的技術故障和依賴性。除此以外，一旦Hadoop完成了三次數據複製，管理員須要快照和副原本克服Hadoop更新的侷限性，1TB的RDBMS數據可能會在湖中變成50TB。這些節省下來的錢就這麼多了。

新興的現實：雲和雲數據倉庫

亞馬遜、微軟和谷歌急於用託管的、基於雲的環境來填補這些生產力的空白，這些環境簡化了管理，使數據科學家更快地提升生產力。接下來，消費模式取代了Hadoop on-pre環境的資本成本，這意味着人們不太願意簡單地將全部大型數據集傾倒到一箇中央環境中。相反，他們根據分析須要加載數據。所以，這就產生了從大型的on-prem數據湖轉移到小型的基於雲的數據池塘的效果，這些數據池塘是爲目的而創建的。再進一步，新的雲倉庫經過基於SQL的工具使訪問和查詢這些數據變得簡單，這進一步向非技術消費者釋放了數據的價值。

假設2: "大數據太大了，搬不動。移動一次數據，把電腦移到數據上"。

過後看來，這個假設是怎樣的？

數據湖的一個關鍵假設是，網絡和處理速度的限制意味着咱們沒法將日誌文件等數據的大副本移動到集羣中進行數據分析。Hadoop也是面向批處理的，這意味着這些類型數據的大批量處理是很是不切實際的。事實證實，數據複製和流媒體的改進，以及網絡方面的巨大收益，致使這種狀況沒有咱們想象的那麼真實。

新興的現實：數據虛擬化和流媒體

技術的改進意味着企業能夠選擇如何訪問數據.也許，他們但願將查詢從事務性系統卸載到雲環境中；數據複製和流媒體如今是簡單的解決方案。也許，交易系統是爲高性能查詢而構建的；在這種狀況下，數據虛擬化功能可使該數據按需提供。所以，企業如今能夠選擇讓數據更多地按需提供給DataOps流程，這意味着並不老是須要將全部企業數據物理地集中在一個位置。

假設3: "讀時的數據湖模式將取代寫時的數據倉庫模式。"

過後看來，這個假設如何？

人們已經厭倦了IT團隊將ETL寫入數據倉庫所花費的時間，並迫切但願簡單地釋放數據科學家對原始數據的處理。有兩個主要的癥結所在。首先，數據科學家每每不能輕易地找到他們要找的數據.其次，一旦他們有了數據，分析負責人很快就會發現，他們的ETL只是被數據糾纏工具所取代，由於數據科學仍然須要清理，如標準化和外鍵匹配。

新興的現實：數據目錄和數據運營

智能數據目錄已經成爲尋找所需數據的關鍵。如今，企業正試圖經過簡單的解決方案，在工做場所創建起用戶在家中享受的谷歌搜索同樣的搜索方式，以查找和訪問數據，而無論保存數據的數據存儲的物理位置在哪裏。DataOps流程也已經出現，它是創建基於領域的數據集的一種方式，這些數據集通過精心規劃和管理，能夠實現最大的分析生產力。所以，數據科學家應該可以輕鬆地找到並信任他們用來發現新的看法的數據，通過深思熟慮的技術和流程的融合應該可以使數據管道和分析管道快速運行，以支持這些新發現。這個過程能夠實現實時分析。

在Qlik尋求現代化的數據分析架構時，這些關鍵的新興現實是他們須要思考的重點：

• 基於雲的應用和分析架構
• 數據倉庫/RDBMS結構在雲中的從新崛起，以實現價值最大化（想一想Snowflake）。
• 數據流以減小關鍵數據的延遲
• 數據虛擬化，以減小數據的複製，直到須要爲止。
• 數據目錄，仔細清點和管理企業數據的訪問。
• DataOps流程的出現，爲數據和分析管道創造了快速上市的時間。

關於Qlik

Qlik的願景是一個數據素養的世界，每一個人均可以使用數據來改善決策並解決他們最具挑戰性的問題。只有Qlik提供端到端的實時數據集成和分析解決方案，以幫助組織訪問全部數據並將其轉化爲價值。慧都做爲Qlik官方的中國合做夥伴，咱們爲Qlik的中國用戶提供產品受權與實施、定製分析方案、技術培訓等服務，旨在讓中國企業的每一個Qlik用戶都能探索出數據的價值，讓企業造成分析文化