本文包括七個小節：1、什麼是數據湖；2、數據湖的基本特徵；3、數據湖基本架構；4、各廠商的數據湖解決方案；5、典型的數據湖應用場景；6、數據湖建設的基本過程；7、總結。受限於個人水平，謬誤在所難免，歡迎同學們一起探討，批評指正，不吝賜教。
一、什麼是數據湖
數據湖是目前比較熱的一個概念，許多企業都在構建或者計劃構建自己的數據湖。但是在計劃構建數據湖之前，搞清楚什麼是數據湖，明確一個數據湖項目的基本組成，進而設計數據湖的基本架構，對於數據湖的構建至關重要。關於什麼是數據湖？有不同的定義。
Wikipedia上說數據湖是一類存儲數據自然/原始格式的系統或存儲，通常是對象塊或者文件，包括原始系統所產生的原始數據拷貝以及爲了各類任務而產生的轉換數據，包括來自於關係型數據庫中的結構化數據（行和列）、半結構化數據（如CSV、日誌、XML、JSON）、非結構化數據（如email、文檔、PDF等）和二進制數據（如圖像、音頻、視頻）。
AWS定義數據湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化數據。
微軟的定義就更加模糊了，並沒有明確給出什麼是Data Lake，而是取巧的將數據湖的功能作爲定義，數據湖包括一切使得開發者、數據科學家、分析師能更簡單的存儲、處理數據的能力，這些能力使得用戶可以存儲任意規模、任意類型、任意產生速度的數據，並且可以跨平臺、跨語言的做所有類型的分析和處理。
關於數據湖的定義其實很多，但是基本上都圍繞着以下幾個特性展開。
1、 數據湖需要提供足夠用的數據存儲能力，這個存儲保存了一個企業/組織中的所有數據。
2、 數據湖可以存儲海量的任意類型的數據，包括結構化、半結構化和非結構化數據。
3、 數據湖中的數據是原始數據，是業務數據的完整副本。數據湖中的數據保持了他們在業務系統中原來的樣子。
4、 數據湖需要具備完善的數據管理能力（完善的元數據），可以管理各類數據相關的要素，包括數據源、數據格式、連接信息、數據schema、權限管理等。
5、 數據湖需要具備多樣化的分析能力，包括但不限於批處理、流式計算、交互式分析以及機器學習；同時，還需要提供一定的任務調度和管理能力。
6、 數據湖需要具備完善的數據生命週期管理能力。不光需要存儲原始數據，還需要能夠保存各類分析處理的中間結果，並完整的記錄數據的分析處理過程，能幫助用戶完整詳細追溯任意一條數據的產生過程。
7、 數據湖需要具備完善的數據獲取和數據發佈能力。數據湖需要能支撐各種各樣的數據源，並能從相關的數據源中獲取全量/增量數據；然後規範存儲。數據湖能將數據分析處理的結果推送到合適的存儲引擎中，滿足不同的應用訪問需求。
8、 對於大數據的支持，包括超大規模存儲以及可擴展的大規模數據處理能力。
綜上，個人認爲數據湖應該是一種不斷演進中、可擴展的大數據存儲、處理、分析的基礎設施；以數據爲導向，實現任意來源、任意速度、任意規模、任意類型數據的全量獲取、全量存儲、多模式處理與全生命週期管理；並通過與各類外部異構數據源的交互集成，支持各類企業級應用。
圖1. 數據湖基本能力示意
這裏需要再特別指出兩點：
1）可擴展是指規模的可擴展和能力的可擴展，即數據湖不但要能夠隨着數據量的增大，提供“足夠”的存儲和計算能力；還需要根據需要不斷提供新的數據處理模式，例如可能一開始業務只需要批處理能力，但隨着業務的發展，可能需要交互式的即席分析能力；又隨着業務的實效性要求不斷提升，可能需要支持實時分析和機器學習等豐富的能力。
2）以數據爲導向，是指數據湖對於用戶來說要足夠的簡單、易用，幫助用戶從複雜的IT基礎設施運維工作中解脫出來，關注業務、關注模型、關注算法、關注數據。數據湖面向的是數據科學家、分析師。目前來看，雲原生應該是構建數據湖的一種比較理想的構建方式，後面在“數據湖基本架構”一節會詳細論述這一觀點。
二、數據湖的基本特徵
對數據湖的概念有了基本的認知之後，我們需要進一步明確數據湖需要具備哪些基本特徵，特別是與大數據平臺或者傳統數據倉庫相比，數據湖具有哪些特點。在具體分析之前，我們先看一張來自AWS官網的對比表格（表格引自：https://aws.amazon.com/cn/big-data/datalakes-and-analytics/what-is-a-data-lake/）
上表對比了數據湖與傳統數倉的區別，個人覺得可以從數據和計算兩個層面進一步分析數據湖應該具備哪些特徵。在數據方面：
1）“保真性”。數據湖中對於業務系統中的數據都會存儲一份“一模一樣”的完整拷貝。與數據倉庫不同的地方在於，數據湖中必須要保存一份原始數據，無論是數據格式、數據模式、數據內容都不應該被修改。在這方面，數據湖強調的是對於業務數據“原汁原味”的保存。同時，數據湖應該能夠存儲任意類型/格式的數據。
2）“靈活性”：上表一個點是 “寫入型schema” v.s.“讀取型schema”，其實本質上來講是數據schema的設計發生在哪個階段的問題。對於任何數據應用來說，其實schema的設計都是必不可少的，即使是mongoDB等一些強調“無模式”的數據庫，其最佳實踐裏依然建議記錄儘量採用相同/相似的結構。“寫入型schema”背後隱含的邏輯是數據在寫入之前，就需要根據業務的訪問方式確定數據的schema，然後按照既定schema，完成數據導入，帶來的好處是數據與業務的良好適配；但是這也意味着數倉的前期擁有成本會比較高，特別是當業務模式不清晰、業務還處於探索階段時，數倉的靈活性不夠。
數據湖強調的“讀取型schema”，背後的潛在邏輯則是認爲業務的不確定性是常態：我們無法預期業務的變化，那麼我們就保持一定的靈活性，將設計去延後，讓整個基礎設施具備使數據“按需”貼合業務的能力。因此，個人認爲“保真性”和“靈活性”是一脈相承的：既然沒辦法預估業務的變化，那麼索性保持數據最爲原始的狀態，一旦需要時，可以根據需求對數據進行加工處理。因此，數據湖更加適合創新型企業、業務高速變化發展的企業。同時，數據湖的用戶也相應的要求更高，數據科學家、業務分析師（配合一定的可視化工具）是數據湖的目標客戶。
3）“可管理”：數據湖應該提供完善的數據管理能力。既然數據要求“保真性”和“靈活性”，那麼至少數據湖中會存在兩類數據：原始數據和處理後的數據。數據湖中的數據會不斷的積累、演化。因此，對於數據管理能力也會要求很高，至少應該包含以下數據管理能力：數據源、數據連接、數據格式、數據schema（庫/表/列/行）。同時，數據湖是單個企業/組織中統一的數據存放場所，因此，還需要具有一定的權限管理能力。
4）“可追溯”：數據湖是一個組織/企業中全量數據的存儲場所，需要對數據的全生命週期進行管理，包括數據的定義、接入、存儲、處理、分析、應用的全過程。一個強大的數據湖實現，需要能做到對其間的任意一條數據的接入、存儲、處理、消費過程是可追溯的，能夠清楚的重現數據完整的產生過程和流動過程。
在計算方面，個人認爲數據湖對於計算能力要求其實非常廣泛，完全取決於業務對於計算的要求。
5）豐富的計算引擎。從批處理、流式計算、交互式分析到機器學習，各類計算引擎都屬於數據湖應該囊括的範疇。一般情況下，數據的加載、轉換、處理會使用批處理計算引擎；需要實時計算的部分，會使用流式計算引擎；對於一些探索式的分析場景，可能又需要引入交互式分析引擎。隨着大數據技術與人工智能技術的結合越來越緊密，各類機器學習/深度學習算法也被不斷引入，例如TensorFlow/PyTorch框架已經支持從HDFS/S3/OSS上讀取樣本數據進行訓練。因此，對於一個合格的數據湖項目而言，計算引擎的可擴展/可插拔，應該是一類基礎能力。
6）多模態的存儲引擎。理論上，數據湖本身應該內置多模態的存儲引擎，以滿足不同的應用對於數據訪問需求（綜合考慮響應時間/併發/訪問頻次/成本等因素）。但是，在實際的使用過程中，數據湖中的數據通常並不會被高頻次的訪問，而且相關的應用也多在進行探索式的數據應用，爲了達到可接受的性價比，數據湖建設通常會選擇相對便宜的存儲引擎（如S3/OSS/HDFS/OBS），並且在需要時與外置存儲引擎協同工作，滿足多樣化的應用需求。
三、數據湖基本架構
數據湖可以認爲是新一代的大數據基礎設施。爲了更好的理解數據湖的基本架構，我們先來看看大數據基礎設施架構的演進過程。
1） 第一階段：以Hadoop爲代表的離線數據處理基礎設施。如下圖所示，Hadoop是以HDFS爲核心存儲，以MapReduce（簡稱MR）爲基本計算模型的批量數據處理基礎設施。圍繞HDFS和MR，產生了一系列的組件，不斷完善整個大數據平臺的數據處理能力，例如面向在線KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。同時，隨着大家對於批處理的性能要求越來越高，新的計算模型不斷被提出，產生了Tez、Spark、Presto等計算引擎，MR模型也逐漸進化成DAG模型。DAG模型一方面，增加計算模型的抽象併發能力：對每一個計算過程進行分解，根據計算過程中的聚合操作點對任務進行邏輯切分，任務被切分成一個個的stage，每個stage都可以有一個或者多個Task組成，Task是可以併發執行的，從而提升整個計算過程的並行能力；另一方面，爲減少數據處理過程中的中間結果寫文件操作，Spark、Presto等計算引擎儘量使用計算節點的內存對數據進行緩存，從而提高整個數據過程的效率和系統吞吐能力。
圖2. Hadoop體系結構示意
2） 第二階段：lambda架構。隨着數據處理能力和處理需求的不斷變化，越來越多的用戶發現，批處理模式無論如何提升性能，也無法滿足一些實時性要求高的處理場景，流式計算引擎應運而生，例如Storm、Spark Streaming、Flink等。然而，隨着越來越多的應用上線，大家發現，其實批處理和流計算配合使用，才能滿足大部分應用需求；而對於用戶而言，其實他們並不關心底層的計算模型是什麼，用戶希望無論是批處理還是流計算，都能基於統一的數據模型來返回處理結果，於是Lambda架構被提出，如下圖所示。（爲了省事，lambda架構和Kappa架構圖均來自於網絡）
圖3. Lambda架構示意
Lambda架構的核心理念是“流批一體”，如上圖所示，整個數據流向自左向右流入平臺。進入平臺後一分爲二，一部分走批處理模式，一部分走流式計算模式。無論哪種計算模式，最終的處理結果都通過服務層對應用提供，確保訪問的一致性。
3） 第三階段：Kappa架構。Lambda架構解決了應用讀取數據的一致性問題，但是“流批分離”的處理鏈路增大了研發的複雜性。因此，有人就提出能不能用一套系統來解決所有問題。目前比較流行的做法就是基於流計算來做。流計算天然的分佈式特徵，註定了他的擴展性更好。通過加大流計算的併發性，加大流式數據的“時間窗口”，來統一批處理與流式處理兩種計算模式。
圖4. Kappa架構示意
綜上，從傳統的hadoop架構往lambda架構，從lambda架構往Kappa架構的演進，大數據平臺基礎架構的演進逐漸囊括了應用所需的各類數據處理能力，大數據平臺逐漸演化成了一個企業/組織的全量數據處理平臺。當前的企業實踐中，除了關係型數據庫依託於各個獨立的業務系統；其餘的數據，幾乎都被考慮納入大數據平臺來進行統一的處理。然而，目前的大數據平臺基礎架構，都將視角鎖定在了存儲和計算，而忽略了對於數據的資產化管理，這恰恰是數據湖作爲新一代的大數據基礎設施所重點關注的方向之一。
大數據基礎架構的演進，其實反應了一點：在企業/組織內部，數據是一類重要資產已經成爲了共識；爲了更好的利用數據，企業/組織需要對數據資產 1）進行長期的原樣存儲；2）進行有效管理與集中治理；3）提供多模式的計算能力滿足處理需求；4）以及面向業務，提供統一的數據視圖、數據模型與數據處理結果。數據湖就是在這個大背景下產生的，除了大數據平臺所擁有的各類基礎能力之外，數據湖更強調對於數據的管理、治理和資產化能力。落到具體的實現上，數據湖需要包括一系列的數據管理組件，包括：1）數據接入；2）數據搬遷；3）數據治理；4）質量管理；5）資產目錄；6）訪問控制；7）任務管理；8）任務編排；9）元數據管理等。如下圖所示，給出了一個數據湖系統的參考架構。對於一個典型的數據湖而言，它與大數據平臺相同的地方在於它也具備處理超大規模數據所需的存儲和計算能力，能提供多模式的數據處理能力；增強點在於數據湖提供了更爲完善的數據管理能力，具體體現在：
1） 更強大的數據接入能力。數據接入能力體現在對於各類外部異構數據源的定義管理能力，以及對於外部數據源相關數據的抽取遷移能力，抽取遷移的數據包括外部數據源的元數據與實際存儲的數據。
2） 更強大的數據管理能力。管理能力具體又可分爲基本管理能力和擴展管理能力。基本管理能力包括對各類元數據的管理、數據訪問控制、數據資產管理，是一個數據湖系統所必須的，後面我們會在“各廠商的數據湖解決方案”一節相信討論各個廠商對於基本管理能力的支持方式。擴展管理能力包括任務管理、流程編排以及與數據質量、數據治理相關的能力。任務管理和流程編排主要用來管理、編排、調度、監測在數據湖系統中處理數據的各類任務，通常情況下，數據湖構建者會通過購買/研製定製的數據集成或數據開發子系統/模塊來提供此類能力，定製的系統/模塊可以通過讀取數據湖的相關元數據，來實現與數據湖系統的融合。而數據質量和數據治理則是更爲複雜的問題，一般情況下，數據湖系統不會直接提供相關功能，但是會開放各類接口或者元數據，供有能力的企業/組織與已有的數據治理軟件集成或者做定製開發。
3） 可共享的元數據。數據湖中的各類計算引擎會與數據湖中的數據深度融合，而融合的基礎就是數據湖的元數據。好的數據湖系統，計算引擎在處理數據時，能從元數據中直接獲取數據存儲位置、數據格式、數據模式、數據分佈等信息，然後直接進行數據處理，而無需進行人工/編程干預。更進一步，好的數據湖系統還可以對數據湖中的數據進行訪問控制，控制的力度可以做到“庫表列行”等不同級別。
圖5. 數據湖組件參考架構
還有一點應該指出的是，上圖的“集中式存儲”更多的是業務概念上的集中，本質上是希望一個企業/組織內部的數據能在一個明確統一的地方進行沉澱。事實上，數據湖的存儲應該是一類可按需擴展的分佈式文件系統，大多數數據湖實踐中也是推薦採用S3/OSS/OBS/HDFS等分佈式系統作爲數據湖的統一存儲。
我們可以再切換到數據維度，從數據生命週期的視角來看待數據湖對於數據的處理方式，數據在數據湖中的整個生命週期如圖6所示。理論上，一個管理完善的數據湖中的數據會永久的保留原始數據，同時過程數據會不斷的完善、演化，以滿足業務的需要。
圖6. 數據湖中的數據生命週期示意
四、各廠商的數據湖解決方案
數據湖作爲當前的一個風口，各大雲廠商紛紛推出自己的數據湖解決方案及相關產品。本節將分析各個主流廠商推出的數據湖解決方案，並將其映射到數據湖參考架構上，幫助大家理解各類方案的優缺點。
4.1 AWS數據湖解決方案
圖7. AWS數據湖解決方案
圖7是AWS推薦的數據湖解決方案。整個方案基於AWS Lake Formation構建，AWS Lake Formation本質上是一個管理性質的組件，它與其他AWS服務互相配合，來完成整個企業級數據湖構建功能。上圖自左向右，體現了數據流入、數據沉澱、數據計算、數據應用四個步驟。我們進一步來看其關鍵點：
1） 數據流入。
數據流入是整個數據湖構建的起始，包括元數據的流入和業務數據流入兩個部分。元數據流入包括數據源創建、元數據抓取兩步，最終會形成數據資源目錄，並生成對應的安全設置與訪問控制策略。解決方案提供專門的組件，獲取外部數據源的相關元信息，該組件能連接外部數據源、檢測數據格式和模式（schema），並在對應的數據資源目錄中創建屬於數據湖的元數據。業務數據的流入是通過ETL來完成的。
在具體的產品形式上，元數據抓取、ETL和數據準備AWS將其單獨抽象出來，形成了一個產品叫AWS GLUE。AWS GLUE與AWS Lake Formation共享同一個數據資源目錄，在AWS GLUE官網文檔上明確指出：“Each AWS account has one AWS Glue Data Catalog per AWS region”。
對於異構數據源的支持。AWS提供的數據湖解決方案，支持S3、AWS關係型數據庫、AWS NoSQL數據庫，AWS利用GLUE、EMR、Athena等組件支持數據的自由流動。
2） 數據沉澱。
採用Amazon S3作爲整個數據湖的集中存儲，按需擴展/按使用量付費。
3） 數據計算。
整個解決方案利用AWS GLUE來進行基本的數據處理。GLUE基本的計算形式是各類批處理模式的ETL任務，任務的出發方式分爲手動觸發、定時觸發、事件觸發三種。不得不說，AWS的各類服務在生態上實現的非常好，事件觸發模式上，可以利用AWS Lambda進行擴展開發，同時觸發一個或多個任務，極大的提升了任務觸發的定製開發能力；同時，各類ETL任務，可以通過CloudWatch進行很好的監控。
4） 數據應用。
在提供基本的批處理計算模式之外，AWS通過各類外部計算引擎，來提供豐富的計算模式支持，例如通過Athena/Redshift來提供基於SQL的交互式批處理能力；通過EMR來提供各類基於Spark的計算能力，包括Spark能提供的流計算能力和機器學習能力。
5） 權限管理。
AWS的數據湖解決方案通過Lake Formation來提供相對完善的權限管理，粒度包括“庫-表-列”。但是，有一點例外的是，GLUE訪問Lake Formation時，粒度只有“庫-表”兩級；這也從另一個側面說明，GLUE和Lake Formation的集成是更爲緊密的，GLUE對於Lake Formation中的數據有更大的訪問權限。
Lake Formation的權限進一步可以細分爲數據資源目錄訪問權限和底層數據訪問權限，分別對應元數據與實際存儲的數據。實際存儲數據的訪問權限又進一步分爲數據存取權限和數據存儲訪問權限。數據存取權限類似於數據庫中對於庫表的訪問權限，數據存儲權限則進一步細化了對於S3中具體目錄的訪問權限（分爲顯示和隱式兩種）。如圖8所示，用戶A在只有數據存取的權限下，無法創建位於S3指定bucket下的表。
個人認爲這進一步體現了數據湖需要支持各種不同的存儲引擎，未來的數據湖可能不只S3/OSS/OBS/HDFS一類核心存儲，可能根據應用的訪問需求，納入更多類型的存儲引擎，例如，S3存儲原始數據，NoSQL存儲處理過後適合以“鍵值”模式訪問的數據，OLAP引擎存儲需要實時出各類報表/adhoc查詢的數據。雖然當前各類材料都在強調數據湖與數據倉庫的不同；但是，從本質上，數據湖更應該是一類融合的數據管理思想的具體實現，“湖倉一體化”也很可能是未來的一個發展趨勢。
圖8. AWS數據湖解決方案權限分離示意
綜上，AWS數據湖方案成熟度高，特別是元數據管理、權限管理上考慮充分，打通了異構數據源與各類計算引擎的上下游關係，讓數據能夠自由“移動”起來。在流計算和機器學習上，AWS的解決方案也比較完善。流計算方面AWS推出了專門的流計算組件Kinesis，Kinesis中的Kinesis data Firehose服務可以創建一個完全被託管的數據分發服務，通過Kinesis data Stream實時處理的數據，可以藉助Firehose方便的寫入S3中，並支持相應的格式轉換，如將JSON轉換成Parquet格式。AWS整個方案最牛的地方還在與Kinesis可以訪問GLUE中的元數據，這一點充分體現了AWS數據湖解決方案在生態上的完備性。同樣，在機器學習方面，AWS提供了SageMaker服務，SageMaker可以讀取S3中的訓練數據，並將訓練好的模型回寫至S3中。但是，有一點需要指出的是，在AWS的數據湖解決方案中，流計算和機器學習並不是固定捆綁的，只是作爲計算能力擴展，能方便的集成。
最後，讓我們回到圖6的數據湖組件參考架構，看看AWS的數據湖解決方案的組件覆蓋情況，參見圖9。
圖9. AWS 數據湖解決方案在參考架構中的映射
綜上，AWS的數據湖解決方案覆蓋了除質量管理和數據治理的所有功能。其實質量管理和數據治理這個工作和企業的組織結構、業務類型強相關，需要做大量的定製開發工作，因此通用解決方案不囊括這塊內容，也是可以理解的。事實上，現在也有比較優秀的開源項目支持這個項目，比如Apache Griffin，如果對質量管理和數據治理有強訴求，可以自行定製開發。
4.2 華爲數據湖解決方案
圖10.華爲數據湖解決方案
華爲的數據湖解決方案相關信息來自華爲官網。目前官網可見的相關產品包括數據湖探索（Data Lake Insight，DLI）和智能數據湖運營平臺（DAYU）。其中DLI相當於是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。官網上沒找到關於DLI的整體架構圖，我根據自己的理解，嘗試畫了一個，主要是和AWS的解決方案有一個對比，所以形式上儘量一致，如果有非常瞭解華爲DLI的同學，也請不吝賜教。
華爲的數據湖解決方案比較完整，DLI承擔了所有的數據湖構建、數據處理、數據管理、數據應用的核心功能。DLI最大的特色是在於分析引擎的完備性，包括基於SQL的交互式分析以及基於Spark+Flink的流批一體處理引擎。在覈心存儲引擎上，DLI依然通過內置的OBS來提供，和AWS S3的能力基本對標。華爲數據湖解決方案在上下游生態上做的比AWS相對完善，對於外部數據源，幾乎支持所有目前華爲雲上提供的數據源服務。
DLI可以與華爲的CDM（雲數據遷移服務）和DIS（數據接入服務）對接：1）藉助DIS，DLI可以定義各類數據點，這些點可以在Flink作業中被使用，做爲source或者sink；2）藉助CDM，DLI甚至能接入IDC、第三方雲服務的數據。
爲了更好的支持數據集成、數據開發、數據治理、質量管理等數據湖高級功能，華爲雲提供了DAYU平臺。DAYU平臺是華爲數據湖治理運營方法論的落地實現。DAYU涵蓋了整個數據湖治理的核心流程，並對其提供了相應的工具支持；甚至在華爲的官方文檔中，給出了數據治理組織的構建建議。DAYU的數據治理方法論的落地實現如圖11所示（來自華爲雲官網）。
圖11 DAYU數據治理方法論流程
可以看到，本質上DAYU數據治理的方法論其實是傳統數據倉庫治理方法論在數據湖基礎設施上的延伸：從數據模型來看，依然包括貼源層、多源整合層、明細數據層，這點與數據倉庫完全一致。根據數據模型和指標模型會生成質量規則和轉換模型，DAYU會和DLI對接，直接調用DLI提供的相關數據處理服務，完成數據治理。華爲雲整個的數據湖解決方案，完整覆蓋了數據處理的生命週期，並且明確支持了數據治理，並提供了基於模型和指標的數據治理流程工具，在華爲雲的數據湖解決方案中逐漸開始往“湖倉一體化”方向演進。
4.3 阿里雲數據湖解決方案
阿里雲上數據類產品衆多，因爲本人目前在數據BU，所以本節方案將關注在如何使用數據庫BU的產品來構建數據湖，其他雲上產品會略有涉及。阿里雲的基於數據庫產品的數據湖解決方案更加聚焦，主打數據湖分析和聯邦分析兩個場景。阿里雲數據湖解決方案如圖12所示。
圖12. 阿里雲數據湖解決方案
整個方案依然採用OSS作爲數據湖的集中存儲。在數據源的支持上，目前也支持所有的阿里雲數據庫，包括OLTP、OLAP和NoSQL等各類數據庫。核心關鍵點如下：
1） 數據接入與搬遷。在建湖過程中，DLA的Formation組件具備元數據發現和一鍵建湖的能力，在本文寫作之時，目前“一鍵建湖”還只支持全量建湖，但是基於binlog的增量建湖已經在開發中了，預計近期上線。增量建湖能力會極大的增加數據湖中數據的實時性，並將對源端業務數據庫的壓力降到最下。這裏需要注意的是，DLA Formation是一個內部組件，對外並沒有暴露。
2） 數據資源目錄。DLA提供Meta data catalog組件對於數據湖中的數據資產進行統一的管理，無論數據是在“湖中”還是在“湖外”。Meta data catalog也是聯邦分析的統一元數據入口。
3） 在內置計算引擎上，DLA提供了SQL計算引擎和Spark計算引擎兩種。無論是SQL還是Spark引擎，都和Meta data catalog深度集成，能方便的獲取元數據信息。基於Spark的能力，DLA解決方案支持批處理、流計算和機器學習等計算模式。
4） 在外圍生態上，除了支持各類異構數據源做數據接入與匯聚之外，在對外訪問能力上，DLA與雲原生數據倉庫（原ADB）深度整合。一方面，DLA處理的結果可之際推送至ADB中，滿足實時、交互式、ad hoc複雜查詢；另一方面，ADB裏的數據也可以藉助外表功能，很方便的進行數據迴流至OSS中。基於DLA，阿里雲上各類異構數據源可以完全被打通，數據自由流動。
5） 在數據集成和開發上，阿里雲的數據湖解決方案提供兩種選擇：一種是採用dataworks完成；另一種是採用DMS來完成。無論是選擇哪種，都能對外提供可視化的流程編排、任務調度、任務管理能力。在數據生命週期管理上，dataworks的數據地圖能力相對更加成熟。
6） 在數據管理和數據安全上，DMS提供了強大的能力。DMS的數據管理粒度分爲“庫-表-列-行”，完善的支持企業級的數據安全管控需求。除了權限管理之外，DMS更精細的地方是把原來基於數據庫的devops理念擴展到了數據湖，使得數據湖的運維、開發更加精細化。
進一步細化整個數據湖方案的數據應用架構，如下圖所示。
圖13. 阿里雲數據湖數據應用架構
自左向右從數據的流向來看，數據生產者產生各類數據（雲下/雲上/其他雲），利用各類工具，上傳至各類通用/標準數據源，包括OSS/HDFS/DB等。針對各類數據源，DLA通過數據發現、數據接入、數據遷移等能力，完整建湖操作。對於“入湖”的數據，DLA提供基於SQL和Spark的數據處理能力，並可以基於Dataworks/DMS，對外提供可視化的數據集成和數據開發能力；在對外應用服務能力上，DLA提供標準化的JDBC接口，可以直接對接各類報表工具、大屏展示功能等。阿里雲的DLA的特色在於背靠整個阿里雲數據庫生態，包括OLTP、OLAP、NoSQL等各類數據庫，對外提供基於SQL的數據處理能力，對於傳統企業基於數據庫的開發技術棧而言，轉型成本相對較低，學習曲線比較平緩。
阿里雲的DLA解決方案的另一個特色在於“基於雲原生的湖倉一體化”。傳統的企業級數據倉庫在大數據時代的今天，在各類報表應用上依然是無法替代的；但是數倉無法滿足大數據時代的數據分析處理的靈活性需求；因此，我們推薦數據倉庫應該作爲數據湖的上層應用存在：即數據湖是原始業務數據在一個企業/組織中唯一官方數據存儲地；數據湖根據各類業務應用需求，將原始數據進行加工處理，形成可再次利用的中間結果；當中間結果的數據模式（Schema）相對固定後，DLA可以將中間結果推送至數據倉庫，供企業/組織開展基於數倉的業務應用。阿里雲在提供DLA的同時，還提供了雲原生數倉（原ADB），DLA和雲原生數倉在以下兩點上深度融合。
1） 使用同源的SQL解析引擎。DLA的SQL與ADB的SQL語法上完全兼容，這意味着開發者使用一套技術棧即能同時開發數據湖應用和數倉應用。
2） 都內置了對於OSS的訪問支持。OSS直接作爲DLA的原生存儲存在；對於ADB而言，可以通過外部表的能力，很方便的訪問OSS上的結構化數據。藉助外部表，數據可以自由的在DLA和ADB之間流轉，做到真正的湖倉一體。
DLA+ADB的組合真正做到了雲原生的湖倉一體（關於什麼是雲原生，不在本文的討論範疇）。本質上，DLA可以看成一個能力擴展的數據倉庫貼源層。與傳統數倉相比，該貼源層：（1）可以保存各類結構化、半結構化和非結構化數據；（2）可以對接各類異構數據源；（3）具備元數據發現、管理、同步等能力；（4）內置的SQL/Spark計算引擎具備更強的數據處理能力，滿足多樣化的數據處理需求；（5）具備全量數據的全生命週期管理能力。基於DLA+ADB的湖倉一體化方案，將同時覆蓋“大數據平臺+數據倉庫”的處理能力。
DLA還有一個重要能力是構建了一個“四通八達”的數據流動體系，並以數據庫的體驗對外提供能力，無論數據在雲上還是雲下，無論數據在組織內部還是外部；藉助數據湖，各個系統之間的數據不再存在壁壘，可以自由的流進流出；更重要的是，這種流動是受監管的，數據湖完整的記錄了數據的流動情況。
4.4 Azure數據湖解決方案
Azure的數據湖解決方案包括數據湖存儲、接口層、資源調度與計算引擎層，如圖15所示（來自Azure官網）。存儲層是基於Azure object Storage構建的，依然是對結構化、半結構化和非結構化數據提供支撐。接口層爲WebHDFS，比較特別的是在Azure object Storage實現了HDFS的接口，Azure把這個能力稱爲“數據湖存儲上的多協議存取”。在資源調度上，Azure基於YARN實現。計算引擎上，Azure提供了U-SQL、hadoop和Spark等多種處理引擎。
圖15. Azure Data lake analysis 架構
Azure的特別之處是基於visual studio提供給了客戶開發的支持。
1）開發工具的支持，與visual studio的深度集成；Azure推薦使用U-SQL作爲數據湖分析應用的開發語言。Visual studio爲U-SQL提供了完備的開發環境；同時，爲了降低分佈式數據湖系統開發的複雜性，visual studio基於項目進行封裝，在進行U-SQL開發時，可以創建“U-SQL database project”，在此類項目中，利用visual studio，可以很方便的進行編碼與調試，同時，也提供嚮導，將開發好的U-SQL腳本發佈到生成環境。U-SQL支持Python、R進行擴展，滿足定製開發需求。
2）多計算引擎的適配：SQL, Apache Hadoop和Apache Spark。這裏的hadoop包括Azure提供的HDInsight（Azure託管的Hadoop服務），Spark包括Azure Databricks。
3）多種不同引擎任務之間的自動轉換能力。微軟推薦U-SQL爲數據湖的缺省開發工具，並提供各類轉換工具，支持U-SQL腳本與Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之間的轉化。
4.5 小結
本文所討論的是數據湖的解決方案，不會涉及到任何雲廠商的單個產品。我們從數據接入、數據存儲、數據計算、數據管理、應用生態幾個方面，簡單做了一個類似下表的總結。
出於篇幅關係，其實知名雲廠商的數據湖解決方案還有谷歌和騰訊的。這兩家從其官方網站上看，數據湖解決方案相對來講比較簡單，也僅僅是一些概念上的闡述，推薦的落地方案是“oss+hadoop（EMR）”。其實數據湖不應該從一個簡單的技術平臺視角來看，實現數據湖的方式也多種多樣，評價一個數據湖解決方案是否成熟，關鍵應該看其提供的數據管理能力，具體包括但不限於元數據、數據資產目錄、數據源、數據處理任務、數據生命週期、數據治理、權限管理等；以及與外圍生態的對接打通能力。
五、典型的數據湖應用案例
5.1 廣告數據分析
近年來，流量獲取的成本就越來越高，線上渠道獲客成本的成倍增長讓各行各業都面臨着嚴峻的挑戰。在互聯網廣告成本不斷攀升的大背景下，以花錢買流量拉新爲主要的經營策略必然行不通了。流量前端的優化已成強弩之末，利用數據工具提高流量到站後的目標轉化，精細化運營廣告投放的各個環節，纔是改變現狀更爲直接有效的方式。說到底，要提高廣告流量的轉化率，必須依靠大數據分析。
爲了能夠提供更多的決策支撐依據，需要採取更多的埋點數據的收集和分析，包括但不限於渠道、投放時間、投放人羣，以點擊率爲數據指標進行數據分析，從而給出更好的、更迅速的方案和建議，實現高效率高產出。因此，面對廣告投放領域多維度、多媒體、多廣告位等結構化、半結構化和非結構化數據採集、存儲、分析和決策建議等要求，數據湖分析產品解決方案在廣告主或者發佈商進行新一代技術選型中上受到了很熱烈的青睞。
DG是一家全球領先的企業國際化智能營銷服務商，基於先進的廣告技術、大數據和運營能力，爲客戶提供全球高質量用戶獲取及流量變現服務。DG從成立之初就決定以公有云爲基礎來構建其IT基礎設施，最初DG選擇了AWS雲平臺，主要將其廣告數據在S3中以數據湖的形態進行存放，通過Athena進行交互式分析。然而隨着互聯網廣告的飛速發展，廣告行業帶來了幾大挑戰，移動廣告的發佈與追蹤系統必須解決幾個關鍵問題：
1） 併發性與峯值問題。在廣告行業，流量高峯時常出現，瞬間的點擊量可能達到數萬，甚至數十萬，這就要求系統具備非常好的可擴展性以快速響應和處理每一次點擊
2） 如何實現對海量數據的實時分析。爲了監控廣告投放效果，系統需要實時對用戶的每一次點擊和激活數據進行分析，同時把相關數據傳輸到下游的媒體；
3） 平臺的數據量在急劇增長，每天的業務日誌數據在持續的產生和上傳，曝光、點擊、推送的數據在持續處理，每天新增的數據量已經在10-50TB左右，對整個數據處理系統提出了更高的要求。如何高效地完成對廣告數據的離線/近實時統計，按照廣告客戶的維度要求進行聚合分析。
針對上述三點業務挑戰，同時DG這個客戶日增量數據正在急劇變大（當前日數據掃描量達到100+TB），繼續在AWS平臺使用遇到Athena讀取S3數據帶寬瓶頸、數據分析滯後時間越來越長、爲應對數據和分析需求增長而急劇攀升的投入成本等，經過認真、仔細的測試和分析，最終決定從AWS雲平臺全量搬站到阿里雲平臺，新架構圖如下：
圖16. 改造後的廣告數據湖方案架構
從AWS搬站到阿里雲後，我們爲該客戶設計了“利用Data Lake Analytics + OSS”極致分析能力來應對業務波峯波谷。一方面輕鬆應對來自品牌客戶的臨時分析。另一方面利用Data Lake Analytics的強大計算能力，分析按月、季度廣告投放，精確計算出一個品牌下面會有多少個活動，每個活動分媒體，分市場，分頻道，分DMP的投放效果，進一步增強了加和智能流量平臺爲品牌營銷帶來的銷售轉化率。並且在廣告投放與分析的總擁有成本上，Data Lake Analytics提供的Serverless的彈性服務爲按需收費，不需要購買固定的資源，完全契合業務潮汐帶來的資源波動，滿足彈性的分析需求，同時極大地降低了運維成本和使用成本。
圖17 數據湖部署示意圖
總體上，DG從AWS切換到阿里雲後，極大地節省了硬件成本、人力成本和開發成本。由於採用DLA serverless雲服務，DG無需先期投入大量的資金去購買服務器、存儲等硬件設備，也無需一次性購買大量的雲服務，其基礎設施的規模完全是按需擴展：需求高的時候增加服務數量，需求減少的時候減少服務數量，提高了資金的利用率。使用阿里雲平臺帶來的第二個顯著好處是性能的提升。在DG業務的快速增長期以及後續多條業務線接入期，DG在移動廣告系統的訪問量經常呈爆發式增長，然而原先AWS方案和平臺在Athena讀取S3數據遇到數據讀取帶寬的極大瓶頸，數據分析的時間變得越來越長，阿里雲DLA聯合OSS團隊等進行了極大的優化和改造，同時，DLA數據庫分析在計算引擎上（與TPC-DS打榜世界第一的AnalyticDB共享計算引擎）比Presto原生計算引擎的能力提升數十倍性能，也極大的爲DG提升了分析性能。
5.2 遊戲運營分析
數據湖是一類TCO表現極其優秀的大數據基礎設施。對於很多快速增長的遊戲公司而言，一個爆款遊戲，往往在短期內相關數據增長極快；同時，公司的研發人員的技術棧很難在短期內與數據的增量和增速進行匹配；此時，呈爆發增長的數據很難被有效利用。數據湖是一個解決此類問題的技術選擇。
YJ是一家高速成長的遊戲公司，公司希望能依託相關用戶行爲數據進行深入分析，指導遊戲的開發和運營。數據分析背後的核心邏輯在於隨着遊戲行業市場競爭局面的擴大，玩家對於品質的要求越來越高，遊戲項目的生命週期越來越短，直接影響項目的投入產出比，通過數據運營則可以有效的延長項目的生命週期，對各個階段的業務走向進行精準把控。而隨着流量成本的日益上升，如何構建經濟、高效的精細化數據運營體系，以更好的支撐業務發展，也變得愈發重要起來。數據運營體系就需要有其配套的基礎支撐設施，如何選擇這類基礎支撐設施，是公司技術決策者需要思考的問題。思考的出發點包括：
1） 要有足夠的彈性。對於遊戲而言，往往就是短時間爆發，數據量激增；因此，能否適應數據的爆發性增長，滿足彈性需求是一個重點考量的點；無論是計算還是存儲，都需要具備足夠的彈性。
2） 要有足夠的性價比。對於用戶行爲數據，往往需要拉到一個很長的週期去分析去對比，比如留存率，不少情況下需要考慮90天甚至180天客戶的留存率；因此，如何以最具性價比的方式長期存儲海量數據是需要重點考慮的問題。
3） 要有夠用的分析能力，且具備可擴展性。許多情況下，用戶行爲體現在埋點數據中，埋點數據又需要與用戶註冊信息、登陸信息、賬單等結構化數據關聯分析；因此，在數據分析上，至少需要有大數據的ETL能力、異構數據源的接入能力和複雜分析的建模能力。
4） 要與公司現有技術棧相匹配，且後續利於招聘。對於YJ，其在技術選型的時候一個重要點就是其技術人員的技術棧，YJ的技術團隊大部分只熟悉傳統的數據庫開發，即MySQL；並且人手緊張，做數據運營分析的技術人員只有1個，短時間內根本沒有能力獨立構建大數據分析的基礎設施。從YJ的角度出發，最好絕大多數分析能夠通過SQL完成；並且在招聘市場上，SQL開發人員的數量也遠高於大數據開發工程師的數量。針對客戶的情況，我們幫助客戶對現有方案做了改造。
圖18. 改造前的方案
改造前，客戶所有的結構化數據都在一個高規格的MySQL裏面；而玩家行爲數據則是通過LogTail採集至日誌服務（SLS）中，然後從日誌服務中分別投遞到OSS和ES裏。這個架構的問題在於：1）行爲數據和結構化數據完全割裂，無法聯動分析；2）對於行爲數據智能提供檢索功能，無法做深層次的挖掘分析；3）OSS僅僅作爲數據存儲資源使用，並沒有挖掘出足夠的數據價值。
事實上，我們分析客戶現存架構其實已經具備了數據湖的雛形：全量數據已經在OSS中保存下來了，現在需要進一步補齊客戶對於OSS中的數據的分析能力。而且數據湖基於SQL的數據處理模式也滿足客戶對於開發技術棧的需求。綜上，我們對客戶的架構做了如下調整，幫助客戶構建了數據湖。
圖19. 改造後的數據湖解決方案
總體上，我們沒有改變客戶的數據鏈路流轉，只是在OSS的基礎上，增加了DLA組件，對OSS的數據進行二次加工處理。DLA提供了標準SQL計算引擎，同時支持接入各類異構數據源。基於DLA對OSS的數據進行處理後，生成業務直接可用的數據。但是DLA的問題在於無法支撐低延遲需求的交互式分析場景，爲了解決這個問題，我們引入了雲原生數據倉庫ADB來解決交互式分析的延遲性問題；同時，在最前端引入QuickBI作爲客戶的可視化分析工具。YJ方案是圖14所示的湖倉一體化解決方案在遊戲行業的一個經典落地案例。
YM是一家數據智能服務提供商，面向各類中小商家提供一系列數據分析運營服務。具體實現的技術邏輯如下圖所示。
圖20. YM智能數據服務SaaS模式示意
平臺方提供多端SDK供用戶（商家提供網頁、APP、小程序等多種接入形式）接入各類埋點數據，平臺方以SaaS的形式提供統一的數據接入服務和數據分析服務。商家通過訪問各類數據分析服務來進行更細粒度的埋點數據分析，完成行爲統計、客戶畫像、客戶圈選、廣告投放監測等基本分析功能。然而，這種SaaS模式下，會存在一定的問題：
1） 由於商家類型和需求的多樣化，平臺提供SaaS類分析功能很難覆蓋所有類型的商家，無法滿足商家的定製化需求；如有些商家關注銷量，有些關注客戶運營，有些關注成本優化，很難滿足所有的需求。
2） 對於一些高級分析功能，如依賴於自定義標籤的客戶圈選、客戶自定義擴展等功能，統一的數據分析服務無法滿足的；特別是一些自定義的標籤依賴於商家自定義的算法，無法滿足客戶的高級分析需求。
3） 數據的資產化管理需求。在大數據時代，數據是一個企業/組織的資產已經成爲了大家的共識，如何能讓屬於商家的數據合理、長期的沉澱下來，也是SaaS服務需要考慮的事情。
綜上，我們在上圖的基本模式上引入了數據湖模式，讓數據湖作爲商家沉澱數據、產出模型、分析運營的基礎支撐設施。引入數據湖後的SaaS數據智能服務模式如下。
圖21. 基於數據湖的數據智能服務
如圖21所示，平臺方爲每個用戶提供一鍵建湖服務，商家使用該功能構建自己的數據湖，“一鍵建湖”能力一方面幫助商家將所有埋點數據的數據模型（schema）同步至數據湖中；另一方面，將屬於該商家的所有埋點數據全量同步至數據湖中，並基於“T+1”的模式，將每天的增量數據歸檔入湖。基於數據湖的服務模式在傳統的數據分析服務的基礎上，賦予了用戶數據資產化、分析模型化和服務定製化三大能力：
1） 數據資產化能力。利用數據湖，商家可以將屬於自己的數據持續沉澱下來，保存多長時間的數據，耗費多少成本，完全由商家自主決定。數據湖還提供了數據資產管理能力，商家除了能管理原始數據外，還能將處理過的過程數據和結果數據分門別類保存，極大的提升了埋點數據的價值。
2） 分析模型化能力。數據湖中不僅僅有原始數據，還有埋點數據的模型（schema）。埋點數據模型體現了全域數據智能服務平臺對於業務邏輯的抽象，通過數據湖，除了將原始數據作爲資產輸出外，還將數據模型進行了輸出，藉助埋點數據模型，商家可以更深入的理解埋點數據背後所體現的用戶行爲邏輯，幫助商家更好的洞察客戶行爲，獲取用戶需求。
3） 服務定製化能力。藉助數據湖提供的數據集成和數據開發能力，基於對埋點數據模型的理解，商家可以定製數據處理過程，不斷對原始數據進行迭代加工，從數據中提煉有價值的信息，最終獲得超越原有數據分析服務的價值。
六、數據湖建設的基本過程
個人認爲數據湖是比傳統大數據平臺更爲完善的大數據處理基礎支撐設施，完善在數據湖是更貼近客戶業務的技術存在。所有數據湖所包括的、且超出大數據平臺存在的特性，例如元數據、數據資產目錄、權限管理、數據生命週期管理、數據集成和數據開發、數據治理和質量管理等，無一不是爲了更好的貼近業務，更好的方便客戶使用。數據湖所強調的一些基本的技術特性，例如彈性、存儲計算獨立擴展、統一的存儲引擎、多模式計算引擎等等，也是爲了滿足業務需求，並且給業務方提供最具性價比的TCO。
數據湖的建設過程應該與業務緊密結合；但是數據湖的建設過程與傳統的數據倉庫，甚至是大熱的數據中臺應該是有所區別的。區別在於，數據湖應該以一種更敏捷的方式去構建，“邊建邊用，邊用邊治理”。爲了更好的理解數據湖建設的敏捷性，我們先來看一下傳統數倉的構建過程。業界對於傳統數倉的構建提出了“自下而上”和“自頂而下”兩種模式，分別由Inmon和KimBall兩位大牛提出。具體的過程就不詳述了，不然可以再寫出幾百頁，這裏只簡單闡述基本思想。
1）Inmon提出自下而上（EDW-DM）的數據倉庫建設模式，即操作型或事務型系統的數據源，通過ETL抽取轉換和加載到數據倉庫的ODS層；ODS層中的數據，根據預先設計好的EDW（企業級數據倉庫）範式進行加工處理，然後進入到EDW。EDW一般是企業/組織的通用數據模型，不方便上層應用直接做數據分析；因此，各個業務部門會再次根據自己的需要，從EDW中處理出數據集市層（DM）。
優勢：易於維護，高度集成；劣勢：結構一旦確定，靈活性不足，且爲了適應業務，部署週期較長。此類方式構造的數倉，適合於比較成熟穩定的業務，例如金融。
2）KimBall提出自頂而下（DM-DW）的數據架構，通過將操作型或事務型系統的數據源，抽取或加載到ODS層；然後通過ODS的數據，利用維度建模方法建設多維主題數據集市（DM）。各個DM，通過一致性的維度聯繫在一起，最終形成企業/組織通用的數據倉庫。
優勢：構建迅速，最快的看到投資回報率，敏捷靈活；劣勢：作爲企業資源不太好維護，結構複雜，數據集市集成困難。常應用於中小企業或互聯網行業。
其實上述只是一個理論上的過程，其實無論是先構造EDW，還是先構造DM，都離不開對於數據的摸底，以及在數倉構建之前的數據模型的設計，包括當前大熱的“數據中臺”，都逃不出下圖所示的基本建設過程。
圖22. 數據倉庫/數據中臺建設基本流程
1） 數據摸底。對於一個企業/組織而言，在構建數據湖初始工作就是對自己企業/組織內部的數據做一個全面的摸底和調研，包括數據來源、數據類型、數據形態、數據模式、數據總量、數據增量等。在這個階段一個隱含的重要工作是藉助數據摸底工作，進一步梳理企業的組織結構，明確數據和組織結構之間關係。爲後續明確數據湖的用戶角色、權限設計、服務方式奠定基礎。
2） 模型抽象。針對企業/組織的業務特點梳理歸類各類數據，對數據進行領域劃分，形成數據管理的元數據，同時基於元數據，構建通用的數據模型。
3） 數據接入。根據第一步的摸排結果，確定要接入的數據源。根據數據源，確定所必須的數據接入技術能力，完成數據接入技術選型，接入的數據至少包括：數據源元數據、原始數據元數據、原始數據。各類數據按照第二步形成的結果，分類存放。
4） 融合治理。簡單來說就是利用數據湖提供的各類計算引擎對數據進行加工處理，形成各類中間數據/結果數據，並妥善管理保存。數據湖應該具備完善的數據開發、任務管理、任務調度的能力，詳細記錄數據的處理過程。在治理的過程中，會需要更多的數據模型和指標模型。
5） 業務支撐。在通用模型基礎上，各個業務部門定製自己的細化數據模型、數據使用流程、數據訪問服務。
上述過程，對於一個快速成長的互聯網企業來說，太重了，很多情況下是無法落地的，最現實的問題就是第二步模型抽象，很多情況下，業務是在試錯、在探索，根本不清楚未來的方向在哪裏，也就根本不可能提煉出通用的數據模型；沒有數據模型，後面的一切操作也就無從談起，這也是很多高速成長的企業覺得數據倉庫/數據中臺無法落地、無法滿足需求的重要原因之一。
數據湖應該是一種更爲“敏捷”的構建方式，我們建議採用如下步驟來構建數據湖。
圖23. 數據湖建設基本流程
對比圖22，依然是五步，但是這五步是一個全面的簡化和“可落地”的改進。
1） 數據摸底。依然需要摸清楚數據的基本情況，包括數據來源、數據類型、數據形態、數據模式、數據總量、數據增量。但是，也就需要做這麼多了。數據湖是對原始數據做全量保存，因此無需事先進行深層次的設計。
2） 技術選型。根據數據摸底的情況，確定數據湖建設的技術選型。事實上，這一步也非常的簡單，因爲關於數據湖的技術選型，業界有很多的通行的做法，基本原則個人建議有三個：“計算與存儲分離”、“彈性”、“獨立擴展”。建議的存儲選型是分佈式對象存儲系統（如S3/OSS/OBS）；計算引擎上建議重點考慮批處理需求和SQL處理能力，因爲在實踐中，這兩類能力是數據處理的關鍵，關於流計算引擎後面會再討論一下。無論是計算還是存儲，建議優先考慮serverless的形式；後續可以在應用中逐步演進，真的需要獨立資源池了，再考慮構建專屬集羣。
3） 數據接入。確定要接入的數據源，完成數據的全量抽取與增量接入。
4） 應用治理。這一步是數據湖的關鍵，我個人把“融合治理”改成了“應用治理”。從數據湖的角度來看，數據應用和數據治理應該是相互融合、密不可分的。從數據應用入手，在應用中明確需求，在數據ETL的過程中，逐步形成業務可使用的數據；同時形成數據模型、指標體系和對應的質量標準。數據湖強調對原始數據的存儲，強調對數據的探索式分析與應用，但這絕對不是說數據湖不需要數據模型；恰恰相反，對業務的理解與抽象，將極大的推動數據湖的發展與應用，數據湖技術使得數據的處理與建模，保留了極大的敏捷性，能快速適應業務的發展與變化。
從技術視角來看，數據湖不同於大數據平臺還在於數據湖爲了支撐數據的全生命週期管理與應用，需要具備相對完善的數據管理、類目管理、流程編排、任務調度、數據溯源、數據治理、質量管理、權限管理等能力。在計算能力上，目前主流的數據湖方案都支持SQL和可編程的批處理兩種模式（對機器學習的支持，可以採用Spark或者Flink的內置能力）；在處理範式上，幾乎都採用基於有向無環圖的工作流的模式，並提供了對應的集成開發環境。對於流式計算的支持，目前各個數據湖解決方案採取了不同的方式。在討論具體的方式之前，我們先對流計算做一個分類：
1） 模式一：實時模式。這種流計算模式相當於對數據採用“來一條處理一條”/“微批”的方式進行處理；多見於在線業務，如風控、推薦、預警等。
2） 模式二：類流式。這種模式需要獲取指定時間點之後變化的數據/讀取某一個版本的數據/讀取當前的最新數據等，是一種類流式的模式；多見於數據探索類應用，如分析某一時間段內的日活、留存、轉化等。
二者的本質不同在於，模式一處理數據時，數據往往還沒有存儲到數據湖中，僅僅是在網路/內存中流動；模式二處理數據時，數據已經存儲到數據湖中了。綜上，我個人建議採用如下圖模式：
圖24 數據湖數據流向示意圖
如圖24所示，在需要數據湖具備模式一的處理能力時，還是應該引入類Kafka中間件，作爲數據轉發的基礎設施。完整的數據湖解決方案方案應該提供將原始數據導流至Kafka的能力。流式引擎具備從類Kafka組件中讀取數據的能力。流式計算引擎在處理數據過後，根據需要，可以將結果寫入OSS/RDBMS/NoSQL/DW，供應用訪問。某種意義上，模式一的流計算引擎並非一定要作爲數據湖不可分割的一部分存在，只需要在應用需要時，能夠方便的引入即可。但是，這裏需要指出的是：
1）流式引擎依然需要能夠很方便的讀取數據湖的元數據；
2）流式引擎任務也需要統一的納入數據湖的任務管理；
3）流式處理任務依然需要納入到統一的權限管理中。
對於模式二，本質上更接近於批處理。現在許多經典的大數據組件已經提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等經典的計算引擎。以HUDI爲例，通過支持特殊類型的表（COW/MOR），提供訪問快照數據（指定版本）、增量數據、準實時數據的能力。目前AWS、騰訊等已經將HUDI集成到了其EMR服務中，阿里雲的DLA也正在計劃推出DLA on HUDI的能力。
讓我們再回到本文開頭的第一章，我們說過，數據湖的主要用戶是數據科學家和數據分析師，探索式分析和機器學習是這類人羣的常見操作；流式計算（實時模式）多用於在線業務，嚴格來看，並非數據湖目標用戶的剛需。但是，流式計算（實時模式）是目前大多數互聯網公司在線業務的重要組成部分，而數據湖作爲企業/組織內部的數據集中存放地，需要在架構上保持一定的擴展能力，可以很方便的進行擴展，整合流式計算能力。
5） 業務支撐。雖然大多數數據湖解決方案都對外提供標準的訪問接口，如JDBC，市面上流行的各類BI報表工具、大屏工具也都可以直接訪問數據湖中的數據。但是在實際的應用中，我們還是建議將數據湖處理好的數據推送到對應的各類支持在線業務的數據引擎中去，能夠讓應用有更好的體驗。
七、總結
數據湖作爲新一代大數據分析處理的基礎設施，需要超越傳統的大數據平臺。個人認爲目前在以下方面，是數據湖解決方案未來可能的發展方向。
1） 雲原生架構。關於什麼是雲原生架構，衆說紛紜，很難找到統一的定義。但是具體到數據湖這個場景，個人認爲就是以下三點特徵：（1）存儲和計算分離，計算能力和存儲能力均可獨立擴展；（2）多模態計算引擎支持，SQL、批處理、流式計算、機器學習等；（3）提供serverless態服務，確保足夠的彈性以及支持按需付費。
2） 足夠用的數據管理能力。數據湖需要提供更爲強大的數據管理能力，包括但不限於數據源管理、數據類目管理、處理流程編排、任務調度、數據溯源、數據治理、質量管理、權限管理等。
3） 大數據的能力，數據庫的體驗。目前絕大多數數據分析人員都只有數據庫的使用經驗，大數據平臺的能力雖強，但是對於用戶來說並不友好，數據科學家和數據數據分析師應該關注數據、算法、模型及其與業務場景的適配，而不是花大量的時間精力去學習大數據平臺的開發。數據湖要想快速發展，如何爲用戶提供良好的使用體驗是關鍵。基於SQL的數據庫應用開發已經深入人心，如何將數據湖的能力通過SQL的形式釋放出來，是未來的一個主要方向。
4） 完善的數據集成與數據開發能力。對各種異構數據源的管理與支持，對異構數據的全量/增量遷移支持，對各種數據格式的支持都是需要不斷完善的方向。同時，需要具備一個完備的、可視化的、可擴展的集成開發環境。
5） 與業務的深度融合與集成。典型數據湖架構的構成基本已經成爲了業界共識：分佈式對象存儲+多模態計算引擎+數據管理。決定數據湖方案是否勝出的關鍵恰恰在於數據管理，無論是原始數據的管理、數據類目的管理、數據模型的管理、數據權限的管理還是處理任務的管理，都離不開與業務的適配和集成；未來，會有越來越多的行業數據湖解決方案湧現出來，與數據科學家和數據分析師形成良性發展與互動。如何在數據湖解決方案中預置行業數據模型、ETL流程、分析模型和定製算法，可能是未來數據湖領域差異化競爭的一個關鍵點。
本文來自阿里雲社區，點擊閱讀原文查看！
往期推薦
▬
官宣！ASF官方正式宣佈Apache Hudi成爲頂級項目
基於 Hadoop 的58同城離線計算平臺設計與實踐
認識 Delta Lake：讓數倉進化到數據湖
乾貨 | Kafka 內核知識梳理，附思維導圖
