[[421588]]

本文轉載自微信公眾號「數(shù)倉寶貝庫」，作者彭鋒 等。轉載本文請聯(lián)系數(shù)倉寶貝庫公眾號。

本文主要介紹數(shù)據湖的建設目標及在此建設目標下的數(shù)據湖中的數(shù)據治理。

作為全局數(shù)據匯總及處理的核心功能，數(shù)據湖在數(shù)據中臺建設中必不可少。那么它與數(shù)據倉庫、數(shù)據中臺是什么關系?

下圖顯示了一個典型的從數(shù)據采集到數(shù)據湖、數(shù)據倉庫及數(shù)據集市，最后為數(shù)據應用提供服務的流程?？梢钥吹?，除了為數(shù)據倉庫提供原始數(shù)據之外，數(shù)據湖也可以直接為上層的數(shù)據應用提供服務。與數(shù)據湖不同，數(shù)據倉庫是針對OLAP需求建設的數(shù)據庫，可以分析來自交易系統(tǒng)或不同業(yè)務部門的結構化數(shù)據。數(shù)據倉庫中的數(shù)據由原始數(shù)據經過清理、填充和轉換后按照核心業(yè)務邏輯組織生成。數(shù)據倉庫一般必須預先定義好數(shù)據庫Schema，重點是實現(xiàn)更快的SQL驅動的深度報告和分析。

從數(shù)據采集到提供數(shù)據服務的流程圖

01數(shù)據湖的起源與作用

數(shù)據湖的出現(xiàn)主要是為了解決存儲全域原始數(shù)據的問題。在捕獲來自業(yè)務應用程序、移動應用程序、IoT設備和互聯(lián)網的結構化和非結構化數(shù)據時，實際上并沒有預先定義好數(shù)據結構，這意味著可以先存儲數(shù)據而無須進行精心設計，也無須明確要進行什么分析，由數(shù)據科學家和數(shù)據工程師在后續(xù)工作中探索和嘗試。這個改動極大推動了大數(shù)據的發(fā)展，早期大數(shù)據系統(tǒng)的一大吸引力是能夠存儲大量日志數(shù)據供后期探索，很多大數(shù)據應用就是在大數(shù)據系統(tǒng)將數(shù)據采集上來之后才出現(xiàn)的。

為什么一定要單獨建立數(shù)據湖呢?要回答這個問題，我們先來了解數(shù)據湖的一個重要組成部分—ODS(Operating Data Store，運營數(shù)據存儲)。在20世紀90年代數(shù)據倉庫剛出來的時候，就已經有ODS了?？梢哉fODS是數(shù)據湖的先行者，因為ODS和數(shù)據湖有兩個共同的重要特征：不加轉換的原始數(shù)據，可以進行不預先設置的分析。ODS一般用來存儲業(yè)務運營數(shù)據，也就是OLTP(聯(lián)機事務處理)數(shù)據的快照和歷史，而數(shù)據倉庫一般用來存儲分析數(shù)據，對應OLAP(聯(lián)機分析處理)需求。下表列出了OLTP和OLAP的一些區(qū)別。

OLTP和OLAP的區(qū)別

絕大多數(shù)情況下，業(yè)務數(shù)據庫的SQL庫表的結構與數(shù)據倉庫的結構是不一樣的：業(yè)務數(shù)據庫是為OLTP設計的，是系統(tǒng)實時狀態(tài)的數(shù)據;而數(shù)據倉庫的數(shù)據是為OLAP的需求建設的，是為了深度的多維度分析。這個差異造成基于數(shù)據倉庫的數(shù)據分析受到以下限制：

• 數(shù)據倉庫的架構設計是事先定好的，很難做到全面覆蓋，因此基于數(shù)據倉庫的分析是受到事先定義的分析目標及數(shù)據庫Schema限制的;
• 從OLTP的實時狀態(tài)到OLAP的分析數(shù)據的轉換中會有不少信息損失，例如某個賬戶在某個具體時間點的余額，在OLTP系統(tǒng)里一般只存儲最新的值，在OLAP系統(tǒng)里只會存儲對賬戶操作的交易，一般不會專門存儲歷史余額，這就使得進行基于歷史余額的分析非常困難。

因此，在建立數(shù)據倉庫的時候，我們必須先將OLTP數(shù)據導入ODS，然后在ODS上進行ETL操作，生成便于分析的數(shù)據，最后將其導入數(shù)據倉庫。這也是為什么ODS有時也被稱為數(shù)據準備區(qū)(staging area)。

隨著Hadoop的逐漸普及，大家發(fā)現(xiàn)數(shù)據倉庫底層的技術(關系型數(shù)據庫)無法處理一些非結構化數(shù)據，最典型的就是服務器日志包含的數(shù)據。除了這些分析上的功能缺陷之外，傳統(tǒng)數(shù)據倉庫底層使用的關系型數(shù)據庫在處理能力上有很大局限，這也是數(shù)據湖，直至整個大數(shù)據生態(tài)出現(xiàn)的一個主要原因。在Hadoop出現(xiàn)之前，就有Teradata和Vertica等公司試圖使用MPP(Massively Parallel Processing，大規(guī)模并行處理)數(shù)據庫技術來解決數(shù)據倉庫的性能問題。在Hadoop出現(xiàn)之后，Hive成為一個比較廉價的數(shù)據倉庫實現(xiàn)方式，也出現(xiàn)了Presto、Impala這些SQL-on-Hadoop的開源MPP系統(tǒng)。從2010年開始，業(yè)界逐漸將ODS、采集的日志以及其他存放在Hadoop上的非結構或半結構化數(shù)據統(tǒng)稱為數(shù)據湖。有時，數(shù)據湖中直接存儲源數(shù)據副本的部分(包括ODS和日志存儲)被稱為貼源數(shù)據層，意思是原始數(shù)據的最直接副本。

從根本上來講，數(shù)據湖的最主要目標是盡可能保持業(yè)務的可還原度。例如，在處理業(yè)務交易的時候，數(shù)據湖不僅會把OLTP業(yè)務數(shù)據庫的交易記錄采集到數(shù)據湖中的ODS，也會把產生這筆交易的相關服務器日志采集到數(shù)據湖的HDFS文件系統(tǒng)中，有時還會把發(fā)回給客戶的交易憑證作為文檔數(shù)據存放。這樣，在分析與這筆交易相關的信息時，系統(tǒng)能夠知道這筆交易產生的渠道(從服務器分析出來的訪問路徑)，給客戶的憑證是否有不合理的數(shù)據格式(因為憑證的格式很多時候是可以動態(tài)變化的)。

02數(shù)據湖建設的4個目標

數(shù)據湖的建設方式有很多種，有的企業(yè)使用以Hadoop為核心的數(shù)據湖實現(xiàn)，有的企業(yè)以MPP為核心加上一些對象存儲來實現(xiàn)。雖然建設方式不同，但是它們建設數(shù)據湖的目標是一致的，主要有以下4點。

1)高效采集和存儲盡可能多的數(shù)據。將盡可能多的有用數(shù)據存放在數(shù)據湖中，為后續(xù)的數(shù)據分析和業(yè)務迭代做準備。一般來說，這里的“有用數(shù)據”就是指能夠提高業(yè)務還原度的數(shù)據。

2)對數(shù)據倉庫的支持。數(shù)據湖可以看作數(shù)據倉庫的主要數(shù)據來源。業(yè)務用戶需要高性能的數(shù)據湖來對PB級數(shù)據運行復雜的SQL查詢，以返回復雜的分析輸出。

3)數(shù)據探索、發(fā)現(xiàn)和共享。允許高效、自由、基于數(shù)據湖的數(shù)據探索、發(fā)現(xiàn)和共享。在很多情況下，數(shù)據工程師和數(shù)據分析師需要運行SQL查詢來分析海量數(shù)據湖數(shù)據。諸如Hive、Presto、Impala之類的工具使用數(shù)據目錄來構建友好的SQL邏輯架構，以查詢存儲在選定格式文件中的基礎數(shù)據。這允許直接在數(shù)據文件中查詢結構化和非結構化數(shù)據。

4)機器學習。數(shù)據科學家通常需要對龐大的數(shù)據集運行機器學習算法以進行預測。數(shù)據湖提供對企業(yè)范圍數(shù)據的訪問，以便于用戶通過探索和挖掘數(shù)據來獲取業(yè)務洞見。

基于這幾個目標，數(shù)據湖必須支持以下特性。

數(shù)據源的全面性：數(shù)據湖應該能夠從任何來源高速、高效地收集數(shù)據，幫助執(zhí)行完整而深入的數(shù)據分析。

• 數(shù)據可訪問性：以安全授權的方式支持組織/部門范圍內的數(shù)據訪問，包括數(shù)據專業(yè)人員和企業(yè)等的訪問，而不受IT部門的束縛。
• 數(shù)據及時性和正確性：數(shù)據很重要，但前提是及時接收正確的數(shù)據。所有用戶都有一個有效的時間窗口，在此期間正確的信息會影響他們的決策。
• 工具的多樣性：借助組織范圍的數(shù)據，數(shù)據湖應使用戶能夠使用所需的工具集構建其報告和模型。

03數(shù)據湖數(shù)據的采集和存儲

數(shù)據采集系統(tǒng)負責將原始數(shù)據從源頭采集到數(shù)據湖中。數(shù)據湖中主要采集如下數(shù)據。

1)ODS：存儲來自各業(yè)務系統(tǒng)(生產系統(tǒng))的原始數(shù)據，一般以定時快照的方式從生產數(shù)據庫中采集，或者采用變化數(shù)據捕獲(Change Data Capture，CDC)的方式從數(shù)據庫日志中采集。后者稍微復雜一些，但是可以減少數(shù)據庫服務器的負載，達到更好的實時性。在從生產數(shù)據庫中采集的時候，建議設置主從集群并從從庫中采集，以避免造成對生產數(shù)據庫的性能影響。

2)服務器日志：系統(tǒng)中各個服務器產生的各種事件日志。典型例子是互聯(lián)網服務器的日志，其中包含頁面請求的歷史記錄，如客戶端IP地址、請求日期/ 時間、請求的網頁、HTTP代碼、提供的字節(jié)數(shù)、用戶代理、引用地址等。這些數(shù)據可能都在一個文件中，也可能分隔成不同的日志，如訪問日志、錯誤日志、引薦者日志等。我們通常會將各個業(yè)務應用的日志不加改動地采集到數(shù)據湖中。

3)動態(tài)數(shù)據：有些動態(tài)產生的數(shù)據不在業(yè)務系統(tǒng)中，例如為客戶動態(tài)產生的推薦產品、客戶行為的埋點數(shù)據等。這些數(shù)據有時在服務器日志中，但更多的時候要以獨立的數(shù)據表或Web Service的方式進行采集。埋點是數(shù)據采集領域(尤其是用戶行為數(shù)據采集領域)的術語，指的是對特定用戶行為或事件進行捕獲、處理和發(fā)送的相關技術及其實施過程，比如用戶點擊某個圖標的次數(shù)、觀看某個視頻的時長等。埋點是用戶行為分析中非常重要的環(huán)節(jié)，決定了數(shù)據的廣度、深度、質量，能影響后續(xù)所有的環(huán)節(jié)。因此，這部分埋點數(shù)據應該采集到數(shù)據湖中。

4)第三方數(shù)據：從第三方獲得的數(shù)據，例如用戶的征信數(shù)據、廣告投放的用戶行為數(shù)據、應用商店的下載數(shù)據等。

采集這些原始數(shù)據的常見方式如下。

• 傳統(tǒng)數(shù)據庫數(shù)據采集：數(shù)據庫采集是通過Sqoop或DataX等采集工具，將數(shù)據庫中的數(shù)據上傳到Hadoop的分布式文件系統(tǒng)中，并創(chuàng)建對應的Hive表的過程。數(shù)據庫采集分為全量采集和增量采集，全量采集是一次性將某個源表中的數(shù)據全部采集過來，增量采集是定時從源表中采集新數(shù)據。
• Kafka實時數(shù)據采集：Web服務的數(shù)據常常會寫入Kafka，通過Kafka快速高效地傳輸?shù)紿adoop中。由Confluent開源的Kafka Connect架構能很方便地支持將Kafka中的數(shù)據傳輸?shù)紿ive表中。
• 日志文件采集：對于日志文件，通常會采用Flume或Logstash來采集。
• 爬蟲程序采集：很多網頁數(shù)據需要編寫爬蟲程序模擬登錄并進行頁面分析來獲取。
• Web Service數(shù)據采集：有的數(shù)據提供商會提供基于HTTP的數(shù)據接口，用戶需要編寫程序來訪問這些接口以持續(xù)獲取數(shù)據。

數(shù)據湖需要支持海量異構數(shù)據的存儲。下面是一些常見的存儲系統(tǒng)及其適用的數(shù)據類型。

• HDFS：一般用來存儲日志數(shù)據和作為通用文件系統(tǒng)。
• Hive：一般用來存儲ODS和導入的關系型數(shù)據。
• 鍵-值存儲(Key-value Store)：例如Cassandra、HBase、ClickHouse等，適合對性能和可擴展性有要求的加載和查詢場景，如物聯(lián)網、用戶推薦和個性化引擎等。
• 文檔數(shù)據庫(Document Store)：例如MongoDB、Couchbase等，適合對數(shù)據存儲有擴展性要求的場景，如處理游戲賬號、票務及實時天氣警報等。
• 圖數(shù)據庫(Graph Store)：例如Neo4j、JanusGraph等，用于在處理大型數(shù)據集時建立數(shù)據關系并提供快速查詢，如進行相關商品的推薦和促銷，建立社交圖譜以增強內容個性化等。
• 對象存儲(Object Store)：例如Ceph、Amazon S3等，適合更新變動較少的對象文件數(shù)據、沒有目錄結構的文件和不能直接打開或修改的文件，如圖片存儲、視頻存儲等。

一般來講，數(shù)據湖的存儲應該支持以下特性。

1)可擴展性。企業(yè)數(shù)據湖充當整個組織或部門數(shù)據的集中數(shù)據存儲，它必須能夠彈性擴展。注意，雖然云原生架構比較容易支持彈性擴展，但是數(shù)據中心都會有空間和電力限制，準備建設大規(guī)模數(shù)據湖的企業(yè)需要考慮多數(shù)據中心或混合云的架構，否則就會陷入幾年就要“搬家”的窘境。

2)數(shù)據高可用性。數(shù)據的及時性和持續(xù)可用性是輔助決策制定的關鍵，因此必須使用HDFS、Ceph、GlusterFS等支持多備份、分布式高可用的架構。

3)高效的存儲效率。數(shù)據湖的數(shù)據量是以PB計的，而且因為需要多備份(3份或更多)，其存儲效率就非常重要。例如，使用LZO壓縮存儲HDFS文件可以達到1∶6甚至1∶7的壓縮比例，而且可以通過系統(tǒng)支持實現(xiàn)透明訪問，也就是說，程序可以直接使用數(shù)據而無須先展開到臨時空間。另外，列式存儲也是一種常用的利于壓縮的存儲方式。存儲效率越高，意味著需要的服務器越少，使用的電量越少，擴容的時間間隔越長，因此存儲效率對數(shù)據湖的運營非常重要。

4)數(shù)據持久性。數(shù)據一旦存儲，就不能因為磁盤、設備、災難或任何其他因素而丟失。除了使用分布式架構，一般還需要考慮多數(shù)據中心和混合云架構支持的異地備份。

5)安全性。對于本地和基于云的企業(yè)數(shù)據湖來說，安全都是至關重要的，應將其放在首位。例如，數(shù)據必須經過加密，必須不可變(在任何需要的地方)，并且必須符合行業(yè)標準;數(shù)據系統(tǒng)的訪問必須支持端到端的授權和鑒權集成等。應該從剛開始建設數(shù)據湖時就進行安全性的設計，并將其納入基本的體系結構和設計中。只有在企業(yè)整體安全基礎架構和控件的框架內部署和管理，數(shù)據湖的安全性才有保障。

6)治理和審計。要能夠應用治理規(guī)則及數(shù)據不變性，識別用戶隱私數(shù)據以及提供完整的數(shù)據使用審計日志的能力，這對于滿足法規(guī)和法定要求至關重要。

7)可以存儲任何內容。數(shù)據湖在設計之初，有一個主要考慮的因素：存儲任何格式(結構化和非結構化)的數(shù)據并提供快速檢索。當然，這里的“快速”并不是說要像面向用戶的系統(tǒng)一樣提供實時響應，在數(shù)據湖上運行的應用對交互的要求會低一些。即便如此，Presto、Impala等SQL-on-Hadoop的解決方案正在逐步提高數(shù)據湖的交互體驗。

8)可以支持不同存儲文件的大小和格式。在很多場景中，系統(tǒng)需要存儲很多小文件，這些文件的尺寸遠小于Hadoop文件系統(tǒng)(HDFS)的默認塊大小128MB。在基于Hadoop的框架中，每個文件在集群的名稱節(jié)點的內存中均表示為一個對象，每個對象通常占用150B。這意味著大量文件將消耗大量內存。因此，大多數(shù)基于Hadoop的框架無法有效使用小文件。另一個重要方面是文件的格式，例如使用列存儲(ORC和Parquet)可以加大文件的壓縮比例，在讀取時僅解壓縮和處理當前查詢所需的值，這樣可以大大減少磁盤I/O和查詢時間。

04數(shù)據湖中的數(shù)據治理

很多人認為數(shù)據湖中存儲的是原始數(shù)據，不需要治理，這其實是個誤區(qū)。確切地說，數(shù)據湖存儲的是未經轉換的數(shù)據，任何需要支持分析的數(shù)據都是需要治理的。數(shù)據治理是指對企業(yè)中數(shù)據的可用性、完整性和安全性的全面管理，具體內容主要取決于企業(yè)的業(yè)務策略和技術實踐。

比如，我們可以要求寫入數(shù)據湖的ODS數(shù)據經過Schema的檢查，確保業(yè)務系統(tǒng)Schema的改變不會未經協(xié)調就進入數(shù)據湖，造成現(xiàn)有數(shù)據湖應用的失效。再比如合規(guī)的要求，數(shù)據湖負責全域數(shù)據采集，其中往往包括消費者的個人可識別信息。這些敏感數(shù)據必須經過合規(guī)處理，以確保系統(tǒng)遵守隱私法律和法規(guī)。因此，從最開始就應將數(shù)據治理納入數(shù)據湖的設計中，至少應采用最低的治理標準。

數(shù)據湖中的數(shù)據治理主要涵蓋以下領域。

• 數(shù)據目錄。由于數(shù)據湖中存儲的數(shù)據量非常大，因此很難跟蹤有哪些數(shù)據可用，而且數(shù)據容易被淹沒。解決方案是維護數(shù)據目錄。數(shù)據目錄是元數(shù)據的集合，結合了數(shù)據管理和搜索工具，可幫助分析師和其他用戶查找數(shù)據。數(shù)據目錄充當可用數(shù)據的清單，并提供信息以評估適用數(shù)據的預期用途。最有效的方法是維護中央數(shù)據目錄，并在各種處理框架(如Hadoop、Spark以及其他可用工具)中使用，這樣可以應用簡單的數(shù)據治理規(guī)則來確保元數(shù)據的完整性。
• 數(shù)據質量。數(shù)據質量系統(tǒng)應該確保數(shù)據的完整性、準確性、一致性以及標準化，否則基于數(shù)據得出的結果是不可靠的，所謂的“垃圾進，垃圾出”(Garbage In, Garbage Out)就是這個意思?，F(xiàn)在并沒有一個通用的數(shù)據質量管理系統(tǒng)適用于數(shù)據湖，但是類似于Delta Lake這樣的項目已經在探索如何解決這些問題。
• 數(shù)據合規(guī)。根據所運營的業(yè)務領域，數(shù)據湖必須滿足一些合規(guī)要求，例如GDPR(《通用數(shù)據保護條例》)、HIPAA(《健康保險便利和責任法案》)和ISO等標準和規(guī)范。對于很多企業(yè)而言，數(shù)據合規(guī)是很重要的工作，數(shù)據合規(guī)一旦出問題，可能導致巨額罰款或者數(shù)據泄露，損害企業(yè)的信譽。

本書摘編自《云原生數(shù)據中臺：架構、方法論與實踐》，經出版方授權發(fā)布。