[[421588]]

本文轉載自微信公眾號「數倉寶貝庫」，作者彭鋒 等。轉載本文請聯系數倉寶貝庫公眾號。

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

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

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

從數據采集到提供數據服務的流程圖

01數據湖的起源與作用

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

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

OLTP和OLAP的區別

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

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

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

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

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

02數據湖建設的4個目標

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

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

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

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

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

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

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

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

03數據湖數據的采集和存儲

數據采集系統負責將原始數據從源頭采集到數據湖中。數據湖中主要采集如下數據。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04數據湖中的數據治理

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

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

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

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

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