蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

  科普數(shù)據(jù)湖：概念、特征與架構(gòu)

發(fā)布日期：2022/1/20 6:56:02      瀏覽量：

一、什么是數(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 是這樣定義的：

數(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 的定義相對就簡潔一點：

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

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

Azure 的數(shù)據(jù)湖包括一切使得開發(fā)者、數(shù)據(jù)科學家、分析師能更簡單的存儲、處理數(shù)據(jù)的能力，這些能力使得用戶可以存儲任意規(guī)模、任意類型、任意產(chǎn)生速度的數(shù)據(jù)，并且可以跨平臺、跨語言的做所有類型的分析和處理。數(shù)據(jù)湖在能幫助用戶加速應(yīng)用數(shù)據(jù)的同時，消除了數(shù)據(jù)采集和存儲的復(fù)雜性，同時也能支持批處理、流式計算、交互式分析等。數(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ù)為導(dǎo)向，實現(xiàn)任意來源、任意速度、任意規(guī)模、任意類型數(shù)據(jù)的全量獲取、全量存儲、多模式處理與全生命周期管理；并通過與各類外部異構(gòu)數(shù)據(jù)源的交互集成，支持各類企業(yè)級應(yīng)用。

這里需要再特別指出兩點：

1. 可擴展是指規(guī)模的可擴展和能力的可擴展，即數(shù)據(jù)湖不但要能夠隨著數(shù)據(jù)量的增大，提供“足夠”的存儲和計算能力；還需要根據(jù)需要不斷提供新的數(shù)據(jù)處理模式，例如可能一開始業(yè)務(wù)只需要批處理能力，但隨著業(yè)務(wù)的發(fā)展，可能需要交互式的即席分析能力；又隨著業(yè)務(wù)的實效性要求不斷提升，可能需要支持實時分析和機器學習等豐富的能力。

2. 以數(shù)據(jù)為導(dǎo)向，是指數(shù)據(jù)湖對于用戶來說要足夠的簡單、易用，幫助用戶從復(fù)雜的 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)的對比表格

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

• “保真性”。數(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ù)。

• “靈活性”：上表一個點是 “寫入型 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ù)導(dǎo)入，帶來的好處是數(shù)據(jù)與業(yè)務(wù)的良好適配；但是這也意味著數(shù)倉的前期擁有成本會比較高，特別是當業(yè)務(wù)模式不清晰、業(yè)務(wù)還處于探索階段時，數(shù)倉的靈活性不夠。數(shù)據(jù)湖強調(diào)的“讀取型 schema”，背后的潛在邏輯則是認為業(yè)務(wù)的不確定性是常態(tài)：我們無法預(yù)期業(yè)務(wù)的變化，那么我們就保持一定的靈活性，將設(shè)計去延后，讓整個基礎(chǔ)設(shè)施具備使數(shù)據(jù)“按需”貼合業(yè)務(wù)的能力。因此，個人認為“保真性”和“靈活性”是一脈相承的：既然沒辦法預(yù)估業(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ù)湖的目標客戶。

• “可管理”：數(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)限管理能力。

• “可追溯”：數(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ù)對于計算的要求。

• 豐富的計算引擎。從批處理、流式計算、交互式分析到機器學習，各類計算引擎都屬于數(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ǔ)能力。

• 多模態(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） 第二階段：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)的核心理念是“流批一體”，如上圖所示，整個數(shù)據(jù)流向自左向右流入平臺。進入平臺后一分為二，一部分走批處理模式，一部分走流式計算模式。無論哪種計算模式，最終的處理結(jié)果都通過服務(wù)層對應(yīng)用提供，確保訪問的一致性。

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

綜上，從傳統(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ù)治理則是更為復(fù)雜的問題，一般情況下，數(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ù)處理，而無需進行人工/編程干預(yù)。更進一步，好的數(shù)據(jù)湖系統(tǒng)還可以對數(shù)據(jù)湖中的數(shù)據(jù)進行訪問控制，控制的力度可以做到“庫表列行”等不同級別。

還有一點應(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ù)的需要。

四、各廠商的數(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ù)湖解決方案。整個方案基于 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ā)展趨勢。

綜上，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。

綜上，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ù)湖解決方案

華為的數(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)）。

可以看到，本質(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 所示。

整個方案依然采用 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ā)中了，預(yù)計近期上線。增量建湖能力會極大的增加數(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 復(fù)雜查詢；另一方面，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)，如下圖所示。

自左向右從數(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ù)倉在以下兩點上深度融合。

• 使用同源的 SQL 解析引擎。DLA 的 SQL 與 ADB 的 SQL 語法上完全兼容，這意味著開發(fā)者使用一套技術(shù)棧即能同時開發(fā)數(shù)據(jù)湖應(yīng)用和數(shù)倉應(yīng)用。

• 都內(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 等多種處理引擎。

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ā)的復(fù)雜性，visual studio 基于項目進行封裝，在進行 U-SQL 開發(fā)時，可以創(chuàng)建“U-SQL database project”，在此類項目中，利用 visual studio，可以很方便的進行編碼與調(diào)試，同時，也提供向?qū)В瑢㈤_發(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)的對接打通能力。

原文鏈接:【https://xie.infoq.cn/article/ef68dbe3516219cdae52f5b76】