Delta Lake 實(shí)踐 | Databricks 數(shù)據(jù)洞察 Delta Lake 在基智科技（STEPONE）的應(yīng)用實(shí)踐
作者
高爽，基智科技數(shù)據(jù)中心負(fù)責(zé)人
尚子鈞，數(shù)據(jù)研發(fā)工程師
1
基智科技
北京基智科技有限公司是一家提供智能營(yíng)銷服務(wù)的科技公司。公司愿景是基于 AI 和大數(shù)據(jù)分析為 B2B 企業(yè)提供全流程的智能營(yíng)銷服務(wù)。公司秉承開放，挑戰(zhàn)，專業(yè)，創(chuàng)新的價(jià)值觀從線索挖掘到 AI 智達(dá)、CRM 客戶管理覆蓋客戶全生命周期，實(shí)現(xiàn)全渠道的營(yíng)銷和數(shù)據(jù)分析決策，幫助企業(yè)高效引流，精準(zhǔn)拓客，以更低的成本獲取更多的商機(jī)。截至目前，基智科技已與包括房產(chǎn)、教育、汽車、企業(yè)服務(wù)等領(lǐng)域展開廣泛合作。
2
背景
在基智科技目前的離線計(jì)算任務(wù)中，大部分?jǐn)?shù)據(jù)源都是來自于業(yè)務(wù) DB(MySQL) 。業(yè)務(wù) DB 數(shù)據(jù)接入的準(zhǔn)確性、穩(wěn)定性和及時(shí)性，決定著下游整個(gè)離線計(jì)算 pipeline 的準(zhǔn)確性和及時(shí)性。最初我們?cè)?ECS 上搭建了自己的 Hadoop 集群，每天使用 Sqoop 同步 MySQL 數(shù)據(jù)，再經(jīng)由 Spark ETL 任務(wù)，落表寫入 Hive ，ES，MongoDB 、MySQL ，通過調(diào)用 Service API 做頁(yè)簽的展示。
我們的 ETL 任務(wù)一般在凌晨1點(diǎn)開始運(yùn)行，數(shù)據(jù)處理階段約1h， Load 階段1h+，整體執(zhí)行時(shí)間為2-3h，下圖為我們的 ETL 過程：
3
存在的問題
上面的架構(gòu)在使用的過程中以下幾個(gè)問題比較突出：
隨著業(yè)務(wù)數(shù)據(jù)的增長(zhǎng)，受 DB 性能瓶頸影響突出。
需要維護(hù)多套數(shù)據(jù)源，數(shù)據(jù)冗雜，容易形成數(shù)據(jù)孤島使用不方便。
天級(jí) ETL 任務(wù)耗時(shí)久，影響下游依賴的產(chǎn)出時(shí)間。
數(shù)據(jù)主要存儲(chǔ)在 HDFS 上，隨著數(shù)據(jù)的增加，需要增加集群，成本這一塊也是不小的開銷。
大數(shù)據(jù)平臺(tái)運(yùn)維成本高。
4
選擇 Databricks 數(shù)據(jù)洞察 Delta Lake
為了解決天級(jí) ETL 逐漸尖銳的問題，減少資源成本、提前數(shù)據(jù)產(chǎn)出，我們決定將T+1級(jí) ETL 任務(wù)轉(zhuǎn)換成T+0實(shí)時(shí)數(shù)據(jù)入庫(kù)，在保證數(shù)據(jù)一致的前提下，做到數(shù)據(jù)落地即可用。
考慮過使用 Lambda 架構(gòu)在離線、實(shí)時(shí)分別維護(hù)一份數(shù)據(jù)但在實(shí)際使用過程中無法保證事務(wù)性，隨著數(shù)據(jù)量增大查詢性能低，操作較復(fù)雜維護(hù)成本比較高等問題最終沒能達(dá)到理想化使用。
后來我們決定選擇數(shù)據(jù)湖架構(gòu)，緊接著考察了市場(chǎng)上主流的數(shù)據(jù)湖架構(gòu)：Delta Lake（開源和商業(yè)版）& Hudi。二者都支持了 ACID 語(yǔ)義、Upsert、Schema 動(dòng)態(tài)變更、Time Travel 等功能，但也存在差異比如：
Delta Lake 優(yōu)勢(shì)：
支持 Java 、Scala 、Python 及 SQL。
支持作為 source 流式讀寫，批流操作簡(jiǎn)捷。
Delta Lake 不足：
引擎強(qiáng)綁定 spark 。
需要手動(dòng)合并小文件。
Hudi 優(yōu)勢(shì)：
基于主鍵的快速 Upsert / Delete 。
支持小文件自動(dòng)合并。
Hudi 不足：
不能支持 SQL 。
API 較為復(fù)雜。
綜合以上指標(biāo)，加上我們之前的平臺(tái)就是基于阿里云平臺(tái)搭建，選型時(shí)阿里云尚未支持 Hudi ，最終我們選擇了阿里云 Databricks 數(shù)據(jù)洞察（商業(yè)版 Delta Lake 專業(yè)性更強(qiáng)）。同時(shí) Databricks 數(shù)據(jù)洞察提供全托管服務(wù)，能夠免去我們的運(yùn)維成本。
5
整體架構(gòu)圖
整體的架構(gòu)如上圖所示。我們接入的數(shù)據(jù)會(huì)分為兩部分,存量歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)，存量數(shù)據(jù)使用 Spark 將 MySQL 全量數(shù)據(jù)導(dǎo)入 Delta Lake 的表中， 實(shí)時(shí)數(shù)據(jù)使用 Binlog 采集實(shí)時(shí)寫入到 Delta Lake 表中，這樣實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)都同步到同一份表里面真正實(shí)現(xiàn)批流一體操作。
集群遷移
前期在阿里同事的協(xié)助下我們完成了數(shù)據(jù)遷移的工作，實(shí)現(xiàn)在Databricks數(shù)據(jù)洞察架構(gòu)下數(shù)據(jù)開發(fā)工作，我們的前期做的準(zhǔn)備如下：
數(shù)據(jù)存儲(chǔ)將Hive數(shù)倉(cāng)數(shù)據(jù)遷移到OSS，數(shù)據(jù)同步繼續(xù)使用Sqoop定時(shí)執(zhí)行。
元數(shù)據(jù)管理從自建Hadoop集群遷移到阿里云RDS MySQL，后面隨著我們業(yè)務(wù)的擴(kuò)展會(huì)轉(zhuǎn)入DLF元數(shù)據(jù)湖管理。
大數(shù)據(jù)分析架構(gòu)由自建CDH遷移到Databricks數(shù)據(jù)洞察。
Delta Lake 數(shù)據(jù)接入
每天做ETL數(shù)據(jù)清洗，做表的merge操作 ，delta表結(jié)構(gòu)為:
%sql
CREATE TABLE IF NOT EXISTS delta.delta_{table_name}(
id bigint,
uname string,
dom string,
email string,
update timestamp,
created timestamp
)
USING delta
LOCATION '------/delta/'
%sql
MERGE INTO delta.delta_{table_name} AS A
USING (SELECT * FROM rds.table_{table_name} where day= date_format (date_sub (current_date,1), 'yyyy-mm-dd') AS B
ON A.id=B.id
WHEN MATCHED THEN
update set
A.uname=B.name,
A.dom=B.dom,
A.email=B.email,
A.updated=current_timestamp()
WHEN NOT MATCHED
THEN INSERT
(A.uname,A.dom,A.email,A.update,A.created) values (B.name,B.dom,B.email,current_timestamp(),current_timestamp())
6
Delta Lake 數(shù)據(jù) Merge & Clones
由于 Delta Lake 的數(shù)據(jù)僅接入實(shí)時(shí)數(shù)據(jù)，對(duì)于存量歷史數(shù)據(jù)我們是通過 SparkSQL 一次性 Sink Delta Lake 的表中，這樣我們流和批處理時(shí)只維護(hù)一張 Delta 表，所以我們只在最初對(duì)這兩部分?jǐn)?shù)據(jù)做一次 merge 操作。
同時(shí)為了保證數(shù)據(jù)的高安全，我們使用 Databricks Deep Clone 每天會(huì)定時(shí)更新來維護(hù)一張從表以備用。對(duì)于每日新增的數(shù)據(jù)，使用 Deep Clone 同樣只會(huì)對(duì)新數(shù)據(jù) Insert 對(duì)需要更新的數(shù)據(jù) Update 操作，這樣可以大大提高執(zhí)行效率。
CREATE OR REPLACE TABLE delta.delta_{table_name}_clone
DEEP CLONE delta.delta_{table_name};
7
產(chǎn)生的效益
節(jié)省了 DB 從庫(kù)的成本，同時(shí) Databricks 數(shù)據(jù)洞察全托管架構(gòu)我們節(jié)省了人力成本（省1運(yùn)維+2名大數(shù)據(jù)）因此我們采用商業(yè)版 Databricks 數(shù)據(jù)洞察 Delta Lake 流批一體架構(gòu)之后，整體成本有很大節(jié)省。
得益于商業(yè)版 Databricks 數(shù)據(jù)洞察 Delta Lake 高效的執(zhí)行引擎，執(zhí)行效率上6-10的性能提升。
實(shí)現(xiàn)了計(jì)算和存儲(chǔ)分離，同時(shí)基于 DLF 元數(shù)據(jù)湖管理，可擴(kuò)展性明顯提高。
商業(yè)版 Databricks 數(shù)據(jù)洞察提供了一整套批流處理的 Spark API 使我們研發(fā)工作高效便捷了很多。
8
后續(xù)計(jì)劃
基于 Delta Lake ，進(jìn)一步打造優(yōu)化實(shí)時(shí)數(shù)倉(cāng)結(jié)構(gòu)，提升部分業(yè)務(wù)指標(biāo)實(shí)時(shí)性，滿足更多更實(shí)時(shí)的業(yè)務(wù)需求。
持續(xù)觀察優(yōu)化 Delta 表查詢計(jì)算性能，嘗試使用 Delta 的更多功能，比如 Z-Ordering ，提升在即席查詢及數(shù)據(jù)分析場(chǎng)景下的性能。
END