3個步驟，4大平臺，搞定大規模數據處理

 

本文由百度智能雲大數據平臺技術架構師——李蒞在百度開發者沙龍線上分享的演講內容整理而成。本次分享圍繞雲原生數據湖架構的價值展開，深度數據湖計算和統一元數據的技術架構。希望開發者能夠通過本文對一站式大數據處理平臺構建有初步認識。

文：李蒞

視頻回放：https://developer.baidu.com/live.html?id=14

 

本次分享的主題是：數據湖架構下的大規模數據處理技術實踐。內容主要分爲以下4個方面：

• 背景介紹

• 大數據基礎建設

• 數據湖數倉建設

• 一站式開發平臺

   

 

01背景介紹

什麼是數據湖

數據湖的概念最早出現在2010年 ，此時數據湖是一個集中式的存儲系統，流入任意規模的結構化和非結構化的數據。但這些還是在關注它存儲的相關特性。

隨着對象存儲（BOS）解決了海量數據和低成本存儲問題，用戶更關注挖掘湖中數據的價值。數據湖的重點從存儲轉向數據的計算分析，核心在於強化數據分析的能力。

2017年隨着AI 的興起，深度學習使用大數據處理海量的訓練數據輸入。藉助數據湖架構，可以更好地打通數據之間的壁壘，支撐AI 模型的訓練、推理以及數據的預處理。

 

數據化架構的演進

• 第一個階段在1980年，當時還是傳統的數倉形式：用戶把關係型數據庫的內容採集下來，通過ETL存儲到專門的分析型數據庫中，然後在上層提供BI、報表類的服務。

• 第二個階段在2011年，此時開始引入數據湖的概念：源端的類型也變爲更多結構化的數據和非結構化的數據，包括音頻和視頻等等，然後把這些數據全部都存到數據湖裏。

  接下來會按照兩種情況處理：第一種通過數據預處理之後爲數據科學或機器學習提供訓練的數據輸入。第二種通過傳統的ETL處理，存到分析型數據庫或實時數據庫裏用來提供傳統的報表或BI分析。

• 第三個階段在2020年，此時提出湖倉一體的概念，稱爲Lakehouse。底層數據保持不變，但是使用一個數據湖來對接上層所有應用，其中沒有相關的分析型數據庫或實時數據庫或數據預處理機制，數據湖可以直接對接BI、報表、訓練、數據科學、流式分析等分析類的場景。

   

大數據項目實例

以一個實際的大數據項目爲例來介紹一下如何在大規模數據的背景下建設一個數據湖的數倉。

客戶的場景主要分爲這四方面的內容。

• 進行 採集傳輸。

  其中包括日誌文件採集、數據庫採集和實時消息。

• 採集上來的數據需要進行 清洗加工。

  其中包括非結構化文本解析、數據清洗、格式轉換和初步加工校對。

• 將清洗完的數據用來 構建數倉。

  構建的方式包括實時聚合、天級聚合和按周按月聚合。

• 數倉裏的數據需要提供給下游去進行 數據消費。

  其中包括人員交互、各類報表和API服務。

 

面臨新的挑戰

在這個背景下會遇到一些新的挑戰。

• 首先客戶的數據量指數級地增加的，客戶很期望在數據量暴增的同時改善存儲的成本並且提高計算能力。

• 其次客戶的業務發展之後， 數據類型更加多樣 ，原來可能以關係型數據庫爲主，後來增加了很多很難直接進行分析和計算的數據庫，用戶也希望能夠統一管理。

• 最後，消費數據的 應用類型更加複雜 ，帶來更大的併發訪問量，wokload和性能期望是複雜多樣的。比如有的客戶期望毫秒級的延遲，也有的客戶期望小時級但是數據吞吐量特別大。

   

用百度智能雲來構建數據湖

使用百度智能運來構建數據湖，這是提供的一個數據湖倉解決方案。

其中最底層是湖倉引擎層，它的核心設計有三個產品：

• 託管大數據平臺BMR，用來構建傳統的Hadoop生態

• 數據倉庫Palo，用來存儲一些高性能訪問的數據

• 對象存儲BOS

上層提供一個治理開發平臺——大數據開發分析平臺EasyDAP。

 

02大數據基礎設施建設

網絡規劃

首先對客戶做一個網絡規劃，其中VPC劃分是最重點需要考慮的，一般有以下幾個內容：

• 在線業務VPC

• 離線業務VPC

• 研發測試VPC

• 考慮部門等組織結構狀況進行更細緻的VPC劃分

• VPC之間網絡隔離，保證互不影響和安全性

 有些情況是需要跨VPC去傳輸數據的，通常會有兩種方式去解決：

1）先將數據導入到公共服務比如Kafka或者BOS上，通過中間服務來上傳和下載數據， 公共服務保證各VPC可以訪問。

 2）VPC如果緊密聯繫也可以通過網絡專線來打通。

 

計算集羣規劃

 

接下來對客戶的計算集羣做規劃，這裏使用BMR去快速創建集羣。主要考慮以三個方面。

• 首先是BMR集羣劃分，其中爲客戶提供多種集羣劃分模式依據如下：

1. 按業務劃分，獨立使用。

2. 不同集羣之間是強物理隔離。

3. 便於審計資源消耗。

 

• 在BMR的節點規劃上可以支持千臺級別規模的集羣，平時它也可動態擴縮容和升配。BMR節點類型主要分爲三種：

1. 主節點，數量比較少，主要是存元數據和管控。

2. 核心節點，通常是用來存HDFS，所以希望它保持穩定。

3. 任務節點，可以進行彈性擴縮容。

還可以爲不同類型可設置不同規格硬件，以滿足業務需要，

 

• BMR的資源選擇上主要權衡CPU和內存的比例，其次配置SSD來優化shuffle的IO開銷，這裏主要使用雲磁盤的可靠性和故障恢復能力。其中CPU和內存配比通常考慮：

1. 通用型，1：4。

2. 計算型，1：2。

3. 內存型，1：8。

 

BMR組件介紹

BMR主節點部署的是傳統的Hadoop各種元數據服務，比如NameNode、JournalNode、Zookeeper、ResourceManager等。

核心節點主要是部署如DataNode、HBase的RegionServer這種存儲服務，同時也會混合佈置一些NodeManager，以充分利用計算資源。

任務節點主要是部署NodeManager，同時也會有一些計算的組件比如像Hive中的Tes，Spark中的Presto。

集羣中的存儲主要使用CDS，數據會存儲到BOS中。

 

計算存儲分離

 

整體架構主要考慮計算和存儲分離的思路，來減少計算對存儲的依賴，提高集羣的彈性，以便獲得更高的性價比來降低運營的成本。計算存儲分離主要做以下三件事情。

• 第一件是BOS替代HDFS，這裏面主要是把很多非結構化文件存到BOS中，核心離線數倉Hive也存到BOS中，針對HBase改造它的底層把其中Hfile也存到BOS中。

• 第二件是使用自動擴縮容機制，通過前面的存儲讓核心節點數量最小化，按需擴容任務節點，任務完成後通過自動策略機制及時釋放，可使用相對穩定性差但成本更低的競價實例。

• 第三件是存儲管理使用對象存儲數據生命週期管理機制，短期臨時的數據進行自動TTL清理，對長期存儲的數據進行存儲冷熱分級，冷數據能夠自動下沉到更低成本的介質中。

 

爲什麼選擇對象存儲

大數據場景數據是日積月累的，所以存儲通常要考慮三個方面：

• 易於擴展。

• 低成本。

• 大數據場景下性能滿足需要。

 

BOS在存儲彈性、存儲成本、存儲管理這三個方面都遠勝過HDFS。

• 在存儲彈性方面，BOS是按量付費的，存儲空間幾乎無限，而HDFS需要規劃機型大小，擴縮容成本高，相比之下對象存儲就簡單很多。

• 在存儲成本方面，BOS通過EC編碼技術和規模效應，單GB成本低，而性能優秀。冷數據可以專門歸檔存儲，可以存到像磁帶、藍光這樣的介質中來進一步獲得更低的成本。

• 在存儲管理方面，BOS的存儲管理功能齊全。可以按業務劃分若干Bucket，易於管理權限。配置生命週期規則等自動管理規則。擁有監控報表，工具齊全，便於分析審計使用情況。

 

大數據場景下對象存儲性能

使用兩種方法對比了大數據場景下對象存儲性能。

• 一是比較傳統的SQL分析，使用10TB的TPC-DS，可以從圖表中看出性能基本上沒有太大的差距，各有所長，但是差距又很小。

• 另一種是在HBase在線訪問，On BOS和On兩種CDS相比，數據中可以看出差距很小，所以BOS在大數據場景下面是可以滿足性能需要的。

   

大數據組件適配對象存儲

大數據組件適配對象存儲的時候做了以下的改造工作：

• 首先適配Hadoop接口其中包括FileSystem接口和AbstractFileSystem接口

  保證在路徑寫法上兼容，之前Hadoop生態裏面能直接使用HDFS的路徑一般能使用BOS。

• 其次在BOS數據讀寫上使用BOS的分塊併發上傳來提高性能

  這樣做不佔用本地緩存直接寫入BOS，保證文件傳完纔可見，這樣能夠避免存儲一些髒數據，確保了操作的原子性。

• 元數據，BOS相比於其他友商的好處就是單個文件可以保證強一致性，同時還能支持rename。使用List對象名的前綴來實現，如果目錄層級很深，在高層級做ls的時候性能較差。但是目錄rename不是原子操作，其底層遍歷整個目錄，然後遞歸，併發rename每個對象，內部重試儘可能達到最終一致。

 

彈性擴容

應用BOS之後可以進行彈性擴縮容，例如圖的右側，從底層採集集羣的指標，聚合之後存到監控數據庫，然後規則引擎會不斷去分析規則數據庫中的指標數據，最後應用各種用戶配置的數據規則和策略對節點進行擴縮容管理。

規則引擎分爲兩種，一種是時間觸發規則，還有一種是監控觸發規則，監控規則觸發支持節點的資源監控比如CPU或者Hadoop集羣隊列的監控，然後爲了避免規則引起的震盪引入冷卻時間的機制，一般來說每條規則觸發5-10分鐘之後纔會觸發下一條規則。

然後在進行節點變更時，考慮到存儲的穩定性，自動策略不會觸發到核心節點的自動擴縮容，主要是針對任務節點，任務節點在擴容的時候會去購買虛機，然後部署yarn服務，然後自動把作業給調度上去，縮容的時候可以確保節點作業任務跑完，不讓新的節點調度上去，最後作業跑完之後纔會釋放這個節點。

 

指標採集

自動擴縮容是非常依賴指標採集，這裏設計了一套自動採集的系統，它會把Agent部署到每一臺BMR裏面的虛機上，並跟集羣保持一體化部署，然後採集的指標涵蓋機器指標、服務指標、集羣聚合等各種集羣級的指標，最後下發採集任務之後拉取指標數據，並且把這些存到百度雲的監控雲存儲裏面。

之後其他的地方就能基於這些指標進行devops的操作，爲運維人員和客戶提供監控報警，同時也可以反饋到彈性伸縮擴容決策上。

 

實際應用

存算分離整體應用到具體的業務場景上，需要根據業務制定一些策略比如

• 規律性的定時報表作業，按時間擴容，運行完縮容。

• 輔助以集羣負載指標，和隊列等待指標，來應對更多突發的情況。

• 非核心業務部分應用競價實例獲得更低的成本。

整體應用彈性擴縮容之後，成本下降40%。

 

03數據湖倉建設

數據倉庫規劃

首先對客戶的數據倉庫做一個規劃，這裏套用一些傳統的數倉概念，基本上分爲三層：

• ODS，貼源層，主要用來管理收集整理的原始數據。客戶的各種數據，比如日誌、關係型數據庫、API等，都會通過入湖最終進到ODS層。

• DW，數據倉庫層，一般是比較典型的庫表形式，在此基礎

          1. uDWD 明細層，存放明細數據。

          2. uDWS 服務層，足夠加工的數據，爲應用提供服務，保證時延和併發滿足要求。

• DM，數據集市層，其形態偏向API服務，跟應用形態耦合更加緊密。

   

 

典型場景

典型的應用場景就在統一元數據的框架下都是一套庫表的結構，大概分爲兩種人員，一種是運維人員，一種是分析人員。

• 運維人員主要負責將數據入湖，並且通過ETL對數據進行清洗、加工等。

• 分析人員主要是進行初步消費數倉裏面的數據，進行一些交互式查詢、報表製作之類的操作。

   

統一元數據

在這個場景下，我們爲數據提供統一的元數據服務。

這是自研的一套全局元數據服務，其中提供全局的 REST API 服務，非常方便在雲上各處訪問而不受網絡的限制，它的底層跟Hive，Spark，Presto等打通，相比於原來的Hive元數據可以做到無縫切換，存儲底層採用NewSQL存儲，橫向擴展能力強，支撐海量庫表和分區。有了這樣一套統一的元數據之後可以更好地跟上層數據治理服務相結合。

統一元數據裏面主要分爲兩種表結構，一種是物理表，跟hive表差不多，它的數據存在對象存儲上，用起來也像Hive。另一種是映射表，通常是面向關係型數據庫或者NoSQL，只存儲映射規則不存儲數據，通過SQL查詢的時候底層直接連源庫去查詢。

 

訪問控制

在統一元數據的基礎之上，還根據客戶的需求制定了訪問控制的機制，因爲客戶要對不同人員做細粒度權限的管控和審計，這裏實現了行列權限，實現的思路是：

• 仿照Ranger的機制，實現成插件的形式，集成到Hive或者Spark引擎中。

• 對引擎提供權限查詢接口，讓引擎根據情形做判斷。

• 同時打通了雲IAM和Hadoop UGI體系，這樣在頁面上的操作同時可以帶入到Hadoop集羣裏面。

• 提供界面化的權限管理流程（授權，審批等）

此外還提供數據脫敏機制，將用戶密級和數據密級進行定義（L0~L5），用戶只能訪問對應密級的數據。

如果用戶要訪問比他高的數據就需要進行脫敏訪問，脫敏訪問分爲兩種：

• 靜態脫敏，入湖時通過ETL可應用脫敏UDF處理。

• 動態脫敏，分析時選取密級適配的脫敏UDF，做SQL改寫。

   

入湖分析&聯邦分析

數據湖分析首先要分析湖裏的數據，但是很多用戶通常有一些存量的數據不想入湖，比如以前購買的傳統數倉中的集羣，但是業務上又希望能夠把這些數據跟數據湖裏的數據一起分析。這裏引入一個聯邦分析的概念，一般通過映射規則將數據源註冊成庫表形式，然後底下引擎運行SQL時直接查詢數據源，這種情況跟入湖一樣同時支持豐富的數據源訪問能力。

聯邦分析的 優勢 有以下幾個方面：

• 避免拖數據帶來的開銷，尤其是傳統數倉裏的數據本身就很大，拖數據會產生計算、網絡方面的開銷，同時也有實時性問題。

• 比較適合訪問小表，維度表。

• 對於數據源本來就是數倉的情形，避免拖數據造成重複消耗。

 

聯邦分析的 劣勢 有以下幾個方面：

• 對數據源有直接的訪問壓力，需要謹慎規劃。

• 性能依賴源庫的計算能力，和算子謂詞下推的能力。

   

數據入湖

數據入湖分爲兩種。

一種是 批量入湖 ，通常都是定時作業的形式，直接掃描源庫，寫入數據湖存儲，批量作業通常都是整庫遷移的場景，所以要根據數據圖表結構生成很多批量作業來進行合理的調度來讓它整體運行起來，在這個過程之中也支持Spark算子進行數據清洗。

另一種 實時入湖 ，通過數據傳輸服務DTS，使用CDC技術採集MySQL、Oracle、SQLServer這些關係型數據庫的增量日誌，然後把這些日誌實時寫入Kafka，實時寫入到數據湖的庫表裏面，通常還會定期將增量日誌合入全量表。

 

湖倉一體

在入湖的時候會遇到一些問題：

• 傳統入湖，需要校驗避免引入髒數據，管理成本高，性能差。

• 實時入湖需要 T+1 merge，數據不能及時可見。

• 傳統數據庫的格式的分區管理在對象存儲上性能差，因爲它依賴數據存儲的各種元數據的管理。

 

這樣我們就引入了湖倉一體的技術，首先採用湖倉一體的存儲格式Iceberg能夠帶來以下幾方面的好處：

• 支持ACID事務（支持insert，update，delete），避免引入髒數據。

• 對象存儲友好，因爲它有一個清單文件去管理裏面的文件，所以避免list，rename等降低對BOS元數據的依賴。

• 同‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍時支持Merge on read 實現實時可見。

• 還能通過統一元數據，統一查詢入口，多場景工作負載（ad-hoc，報表等）性能優化，保證性能和統一的訪問體驗，性能優化主要有兩方面：

• 自研存儲緩存系統，通過緩存去加速對對象存儲上面數據的訪問。

• 對存儲格式進行優化，引入了SortKey機制，訪問特定模式時可以獲得更好的性能。

   

統一數據湖分析

在統一元數據的基礎上，基於Trino的引擎去做改造，從而實現了統一的數據湖分析，實現了自研的數據湖分析引擎。

通過統一元數據，將底層Hive表、PALO表和源庫都包裝成統一的視圖形成統一的查詢入口，然後使用Presto SQL進行分析，降低各種SQL的學習成本，然後通過配套的數據資產快速檢索，找到用戶想去查詢的庫表信息，這樣就給統一數據湖分析帶來一些好處。

其中實現了以下幾個方面的核心能力：

• 改造trino引擎讓它可以on 容器的計算節點管理，即申請即用的資源彈性。

• 支持豐富的數據源類型，涵蓋大部分DB，傳統數倉和NoSQL。

• 引擎下推優化，CBO優化。

 

04一站式開發平臺

EasyDAP 一站式全流程管理

EasyDAP一站式開發平臺主要涵蓋以下幾個功能板塊，

• 數據集成。

• 數據開發運維。

• 數據湖分析。

• 數據服務。

• 數據應用。

• 數據治理。

這個平臺可以將前面所有介紹到的大數據開發操作都界面化，然後在同一個平臺上去操作完成。

 

低代碼開發Studio

這個平臺提供低代碼的開發studio，通過插件化的算子，可以在畫布上進行可視化的拖拽和配置，是以節點的形式把線連起來去構建數據流，同時還有在線文檔展示。它是可插拔和熱加載的，還有專用的Classloader解決jar版本衝突。

支持豐富的數據源類型和中間算子：

• 關係型數據庫、NoSQL、大數據存儲hive等。

• 常見的抽取和聚合算子，如格式解析，Join，GroupBy等。

• 支持用戶使用js，python，spark，sql等語言的自定義算子。

   

作業調度

作業調度，主要抽象了三種作業依賴形式：

• 將不同的作業包裝成一個作業組，作業組內不同作業間有一個DAG的依賴關係。

• 跨項目作業間的依賴。

• 時空依賴（週報表依賴天報表）。

   

  然後在作業調度這一塊重點建設以下三個方面：

• 全局邏輯時鐘和每個作業的基線時鐘，作業調度的基線時鐘通過邏輯時鐘來表達。

• 實現了自動化的上下游重算機制。

• 支持事件通知機制。

 

數據血緣

在平臺上構建的作業也爲其提供數據血緣的服務，作業運行的時候通過作業調度或者用戶交互式運行會觸發時間通知。

數據血緣分析模塊收到通知之後就會分析作業字段的解析，SQL行列的解析，用戶自己標識的血緣信息也可以提取出來。

基於這些血緣分析的信息，把庫表作位點存儲，把運行的作業作位邊存儲，這樣可以構建一個血緣關係圖，然後存到圖數據庫裏面，可以基於此進行搜索。

最後通過界面把這些血緣關係展示出來，可以在界面上去搜索庫表，然後展示以庫表爲中心的血緣（可以支持到列的粒度），也支持整顆依賴樹的展示。

 

數據質量

數據作業還提供數據質量圖，我們給庫表去配置一些質量相關的算子，這樣用戶可以定時去跑作業分析庫表的四個特徵維度，然後根據這四個特徵維度去形成對應的質量報表和監控數據。

以上是老師的全部分享內容，有問題歡迎在評論區提出。

 往期推薦 

🔗

可視化神器背後的奧祕

6000字，詳解數據倉庫明星產品背後的技術奧祕

掃描二維碼，備註：大數據開發，立即加入大數據產品&技術交流羣。