[[421588]]

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

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

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

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

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

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

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

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

OLTP和OLAP的區(qū)別

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

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

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

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

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

02數(shù)據(jù)湖建設(shè)的4個目標(biāo)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4)數(shù)據(jù)持久性。數(shù)據(jù)一旦存儲，就不能因?yàn)榇疟P、設(shè)備、災(zāi)難或任何其他因素而丟失。除了使用分布式架構(gòu)，一般還需要考慮多數(shù)據(jù)中心和混合云架構(gòu)支持的異地備份。

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

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

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

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

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

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

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

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

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

本書摘編自《云原生數(shù)據(jù)中臺：架構(gòu)、方法論與實(shí)踐》，經(jīng)出版方授權(quán)發(fā)布。