寫在前面：
最近，數(shù)據(jù)湖的概念非常熱，許多前線的同學都在討論數(shù)據(jù)湖應(yīng)該怎么建？阿里云有沒有成熟的數(shù)據(jù)湖解決方案？阿里云的數(shù)據(jù)湖解決方案到底有沒有實際落地的案例？怎么理解數(shù)據(jù)湖？數(shù)據(jù)湖和大數(shù)據(jù)平臺有什么不同？頭部的云計算玩家都各自推出了什么樣的數(shù)據(jù)湖解決方案？帶著這些問題，我們嘗試寫了這樣一篇文章，希望能拋磚引玉，引起大家一些思考和共鳴。感謝南靖同學為本文編寫了5.1節(jié)的案例，感謝西壁的review。

本文包括七個小節(jié)：1、什么是數(shù)據(jù)湖；2、數(shù)據(jù)湖的基本特征；3、數(shù)據(jù)湖基本架構(gòu)；4、各廠商的數(shù)據(jù)湖解決方案；5、典型的數(shù)據(jù)湖應(yīng)用場景；6、數(shù)據(jù)湖建設(shè)的基本過程；7、總結(jié)。受限于個人水平，謬誤在所難免，歡迎同學們一起探討，批評指正，不吝賜教。

一、什么是數(shù)據(jù)湖

數(shù)據(jù)湖是目前比較熱的一個概念，許多企業(yè)都在構(gòu)建或者計劃構(gòu)建自己的數(shù)據(jù)湖。但是在計劃構(gòu)建數(shù)據(jù)湖之前，搞清楚什么是數(shù)據(jù)湖，明確一個數(shù)據(jù)湖項目的基本組成，進而設(shè)計數(shù)據(jù)湖的基本架構(gòu)，對于數(shù)據(jù)湖的構(gòu)建至關(guān)重要。關(guān)于什么是數(shù)據(jù)湖，有如下定義。

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

數(shù)據(jù)湖是一類存儲數(shù)據(jù)自然/原始格式的系統(tǒng)或存儲，通常是對象塊或者文件。數(shù)據(jù)湖通常是企業(yè)中全量數(shù)據(jù)的單一存儲。全量數(shù)據(jù)包括原始系統(tǒng)所產(chǎn)生的原始數(shù)據(jù)拷貝以及為了各類任務(wù)而產(chǎn)生的轉(zhuǎn)換數(shù)據(jù)，各類任務(wù)包括報表、可視化、高級分析和機器學習。數(shù)據(jù)湖中包括來自于關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)（行和列）、半結(jié)構(gòu)化數(shù)據(jù)（如CSV、日志、XML、JSON）、非結(jié)構(gòu)化數(shù)據(jù)（如email、文檔、PDF等）和二進制數(shù)據(jù)（如圖像、音頻、視頻）。數(shù)據(jù)沼澤是一種退化的、缺乏管理的數(shù)據(jù)湖，數(shù)據(jù)沼澤對于用戶來說要么是不可訪問的要么就是無法提供足夠的價值。

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.

數(shù)據(jù)湖是一個集中式存儲庫，允許您以任意規(guī)模存儲所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。您可以按原樣存儲數(shù)據(jù)（無需先對數(shù)據(jù)進行結(jié)構(gòu)化處理），并運行不同類型的分析 – 從控制面板和可視化到大數(shù)據(jù)處理、實時分析和機器學習，以指導做出更好的決策。

微軟的定義就更加模糊了，并沒有明確給出什么是Data Lake，而是取巧的將數(shù)據(jù)湖的功能作為定義：

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的數(shù)據(jù)湖包括一切使得開發(fā)者、數(shù)據(jù)科學家、分析師能更簡單的存儲、處理數(shù)據(jù)的能力，這些能力使得用戶可以存儲任意規(guī)模、任意類型、任意產(chǎn)生速度的數(shù)據(jù)，并且可以跨平臺、跨語言的做所有類型的分析和處理。數(shù)據(jù)湖在能幫助用戶加速應(yīng)用數(shù)據(jù)的同時，消除了數(shù)據(jù)采集和存儲的復雜性，同時也能支持批處理、流式計算、交互式分析等。數(shù)據(jù)湖能同現(xiàn)有的數(shù)據(jù)管理和治理的IT投資一起工作，保證數(shù)據(jù)的一致、可管理和安全。它也能同現(xiàn)有的業(yè)務(wù)數(shù)據(jù)庫和數(shù)據(jù)倉庫無縫集成，幫助擴展現(xiàn)有的數(shù)據(jù)應(yīng)用。Azure數(shù)據(jù)湖吸取了大量企業(yè)級用戶的經(jīng)驗，并且在微軟一些業(yè)務(wù)中支持了大規(guī)模處理和分析場景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解決了許多效率和可擴展性的挑戰(zhàn)，作為一類服務(wù)使得用戶可以最大化數(shù)據(jù)資產(chǎn)的價值來滿足當前和未來需求。
關(guān)于數(shù)據(jù)湖的定義其實很多，但是基本上都圍繞著以下幾個特性展開。

1、 數(shù)據(jù)湖需要提供足夠用的數(shù)據(jù)存儲能力，這個存儲保存了一個企業(yè)/組織中的所有數(shù)據(jù)。

2、 數(shù)據(jù)湖可以存儲海量的任意類型的數(shù)據(jù)，包括結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

3、 數(shù)據(jù)湖中的數(shù)據(jù)是原始數(shù)據(jù)，是業(yè)務(wù)數(shù)據(jù)的完整副本。數(shù)據(jù)湖中的數(shù)據(jù)保持了他們在業(yè)務(wù)系統(tǒng)中原來的樣子。

4、 數(shù)據(jù)湖需要具備完善的數(shù)據(jù)管理能力（完善的元數(shù)據(jù)），可以管理各類數(shù)據(jù)相關(guān)的要素，包括數(shù)據(jù)源、數(shù)據(jù)格式、連接信息、數(shù)據(jù)schema、權(quán)限管理等。

5、 數(shù)據(jù)湖需要具備多樣化的分析能力，包括但不限于批處理、流式計算、交互式分析以及機器學習；同時，還需要提供一定的任務(wù)調(diào)度和管理能力。

6、 數(shù)據(jù)湖需要具備完善的數(shù)據(jù)生命周期管理能力。不光需要存儲原始數(shù)據(jù)，還需要能夠保存各類分析處理的中間結(jié)果，并完整的記錄數(shù)據(jù)的分析處理過程，能幫助用戶完整詳細追溯任意一條數(shù)據(jù)的產(chǎn)生過程。

7、 數(shù)據(jù)湖需要具備完善的數(shù)據(jù)獲取和數(shù)據(jù)發(fā)布能力。數(shù)據(jù)湖需要能支撐各種各樣的數(shù)據(jù)源，并能從相關(guān)的數(shù)據(jù)源中獲取全量/增量數(shù)據(jù)；然后規(guī)范存儲。數(shù)據(jù)湖能將數(shù)據(jù)分析處理的結(jié)果推送到合適的存儲引擎中，滿足不同的應(yīng)用訪問需求。

8、 對于大數(shù)據(jù)的支持，包括超大規(guī)模存儲以及可擴展的大規(guī)模數(shù)據(jù)處理能力。

綜上，個人認為數(shù)據(jù)湖應(yīng)該是一種不斷演進中、可擴展的大數(shù)據(jù)存儲、處理、分析的基礎(chǔ)設(shè)施；以數(shù)據(jù)為導向，實現(xiàn)任意來源、任意速度、任意規(guī)模、任意類型數(shù)據(jù)的全量獲取、全量存儲、多模式處理與全生命周期管理；并通過與各類外部異構(gòu)數(shù)據(jù)源的交互集成，支持各類企業(yè)級應(yīng)用。

圖1. 數(shù)據(jù)湖基本能力示意

這里需要再特別指出兩點：1）可擴展是指規(guī)模的可擴展和能力的可擴展，即數(shù)據(jù)湖不但要能夠隨著數(shù)據(jù)量的增大，提供“足夠”的存儲和計算能力；還需要根據(jù)需要不斷提供新的數(shù)據(jù)處理模式，例如可能一開始業(yè)務(wù)只需要批處理能力，但隨著業(yè)務(wù)的發(fā)展，可能需要交互式的即席分析能力；又隨著業(yè)務(wù)的實效性要求不斷提升，可能需要支持實時分析和機器學習等豐富的能力。2）以數(shù)據(jù)為導向，是指數(shù)據(jù)湖對于用戶來說要足夠的簡單、易用，幫助用戶從復雜的IT基礎(chǔ)設(shè)施運維工作中解脫出來，關(guān)注業(yè)務(wù)、關(guān)注模型、關(guān)注算法、關(guān)注數(shù)據(jù)。數(shù)據(jù)湖面向的是數(shù)據(jù)科學家、分析師。目前來看，云原生應(yīng)該是構(gòu)建數(shù)據(jù)湖的一種比較理想的構(gòu)建方式，后面在“數(shù)據(jù)湖基本架構(gòu)”一節(jié)會詳細論述這一觀點。

二、數(shù)據(jù)湖的基本特征

對數(shù)據(jù)湖的概念有了基本的認知之后，我們需要進一步明確數(shù)據(jù)湖需要具備哪些基本特征，特別是與大數(shù)據(jù)平臺或者傳統(tǒng)數(shù)據(jù)倉庫相比，數(shù)據(jù)湖具有哪些特點。在具體分析之前，我們先看一張來自AWS官網(wǎng)的對比表格（表格引自：https://aws.amazon.com/cn/big-data/datalakes-and-analytics/what-is-a-data-lake/）

上表對比了數(shù)據(jù)湖與傳統(tǒng)數(shù)倉的區(qū)別，個人覺得可以從數(shù)據(jù)和計算兩個層面進一步分析數(shù)據(jù)湖應(yīng)該具備哪些特征。在數(shù)據(jù)方面：

1）“保真性”。數(shù)據(jù)湖中對于業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)都會存儲一份“一模一樣”的完整拷貝。與數(shù)據(jù)倉庫不同的地方在于，數(shù)據(jù)湖中必須要保存一份原始數(shù)據(jù)，無論是數(shù)據(jù)格式、數(shù)據(jù)模式、數(shù)據(jù)內(nèi)容都不應(yīng)該被修改。在這方面，數(shù)據(jù)湖強調(diào)的是對于業(yè)務(wù)數(shù)據(jù)“原汁原味”的保存。同時，數(shù)據(jù)湖應(yīng)該能夠存儲任意類型/格式的數(shù)據(jù)。

2）“靈活性”： 上表一個點是 “寫入型schema” v.s.“讀取型schema”，其實本質(zhì)上來講是數(shù)據(jù)schema的設(shè)計發(fā)生在哪個階段的問題。對于任何數(shù)據(jù)應(yīng)用來說，其實schema的設(shè)計都是必不可少的，即使是mongoDB等一些強調(diào)“無模式”的數(shù)據(jù)庫，其最佳實踐里依然建議記錄盡量采用相同/相似的結(jié)構(gòu)。“寫入型schema”背后隱含的邏輯是數(shù)據(jù)在寫入之前，就需要根據(jù)業(yè)務(wù)的訪問方式確定數(shù)據(jù)的schema，然后按照既定schema，完成數(shù)據(jù)導入，帶來的好處是數(shù)據(jù)與業(yè)務(wù)的良好適配；但是這也意味著數(shù)倉的前期擁有成本會比較高，特別是當業(yè)務(wù)模式不清晰、業(yè)務(wù)還處于探索階段時，數(shù)倉的靈活性不夠。

數(shù)據(jù)湖強調(diào)的“讀取型schema”，背后的潛在邏輯則是認為業(yè)務(wù)的不確定性是常態(tài)：我們無法預期業(yè)務(wù)的變化，那么我們就保持一定的靈活性，將設(shè)計去延后，讓整個基礎(chǔ)設(shè)施具備使數(shù)據(jù)“按需”貼合業(yè)務(wù)的能力。因此，個人認為“保真性”和“靈活性”是一脈相承的：既然沒辦法預估業(yè)務(wù)的變化，那么索性保持數(shù)據(jù)最為原始的狀態(tài)，一旦需要時，可以根據(jù)需求對數(shù)據(jù)進行加工處理。因此，數(shù)據(jù)湖更加適合創(chuàng)新型企業(yè)、業(yè)務(wù)高速變化發(fā)展的企業(yè)。同時，數(shù)據(jù)湖的用戶也相應(yīng)的要求更高，數(shù)據(jù)科學家、業(yè)務(wù)分析師（配合一定的可視化工具）是數(shù)據(jù)湖的目標客戶。

3）“可管理”：數(shù)據(jù)湖應(yīng)該提供完善的數(shù)據(jù)管理能力。既然數(shù)據(jù)要求“保真性”和“靈活性”，那么至少數(shù)據(jù)湖中會存在兩類數(shù)據(jù)：原始數(shù)據(jù)和處理后的數(shù)據(jù)。數(shù)據(jù)湖中的數(shù)據(jù)會不斷的積累、演化。因此，對于數(shù)據(jù)管理能力也會要求很高，至少應(yīng)該包含以下數(shù)據(jù)管理能力：數(shù)據(jù)源、數(shù)據(jù)連接、數(shù)據(jù)格式、數(shù)據(jù)schema（庫/表/列/行）。同時，數(shù)據(jù)湖是單個企業(yè)/組織中統(tǒng)一的數(shù)據(jù)存放場所，因此，還需要具有一定的權(quán)限管理能力。

4）“可追溯”：數(shù)據(jù)湖是一個組織/企業(yè)中全量數(shù)據(jù)的存儲場所，需要對數(shù)據(jù)的全生命周期進行管理，包括數(shù)據(jù)的定義、接入、存儲、處理、分析、應(yīng)用的全過程。一個強大的數(shù)據(jù)湖實現(xiàn)，需要能做到對其間的任意一條數(shù)據(jù)的接入、存儲、處理、消費過程是可追溯的，能夠清楚的重現(xiàn)數(shù)據(jù)完整的產(chǎn)生過程和流動過程。

在計算方面，個人認為數(shù)據(jù)湖對于計算能力要求其實非常廣泛，完全取決于業(yè)務(wù)對于計算的要求。

5）豐富的計算引擎。從批處理、流式計算、交互式分析到機器學習，各類計算引擎都屬于數(shù)據(jù)湖應(yīng)該囊括的范疇。一般情況下，數(shù)據(jù)的加載、轉(zhuǎn)換、處理會使用批處理計算引擎；需要實時計算的部分，會使用流式計算引擎；對于一些探索式的分析場景，可能又需要引入交互式分析引擎。隨著大數(shù)據(jù)技術(shù)與人工智能技術(shù)的結(jié)合越來越緊密，各類機器學習/深度學習算法也被不斷引入，例如TensorFlow/PyTorch框架已經(jīng)支持從HDFS/S3/OSS上讀取樣本數(shù)據(jù)進行訓練。因此，對于一個合格的數(shù)據(jù)湖項目而言，計算引擎的可擴展/可插拔，應(yīng)該是一類基礎(chǔ)能力。

6）多模態(tài)的存儲引擎。理論上，數(shù)據(jù)湖本身應(yīng)該內(nèi)置多模態(tài)的存儲引擎，以滿足不同的應(yīng)用對于數(shù)據(jù)訪問需求（綜合考慮響應(yīng)時間/并發(fā)/訪問頻次/成本等因素）。但是，在實際的使用過程中，數(shù)據(jù)湖中的數(shù)據(jù)通常并不會被高頻次的訪問，而且相關(guān)的應(yīng)用也多在進行探索式的數(shù)據(jù)應(yīng)用，為了達到可接受的性價比，數(shù)據(jù)湖建設(shè)通常會選擇相對便宜的存儲引擎（如S3/OSS/HDFS/OBS），并且在需要時與外置存儲引擎協(xié)同工作，滿足多樣化的應(yīng)用需求。

三、數(shù)據(jù)湖基本架構(gòu)

數(shù)據(jù)湖可以認為是新一代的大數(shù)據(jù)基礎(chǔ)設(shè)施。為了更好的理解數(shù)據(jù)湖的基本架構(gòu)，我們先來看看大數(shù)據(jù)基礎(chǔ)設(shè)施架構(gòu)的演進過程。

1） 第一階段：以Hadoop為代表的離線數(shù)據(jù)處理基礎(chǔ)設(shè)施。如下圖所示，Hadoop是以HDFS為核心存儲，以MapReduce（簡稱MR）為基本計算模型的批量數(shù)據(jù)處理基礎(chǔ)設(shè)施。圍繞HDFS和MR，產(chǎn)生了一系列的組件，不斷完善整個大數(shù)據(jù)平臺的數(shù)據(jù)處理能力，例如面向在線KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。同時，隨著大家對于批處理的性能要求越來越高，新的計算模型不斷被提出，產(chǎn)生了Tez、Spark、Presto等計算引擎，MR模型也逐漸進化成DAG模型。DAG模型一方面，增加計算模型的抽象并發(fā)能力：對每一個計算過程進行分解，根據(jù)計算過程中的聚合操作點對任務(wù)進行邏輯切分，任務(wù)被切分成一個個的stage，每個stage都可以有一個或者多個Task組成，Task是可以并發(fā)執(zhí)行的，從而提升整個計算過程的并行能力；另一方面，為減少數(shù)據(jù)處理過程中的中間結(jié)果寫文件操作，Spark、Presto等計算引擎盡量使用計算節(jié)點的內(nèi)存對數(shù)據(jù)進行緩存，從而提高整個數(shù)據(jù)過程的效率和系統(tǒng)吞吐能力。

圖2. Hadoop體系結(jié)構(gòu)示意

2） 第二階段：lambda架構(gòu)。隨著數(shù)據(jù)處理能力和處理需求的不斷變化，越來越多的用戶發(fā)現(xiàn)，批處理模式無論如何提升性能，也無法滿足一些實時性要求高的處理場景，流式計算引擎應(yīng)運而生，例如Storm、Spark Streaming、Flink等。然而，隨著越來越多的應(yīng)用上線，大家發(fā)現(xiàn)，其實批處理和流計算配合使用，才能滿足大部分應(yīng)用需求；而對于用戶而言，其實他們并不關(guān)心底層的計算模型是什么，用戶希望無論是批處理還是流計算，都能基于統(tǒng)一的數(shù)據(jù)模型來返回處理結(jié)果，于是Lambda架構(gòu)被提出，如下圖所示。（為了省事，lambda架構(gòu)和Kappa架構(gòu)圖均來自于網(wǎng)絡(luò)）

圖3. Lambda架構(gòu)示意

Lambda架構(gòu)的核心理念是“流批一體”，如上圖所示，整個數(shù)據(jù)流向自左向右流入平臺。進入平臺后一分為二，一部分走批處理模式，一部分走流式計算模式。無論哪種計算模式，最終的處理結(jié)果都通過服務(wù)層對應(yīng)用提供，確保訪問的一致性。

3） 第三階段：Kappa架構(gòu)。Lambda架構(gòu)解決了應(yīng)用讀取數(shù)據(jù)的一致性問題，但是“流批分離”的處理鏈路增大了研發(fā)的復雜性。因此，有人就提出能不能用一套系統(tǒng)來解決所有問題。目前比較流行的做法就是基于流計算來做。流計算天然的分布式特征，注定了他的擴展性更好。通過加大流計算的并發(fā)性，加大流式數(shù)據(jù)的“時間窗口”，來統(tǒng)一批處理與流式處理兩種計算模式。

圖4. Kappa架構(gòu)示意
綜上，從傳統(tǒng)的hadoop架構(gòu)往lambda架構(gòu)，從lambda架構(gòu)往Kappa架構(gòu)的演進，大數(shù)據(jù)平臺基礎(chǔ)架構(gòu)的演進逐漸囊括了應(yīng)用所需的各類數(shù)據(jù)處理能力，大數(shù)據(jù)平臺逐漸演化成了一個企業(yè)/組織的全量數(shù)據(jù)處理平臺。當前的企業(yè)實踐中，除了關(guān)系型數(shù)據(jù)庫依托于各個獨立的業(yè)務(wù)系統(tǒng)；其余的數(shù)據(jù)，幾乎都被考慮納入大數(shù)據(jù)平臺來進行統(tǒng)一的處理。然而，目前的大數(shù)據(jù)平臺基礎(chǔ)架構(gòu)，都將視角鎖定在了存儲和計算，而忽略了對于數(shù)據(jù)的資產(chǎn)化管理，這恰恰是數(shù)據(jù)湖作為新一代的大數(shù)據(jù)基礎(chǔ)設(shè)施所重點關(guān)注的方向之一。

曾經(jīng)看過一個很有意思的文章，提出過如下問題：數(shù)據(jù)湖為什么叫數(shù)據(jù)湖而不叫數(shù)據(jù)河或者數(shù)據(jù)海？一個有意思的回答是：

1）“河”強調(diào)的是流動性，“海納百川”，河終究是要流入大海的，而企業(yè)級數(shù)據(jù)是需要長期沉淀的，因此叫“湖”比叫“河”要貼切；同時，湖水天然是分層的，滿足不同的生態(tài)系統(tǒng)要求，這與企業(yè)建設(shè)統(tǒng)一數(shù)據(jù)中心，存放管理數(shù)據(jù)的需求是一致的，“熱”數(shù)據(jù)在上層，方便應(yīng)用隨時使用；溫數(shù)據(jù)、冷數(shù)據(jù)位于數(shù)據(jù)中心不同的存儲介質(zhì)中，達到數(shù)據(jù)存儲容量與成本的平衡。

2）不叫“海”的原因在于，海是無邊無界的，而“湖”是有邊界的，這個邊界就是企業(yè)/組織的業(yè)務(wù)邊界；因此數(shù)據(jù)湖需要更多的數(shù)據(jù)管理和權(quán)限管理能力。

3）叫“湖”的另一個重要原因是數(shù)據(jù)湖是需要精細治理的，一個缺乏管控、缺乏治理的數(shù)據(jù)湖最終會退化為“數(shù)據(jù)沼澤”，從而使應(yīng)用無法有效訪問數(shù)據(jù)，使存于其中的數(shù)據(jù)失去價值。

大數(shù)據(jù)基礎(chǔ)架構(gòu)的演進，其實反應(yīng)了一點：在企業(yè)/組織內(nèi)部，數(shù)據(jù)是一類重要資產(chǎn)已經(jīng)成為了共識；為了更好的利用數(shù)據(jù)，企業(yè)/組織需要對數(shù)據(jù)資產(chǎn)1）進行長期的原樣存儲；2）進行有效管理與集中治理；3）提供多模式的計算能力滿足處理需求；4）以及面向業(yè)務(wù)，提供統(tǒng)一的數(shù)據(jù)視圖、數(shù)據(jù)模型與數(shù)據(jù)處理結(jié)果。數(shù)據(jù)湖就是在這個大背景下產(chǎn)生的，除了大數(shù)據(jù)平臺所擁有的各類基礎(chǔ)能力之外，數(shù)據(jù)湖更強調(diào)對于數(shù)據(jù)的管理、治理和資產(chǎn)化能力。落到具體的實現(xiàn)上，數(shù)據(jù)湖需要包括一系列的數(shù)據(jù)管理組件，包括：1）數(shù)據(jù)接入；2）數(shù)據(jù)搬遷；3）數(shù)據(jù)治理；4）質(zhì)量管理；5）資產(chǎn)目錄；6）訪問控制；7）任務(wù)管理；8）任務(wù)編排；9）元數(shù)據(jù)管理等。如下圖所示，給出了一個數(shù)據(jù)湖系統(tǒng)的參考架構(gòu)。對于一個典型的數(shù)據(jù)湖而言，它與大數(shù)據(jù)平臺相同的地方在于它也具備處理超大規(guī)模數(shù)據(jù)所需的存儲和計算能力，能提供多模式的數(shù)據(jù)處理能力；增強點在于數(shù)據(jù)湖提供了更為完善的數(shù)據(jù)管理能力，具體體現(xiàn)在：

1） 更強大的數(shù)據(jù)接入能力。數(shù)據(jù)接入能力體現(xiàn)在對于各類外部異構(gòu)數(shù)據(jù)源的定義管理能力，以及對于外部數(shù)據(jù)源相關(guān)數(shù)據(jù)的抽取遷移能力，抽取遷移的數(shù)據(jù)包括外部數(shù)據(jù)源的元數(shù)據(jù)與實際存儲的數(shù)據(jù)。

2） 更強大的數(shù)據(jù)管理能力。管理能力具體又可分為基本管理能力和擴展管理能力。基本管理能力包括對各類元數(shù)據(jù)的管理、數(shù)據(jù)訪問控制、數(shù)據(jù)資產(chǎn)管理，是一個數(shù)據(jù)湖系統(tǒng)所必須的，后面我們會在“各廠商的數(shù)據(jù)湖解決方案”一節(jié)相信討論各個廠商對于基本管理能力的支持方式。擴展管理能力包括任務(wù)管理、流程編排以及與數(shù)據(jù)質(zhì)量、數(shù)據(jù)治理相關(guān)的能力。任務(wù)管理和流程編排主要用來管理、編排、調(diào)度、監(jiān)測在數(shù)據(jù)湖系統(tǒng)中處理數(shù)據(jù)的各類任務(wù)，通常情況下，數(shù)據(jù)湖構(gòu)建者會通過購買/研制定制的數(shù)據(jù)集成或數(shù)據(jù)開發(fā)子系統(tǒng)/模塊來提供此類能力，定制的系統(tǒng)/模塊可以通過讀取數(shù)據(jù)湖的相關(guān)元數(shù)據(jù)，來實現(xiàn)與數(shù)據(jù)湖系統(tǒng)的融合。而數(shù)據(jù)質(zhì)量和數(shù)據(jù)治理則是更為復雜的問題，一般情況下，數(shù)據(jù)湖系統(tǒng)不會直接提供相關(guān)功能，但是會開放各類接口或者元數(shù)據(jù)，供有能力的企業(yè)/組織與已有的數(shù)據(jù)治理軟件集成或者做定制開發(fā)。

3） 可共享的元數(shù)據(jù)。數(shù)據(jù)湖中的各類計算引擎會與數(shù)據(jù)湖中的數(shù)據(jù)深度融合，而融合的基礎(chǔ)就是數(shù)據(jù)湖的元數(shù)據(jù)。好的數(shù)據(jù)湖系統(tǒng)，計算引擎在處理數(shù)據(jù)時，能從元數(shù)據(jù)中直接獲取數(shù)據(jù)存儲位置、數(shù)據(jù)格式、數(shù)據(jù)模式、數(shù)據(jù)分布等信息，然后直接進行數(shù)據(jù)處理，而無需進行人工/編程干預。更進一步，好的數(shù)據(jù)湖系統(tǒng)還可以對數(shù)據(jù)湖中的數(shù)據(jù)進行訪問控制，控制的力度可以做到“庫表列行”等不同級別。

圖5. 數(shù)據(jù)湖組件參考架構(gòu)
還有一點應(yīng)該指出的是，上圖的“集中式存儲”更多的是業(yè)務(wù)概念上的集中，本質(zhì)上是希望一個企業(yè)/組織內(nèi)部的數(shù)據(jù)能在一個明確統(tǒng)一的地方進行沉淀。事實上，數(shù)據(jù)湖的存儲應(yīng)該是一類可按需擴展的分布式文件系統(tǒng)，大多數(shù)數(shù)據(jù)湖實踐中也是推薦采用S3/OSS/OBS/HDFS等分布式系統(tǒng)作為數(shù)據(jù)湖的統(tǒng)一存儲。

我們可以再切換到數(shù)據(jù)維度，從數(shù)據(jù)生命周期的視角來看待數(shù)據(jù)湖對于數(shù)據(jù)的處理方式，數(shù)據(jù)在數(shù)據(jù)湖中的整個生命周期如圖6所示。理論上，一個管理完善的數(shù)據(jù)湖中的數(shù)據(jù)會永久的保留原始數(shù)據(jù)，同時過程數(shù)據(jù)會不斷的完善、演化，以滿足業(yè)務(wù)的需要。

圖6. 數(shù)據(jù)湖中的數(shù)據(jù)生命周期示意

四、各廠商的數(shù)據(jù)湖解決方案

數(shù)據(jù)湖作為當前的一個風口，各大云廠商紛紛推出自己的數(shù)據(jù)湖解決方案及相關(guān)產(chǎn)品。本節(jié)將分析各個主流廠商推出的數(shù)據(jù)湖解決方案，并將其映射到數(shù)據(jù)湖參考架構(gòu)上，幫助大家理解各類方案的優(yōu)缺點。

4.1 AWS數(shù)據(jù)湖解決方案

圖7. AWS數(shù)據(jù)湖解決方案
圖7是AWS推薦的數(shù)據(jù)湖解決方案。整個方案基于AWS Lake Formation構(gòu)建，AWS Lake Formation本質(zhì)上是一個管理性質(zhì)的組件，它與其他AWS服務(wù)互相配合，來完成整個企業(yè)級數(shù)據(jù)湖構(gòu)建功能。上圖自左向右，體現(xiàn)了數(shù)據(jù)流入、數(shù)據(jù)沉淀、數(shù)據(jù)計算、數(shù)據(jù)應(yīng)用四個步驟。我們進一步來看其關(guān)鍵點：

1） 數(shù)據(jù)流入。
數(shù)據(jù)流入是整個數(shù)據(jù)湖構(gòu)建的起始，包括元數(shù)據(jù)的流入和業(yè)務(wù)數(shù)據(jù)流入兩個部分。元數(shù)據(jù)流入包括數(shù)據(jù)源創(chuàng)建、元數(shù)據(jù)抓取兩步，最終會形成數(shù)據(jù)資源目錄，并生成對應(yīng)的安全設(shè)置與訪問控制策略。解決方案提供專門的組件，獲取外部數(shù)據(jù)源的相關(guān)元信息，該組件能連接外部數(shù)據(jù)源、檢測數(shù)據(jù)格式和模式（schema），并在對應(yīng)的數(shù)據(jù)資源目錄中創(chuàng)建屬于數(shù)據(jù)湖的元數(shù)據(jù)。業(yè)務(wù)數(shù)據(jù)的流入是通過ETL來完成的。

在具體的產(chǎn)品形式上，元數(shù)據(jù)抓取、ETL和數(shù)據(jù)準備AWS將其單獨抽象出來，形成了一個產(chǎn)品叫AWS GLUE。AWS GLUE與AWS Lake Formation共享同一個數(shù)據(jù)資源目錄，在AWS GLUE官網(wǎng)文檔上明確指出：“Each AWS account has one AWS Glue Data Catalog per AWS region”。

對于異構(gòu)數(shù)據(jù)源的支持。AWS提供的數(shù)據(jù)湖解決方案，支持S3、AWS關(guān)系型數(shù)據(jù)庫、AWS NoSQL數(shù)據(jù)庫，AWS利用GLUE、EMR、Athena等組件支持數(shù)據(jù)的自由流動。

2） 數(shù)據(jù)沉淀。

采用Amazon S3作為整個數(shù)據(jù)湖的集中存儲，按需擴展/按使用量付費。

3） 數(shù)據(jù)計算。

整個解決方案利用AWS GLUE來進行基本的數(shù)據(jù)處理。GLUE基本的計算形式是各類批處理模式的ETL任務(wù)，任務(wù)的出發(fā)方式分為手動觸發(fā)、定時觸發(fā)、事件觸發(fā)三種。不得不說，AWS的各類服務(wù)在生態(tài)上實現(xiàn)的非常好，事件觸發(fā)模式上，可以利用AWS Lambda進行擴展開發(fā)，同時觸發(fā)一個或多個任務(wù)，極大的提升了任務(wù)觸發(fā)的定制開發(fā)能力；同時，各類ETL任務(wù)，可以通過CloudWatch進行很好的監(jiān)控。

4） 數(shù)據(jù)應(yīng)用。

在提供基本的批處理計算模式之外，AWS通過各類外部計算引擎，來提供豐富的計算模式支持，例如通過Athena/Redshift來提供基于SQL的交互式批處理能力；通過EMR來提供各類基于Spark的計算能力，包括Spark能提供的流計算能力和機器學習能力。

5） 權(quán)限管理。

AWS的數(shù)據(jù)湖解決方案通過Lake Formation來提供相對完善的權(quán)限管理，粒度包括“庫-表-列”。但是，有一點例外的是，GLUE訪問Lake Formation時，粒度只有“庫-表”兩級；這也從另一個側(cè)面說明，GLUE和Lake Formation的集成是更為緊密的，GLUE對于Lake Formation中的數(shù)據(jù)有更大的訪問權(quán)限。

Lake Formation的權(quán)限進一步可以細分為數(shù)據(jù)資源目錄訪問權(quán)限和底層數(shù)據(jù)訪問權(quán)限，分別對應(yīng)元數(shù)據(jù)與實際存儲的數(shù)據(jù)。實際存儲數(shù)據(jù)的訪問權(quán)限又進一步分為數(shù)據(jù)存取權(quán)限和數(shù)據(jù)存儲訪問權(quán)限。數(shù)據(jù)存取權(quán)限類似于數(shù)據(jù)庫中對于庫表的訪問權(quán)限，數(shù)據(jù)存儲權(quán)限則進一步細化了對于S3中具體目錄的訪問權(quán)限（分為顯示和隱式兩種）。如圖8所示，用戶A在只有數(shù)據(jù)存取的權(quán)限下，無法創(chuàng)建位于S3指定bucket下的表。

個人認為這進一步體現(xiàn)了數(shù)據(jù)湖需要支持各種不同的存儲引擎，未來的數(shù)據(jù)湖可能不只S3/OSS/OBS/HDFS一類核心存儲，可能根據(jù)應(yīng)用的訪問需求，納入更多類型的存儲引擎，例如，S3存儲原始數(shù)據(jù)，NoSQL存儲處理過后適合以“鍵值”模式訪問的數(shù)據(jù)，OLAP引擎存儲需要實時出各類報表/adhoc查詢的數(shù)據(jù)。雖然當前各類材料都在強調(diào)數(shù)據(jù)湖與數(shù)據(jù)倉庫的不同；但是，從本質(zhì)上，數(shù)據(jù)湖更應(yīng)該是一類融合的數(shù)據(jù)管理思想的具體實現(xiàn)，“湖倉一體化”也很可能是未來的一個發(fā)展趨勢。

圖8. AWS數(shù)據(jù)湖解決方案權(quán)限分離示意

綜上，AWS數(shù)據(jù)湖方案成熟度高，特別是元數(shù)據(jù)管理、權(quán)限管理上考慮充分，打通了異構(gòu)數(shù)據(jù)源與各類計算引擎的上下游關(guān)系，讓數(shù)據(jù)能夠自由“移動”起來。在流計算和機器學習上，AWS的解決方案也比較完善。流計算方面AWS推出了專門的流計算組件Kinesis，Kinesis中的Kinesis data Firehose服務(wù)可以創(chuàng)建一個完全被托管的數(shù)據(jù)分發(fā)服務(wù)，通過Kinesis data Stream實時處理的數(shù)據(jù)，可以借助Firehose方便的寫入S3中，并支持相應(yīng)的格式轉(zhuǎn)換，如將JSON轉(zhuǎn)換成Parquet格式。AWS整個方案最牛的地方還在與Kinesis可以訪問GLUE中的元數(shù)據(jù)，這一點充分體現(xiàn)了AWS數(shù)據(jù)湖解決方案在生態(tài)上的完備性。同樣，在機器學習方面，AWS提供了SageMaker服務(wù)，SageMaker可以讀取S3中的訓練數(shù)據(jù)，并將訓練好的模型回寫至S3中。但是，有一點需要指出的是，在AWS的數(shù)據(jù)湖解決方案中，流計算和機器學習并不是固定捆綁的，只是作為計算能力擴展，能方便的集成。

最后，讓我們回到圖6的數(shù)據(jù)湖組件參考架構(gòu)，看看AWS的數(shù)據(jù)湖解決方案的組件覆蓋情況，參見圖9。

圖9. AWS 數(shù)據(jù)湖解決方案在參考架構(gòu)中的映射

綜上，AWS的數(shù)據(jù)湖解決方案覆蓋了除質(zhì)量管理和數(shù)據(jù)治理的所有功能。其實質(zhì)量管理和數(shù)據(jù)治理這個工作和企業(yè)的組織結(jié)構(gòu)、業(yè)務(wù)類型強相關(guān)，需要做大量的定制開發(fā)工作，因此通用解決方案不囊括這塊內(nèi)容，也是可以理解的。事實上，現(xiàn)在也有比較優(yōu)秀的開源項目支持這個項目，比如Apache Griffin，如果對質(zhì)量管理和數(shù)據(jù)治理有強訴求，可以自行定制開發(fā)。

4.2 華為數(shù)據(jù)湖解決方案

圖10.華為數(shù)據(jù)湖解決方案
華為的數(shù)據(jù)湖解決方案相關(guān)信息來自華為官網(wǎng)。目前官網(wǎng)可見的相關(guān)產(chǎn)品包括數(shù)據(jù)湖探索（Data Lake Insight，DLI）和智能數(shù)據(jù)湖運營平臺（DAYU）。其中DLI相當于是AWS的Lake Formation、GLUE、Athena、EMR（Flink&Spark）的集合。官網(wǎng)上沒找到關(guān)于DLI的整體架構(gòu)圖，我根據(jù)自己的理解，嘗試畫了一個，主要是和AWS的解決方案有一個對比，所以形式上盡量一致，如果有非常了解華為DLI的同學，也請不吝賜教。

華為的數(shù)據(jù)湖解決方案比較完整，DLI承擔了所有的數(shù)據(jù)湖構(gòu)建、數(shù)據(jù)處理、數(shù)據(jù)管理、數(shù)據(jù)應(yīng)用的核心功能。DLI最大的特色是在于分析引擎的完備性，包括基于SQL的交互式分析以及基于Spark+Flink的流批一體處理引擎。在核心存儲引擎上，DLI依然通過內(nèi)置的OBS來提供，和AWS S3的能力基本對標。華為數(shù)據(jù)湖解決方案在上下游生態(tài)上做的比AWS相對完善，對于外部數(shù)據(jù)源，幾乎支持所有目前華為云上提供的數(shù)據(jù)源服務(wù)。

DLI可以與華為的CDM（云數(shù)據(jù)遷移服務(wù)）和DIS（數(shù)據(jù)接入服務(wù)）對接：1）借助DIS，DLI可以定義各類數(shù)據(jù)點，這些點可以在Flink作業(yè)中被使用，做為source或者sink；2）借助CDM，DLI甚至能接入IDC、第三方云服務(wù)的數(shù)據(jù)。

為了更好的支持數(shù)據(jù)集成、數(shù)據(jù)開發(fā)、數(shù)據(jù)治理、質(zhì)量管理等數(shù)據(jù)湖高級功能，華為云提供了DAYU平臺。DAYU平臺是華為數(shù)據(jù)湖治理運營方法論的落地實現(xiàn)。DAYU涵蓋了整個數(shù)據(jù)湖治理的核心流程，并對其提供了相應(yīng)的工具支持；甚至在華為的官方文檔中，給出了數(shù)據(jù)治理組織的構(gòu)建建議。DAYU的數(shù)據(jù)治理方法論的落地實現(xiàn)如圖11所示（來自華為云官網(wǎng)）。

圖11 DAYU數(shù)據(jù)治理方法論流程

可以看到，本質(zhì)上DAYU數(shù)據(jù)治理的方法論其實是傳統(tǒng)數(shù)據(jù)倉庫治理方法論在數(shù)據(jù)湖基礎(chǔ)設(shè)施上的延伸：從數(shù)據(jù)模型來看，依然包括貼源層、多源整合層、明細數(shù)據(jù)層，這點與數(shù)據(jù)倉庫完全一致。根據(jù)數(shù)據(jù)模型和指標模型會生成質(zhì)量規(guī)則和轉(zhuǎn)換模型，DAYU會和DLI對接，直接調(diào)用DLI提供的相關(guān)數(shù)據(jù)處理服務(wù)，完成數(shù)據(jù)治理。華為云整個的數(shù)據(jù)湖解決方案，完整覆蓋了數(shù)據(jù)處理的生命周期，并且明確支持了數(shù)據(jù)治理，并提供了基于模型和指標的數(shù)據(jù)治理流程工具，在華為云的數(shù)據(jù)湖解決方案中逐漸開始往“湖倉一體化”方向演進。

4.3 阿里云數(shù)據(jù)湖解決方案

阿里云上數(shù)據(jù)類產(chǎn)品眾多，因為本人目前在數(shù)據(jù)BU，所以本節(jié)方案將關(guān)注在如何使用數(shù)據(jù)庫BU的產(chǎn)品來構(gòu)建數(shù)據(jù)湖，其他云上產(chǎn)品會略有涉及。阿里云的基于數(shù)據(jù)庫產(chǎn)品的數(shù)據(jù)湖解決方案更加聚焦，主打數(shù)據(jù)湖分析和聯(lián)邦分析兩個場景。阿里云數(shù)據(jù)湖解決方案如圖12所示。

圖12. 阿里云數(shù)據(jù)湖解決方案

整個方案依然采用OSS作為數(shù)據(jù)湖的集中存儲。在數(shù)據(jù)源的支持上，目前也支持所有的阿里云數(shù)據(jù)庫，包括OLTP、OLAP和NoSQL等各類數(shù)據(jù)庫。核心關(guān)鍵點如下：

1） 數(shù)據(jù)接入與搬遷。在建湖過程中，DLA的Formation組件具備元數(shù)據(jù)發(fā)現(xiàn)和一鍵建湖的能力，在本文寫作之時，目前“一鍵建湖”還只支持全量建湖，但是基于binlog的增量建湖已經(jīng)在開發(fā)中了，預計近期上線。增量建湖能力會極大的增加數(shù)據(jù)湖中數(shù)據(jù)的實時性，并將對源端業(yè)務(wù)數(shù)據(jù)庫的壓力降到最下。這里需要注意的是，DLA Formation是一個內(nèi)部組件，對外并沒有暴露。

2） 數(shù)據(jù)資源目錄。DLA提供Meta data catalog組件對于數(shù)據(jù)湖中的數(shù)據(jù)資產(chǎn)進行統(tǒng)一的管理，無論數(shù)據(jù)是在“湖中”還是在“湖外”。Meta data catalog也是聯(lián)邦分析的統(tǒng)一元數(shù)據(jù)入口。

3） 在內(nèi)置計算引擎上，DLA提供了SQL計算引擎和Spark計算引擎兩種。無論是SQL還是Spark引擎，都和Meta data catalog深度集成，能方便的獲取元數(shù)據(jù)信息。基于Spark的能力，DLA解決方案支持批處理、流計算和機器學習等計算模式。

4） 在外圍生態(tài)上，除了支持各類異構(gòu)數(shù)據(jù)源做數(shù)據(jù)接入與匯聚之外，在對外訪問能力上，DLA與云原生數(shù)據(jù)倉庫（原ADB）深度整合。一方面，DLA處理的結(jié)果可之際推送至ADB中，滿足實時、交互式、ad hoc復雜查詢；另一方面，ADB里的數(shù)據(jù)也可以借助外表功能，很方便的進行數(shù)據(jù)回流至OSS中。基于DLA，阿里云上各類異構(gòu)數(shù)據(jù)源可以完全被打通，數(shù)據(jù)自由流動。

5） 在數(shù)據(jù)集成和開發(fā)上，阿里云的數(shù)據(jù)湖解決方案提供兩種選擇：一種是采用dataworks完成；另一種是采用DMS來完成。無論是選擇哪種，都能對外提供可視化的流程編排、任務(wù)調(diào)度、任務(wù)管理能力。在數(shù)據(jù)生命周期管理上，dataworks的數(shù)據(jù)地圖能力相對更加成熟。

6） 在數(shù)據(jù)管理和數(shù)據(jù)安全上，DMS提供了強大的能力。DMS的數(shù)據(jù)管理粒度分為“庫-表-列-行”，完善的支持企業(yè)級的數(shù)據(jù)安全管控需求。除了權(quán)限管理之外，DMS更精細的地方是把原來基于數(shù)據(jù)庫的devops理念擴展到了數(shù)據(jù)湖，使得數(shù)據(jù)湖的運維、開發(fā)更加精細化。

進一步細化整個數(shù)據(jù)湖方案的數(shù)據(jù)應(yīng)用架構(gòu)，如下圖所示。

圖13. 阿里云數(shù)據(jù)湖數(shù)據(jù)應(yīng)用架構(gòu)

自左向右從數(shù)據(jù)的流向來看，數(shù)據(jù)生產(chǎn)者產(chǎn)生各類數(shù)據(jù)（云下/云上/其他云），利用各類工具，上傳至各類通用/標準數(shù)據(jù)源，包括OSS/HDFS/DB等。針對各類數(shù)據(jù)源，DLA通過數(shù)據(jù)發(fā)現(xiàn)、數(shù)據(jù)接入、數(shù)據(jù)遷移等能力，完整建湖操作。對于“入湖”的數(shù)據(jù)，DLA提供基于SQL和Spark的數(shù)據(jù)處理能力，并可以基于Dataworks/DMS，對外提供可視化的數(shù)據(jù)集成和數(shù)據(jù)開發(fā)能力；在對外應(yīng)用服務(wù)能力上，DLA提供標準化的JDBC接口，可以直接對接各類報表工具、大屏展示功能等。阿里云的DLA的特色在于背靠整個阿里云數(shù)據(jù)庫生態(tài)，包括OLTP、OLAP、NoSQL等各類數(shù)據(jù)庫，對外提供基于SQL的數(shù)據(jù)處理能力，對于傳統(tǒng)企業(yè)基于數(shù)據(jù)庫的開發(fā)技術(shù)棧而言，轉(zhuǎn)型成本相對較低，學習曲線比較平緩。

阿里云的DLA解決方案的另一個特色在于“基于云原生的湖倉一體化”。傳統(tǒng)的企業(yè)級數(shù)據(jù)倉庫在大數(shù)據(jù)時代的今天，在各類報表應(yīng)用上依然是無法替代的；但是數(shù)倉無法滿足大數(shù)據(jù)時代的數(shù)據(jù)分析處理的靈活性需求；因此，我們推薦數(shù)據(jù)倉庫應(yīng)該作為數(shù)據(jù)湖的上層應(yīng)用存在：即數(shù)據(jù)湖是原始業(yè)務(wù)數(shù)據(jù)在一個企業(yè)/組織中唯一官方數(shù)據(jù)存儲地；數(shù)據(jù)湖根據(jù)各類業(yè)務(wù)應(yīng)用需求，將原始數(shù)據(jù)進行加工處理，形成可再次利用的中間結(jié)果；當中間結(jié)果的數(shù)據(jù)模式（Schema）相對固定后，DLA可以將中間結(jié)果推送至數(shù)據(jù)倉庫，供企業(yè)/組織開展基于數(shù)倉的業(yè)務(wù)應(yīng)用。阿里云在提供DLA的同時，還提供了云原生數(shù)倉（原ADB），DLA和云原生數(shù)倉在以下兩點上深度融合。
1） 使用同源的SQL解析引擎。DLA的SQL與ADB的SQL語法上完全兼容，這意味著開發(fā)者使用一套技術(shù)棧即能同時開發(fā)數(shù)據(jù)湖應(yīng)用和數(shù)倉應(yīng)用。
2） 都內(nèi)置了對于OSS的訪問支持。OSS直接作為DLA的原生存儲存在；對于ADB而言，可以通過外部表的能力，很方便的訪問OSS上的結(jié)構(gòu)化數(shù)據(jù)。借助外部表，數(shù)據(jù)可以自由的在DLA和ADB之間流轉(zhuǎn)，做到真正的湖倉一體。

DLA+ADB的組合真正做到了云原生的湖倉一體（關(guān)于什么是云原生，不在本文的討論范疇）。本質(zhì)上，DLA可以看成一個能力擴展的數(shù)據(jù)倉庫貼源層。與傳統(tǒng)數(shù)倉相比，該貼源層：（1）可以保存各類結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)；（2）可以對接各類異構(gòu)數(shù)據(jù)源；（3）具備元數(shù)據(jù)發(fā)現(xiàn)、管理、同步等能力；（4）內(nèi)置的SQL/Spark計算引擎具備更強的數(shù)據(jù)處理能力，滿足多樣化的數(shù)據(jù)處理需求；（5）具備全量數(shù)據(jù)的全生命周期管理能力。基于DLA+ADB的湖倉一體化方案，將同時覆蓋“大數(shù)據(jù)平臺+數(shù)據(jù)倉庫”的處理能力。

DLA還有一個重要能力是構(gòu)建了一個“四通八達”的數(shù)據(jù)流動體系，并以數(shù)據(jù)庫的體驗對外提供能力，無論數(shù)據(jù)在云上還是云下，無論數(shù)據(jù)在組織內(nèi)部還是外部；借助數(shù)據(jù)湖，各個系統(tǒng)之間的數(shù)據(jù)不再存在壁壘，可以自由的流進流出；更重要的是，這種流動是受監(jiān)管的，數(shù)據(jù)湖完整的記錄了數(shù)據(jù)的流動情況。

4.4 Azure數(shù)據(jù)湖解決方案

Azure的數(shù)據(jù)湖解決方案包括數(shù)據(jù)湖存儲、接口層、資源調(diào)度與計算引擎層，如圖15所示（來自Azure官網(wǎng)）。存儲層是基于Azure object Storage構(gòu)建的，依然是對結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)提供支撐。接口層為WebHDFS，比較特別的是在Azure object Storage實現(xiàn)了HDFS的接口，Azure把這個能力稱為“數(shù)據(jù)湖存儲上的多協(xié)議存取”。在資源調(diào)度上，Azure基于YARN實現(xiàn)。計算引擎上，Azure提供了U-SQL、hadoop和Spark等多種處理引擎。

圖15. Azure Data lake analysis 架構(gòu)

Azure的特別之處是基于visual studio提供給了客戶開發(fā)的支持。

1）開發(fā)工具的支持，與visual studio的深度集成；Azure推薦使用U-SQL作為數(shù)據(jù)湖分析應(yīng)用的開發(fā)語言。Visual studio為U-SQL提供了完備的開發(fā)環(huán)境；同時，為了降低分布式數(shù)據(jù)湖系統(tǒng)開發(fā)的復雜性，visual studio基于項目進行封裝，在進行U-SQL開發(fā)時，可以創(chuàng)建“U-SQL database project”，在此類項目中，利用visual studio，可以很方便的進行編碼與調(diào)試，同時，也提供向?qū)?#xff0c;將開發(fā)好的U-SQL腳本發(fā)布到生成環(huán)境。U-SQL支持Python、R進行擴展，滿足定制開發(fā)需求。

2）多計算引擎的適配： SQL, Apache Hadoop和Apache Spark。這里的hadoop包括Azure提供的HDInsight（Azure托管的Hadoop服務(wù)），Spark包括Azure Databricks。

3）多種不同引擎任務(wù)之間的自動轉(zhuǎn)換能力。微軟推薦U-SQL為數(shù)據(jù)湖的缺省開發(fā)工具，并提供各類轉(zhuǎn)換工具，支持U-SQL腳本與Hive、Spark（HDSight&databricks）、Azure Data Factory data Flow之間的轉(zhuǎn)化。

4.5 小結(jié)

本文所討論的是數(shù)據(jù)湖的解決方案，不會涉及到任何云廠商的單個產(chǎn)品。我們從數(shù)據(jù)接入、數(shù)據(jù)存儲、數(shù)據(jù)計算、數(shù)據(jù)管理、應(yīng)用生態(tài)幾個方面，簡單做了一個類似下表的總結(jié)。

出于篇幅關(guān)系，其實知名云廠商的數(shù)據(jù)湖解決方案還有谷歌和騰訊的。這兩家從其官方網(wǎng)站上看，數(shù)據(jù)湖解決方案相對來講比較簡單，也僅僅是一些概念上的闡述，推薦的落地方案是“oss+hadoop（EMR）”。其實數(shù)據(jù)湖不應(yīng)該從一個簡單的技術(shù)平臺視角來看，實現(xiàn)數(shù)據(jù)湖的方式也多種多樣，評價一個數(shù)據(jù)湖解決方案是否成熟，關(guān)鍵應(yīng)該看其提供的數(shù)據(jù)管理能力，具體包括但不限于元數(shù)據(jù)、數(shù)據(jù)資產(chǎn)目錄、數(shù)據(jù)源、數(shù)據(jù)處理任務(wù)、數(shù)據(jù)生命周期、數(shù)據(jù)治理、權(quán)限管理等；以及與外圍生態(tài)的對接打通能力。

五、典型的數(shù)據(jù)湖應(yīng)用案例

5.1 廣告數(shù)據(jù)分析

近年來，流量獲取的成本就越來越高，線上渠道獲客成本的成倍增長讓各行各業(yè)都面臨著嚴峻的挑戰(zhàn)。在互聯(lián)網(wǎng)廣告成本不斷攀升的大背景下，以花錢買流量拉新為主要的經(jīng)營策略必然行不通了。流量前端的優(yōu)化已成強弩之末，利用數(shù)據(jù)工具提高流量到站后的目標轉(zhuǎn)化，精細化運營廣告投放的各個環(huán)節(jié)，才是改變現(xiàn)狀更為直接有效的方式。說到底，要提高廣告流量的轉(zhuǎn)化率，必須依靠大數(shù)據(jù)分析。

為了能夠提供更多的決策支撐依據(jù)，需要采取更多的埋點數(shù)據(jù)的收集和分析，包括但不限于渠道、投放時間、投放人群，以點擊率為數(shù)據(jù)指標進行數(shù)據(jù)分析，從而給出更好的、更迅速的方案和建議，實現(xiàn)高效率高產(chǎn)出。因此，面對廣告投放領(lǐng)域多維度、多媒體、多廣告位等結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)采集、存儲、分析和決策建議等要求，數(shù)據(jù)湖分析產(chǎn)品解決方案在廣告主或者發(fā)布商進行新一代技術(shù)選型中上受到了很熱烈的青睞。

DG是一家全球領(lǐng)先的企業(yè)國際化智能營銷服務(wù)商，基于先進的廣告技術(shù)、大數(shù)據(jù)和運營能力，為客戶提供全球高質(zhì)量用戶獲取及流量變現(xiàn)服務(wù)。DG從成立之初就決定以公有云為基礎(chǔ)來構(gòu)建其IT基礎(chǔ)設(shè)施，最初DG選擇了AWS云平臺，主要將其廣告數(shù)據(jù)在S3中以數(shù)據(jù)湖的形態(tài)進行存放，通過Athena進行交互式分析。然而隨著互聯(lián)網(wǎng)廣告的飛速發(fā)展，廣告行業(yè)帶來了幾大挑戰(zhàn)，移動廣告的發(fā)布與追蹤系統(tǒng)必須解決幾個關(guān)鍵問題：

1） 并發(fā)性與峰值問題。在廣告行業(yè)，流量高峰時常出現(xiàn)，瞬間的點擊量可能達到數(shù)萬，甚至數(shù)十萬，這就要求系統(tǒng)具備非常好的可擴展性以快速響應(yīng)和處理每一次點擊

2） 如何實現(xiàn)對海量數(shù)據(jù)的實時分析。為了監(jiān)控廣告投放效果，系統(tǒng)需要實時對用戶的每一次點擊和激活數(shù)據(jù)進行分析，同時把相關(guān)數(shù)據(jù)傳輸?shù)较掠蔚拿襟w；

3） 平臺的數(shù)據(jù)量在急劇增長，每天的業(yè)務(wù)日志數(shù)據(jù)在持續(xù)的產(chǎn)生和上傳，曝光、點擊、推送的數(shù)據(jù)在持續(xù)處理，每天新增的數(shù)據(jù)量已經(jīng)在10-50TB左右，對整個數(shù)據(jù)處理系統(tǒng)提出了更高的要求。如何高效地完成對廣告數(shù)據(jù)的離線/近實時統(tǒng)計，按照廣告客戶的維度要求進行聚合分析。

針對上述三點業(yè)務(wù)挑戰(zhàn)，同時DG這個客戶日增量數(shù)據(jù)正在急劇變大（當前日數(shù)據(jù)掃描量達到100+TB），繼續(xù)在AWS平臺使用遇到Athena讀取S3數(shù)據(jù)帶寬瓶頸、數(shù)據(jù)分析滯后時間越來越長、為應(yīng)對數(shù)據(jù)和分析需求增長而急劇攀升的投入成本等，經(jīng)過認真、仔細的測試和分析，最終決定從AWS云平臺全量搬站到阿里云平臺，新架構(gòu)圖如下：

圖16. 改造后的廣告數(shù)據(jù)湖方案架構(gòu)

從AWS搬站到阿里云后，我們?yōu)樵摽蛻粼O(shè)計了“利用Data Lake Analytics + OSS”極致分析能力來應(yīng)對業(yè)務(wù)波峰波谷。一方面輕松應(yīng)對來自品牌客戶的臨時分析。另一方面利用Data Lake Analytics的強大計算能力，分析按月、季度廣告投放，精確計算出一個品牌下面會有多少個活動，每個活動分媒體，分市場，分頻道，分DMP的投放效果，進一步增強了加和智能流量平臺為品牌營銷帶來的銷售轉(zhuǎn)化率。并且在廣告投放與分析的總擁有成本上，Data Lake Analytics提供的Serverless的彈性服務(wù)為按需收費，不需要購買固定的資源，完全契合業(yè)務(wù)潮汐帶來的資源波動，滿足彈性的分析需求，同時極大地降低了運維成本和使用成本。

圖17 數(shù)據(jù)湖部署示意圖

總體上，DG從AWS切換到阿里云后，極大地節(jié)省了硬件成本、人力成本和開發(fā)成本。由于采用DLA serverless云服務(wù)，DG無需先期投入大量的資金去購買服務(wù)器、存儲等硬件設(shè)備，也無需一次性購買大量的云服務(wù)，其基礎(chǔ)設(shè)施的規(guī)模完全是按需擴展：需求高的時候增加服務(wù)數(shù)量，需求減少的時候減少服務(wù)數(shù)量，提高了資金的利用率。使用阿里云平臺帶來的第二個顯著好處是性能的提升。在DG業(yè)務(wù)的快速增長期以及后續(xù)多條業(yè)務(wù)線接入期，DG在移動廣告系統(tǒng)的訪問量經(jīng)常呈爆發(fā)式增長，然而原先AWS方案和平臺在Athena讀取S3數(shù)據(jù)遇到數(shù)據(jù)讀取帶寬的極大瓶頸，數(shù)據(jù)分析的時間變得越來越長，阿里云DLA聯(lián)合OSS團隊等進行了極大的優(yōu)化和改造，同時，DLA數(shù)據(jù)庫分析在計算引擎上（與TPC-DS打榜世界第一的AnalyticDB共享計算引擎）比Presto原生計算引擎的能力提升數(shù)十倍性能，也極大的為DG提升了分析性能。

5.2 游戲運營分析

數(shù)據(jù)湖是一類TCO表現(xiàn)極其優(yōu)秀的大數(shù)據(jù)基礎(chǔ)設(shè)施。對于很多快速增長的游戲公司而言，一個爆款游戲，往往在短期內(nèi)相關(guān)數(shù)據(jù)增長極快；同時，公司的研發(fā)人員的技術(shù)棧很難在短期內(nèi)與數(shù)據(jù)的增量和增速進行匹配；此時，呈爆發(fā)增長的數(shù)據(jù)很難被有效利用。數(shù)據(jù)湖是一個解決此類問題的技術(shù)選擇。

YJ是一家高速成長的游戲公司，公司希望能依托相關(guān)用戶行為數(shù)據(jù)進行深入分析，指導游戲的開發(fā)和運營。數(shù)據(jù)分析背后的核心邏輯在于隨著游戲行業(yè)市場競爭局面的擴大，玩家對于品質(zhì)的要求越來越高，游戲項目的生命周期越來越短，直接影響項目的投入產(chǎn)出比，通過數(shù)據(jù)運營則可以有效的延長項目的生命周期，對各個階段的業(yè)務(wù)走向進行精準把控。而隨著流量成本的日益上升，如何構(gòu)建經(jīng)濟、高效的精細化數(shù)據(jù)運營體系，以更好的支撐業(yè)務(wù)發(fā)展，也變得愈發(fā)重要起來。數(shù)據(jù)運營體系就需要有其配套的基礎(chǔ)支撐設(shè)施，如何選擇這類基礎(chǔ)支撐設(shè)施，是公司技術(shù)決策者需要思考的問題。思考的出發(fā)點包括：

1） 要有足夠的彈性。對于游戲而言，往往就是短時間爆發(fā)，數(shù)據(jù)量激增；因此，能否適應(yīng)數(shù)據(jù)的爆發(fā)性增長，滿足彈性需求是一個重點考量的點；無論是計算還是存儲，都需要具備足夠的彈性。

2） 要有足夠的性價比。對于用戶行為數(shù)據(jù)，往往需要拉到一個很長的周期去分析去對比，比如留存率，不少情況下需要考慮90天甚至180天客戶的留存率；因此，如何以最具性價比的方式長期存儲海量數(shù)據(jù)是需要重點考慮的問題。

3） 要有夠用的分析能力，且具備可擴展性。許多情況下，用戶行為體現(xiàn)在埋點數(shù)據(jù)中，埋點數(shù)據(jù)又需要與用戶注冊信息、登陸信息、賬單等結(jié)構(gòu)化數(shù)據(jù)關(guān)聯(lián)分析；因此，在數(shù)據(jù)分析上，至少需要有大數(shù)據(jù)的ETL能力、異構(gòu)數(shù)據(jù)源的接入能力和復雜分析的建模能力。

4） 要與公司現(xiàn)有技術(shù)棧相匹配，且后續(xù)利于招聘。對于YJ，其在技術(shù)選型的時候一個重要點就是其技術(shù)人員的技術(shù)棧，YJ的技術(shù)團隊大部分只熟悉傳統(tǒng)的數(shù)據(jù)庫開發(fā)，即MySQL；并且人手緊張，做數(shù)據(jù)運營分析的技術(shù)人員只有1個，短時間內(nèi)根本沒有能力獨立構(gòu)建大數(shù)據(jù)分析的基礎(chǔ)設(shè)施。從YJ的角度出發(fā)，最好絕大多數(shù)分析能夠通過SQL完成；并且在招聘市場上，SQL開發(fā)人員的數(shù)量也遠高于大數(shù)據(jù)開發(fā)工程師的數(shù)量。針對客戶的情況，我們幫助客戶對現(xiàn)有方案做了改造。

圖18. 改造前的方案

改造前，客戶所有的結(jié)構(gòu)化數(shù)據(jù)都在一個高規(guī)格的MySQL里面；而玩家行為數(shù)據(jù)則是通過LogTail采集至日志服務(wù)（SLS）中，然后從日志服務(wù)中分別投遞到OSS和ES里。這個架構(gòu)的問題在于：1）行為數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)完全割裂，無法聯(lián)動分析；2）對于行為數(shù)據(jù)智能提供檢索功能，無法做深層次的挖掘分析；3）OSS僅僅作為數(shù)據(jù)存儲資源使用，并沒有挖掘出足夠的數(shù)據(jù)價值。

事實上，我們分析客戶現(xiàn)存架構(gòu)其實已經(jīng)具備了數(shù)據(jù)湖的雛形：全量數(shù)據(jù)已經(jīng)在OSS中保存下來了，現(xiàn)在需要進一步補齊客戶對于OSS中的數(shù)據(jù)的分析能力。而且數(shù)據(jù)湖基于SQL的數(shù)據(jù)處理模式也滿足客戶對于開發(fā)技術(shù)棧的需求。綜上，我們對客戶的架構(gòu)做了如下調(diào)整，幫助客戶構(gòu)建了數(shù)據(jù)湖。

圖19. 改造后的數(shù)據(jù)湖解決方案

總體上，我們沒有改變客戶的數(shù)據(jù)鏈路流轉(zhuǎn)，只是在OSS的基礎(chǔ)上，增加了DLA組件，對OSS的數(shù)據(jù)進行二次加工處理。DLA提供了標準SQL計算引擎，同時支持接入各類異構(gòu)數(shù)據(jù)源。基于DLA對OSS的數(shù)據(jù)進行處理后，生成業(yè)務(wù)直接可用的數(shù)據(jù)。但是DLA的問題在于無法支撐低延遲需求的交互式分析場景，為了解決這個問題，我們引入了云原生數(shù)據(jù)倉庫ADB來解決交互式分析的延遲性問題；同時，在最前端引入QuickBI作為客戶的可視化分析工具。YJ方案是圖14所示的湖倉一體化解決方案在游戲行業(yè)的一個經(jīng)典落地案例。

YM是一家數(shù)據(jù)智能服務(wù)提供商，面向各類中小商家提供一系列數(shù)據(jù)分析運營服務(wù)。具體實現(xiàn)的技術(shù)邏輯如下圖所示。

圖20. YM智能數(shù)據(jù)服務(wù)SaaS模式示意

平臺方提供多端SDK供用戶（商家提供網(wǎng)頁、APP、小程序等多種接入形式）接入各類埋點數(shù)據(jù)，平臺方以SaaS的形式提供統(tǒng)一的數(shù)據(jù)接入服務(wù)和數(shù)據(jù)分析服務(wù)。商家通過訪問各類數(shù)據(jù)分析服務(wù)來進行更細粒度的埋點數(shù)據(jù)分析，完成行為統(tǒng)計、客戶畫像、客戶圈選、廣告投放監(jiān)測等基本分析功能。然而，這種SaaS模式下，會存在一定的問題：

1） 由于商家類型和需求的多樣化，平臺提供SaaS類分析功能很難覆蓋所有類型的商家，無法滿足商家的定制化需求；如有些商家關(guān)注銷量，有些關(guān)注客戶運營，有些關(guān)注成本優(yōu)化，很難滿足所有的需求。

2） 對于一些高級分析功能，如依賴于自定義標簽的客戶圈選、客戶自定義擴展等功能，統(tǒng)一的數(shù)據(jù)分析服務(wù)無法滿足的；特別是一些自定義的標簽依賴于商家自定義的算法，無法滿足客戶的高級分析需求。

3） 數(shù)據(jù)的資產(chǎn)化管理需求。在大數(shù)據(jù)時代，數(shù)據(jù)是一個企業(yè)/組織的資產(chǎn)已經(jīng)成為了大家的共識，如何能讓屬于商家的數(shù)據(jù)合理、長期的沉淀下來，也是SaaS服務(wù)需要考慮的事情。

綜上，我們在上圖的基本模式上引入了數(shù)據(jù)湖模式，讓數(shù)據(jù)湖作為商家沉淀數(shù)據(jù)、產(chǎn)出模型、分析運營的基礎(chǔ)支撐設(shè)施。引入數(shù)據(jù)湖后的SaaS數(shù)據(jù)智能服務(wù)模式如下。

圖21. 基于數(shù)據(jù)湖的數(shù)據(jù)智能服務(wù)

如圖21所示，平臺方為每個用戶提供一鍵建湖服務(wù)，商家使用該功能構(gòu)建自己的數(shù)據(jù)湖，“一鍵建湖”能力一方面幫助商家將所有埋點數(shù)據(jù)的數(shù)據(jù)模型（schema）同步至數(shù)據(jù)湖中；另一方面，將屬于該商家的所有埋點數(shù)據(jù)全量同步至數(shù)據(jù)湖中，并基于“T+1”的模式，將每天的增量數(shù)據(jù)歸檔入湖。基于數(shù)據(jù)湖的服務(wù)模式在傳統(tǒng)的數(shù)據(jù)分析服務(wù)的基礎(chǔ)上，賦予了用戶數(shù)據(jù)資產(chǎn)化、分析模型化和服務(wù)定制化三大能力：

1） 數(shù)據(jù)資產(chǎn)化能力。利用數(shù)據(jù)湖，商家可以將屬于自己的數(shù)據(jù)持續(xù)沉淀下來，保存多長時間的數(shù)據(jù)，耗費多少成本，完全由商家自主決定。數(shù)據(jù)湖還提供了數(shù)據(jù)資產(chǎn)管理能力，商家除了能管理原始數(shù)據(jù)外，還能將處理過的過程數(shù)據(jù)和結(jié)果數(shù)據(jù)分門別類保存，極大的提升了埋點數(shù)據(jù)的價值。

2） 分析模型化能力。數(shù)據(jù)湖中不僅僅有原始數(shù)據(jù)，還有埋點數(shù)據(jù)的模型（schema）。埋點數(shù)據(jù)模型體現(xiàn)了全域數(shù)據(jù)智能服務(wù)平臺對于業(yè)務(wù)邏輯的抽象，通過數(shù)據(jù)湖，除了將原始數(shù)據(jù)作為資產(chǎn)輸出外，還將數(shù)據(jù)模型進行了輸出，借助埋點數(shù)據(jù)模型，商家可以更深入的理解埋點數(shù)據(jù)背后所體現(xiàn)的用戶行為邏輯，幫助商家更好的洞察客戶行為，獲取用戶需求。

3） 服務(wù)定制化能力。借助數(shù)據(jù)湖提供的數(shù)據(jù)集成和數(shù)據(jù)開發(fā)能力，基于對埋點數(shù)據(jù)模型的理解，商家可以定制數(shù)據(jù)處理過程，不斷對原始數(shù)據(jù)進行迭代加工，從數(shù)據(jù)中提煉有價值的信息，最終獲得超越原有數(shù)據(jù)分析服務(wù)的價值。

六、數(shù)據(jù)湖建設(shè)的基本過程

個人認為數(shù)據(jù)湖是比傳統(tǒng)大數(shù)據(jù)平臺更為完善的大數(shù)據(jù)處理基礎(chǔ)支撐設(shè)施，完善在數(shù)據(jù)湖是更貼近客戶業(yè)務(wù)的技術(shù)存在。所有數(shù)據(jù)湖所包括的、且超出大數(shù)據(jù)平臺存在的特性，例如元數(shù)據(jù)、數(shù)據(jù)資產(chǎn)目錄、權(quán)限管理、數(shù)據(jù)生命周期管理、數(shù)據(jù)集成和數(shù)據(jù)開發(fā)、數(shù)據(jù)治理和質(zhì)量管理等，無一不是為了更好的貼近業(yè)務(wù)，更好的方便客戶使用。數(shù)據(jù)湖所強調(diào)的一些基本的技術(shù)特性，例如彈性、存儲計算獨立擴展、統(tǒng)一的存儲引擎、多模式計算引擎等等，也是為了滿足業(yè)務(wù)需求，并且給業(yè)務(wù)方提供最具性價比的TCO。

數(shù)據(jù)湖的建設(shè)過程應(yīng)該與業(yè)務(wù)緊密結(jié)合；但是數(shù)據(jù)湖的建設(shè)過程與傳統(tǒng)的數(shù)據(jù)倉庫，甚至是大熱的數(shù)據(jù)中臺應(yīng)該是有所區(qū)別的。區(qū)別在于，數(shù)據(jù)湖應(yīng)該以一種更敏捷的方式去構(gòu)建，“邊建邊用，邊用邊治理”。為了更好的理解數(shù)據(jù)湖建設(shè)的敏捷性，我們先來看一下傳統(tǒng)數(shù)倉的構(gòu)建過程。業(yè)界對于傳統(tǒng)數(shù)倉的構(gòu)建提出了“自下而上”和“自頂而下”兩種模式，分別由Inmon和KimBall兩位大牛提出。具體的過程就不詳述了，不然可以再寫出幾百頁，這里只簡單闡述基本思想。

1）Inmon提出自下而上（EDW-DM）的數(shù)據(jù)倉庫建設(shè)模式，即操作型或事務(wù)型系統(tǒng)的數(shù)據(jù)源，通過ETL抽取轉(zhuǎn)換和加載到數(shù)據(jù)倉庫的ODS層；ODS層中的數(shù)據(jù)，根據(jù)預先設(shè)計好的EDW（企業(yè)級數(shù)據(jù)倉庫）范式進行加工處理，然后進入到EDW。EDW一般是企業(yè)/組織的通用數(shù)據(jù)模型，不方便上層應(yīng)用直接做數(shù)據(jù)分析；因此，各個業(yè)務(wù)部門會再次根據(jù)自己的需要，從EDW中處理出數(shù)據(jù)集市層（DM）。

優(yōu)勢：易于維護，高度集成；劣勢：結(jié)構(gòu)一旦確定，靈活性不足，且為了適應(yīng)業(yè)務(wù)，部署周期較長。此類方式構(gòu)造的數(shù)倉，適合于比較成熟穩(wěn)定的業(yè)務(wù)，例如金融。

2）KimBall提出自頂而下（DM-DW）的數(shù)據(jù)架構(gòu)，通過將操作型或事務(wù)型系統(tǒng)的數(shù)據(jù)源，抽取或加載到ODS層；然后通過ODS的數(shù)據(jù)，利用維度建模方法建設(shè)多維主題數(shù)據(jù)集市（DM）。各個DM，通過一致性的維度聯(lián)系在一起，最終形成企業(yè)/組織通用的數(shù)據(jù)倉庫。

優(yōu)勢：構(gòu)建迅速，最快的看到投資回報率，敏捷靈活；劣勢：作為企業(yè)資源不太好維護，結(jié)構(gòu)復雜，數(shù)據(jù)集市集成困難。常應(yīng)用于中小企業(yè)或互聯(lián)網(wǎng)行業(yè)。

其實上述只是一個理論上的過程，其實無論是先構(gòu)造EDW，還是先構(gòu)造DM，都離不開對于數(shù)據(jù)的摸底，以及在數(shù)倉構(gòu)建之前的數(shù)據(jù)模型的設(shè)計，包括當前大熱的“數(shù)據(jù)中臺”，都逃不出下圖所示的基本建設(shè)過程。

圖22. 數(shù)據(jù)倉庫/數(shù)據(jù)中臺建設(shè)基本流程

1）?數(shù)據(jù)摸底。對于一個企業(yè)/組織而言，在構(gòu)建數(shù)據(jù)湖初始工作就是對自己企業(yè)/組織內(nèi)部的數(shù)據(jù)做一個全面的摸底和調(diào)研，包括數(shù)據(jù)來源、數(shù)據(jù)類型、數(shù)據(jù)形態(tài)、數(shù)據(jù)模式、數(shù)據(jù)總量、數(shù)據(jù)增量等。在這個階段一個隱含的重要工作是借助數(shù)據(jù)摸底工作，進一步梳理企業(yè)的組織結(jié)構(gòu)，明確數(shù)據(jù)和組織結(jié)構(gòu)之間關(guān)系。為后續(xù)明確數(shù)據(jù)湖的用戶角色、權(quán)限設(shè)計、服務(wù)方式奠定基礎(chǔ)。

2）?模型抽象。針對企業(yè)/組織的業(yè)務(wù)特點梳理歸類各類數(shù)據(jù)，對數(shù)據(jù)進行領(lǐng)域劃分，形成數(shù)據(jù)管理的元數(shù)據(jù)，同時基于元數(shù)據(jù)，構(gòu)建通用的數(shù)據(jù)模型。

3）?數(shù)據(jù)接入。根據(jù)第一步的摸排結(jié)果，確定要接入的數(shù)據(jù)源。根據(jù)數(shù)據(jù)源，確定所必須的數(shù)據(jù)接入技術(shù)能力，完成數(shù)據(jù)接入技術(shù)選型，接入的數(shù)據(jù)至少包括：數(shù)據(jù)源元數(shù)據(jù)、原始數(shù)據(jù)元數(shù)據(jù)、原始數(shù)據(jù)。各類數(shù)據(jù)按照第二步形成的結(jié)果，分類存放。

4）?融合治理。簡單來說就是利用數(shù)據(jù)湖提供的各類計算引擎對數(shù)據(jù)進行加工處理，形成各類中間數(shù)據(jù)/結(jié)果數(shù)據(jù)，并妥善管理保存。數(shù)據(jù)湖應(yīng)該具備完善的數(shù)據(jù)開發(fā)、任務(wù)管理、任務(wù)調(diào)度的能力，詳細記錄數(shù)據(jù)的處理過程。在治理的過程中，會需要更多的數(shù)據(jù)模型和指標模型。

5）?業(yè)務(wù)支撐。在通用模型基礎(chǔ)上，各個業(yè)務(wù)部門定制自己的細化數(shù)據(jù)模型、數(shù)據(jù)使用流程、數(shù)據(jù)訪問服務(wù)。

上述過程，對于一個快速成長的互聯(lián)網(wǎng)企業(yè)來說，太重了，很多情況下是無法落地的，最現(xiàn)實的問題就是第二步模型抽象，很多情況下，業(yè)務(wù)是在試錯、在探索，根本不清楚未來的方向在哪里，也就根本不可能提煉出通用的數(shù)據(jù)模型；沒有數(shù)據(jù)模型，后面的一切操作也就無從談起，這也是很多高速成長的企業(yè)覺得數(shù)據(jù)倉庫/數(shù)據(jù)中臺無法落地、無法滿足需求的重要原因之一。

數(shù)據(jù)湖應(yīng)該是一種更為“敏捷”的構(gòu)建方式，我們建議采用如下步驟來構(gòu)建數(shù)據(jù)湖。

圖23. 數(shù)據(jù)湖建設(shè)基本流程

對比圖22，依然是五步，但是這五步是一個全面的簡化和“可落地”的改進。

1）?數(shù)據(jù)摸底。依然需要摸清楚數(shù)據(jù)的基本情況，包括數(shù)據(jù)來源、數(shù)據(jù)類型、數(shù)據(jù)形態(tài)、數(shù)據(jù)模式、數(shù)據(jù)總量、數(shù)據(jù)增量。但是，也就需要做這么多了。數(shù)據(jù)湖是對原始數(shù)據(jù)做全量保存，因此無需事先進行深層次的設(shè)計。

2）?技術(shù)選型。根據(jù)數(shù)據(jù)摸底的情況，確定數(shù)據(jù)湖建設(shè)的技術(shù)選型。事實上，這一步也非常的簡單，因為關(guān)于數(shù)據(jù)湖的技術(shù)選型，業(yè)界有很多的通行的做法，基本原則個人建議有三個：“計算與存儲分離”、“彈性”、“獨立擴展”。建議的存儲選型是分布式對象存儲系統(tǒng)（如S3/OSS/OBS）；計算引擎上建議重點考慮批處理需求和SQL處理能力，因為在實踐中，這兩類能力是數(shù)據(jù)處理的關(guān)鍵，關(guān)于流計算引擎后面會再討論一下。無論是計算還是存儲，建議優(yōu)先考慮serverless的形式；后續(xù)可以在應(yīng)用中逐步演進，真的需要獨立資源池了，再考慮構(gòu)建專屬集群。

3）?數(shù)據(jù)接入。確定要接入的數(shù)據(jù)源，完成數(shù)據(jù)的全量抽取與增量接入。

4）?應(yīng)用治理。這一步是數(shù)據(jù)湖的關(guān)鍵，我個人把“融合治理”改成了“應(yīng)用治理”。從數(shù)據(jù)湖的角度來看，數(shù)據(jù)應(yīng)用和數(shù)據(jù)治理應(yīng)該是相互融合、密不可分的。從數(shù)據(jù)應(yīng)用入手，在應(yīng)用中明確需求，在數(shù)據(jù)ETL的過程中，逐步形成業(yè)務(wù)可使用的數(shù)據(jù)；同時形成數(shù)據(jù)模型、指標體系和對應(yīng)的質(zhì)量標準。數(shù)據(jù)湖強調(diào)對原始數(shù)據(jù)的存儲，強調(diào)對數(shù)據(jù)的探索式分析與應(yīng)用，但這絕對不是說數(shù)據(jù)湖不需要數(shù)據(jù)模型；恰恰相反，對業(yè)務(wù)的理解與抽象，將極大的推動數(shù)據(jù)湖的發(fā)展與應(yīng)用，數(shù)據(jù)湖技術(shù)使得數(shù)據(jù)的處理與建模，保留了極大的敏捷性，能快速適應(yīng)業(yè)務(wù)的發(fā)展與變化。

從技術(shù)視角來看，數(shù)據(jù)湖不同于大數(shù)據(jù)平臺還在于數(shù)據(jù)湖為了支撐數(shù)據(jù)的全生命周期管理與應(yīng)用，需要具備相對完善的數(shù)據(jù)管理、類目管理、流程編排、任務(wù)調(diào)度、數(shù)據(jù)溯源、數(shù)據(jù)治理、質(zhì)量管理、權(quán)限管理等能力。在計算能力上，目前主流的數(shù)據(jù)湖方案都支持SQL和可編程的批處理兩種模式（對機器學習的支持，可以采用Spark或者Flink的內(nèi)置能力）；在處理范式上，幾乎都采用基于有向無環(huán)圖的工作流的模式，并提供了對應(yīng)的集成開發(fā)環(huán)境。對于流式計算的支持，目前各個數(shù)據(jù)湖解決方案采取了不同的方式。在討論具體的方式之前，我們先對流計算做一個分類：

1） 模式一：實時模式。這種流計算模式相當于對數(shù)據(jù)采用“來一條處理一條”/“微批”的方式進行處理；多見于在線業(yè)務(wù)，如風控、推薦、預警等。

2） 模式二：類流式。這種模式需要獲取指定時間點之后變化的數(shù)據(jù)/讀取某一個版本的數(shù)據(jù)/讀取當前的最新數(shù)據(jù)等，是一種類流式的模式；多見于數(shù)據(jù)探索類應(yīng)用，如分析某一時間段內(nèi)的日活、留存、轉(zhuǎn)化等。

二者的本質(zhì)不同在于，模式一處理數(shù)據(jù)時，數(shù)據(jù)往往還沒有存儲到數(shù)據(jù)湖中，僅僅是在網(wǎng)路/內(nèi)存中流動；模式二處理數(shù)據(jù)時，數(shù)據(jù)已經(jīng)存儲到數(shù)據(jù)湖中了。綜上，我個人建議采用如下圖模式：

圖24 數(shù)據(jù)湖數(shù)據(jù)流向示意圖
如圖24所示，在需要數(shù)據(jù)湖具備模式一的處理能力時，還是應(yīng)該引入類Kafka中間件，作為數(shù)據(jù)轉(zhuǎn)發(fā)的基礎(chǔ)設(shè)施。完整的數(shù)據(jù)湖解決方案方案應(yīng)該提供將原始數(shù)據(jù)導流至Kafka的能力。流式引擎具備從類Kafka組件中讀取數(shù)據(jù)的能力。流式計算引擎在處理數(shù)據(jù)過后，根據(jù)需要，可以將結(jié)果寫入OSS/RDBMS/NoSQL/DW，供應(yīng)用訪問。某種意義上，模式一的流計算引擎并非一定要作為數(shù)據(jù)湖不可分割的一部分存在，只需要在應(yīng)用需要時，能夠方便的引入即可。但是，這里需要指出的是：

1）流式引擎依然需要能夠很方便的讀取數(shù)據(jù)湖的元數(shù)據(jù)；

2）流式引擎任務(wù)也需要統(tǒng)一的納入數(shù)據(jù)湖的任務(wù)管理；

3）流式處理任務(wù)依然需要納入到統(tǒng)一的權(quán)限管理中。

對于模式二，本質(zhì)上更接近于批處理。現(xiàn)在許多經(jīng)典的大數(shù)據(jù)組件已經(jīng)提供了支持方式，如HUDI/IceBerg/Delta等，均支持Spark、Presto等經(jīng)典的計算引擎。以HUDI為例，通過支持特殊類型的表（COW/MOR），提供訪問快照數(shù)據(jù)（指定版本）、增量數(shù)據(jù)、準實時數(shù)據(jù)的能力。目前AWS、騰訊等已經(jīng)將HUDI集成到了其EMR服務(wù)中，阿里云的DLA也正在計劃推出DLA on HUDI的能力。

讓我們再回到本文開頭的第一章，我們說過，數(shù)據(jù)湖的主要用戶是數(shù)據(jù)科學家和數(shù)據(jù)分析師，探索式分析和機器學習是這類人群的常見操作；流式計算（實時模式）多用于在線業(yè)務(wù)，嚴格來看，并非數(shù)據(jù)湖目標用戶的剛需。但是，流式計算（實時模式）是目前大多數(shù)互聯(lián)網(wǎng)公司在線業(yè)務(wù)的重要組成部分，而數(shù)據(jù)湖作為企業(yè)/組織內(nèi)部的數(shù)據(jù)集中存放地，需要在架構(gòu)上保持一定的擴展能力，可以很方便的進行擴展，整合流式計算能力。

5）?業(yè)務(wù)支撐。雖然大多數(shù)數(shù)據(jù)湖解決方案都對外提供標準的訪問接口，如JDBC，市面上流行的各類BI報表工具、大屏工具也都可以直接訪問數(shù)據(jù)湖中的數(shù)據(jù)。但是在實際的應(yīng)用中，我們還是建議將數(shù)據(jù)湖處理好的數(shù)據(jù)推送到對應(yīng)的各類支持在線業(yè)務(wù)的數(shù)據(jù)引擎中去，能夠讓應(yīng)用有更好的體驗。

七、總結(jié)

數(shù)據(jù)湖作為新一代大數(shù)據(jù)分析處理的基礎(chǔ)設(shè)施，需要超越傳統(tǒng)的大數(shù)據(jù)平臺。個人認為目前在以下方面，是數(shù)據(jù)湖解決方案未來可能的發(fā)展方向。

1）?云原生架構(gòu)。關(guān)于什么是云原生架構(gòu)，眾說紛紜，很難找到統(tǒng)一的定義。但是具體到數(shù)據(jù)湖這個場景，個人認為就是以下三點特征：（1）存儲和計算分離，計算能力和存儲能力均可獨立擴展；（2）多模態(tài)計算引擎支持，SQL、批處理、流式計算、機器學習等；（3）提供serverless態(tài)服務(wù)，確保足夠的彈性以及支持按需付費。

2）?足夠用的數(shù)據(jù)管理能力。數(shù)據(jù)湖需要提供更為強大的數(shù)據(jù)管理能力，包括但不限于數(shù)據(jù)源管理、數(shù)據(jù)類目管理、處理流程編排、任務(wù)調(diào)度、數(shù)據(jù)溯源、數(shù)據(jù)治理、質(zhì)量管理、權(quán)限管理等。

3）?大數(shù)據(jù)的能力，數(shù)據(jù)庫的體驗。目前絕大多數(shù)數(shù)據(jù)分析人員都只有數(shù)據(jù)庫的使用經(jīng)驗，大數(shù)據(jù)平臺的能力雖強，但是對于用戶來說并不友好，數(shù)據(jù)科學家和數(shù)據(jù)數(shù)據(jù)分析師應(yīng)該關(guān)注數(shù)據(jù)、算法、模型及其與業(yè)務(wù)場景的適配，而不是花大量的時間精力去學習大數(shù)據(jù)平臺的開發(fā)。數(shù)據(jù)湖要想快速發(fā)展，如何為用戶提供良好的使用體驗是關(guān)鍵。基于SQL的數(shù)據(jù)庫應(yīng)用開發(fā)已經(jīng)深入人心，如何將數(shù)據(jù)湖的能力通過SQL的形式釋放出來，是未來的一個主要方向。

4）?完善的數(shù)據(jù)集成與數(shù)據(jù)開發(fā)能力。對各種異構(gòu)數(shù)據(jù)源的管理與支持，對異構(gòu)數(shù)據(jù)的全量/增量遷移支持，對各種數(shù)據(jù)格式的支持都是需要不斷完善的方向。同時，需要具備一個完備的、可視化的、可擴展的集成開發(fā)環(huán)境。

5）?與業(yè)務(wù)的深度融合與集成。典型數(shù)據(jù)湖架構(gòu)的構(gòu)成基本已經(jīng)成為了業(yè)界共識：分布式對象存儲+多模態(tài)計算引擎+數(shù)據(jù)管理。決定數(shù)據(jù)湖方案是否勝出的關(guān)鍵恰恰在于數(shù)據(jù)管理，無論是原始數(shù)據(jù)的管理、數(shù)據(jù)類目的管理、數(shù)據(jù)模型的管理、數(shù)據(jù)權(quán)限的管理還是處理任務(wù)的管理，都離不開與業(yè)務(wù)的適配和集成；未來，會有越來越多的行業(yè)數(shù)據(jù)湖解決方案涌現(xiàn)出來，與數(shù)據(jù)科學家和數(shù)據(jù)分析師形成良性發(fā)展與互動。如何在數(shù)據(jù)湖解決方案中預置行業(yè)數(shù)據(jù)模型、ETL流程、分析模型和定制算法，可能是未來數(shù)據(jù)湖領(lǐng)域差異化競爭的一個關(guān)鍵點。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的“数据湖”：概念、特征、架构与案例的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。