作者
高爽，基智科技資料中心負責人
尚子鈞，資料研發工程師
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_{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 資料 Merge & Clones
由于 Delta Lake 的資料僅接入實時資料，對于存量曆史資料我們是通過 SparkSQL 一次性 Sink Delta Lake 的表中，這樣我們流和批處理時隻維護一張 Delta 表，是以我們隻在最初對這兩部分資料做一次 merge 操作。
同時為了保證資料的高安全，我們使用 Databricks Deep Clone 每天會定時更新來維護一張從表以備用。對于每日新增的資料，使用 Deep Clone 同樣隻會對新資料 Insert 對需要更新的資料 Update 操作，這樣可以大大提高執行效率。
CREATE OR REPLACE TABLE delta.delta_{table_name}_clone
DEEP CLONE delta.delta_{table_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 資料洞察産品交流釘釘群一起參與交流讨論！