企業如何借實時湖倉贏在“資料制勝”時代？

如果說，Hadoop的出現，標誌著企業IT架構進入大資料時代;那麼，以實時湖倉為代表的新IT架構，則把大資料推向更現代化的技術棧。

近日，實時數倉專題研討會以閉門會議的形式成功召開，北京滴普科技有限公司FastData DLink PDT計算引擎部總監張趙中，以《實時湖倉一體平臺的落地與實踐》為主題，與來自銀行、證券、保險、製造、網際網路等行業技術高層匯聚一堂，共話實時數倉。

透過Data Mesh實時撈取資料

提到湖倉一體，我們再熟悉不過，和流批一體一樣，都是大資料領域前沿概念。問題是，實時湖倉一體概念我們該如何理解?

“大資料技術越來越成熟，企業對資料時效性要求越來越高，之前Hadoop時代的T+1鏈路已經不能滿足業務需求。” 張趙中認為，實時湖倉一體的出現，是大資料技術及企業業務雙重推動的結果。

半結構化、非結構化資料的出現，使得原來只能處理關係型資料的Hadoop，出現了難以跨越的鴻溝。首先，時效性差。對於企業管理者以及營銷人員來說，更希望實時看到業務資料，而不是T+1天，只能看到事後資料。其次，無法統一管理資料。在傳統資料架構下，大量資料無法統一管理、統一運維、統一許可權管控。

此種背景下，北京滴普科技有限公司提出一個新概念，那就是類似於網格架構的Mesh。我們可以把Mesh當作是一個資料網格，在這種架構下，使用者不需要搬運資料，因為資料本身就散落在各個系統中，然後透過統一的引擎或者技術把後設資料給管理起來，在做實時性探查的時候，直接撈取資料就可以了，這也是典型的存算分離架構。

採用Iceberg實現資料統一管理

從具體技術架構來看，實時湖倉一體主要分為四層：最底層是資料儲存層、再往上是表格式層、資料加速層和計算引擎層。儲存層可以是Amazon S3、阿里雲OSS、HDFS等，只負責儲存;表格式層，需要對資料進行編織，把資料抽象成一個類似於 table format 這種格式;資料加速層，提供的是本地資料快取和後設資料加速服務;最上面一層，是Spark、Flink等計算引擎。實時湖倉一體的本質是，透過四層架構實現了資料的實時流動，包括資料進來如何取，如何算，最後產出結果。

其中，在表格式層會引入湖倉一體的核心技術，包括Delta Lake 、Iceberg和Hudi。Delta Lake在國內的應用比較少，大多數企業會選擇Iceberg或者Hudi部署湖倉一體架構。那麼，滴普在構建實時湖倉一體技術架構時，為什麼要選擇Iceberg?

主要基於以下6個原因：

1)支援Schema和分割槽演進，方便使用者靈活的動態調整表結構和分割槽結構。

2)支援隱藏分割槽，使用者可以不需要指定分割槽鍵，即可實現分割槽過濾的效果，SQL更加智慧化。

3)統一的對外介面，不會出現多引擎之間訪問不相容的問題。良好的使用者體驗，Iceberg 配置引數較少。

4)支援謂詞和聚合下推，可以更好地過濾資料，提升查詢效能。

5)支援 Python 語言，可以支援機器學習領域的開發，對非結構化資料進行統一管理。比如，透過實時和離線方式把資料拉取到平臺上來的時候，如何把後設資料給抽取進來，形成一個非結構化資料的後設資料層，做統一管理和許可權管控，然後進行資料加工，這點非常重要。

6)支援最高的事務隔離級別，支援併發讀寫，不需要依賴外部元件控制鎖。

簡單理解，Iceberg最大的優勢在於，不會和任何引擎繫結，擁有獨立的table format 層。當然，隨著技術路線的逐漸成熟，Iceberg和Hudi都在各自補齊，功能都差不多。所以，實時湖倉一體的關鍵點，不是選擇Iceberg還是 Hudi，而是整體架構的落地。

DLink讓整庫資料流批一體入湖

大體來看，資料入湖這一層，是實時湖倉一體架構搭建過程中遇到的一大痛點。比如：表的動態性做得不夠、schema 在變更時不能實現ODS 層同步、不能做斷點續傳、無法做存量資料和增量資料的一體化等等。

而有了實時湖倉引擎DLink，使用者就可以實現整庫多表入湖、存量和增量資料的一體化入湖，同時還可以實現執行時的DDL變更(新增列，新增表)等。

當資料從各種業務庫資料採集出來，會直接進入DDL處理運算元，然後所有變更也會同步，Apply 到ODS層。只不過，DDL 種類很多，有的種類還很危險，使用者可以自主選擇。但在數倉裡，一般不推薦個別動作，比如不會drop資料表。一旦業務庫的有些表drop 掉，數倉一般不drop，最多會做一些列刪除動作。

另外，構建實時湖倉，少不了表運維能力。因為，既然資料是實時寫入，而且又有分割槽寫入，還涉及多長時間 commit (提交事務)，導致各種各樣的小檔案問題出現，同時還涉及資料檔案跟刪除檔案合併的問題……這些問題搞不定，資料湖就“玩不轉”。DLink 把這一切過程實現了自動化，在 DLink 上構建後臺，可以自動合併小檔案任務，讓使用者忘記繁重的表運維任務，進而實現Iceberg開箱即用。

以某半導體客戶為例，這家企業之前是基於CDH(6.3.2)技術棧搭建的大資料平臺，每天需要定時去業務庫拉資料，然後透過Impala去做查詢，再加個Apache Kudu做一些去重的動作。但是，因為資料量龐大，總計20萬億條資料，單表每天5億條資料，系統架構已經無法支撐。通常是，歷史資料還沒跑完，當天資料就已經進來了。後來，他們透過DLink平臺把表全部建在Iceberg上，在流式資料入湖的時候就實現了流式去重。新系統構建上線後，帶來的資料處理速度有了質的提升，之前是T+1，現在控制到2分鐘內完成。

技術在不斷進步，實時湖倉一體架構也在不斷演進。Iceberg本質上是個微批，寫一段資料進行commit後下遊才可見，如果不這樣做，小檔案的事務會特別多。所以，為了幫助使用者贏在“資料制勝”時代，DLink的下一步計劃是，透過Iceberg實現秒級甚至亞秒級的實時數倉。另外，Iceberg未來也不是DLink的唯一核心技術，也正在把Hudi引入進來。最後，自適應實時物化檢視功能，也可以解決大部分實時數倉的需求，讓資料一層一層地往下流轉，實現二級物化檢視的再造，進而滿足業務資料的實時性處理需求。