作者
高爽，基智科技數據中心負責人
尚子鈞，數據研發工程師
1、基智科技
北京基智科技有限公司是一家提供智能營銷服務的科技公司。公司願景是基於 AI 和大數據分析為 B2B 企業提供全流程的智能營銷服務。公司秉承開放，挑戰，專業，創新的價值觀從線索挖掘到 AI 智達、CRM 客戶管理覆蓋客戶全生命週期，實現全渠道的營銷和數據分析決策，幫助企業高效引流，精準拓客，以更低的成本獲取更多的商機。截至目前，基智科技已與包括房產、教育、汽車、企業服務等領域展開廣泛合作。
2、背景
在基智科技目前的離線計算任務中，大部分數據源都是來自於業務 DB(MySQL) 。業務 DB 數據接入的準確性、穩定性和及時性，決定著下游整個離線計算 pipeline 的準確性和及時性。最初我們在 ECS 上搭建了自己的 Hadoop 集群，每天使用 Sqoop 同步 MySQL 數據，再經由 Spark ETL 任務，落表寫入 Hive ，ES，MongoDB 、MySQL ，通過調用 Service API 做頁籤的展示。
我們的 ETL 任務一般在凌晨1點開始運行，數據處理階段約1h， Load 階段1h+，整體執行時間為2-3h，下圖為我們的 ETL 過程：
3、存在的問題
上面的架構在使用的過程中以下幾個問題比較突出：
- 隨著業務數據的增長，受 DB 性能瓶頸影響突出。
- 需要維護多套數據源，數據冗雜，容易形成數據孤島使用不方便。
- 天級 ETL 任務耗時久，影響下游依賴的產出時間。
- 數據主要存儲在 HDFS 上，隨著數據的增加，需要增加集群，成本這一塊也是不小的開銷。
- 大數據平臺運維成本高。
4、選擇 Databricks 數據洞察 Delta Lake的原因
為了解決天級 ETL 逐漸尖銳的問題，減少資源成本、提前數據產出，我們決定將T+1級 ETL 任務轉換成T+0實時數據入庫，在保證數據一致的前提下，做到數據落地即可用。
考慮過使用 Lambda 架構在離線、實時分別維護一份數據但在實際使用過程中無法保證事務性，隨著數據量增大查詢性能低，操作較複雜維護成本比較高等問題最終沒能達到理想化使用。
後來我們決定選擇數據湖架構，緊接著考察了市場上主流的數據湖架構：Delta Lake（開源和商業版）& Hudi。二者都支持了 ACID 語義、Upsert、Schema 動態變更、Time Travel 等功能，但也存在差異比如：
Delta Lake 優勢：
- 支持 Java 、Scala 、Python 及 SQL。
- 支持作為 source 流式讀寫，批流操作簡捷。
Delta Lake 不足：
- 引擎強綁定 spark 。
- 需要手動合併小文件。
Hudi 優勢：
- 基於主鍵的快速 Upsert / Delete 。
- 支持小文件自動合併。
Hudi 不足：
- 不能支持 SQL 。
- API 較為複雜。
綜合以上指標，加上我們之前的平臺就是基於阿里雲平臺搭建，選型時阿里雲尚未支持 Hudi ，最終我們選擇了阿里雲 Databricks 數據洞察（商業版 Delta Lake 專業性更強）。同時 Databricks 數據洞察提供全託管服務，能夠免去我們的運維成本。
5、整體架構圖
整體的架構如上圖所示。我們接入的數據會分為兩部分,存量歷史數據和實時數據，存量數據使用 Spark 將 MySQL 全量數據導入 Delta Lake 的表中， 實時數據使用 Binlog 採集實時寫入到 Delta Lake 表中，這樣實時數據和歷史數據都同步到同一份表裡面真正實現批流一體操作。
集群遷移
前期在阿里同事的協助下我們完成了數據遷移的工作，實現在Databricks數據洞察架構下數據開發工作，我們的前期做的準備如下：
- 數據存儲將Hive數倉數據遷移到OSS，數據同步繼續使用Sqoop定時執行。
- 元數據管理從自建Hadoop集群遷移到阿里雲RDS MySQL，後面隨著我們業務的擴展會轉入DLF元數據湖管理。
- 大數據分析架構由自建CDH遷移到Databricks數據洞察。
Delta Lake 數據接入
每天做ETL數據清洗，做表的merge操作 ，delta表結構為:
%sql
CREATE TABLE IF NOT EXISTS delta.delta_{db_name}(
id bigint,
uname string,
dom string,
email string,
update timestamp
)
USING delta
LOCATION '------/delta/'%sql
MERGE INTO delta.delta_{db_name} AS A
USING(SELECT * FROM rds.table_{db_name}_{table_name} where day= date_format(data_sub(current_date,1),'yyyy-mm-dd') AS B
ON A.id=B.id
WHEN MATCHED THEN
update set
A.uname=B.neme,
A.dom=B.dom,
A.email=B.email,
A.update=current_timestamp()
WHEN NOT MATCHED
THEN INSERT
(A.uname,A.dom,A.email,current_timestamp())6、Delta Lake 數據 Merge & Clones
由於 Delta Lake 的數據僅接入實時數據，對於存量歷史數據我們是通過 SparkSQL 一次性 Sink Delta Lake 的表中，這樣我們流和批處理時只維護一張 Delta 表，所以我們只在最初對這兩部分數據做一次 merge 操作。
同時為了保證數據的高安全，我們使用 Databricks Deep Clone 每天會定時更新來維護一張從表以備用。對於每日新增的數據，使用 Deep Clone 同樣只會對新數據 Insert 對需要更新的數據 Update 操作，這樣可以大大提高執行效率。
CREATE OR REPLACE TABLE delta.delta_{db_name}_clone
DEEP CLONE delta.delta_{db_name};7、產生的效益
- 節省了 DB 從庫的成本，同時 Databricks 數據洞察全託管架構我們節省了人力成本（省1運維+2名大數據）因此我們採用商業版 Databricks 數據洞察 Delta Lake 流批一體架構之後，整體成本有很大節省。
- 得益於商業版 Databricks 數據洞察 Delta Lake 高效的執行引擎，執行效率上6-10的性能提升。
- 實現了計算和存儲分離，同時基於 DLF 元數據湖管理，可擴展性明顯提高。
- 商業版 Databricks 數據洞察提供了一整套批流處理的 Spark API 使我們研發工作高效便捷了很多。
8、後續計劃
- 基於 Delta Lake ，進一步打造優化實時數倉結構，提升部分業務指標實時性，滿足更多更實時的業務需求。
- 持續觀察優化 Delta 表查詢計算性能，嘗試使用 Delta 的更多功能，比如 Z-Ordering ，提升在即席查詢及數據分析場景下的性能。
獲取更詳細的 Databricks 數據洞察相關信息，可至產品詳情頁查看：
https://www.aliyun.com/product/bigdata/spark
阿里巴巴開源大數據技術團隊成立 Apache Spark 中國技術社區，定期推送精彩案例，技術專家直播，只為營造純粹的 Spark 氛圍，歡迎關注公眾號！
掃描下方二維碼入 Databricks 數據洞察產品交流釘釘群一起參與交流討論！