一 數(shù)據(jù)湖技術(shù)產(chǎn)生的背景國內(nèi)的大型互聯(lián)網(wǎng)公司，每天都會生成幾十,、幾百TB,，甚至幾PB的原始數(shù)據(jù)。這些公司通常采用開源的大數(shù)據(jù)組件來搭建大數(shù)據(jù)平臺,。大數(shù)據(jù)平臺經(jīng)歷過“以Hadoop為代表的離線數(shù)據(jù)平臺”,、“Lambda架構(gòu)平臺”,、“Kappa架構(gòu)平臺”三個階段。 可以把數(shù)據(jù)湖認為是最新一代大數(shù)據(jù)技術(shù)平臺,，為了更好地理解數(shù)據(jù)湖的基本架構(gòu),，我們先來看看大數(shù)據(jù)平臺的演進過程，從而理解為什么要學習數(shù)據(jù)湖技術(shù),。 1.1 離線大數(shù)據(jù)平臺-第一代 第一階段：以Hadoop為代表的離線數(shù)據(jù)處理組件。Hadoop是以HDFS為核心存儲,，以MapReduce為基本計算模型的批量數(shù)據(jù)處理基礎(chǔ)組件,。圍繞HDFS和MR，為不斷完善大數(shù)據(jù)平臺的數(shù)據(jù)處理能力,，先后誕生了一系列大數(shù)據(jù)組件,，例如面向?qū)崟rKV操作的HBase、面向SQL的Hive,、面向工作流的Pig等,。同時，隨著大家對于批處理的性能要求越來越高,，新的計算模型不斷被提出,，產(chǎn)生了Tez、Spark,、Presto等計算引擎,，MR模型也逐漸進化成DAG模型。 為減少數(shù)據(jù)處理過程中的中間結(jié)果寫文件操作,，Spark,、Presto等計算引擎盡量使用計算節(jié)點的內(nèi)存對數(shù)據(jù)進行緩存，從而提高整個數(shù)據(jù)過程的效率和系統(tǒng)吞吐能力,。 1.2 Lambda架構(gòu)隨著數(shù)據(jù)處理能力和處理需求的不斷變化,，越來越多的用戶發(fā)現(xiàn)，批處理模式無論如何提升性能,，也無法滿足實時性要求高的處理場景,，流式計算引擎應(yīng)運而生，例如Storm,、Spark Streaming,、Flink等。 然而,，隨著越來越多的應(yīng)用上線,，大家發(fā)現(xiàn)，其實批處理和流計算配合使用，才能滿足大部分應(yīng)用需求,，對實時性要求高的場景，就會使用Flink+Kafka的方式構(gòu)建實時流處理平臺,，來滿足用戶的實時需求,。于是Lambda架構(gòu)被提出，如下圖所示,。  Lambda架構(gòu)的核心理念是“流批分離”，如上圖所示,，整個數(shù)據(jù)流向自左向右流入平臺,。進入平臺后一分為二，一部分走批處理模式,，一部分走流式計算模式,。無論哪種計算模式，最終的處理結(jié)果都通過服務(wù)層對應(yīng)用提供,，確保訪問的一致性,。 這種數(shù)據(jù)架構(gòu)包含非常多的大數(shù)據(jù)組件，很大程度上增強了整體架構(gòu)的復(fù)雜性和維護成本,。 1.3 Lambda架構(gòu)的痛點經(jīng)過多年的發(fā)展,，Lambda架構(gòu)比較穩(wěn)定，能滿足過去的應(yīng)用場景,。但是它有很多致命的弱點：  1、數(shù)據(jù)治理成本高 實時計算流程無法復(fù)用離線數(shù)倉的數(shù)據(jù)血緣,、數(shù)據(jù)質(zhì)量管理體系,。需要重新實現(xiàn)一套針對實時計算的數(shù)據(jù)血緣、數(shù)據(jù)質(zhì)量管理體系,。 2,、開發(fā)維護成本高 需要同時維護離線和實時兩套數(shù)據(jù)倉庫系統(tǒng)，同一套計算邏輯要存儲兩份數(shù)據(jù),。例如,，某一條或幾條原式數(shù)據(jù)的更新，就需要重新跑一遍離線數(shù)據(jù)倉庫,，數(shù)據(jù)更新成本非常大,。 3、數(shù)據(jù)口徑不一致 因為離線和實時計算走的是兩個完全不同的代碼,，由于數(shù)據(jù)數(shù)據(jù)的延遲到達和兩類代碼運行的時間不一樣,，導(dǎo)致計算結(jié)果不一致。 那么有沒有一種架構(gòu)能解決Lambda架構(gòu)的問題呢？ 1.4 Kappa架構(gòu)Lambda架構(gòu)的“流批分離”處理鏈路增大了研發(fā)的復(fù)雜性,。因此,，有人就提出能不能用一套系統(tǒng)來解決所有問題。目前比較流行的做法就是基于流計算來做,。接下來我們介紹一下Kappa架構(gòu),，通過Flink+Kafka將整個鏈路串聯(lián)起來。Kappa架構(gòu)解決了Lambda架構(gòu)中離線處理層和實時處理層之間計算引擎不一致,，開發(fā),、運維成本成本高，計算結(jié)果不一致等問題,。  Kappa架構(gòu)的方案也被稱為“批流一體化”方案。我們借用Flink+Kafka來構(gòu)建流批一體化場景,，當需要對ODS層數(shù)據(jù)做進一步的分析時,，將Flink計算結(jié)果的DWD層寫入到Kafka，同樣也會將一部分DWS層的計算結(jié)果Kafka,。Kappa架構(gòu)也不是完美的,，它也有很多痛點。 1.5 Kappa架構(gòu)的痛點 1,、數(shù)據(jù)回溯能力弱 但是Kafka對復(fù)雜的需求分析支持能力弱，在面對更復(fù)雜的數(shù)據(jù)分析時,，又要將DWD和DWS層的數(shù)據(jù)寫入到ClickHouse,、ES、MySQL或者是Hive里做進一步分析,，這無疑帶來了鏈路的復(fù)雜性,。更大的問題是在做數(shù)據(jù)回溯時，由于鏈路的復(fù)雜性導(dǎo)致數(shù)據(jù)回溯能力非常弱,。 2,、OLAP分析能力弱 由于Kafka是一個順序存儲的系統(tǒng)，順序存儲系統(tǒng)是沒有辦法直接在其上進行OLAP分析的,，例如謂詞下推這類的優(yōu)化策略,，在順序存儲平臺（Kafka）上實現(xiàn)是比較困難的事情。 3,、數(shù)據(jù)時序性受到挑戰(zhàn) Kappa架構(gòu)是嚴重依賴于消息隊列的,，我們知道消息隊列本身的準確性嚴格依賴它上游數(shù)據(jù)的順序，但是,，消息隊列的數(shù)據(jù)分層越多,，發(fā)生亂序的可能性越大。通常情況下，ODS層的數(shù)據(jù)是絕對準確的,，把ODS層數(shù)據(jù)經(jīng)過計算之后寫入到DWD層時就會產(chǎn)生亂序,，DWD到DWS更容易產(chǎn)生亂序，這樣的數(shù)據(jù)不一致性問題非常大,。 1.6 大數(shù)據(jù)架構(gòu)痛點總結(jié)從傳統(tǒng)的hadoop架構(gòu)往Lambda架構(gòu),，從Lambda架構(gòu)往Kappa架構(gòu)的演進，大數(shù)據(jù)平臺基礎(chǔ)架構(gòu)的演進逐漸囊括了應(yīng)用所需的各類數(shù)據(jù)處理能力,，但是這些平臺仍然存在很多痛點,。  是否存在一種存儲技術(shù),，既能夠支持數(shù)據(jù)高效的回溯能力，支持數(shù)據(jù)的更新,，又能夠?qū)崿F(xiàn)數(shù)據(jù)的批流讀寫,，并且還能夠?qū)崿F(xiàn)分鐘級到秒級的數(shù)據(jù)接入？ 1.7 實時數(shù)倉建設(shè)需求這也是實時數(shù)倉建設(shè)的迫切需求,。實際上是可以通過對Kappa架構(gòu)進行升級,，以解決Kappa架構(gòu)中遇到的一些問題，接下來主要分享當前比較火的數(shù)據(jù)湖技術(shù),。  那么有沒有這樣一個架構(gòu)，既能夠滿足實時性的需求,，又能夠滿足離線計算的要求,，而且還能夠減輕開發(fā)運維的成本，解決通過消息隊列方式構(gòu)建的Kappa架構(gòu)中遇到的痛點,？答案是肯定的,，在文章的后面會詳細論述。 二 數(shù)據(jù)湖助力于解決數(shù)據(jù)倉庫痛點問題2.1 不斷完善的數(shù)據(jù)湖理念數(shù)據(jù)湖是一個集中式存儲庫,，可以存儲結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù),。可以按業(yè)務(wù)數(shù)據(jù)的原樣存儲（無需先對數(shù)據(jù)進行結(jié)構(gòu)化處理）,，并運行不同類型的分析 – 從控制面板和可視化到大數(shù)據(jù)處理,、實時分析和機器學習，以指導(dǎo)做出更好的決策,。  2.1.1 存儲原式數(shù)據(jù)
2.1.2 靈活的底層存儲功能在實際的使用過程中，數(shù)據(jù)湖中的數(shù)據(jù)通常并不會被高頻訪問,，為了達到可接受的性價比,，數(shù)據(jù)湖建設(shè)通常會選擇性價比高的存儲引擎（如S3/OSS/HDFS）。
2.1.3 豐富的計算引擎從數(shù)據(jù)的批量計算,、流式計算，交互式查詢分析到機器學習,，各類計算引擎都屬于數(shù)據(jù)湖應(yīng)該囊括的范疇,。隨著大數(shù)據(jù)與人工智能技術(shù)的結(jié)合，各類機器學習/深度學習算法也被不斷引入進來,，例如TensorFlow/PyTorch框架已經(jīng)支持從HDFS/S3/OSS上讀取樣本數(shù)據(jù)進行機器學習訓練,。因此，對于一個合格的數(shù)據(jù)湖項目而言,，計算存儲引擎的可插拔性,，是數(shù)據(jù)湖必須具備的基礎(chǔ)能力。 2.1.4 完善的數(shù)據(jù)管理
2.2 開源數(shù)據(jù)湖的架構(gòu)LakeHouse架構(gòu)成為當下架構(gòu)演進最熱的趨勢,，可直接訪問存儲的數(shù)據(jù)管理系統(tǒng),，它結(jié)合了數(shù)據(jù)倉庫的主要優(yōu)勢。LakeHouse是基于存算分離的架構(gòu)來構(gòu)建的,。存算分離最大的問題在于網(wǎng)絡(luò),，特別是對于高頻訪問的數(shù)倉數(shù)據(jù)，網(wǎng)絡(luò)性能至關(guān)重要,。實現(xiàn)Lakehouse的可選方案很多,，比如Delta，Hudi,，Iceberg,。雖然三者側(cè)重點有所不同,，但都具備數(shù)據(jù)湖的一般功能,，比如：統(tǒng)一元數(shù)據(jù)管理、支持多種計算分析引擎,、支持高階分析和計算存儲分離,。 那么開源數(shù)據(jù)湖架構(gòu)一般是啥樣的呢？這里我畫了一個架構(gòu)圖,，主要分為四層：  2.2.1 分布式文件系統(tǒng)第一層是分布式文件系統(tǒng)，對于選擇云上技術(shù)的用戶,，通常會選擇S3和阿里云存儲數(shù)據(jù),；喜歡開源技術(shù)的用戶一般采用自己維護的HDFS存儲數(shù)據(jù)。 2.2.2 數(shù)據(jù)加速層第二層是數(shù)據(jù)加速層,。數(shù)據(jù)湖架構(gòu)是一個典型的存儲計算分離架構(gòu),，遠程讀寫的性能損耗非常大。我們常見的做法是,，把經(jīng)常訪問的數(shù)據(jù)（熱點數(shù)據(jù)）緩存在計算節(jié)點本地,，從而實現(xiàn)數(shù)據(jù)的冷熱分離。這樣做的好處是,，提高數(shù)據(jù)的讀寫性能,，節(jié)省網(wǎng)絡(luò)帶寬。我們可以選擇開源的Alluxio,，或者阿里云的Jindofs,。 2.2.3 Table format 層第三層是Table format層,，把數(shù)據(jù)文件封裝成具有業(yè)務(wù)含義的表，數(shù)據(jù)本身提供ACID,、snapshot,、schema、partition等表級別的語義,。這一層可以選擇開源數(shù)據(jù)湖三劍客Delta,、Iceberg、Hudi之一,。Delta,、Iceberg、Hudi是構(gòu)建數(shù)據(jù)湖的一種技術(shù),，它們本身并不是數(shù)據(jù)湖,。 2.2.4 計算引擎第四層是各種數(shù)據(jù)計算引擎。包括Spark,、Flink,、Hive、Presto等,，這些計算引擎都可以訪問數(shù)據(jù)湖中的同一張表,。 三 數(shù)據(jù)湖和數(shù)據(jù)倉庫理念的對比3.1 數(shù)據(jù)湖和數(shù)據(jù)倉庫對比下面跟大家聊聊我所理解的數(shù)據(jù)湖的本質(zhì)，對于一種新事物不了解本質(zhì),，你就很難駕馭它,，下面這張圖道盡了一切。  對數(shù)據(jù)湖的概念有了基本的認知之后,，我們需要進一步明確數(shù)據(jù)湖需要具備哪些基本特征，特別是與數(shù)據(jù)倉庫相比,，數(shù)據(jù)湖具有哪些特點,。我們引用一下AWS數(shù)據(jù)倉庫和數(shù)據(jù)湖對比官方對比表格。 每個公司需要數(shù)據(jù)倉庫和數(shù)據(jù)湖,，因為它們分別滿足不同的需要和使用案例：
 上表介紹了數(shù)據(jù)湖與傳統(tǒng)數(shù)據(jù)倉庫的區(qū)別，下面我們將從數(shù)據(jù)存儲和計算兩個層面進一步分析數(shù)據(jù)湖應(yīng)該具備哪些特征,。 3.2 寫時模式和讀時模式3.2.1 寫時模式數(shù)據(jù)倉庫的“寫入型Schema”背后隱藏的邏輯就是在數(shù)據(jù)寫入之前,，必須確認好數(shù)據(jù)的Schema，然后進行數(shù)據(jù)導(dǎo)入,，這樣做的好處是：可以把業(yè)務(wù)和數(shù)據(jù)很好的結(jié)合在一起,；不足就是在業(yè)務(wù)模式不清晰，還處于探索階段時,，數(shù)倉的靈活性不夠,。 3.2.2 讀時模式數(shù)據(jù)湖強調(diào)的是“讀取型Schema”，背后潛在的邏輯是,，認為業(yè)務(wù)的不確定性是常態(tài)：既然我們無法預(yù)測業(yè)務(wù)的發(fā)展變化,，那么我們就保持一定的靈活性,。將結(jié)構(gòu)化設(shè)計延后,，讓整個基礎(chǔ)設(shè)施具備使數(shù)據(jù)“按需”貼合業(yè)務(wù)的能力。因此,，數(shù)據(jù)湖更適合發(fā)展,、創(chuàng)新型企業(yè)。 3.3 數(shù)據(jù)倉庫開發(fā)流程數(shù)據(jù)湖采用的是靈活,，快速的“讀時模式” ，在數(shù)字化轉(zhuǎn)型的浪潮下真正幫助企業(yè)完成技術(shù)轉(zhuǎn)型,，完成數(shù)據(jù)沉淀,，應(yīng)對企業(yè)快速發(fā)展下層出不窮的數(shù)據(jù)需求問題。 3.4 數(shù)據(jù)湖的架構(gòu)方案數(shù)據(jù)湖可以認為是新一代的大數(shù)據(jù)基礎(chǔ)設(shè)施,。在這套架構(gòu)中,，無論是數(shù)據(jù)的流式處理，還是批處理,，數(shù)據(jù)存儲都統(tǒng)一到數(shù)據(jù)湖-Iceberg上,。很明顯,，這套架構(gòu)可以解決Lambda架構(gòu)和Kappa架構(gòu)的痛點問題： 3.4.1 解決Kafka存儲數(shù)據(jù)量少的問題目前所有數(shù)據(jù)湖基本思路都是基于HDFS之上實現(xiàn)的一個文件管理系統(tǒng),，所以數(shù)據(jù)體量可以很大,。 3.4.2 支持OLAP查詢同樣數(shù)據(jù)湖基于HDFS之上實現(xiàn)，只需要當前的OLAP查詢引擎做一些適配,，就可以對中間層數(shù)據(jù)進行OLAP查詢,。 3.4.3 數(shù)據(jù)治理一體化批流的數(shù)據(jù)在HDFS、S3等介質(zhì)上存儲之后,，就完全可以復(fù)用一套相同的數(shù)據(jù)血緣,、數(shù)據(jù)質(zhì)量管理體系。 3.4.4 流批架構(gòu)統(tǒng)一數(shù)據(jù)湖架構(gòu)相比Lambad架構(gòu)來說,，schema統(tǒng)一,，數(shù)據(jù)處理邏輯統(tǒng)一，用戶不再需要維護兩份數(shù)據(jù),。 3.4.5 數(shù)據(jù)統(tǒng)計口徑一致由于采用統(tǒng)一的流批一體化計算和存儲方案,，因此數(shù)據(jù)一致性得到了保證。 3.5 孰優(yōu)孰劣數(shù)據(jù)湖和數(shù)據(jù)倉庫,，不能說誰更好誰更差,，大家都有可取之處，可以實現(xiàn)雙方的優(yōu)勢互補,，我這里畫一張圖,，方便你的理解：
四 數(shù)據(jù)湖助力數(shù)據(jù)倉庫架構(gòu)升級4.1 構(gòu)建數(shù)據(jù)湖的目標數(shù)據(jù)湖技術(shù)-Iceberg目前支持三種文件格式：Parquet，Avro,，ORC,。如下圖所示,，Iceberg本身具備的能力總結(jié)如下，這些能力對于構(gòu)建湖倉一體化是至關(guān)重要的,。
4.2 準實時數(shù)據(jù)接入數(shù)據(jù)湖技術(shù)-Iceberg既支持讀寫分離，又支持并發(fā)讀,、增量讀,、小文件合并，還可以支持秒級到分鐘級的延遲,，基于這些優(yōu)勢我們嘗試采用Iceberg這些功能來構(gòu)建基于Flink的實時全鏈路批流一體化的實時數(shù)倉架構(gòu),。 如下圖所示，Iceberg每次的commit操作,，都是對數(shù)據(jù)的可見性的改變,，比如說讓數(shù)據(jù)從不可見變成可見，在這個過程中,，就可以實現(xiàn)近實時的數(shù)據(jù)記錄,。 4.3 實時數(shù)倉 - 數(shù)據(jù)湖分析系統(tǒng)在建設(shè)離線數(shù)據(jù)倉庫時,，首先要進行數(shù)據(jù)接入操作,，比如用離線調(diào)度系統(tǒng)定時抽取數(shù)據(jù)，再經(jīng)過一系列的ETL操作,，最后將數(shù)據(jù)寫入到Hive表里面,，這個過程的延時比較大。因此,，借助于Iceberg的表結(jié)構(gòu)，可以使用Flink,，或者Spark Streaming,，實現(xiàn)近實時的數(shù)據(jù)接入，以降低數(shù)據(jù)延遲性,。 基于上面的功能,，我們回顧一下前面討論的Kappa架構(gòu)，我們已經(jīng)知道Kappa架構(gòu)的痛點,，Iceberg既然能夠作為一個優(yōu)秀的表格式,，又可以支持Streaming reader和Streaming sink,。那么，是否可以考慮將Kafka替換成Iceberg,？ Iceberg底層依賴的存儲是像HDFS或S3這樣的廉價存儲,，并且支持parquet、orc,、Avro等存儲結(jié)構(gòu),。可以對中間層的結(jié)果數(shù)據(jù)進行OLAP分析,?；贗ceberg snapshot的Streaming reader功能，可以把離線任務(wù)天級別到小時級別的延遲大大的降低,，改造成一個近實時的數(shù)據(jù)湖分析系統(tǒng),。 在中間處理層,，可以用Presto進行一些簡單的SQL查詢,，因為Iceberg支持Streaming Read，所以在系統(tǒng)的中間層也可以直接接入Flink,，直接在中間層用Flink做一些批處理或者流式計算的任務(wù),，把中間結(jié)果做進一步計算后輸出到下游。 4.4 Iceberg替換Kafka的劣勢總的來說,，Iceberg替換Kafka的優(yōu)勢主要包括：
當然，也存在一定的缺陷,，如：
4.5 通過Flink CDC解決MySQL數(shù)據(jù)同步問題Iceberg提供統(tǒng)一的數(shù)據(jù)湖存儲表格式,，支持多種計算引擎（包括 Spark、Presto,、hive）進行數(shù)據(jù)分析,；可以產(chǎn)生純列存的數(shù)據(jù)文件，而列式文件非常適合用來做OLAP操作,；Iceberg基于Snapshot的設(shè)計模式,，支持增量讀取數(shù)據(jù)；Iceberg的接口抽象程度高,，兼容性好,，既獨立于上層的計算引擎又獨立于下層的存儲引擎，這就方便用戶自行定義業(yè)務(wù)邏輯,。 將數(shù)據(jù)連同CDC flag直接append到Iceberg當中,，在merge的時候，把這些增量的數(shù)據(jù)按照一定的組織格式、一定高效的計算方式與全量的上一次數(shù)據(jù)進行一次merge,。這樣的好處是支持近實時的導(dǎo)入和實時數(shù)據(jù)讀?。贿@套計算方案的Flink SQL原生支持CDC的攝入,，不需要額外的業(yè)務(wù)字段設(shè)計,。 五 數(shù)據(jù)湖技術(shù)的發(fā)展前景數(shù)據(jù)湖可能是在下一場大數(shù)據(jù)技術(shù)變革中的亮點,，我們需要抓住機遇,、搶占先機，一起來學習數(shù)據(jù)湖,。但是我的建議仍然是“學而不用”,，為什么這么說呢？例如：在2018年開始的時候,，我們一窩蜂的上線Flink,，然后一個月一個版本的升級。簡直是吃盡了苦頭,。所以,，我們就等互聯(lián)網(wǎng)大廠把坑填完了，我們再直接短平快的上馬數(shù)據(jù)湖,，但是我們一定要學習,。 六 總結(jié)通過這篇文章，我們基本了解了什么是數(shù)據(jù)湖,，以及為什么要學習數(shù)據(jù)湖,，它能解決哪些實際問題。后面我們將繼續(xù)重點講解為什么要選擇Iceberg作為數(shù)據(jù)湖的解決方案,。 |
|
|
