寫在前面：
最近，資料湖的概念非常熱，許多前線的同學都在讨論資料湖應該怎麼建？阿裡雲有沒有成熟的資料湖解決方案？阿裡雲的資料湖解決方案到底有沒有實際落地的案例？怎麼了解資料湖？資料湖和大資料平台有什麼不同？頭部的雲計算玩家都各自推出了什麼樣的資料湖解決方案？帶着這些問題，我們嘗試寫了這樣一篇文章，希望能抛磚引玉，引起大家一些思考和共鳴。感謝南靖同學為本文編寫了5.1節的案例，感謝西壁的review。
本文包括七個小節：1、什麼是資料湖；2、資料湖的基本特征；3、資料湖基本架構；4、各廠商的資料湖解決方案；5、典型的資料湖應用場景；6、資料湖建設的基本過程；7、總結。受限于個人水準，謬誤在所難免，歡迎同學們一起探讨，批評指正，不吝賜教。
一、什麼是資料湖
資料湖是目前比較熱的一個概念，許多企業都在建構或者計劃建構自己的資料湖。但是在計劃建構資料湖之前，搞清楚什麼是資料湖，明确一個資料湖項目的基本組成，進而設計資料湖的基本架構，對于資料湖的建構至關重要。關于什麼是資料湖，有如下定義。
Wikipedia是這樣定義的：
A data lake is a system or repository of data stored in its natural/raw format,[1] usually object blobs or files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning. A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video). [2]A data swamp is a deteriorated and unmanaged data lake that is either inaccessible to its intended users or is providing little value
資料湖是一類存儲資料自然/原始格式的系統或存儲，通常是對象塊或者檔案。資料湖通常是企業中全量資料的單一存儲。全量資料包括原始系統所産生的原始資料拷貝以及為了各類任務而産生的轉換資料，各類任務包括報表、可視化、進階分析和機器學習。資料湖中包括來自于關系型資料庫中的結構化資料（行和列）、半結構化資料（如CSV、日志、XML、JSON）、非結構化資料（如email、文檔、PDF等）和二進制資料（如圖像、音頻、視訊）。資料沼澤是一種退化的、缺乏管理的資料湖，資料沼澤對于使用者來說要麼是不可通路的要麼就是無法提供足夠的價值。
AWS的定義相對就簡潔一點：
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
資料湖是一個集中式存儲庫，允許您以任意規模存儲所有結構化和非結構化資料。您可以按原樣存儲資料（無需先對資料進行結構化處理），并運作不同類型的分析 – 從控制台和可視化到大資料處理、實時分析和機器學習，以指導做出更好的決策。
微軟的定義就更加模糊了，并沒有明确給出什麼是Data Lake，而是取巧的将資料湖的功能作為定義：
Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics. Azure Data Lake works with existing IT investments for identity, management, and security for simplified data management and governance. It also integrates seamlessly with operational stores and data warehouses so you can extend current data applications. We’ve drawn on the experience of working with enterprise customers and running some of the largest scale processing and analytics in the world for Microsoft businesses like Office 365, Xbox Live, Azure, Windows, Bing, and Skype. Azure Data Lake solves many of the productivity and scalability challenges that prevent you from maximizing the value of your data assets with a service that’s ready to meet your current and future business needs.
Azure的資料湖包括一切使得開發者、資料科學家、分析師能更簡單的存儲、處理資料的能力，這些能力使得使用者可以存儲任意規模、任意類型、任意産生速度的資料，并且可以跨平台、跨語言的做所有類型的分析和處理。資料湖在能幫助使用者加速應用資料的同時，消除了資料采集和存儲的複雜性，同時也能支援批處理、流式計算、互動式分析等。資料湖能同現有的資料管理和治理的IT投資一起工作，保證資料的一緻、可管理和安全。它也能同現有的業務資料庫和資料倉庫無縫內建，幫助擴充現有的資料應用。Azure資料湖吸取了大量企業級使用者的經驗，并且在微軟一些業務中支援了大規模處理和分析場景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解決了許多效率和可擴充性的挑戰，作為一類服務使得使用者可以最大化資料資産的價值來滿足目前和未來需求。
關于資料湖的定義其實很多，但是基本上都圍繞着以下幾個特性展開。
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）叫“湖”的另一個重要原因是資料湖是需要精細治理的，一個缺乏管控、缺乏治理的資料湖最終會退化為“資料沼澤”，進而使應用無法有效通路資料，使存于其中的資料失去價值。
大資料基礎架構的演進，其實反應了一點：在企業/組織内部，資料是一類重要資産已經成為了共識；為了更好的利用資料，企業/組織需要對資料資産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流程、分析模型和定制算法，可能是未來資料湖領域差異化競争的一個關鍵點。