簡介：?獲取更詳細(xì)的 Databricks 數(shù)據(jù)洞察相關(guān)信息，可至產(chǎn)品詳情頁查看：https://www.aliyun.com/product/bigdata/spark

作者

高爽，基智科技數(shù)據(jù)中心負(fù)責(zé)人
尚子鈞，數(shù)據(jù)研發(fā)工程師

1、基智科技

北京基智科技有限公司是一家提供智能營銷服務(wù)的科技公司。公司愿景是基于 AI 和大數(shù)據(jù)分析為 B2B 企業(yè)提供全流程的智能營銷服務(wù)。公司秉承開放，挑戰(zhàn)，專業(yè)，創(chuàng)新的價值觀從線索挖掘到 AI 智達、CRM 客戶管理覆蓋客戶全生命周期，實現(xiàn)全渠道的營銷和數(shù)據(jù)分析決策，幫助企業(yè)高效引流，精準(zhǔn)拓客，以更低的成本獲取更多的商機。截至目前，基智科技已與包括房產(chǎn)、教育、汽車、企業(yè)服務(wù)等領(lǐng)域展開廣泛合作。

2、背景

在基智科技目前的離線計算任務(wù)中，大部分?jǐn)?shù)據(jù)源都是來自于業(yè)務(wù) DB(MySQL) 。業(yè)務(wù) DB 數(shù)據(jù)接入的準(zhǔn)確性、穩(wěn)定性和及時性，決定著下游整個離線計算 pipeline 的準(zhǔn)確性和及時性。最初我們在 ECS 上搭建了自己的 Hadoop 集群，每天使用 Sqoop 同步 MySQL 數(shù)據(jù)，再經(jīng)由 Spark ETL 任務(wù)，落表寫入 Hive ，ES，MongoDB 、MySQL ，通過調(diào)用 Service API 做頁簽的展示。

我們的 ETL 任務(wù)一般在凌晨1點開始運行，數(shù)據(jù)處理階段約1h， Load 階段1h+，整體執(zhí)行時間為2-3h，下圖為我們的 ETL 過程：

3、存在的問題

上面的架構(gòu)在使用的過程中以下幾個問題比較突出：

• 隨著業(yè)務(wù)數(shù)據(jù)的增長，受 DB 性能瓶頸影響突出。
• 需要維護多套數(shù)據(jù)源，數(shù)據(jù)冗雜，容易形成數(shù)據(jù)孤島使用不方便。
• 天級 ETL 任務(wù)耗時久，影響下游依賴的產(chǎn)出時間。
• 數(shù)據(jù)主要存儲在 HDFS 上，隨著數(shù)據(jù)的增加，需要增加集群，成本這一塊也是不小的開銷。
• 大數(shù)據(jù)平臺運維成本高。

4、選擇 Databricks 數(shù)據(jù)洞察 Delta Lake的原因

為了解決天級 ETL 逐漸尖銳的問題，減少資源成本、提前數(shù)據(jù)產(chǎn)出，我們決定將T+1級 ETL 任務(wù)轉(zhuǎn)換成T+0實時數(shù)據(jù)入庫，在保證數(shù)據(jù)一致的前提下，做到數(shù)據(jù)落地即可用。

考慮過使用 Lambda 架構(gòu)在離線、實時分別維護一份數(shù)據(jù)但在實際使用過程中無法保證事務(wù)性，隨著數(shù)據(jù)量增大查詢性能低，操作較復(fù)雜維護成本比較高等問題最終沒能達到理想化使用。

后來我們決定選擇數(shù)據(jù)湖架構(gòu)，緊接著考察了市場上主流的數(shù)據(jù)湖架構(gòu)：Delta Lake（開源和商業(yè)版）& Hudi。二者都支持了 ACID 語義、Upsert、Schema 動態(tài)變更、Time Travel 等功能，但也存在差異比如：

Delta Lake 優(yōu)勢：

• 支持 Java 、Scala 、Python 及 SQL。
• 支持作為 source 流式讀寫，批流操作簡捷。

Delta Lake 不足：

• 引擎強綁定 spark 。
• 需要手動合并小文件。

Hudi 優(yōu)勢：

• 基于主鍵的快速 Upsert / Delete 。
• 支持小文件自動合并。

Hudi 不足：

• 不能支持 SQL 。
• API 較為復(fù)雜。

綜合以上指標(biāo)，加上我們之前的平臺就是基于阿里云平臺搭建，選型時阿里云尚未支持 Hudi ，最終我們選擇了阿里云 Databricks 數(shù)據(jù)洞察（商業(yè)版 Delta Lake 專業(yè)性更強）。同時 Databricks 數(shù)據(jù)洞察提供全托管服務(wù)，能夠免去我們的運維成本。

5、整體架構(gòu)圖

整體的架構(gòu)如上圖所示。我們接入的數(shù)據(jù)會分為兩部分,存量歷史數(shù)據(jù)和實時數(shù)據(jù)，存量數(shù)據(jù)使用 Spark 將 MySQL 全量數(shù)據(jù)導(dǎo)入 Delta Lake 的表中， 實時數(shù)據(jù)使用 Binlog 采集實時寫入到 Delta Lake 表中，這樣實時數(shù)據(jù)和歷史數(shù)據(jù)都同步到同一份表里面真正實現(xiàn)批流一體操作。

集群遷移

前期在阿里同事的協(xié)助下我們完成了數(shù)據(jù)遷移的工作，實現(xiàn)在Databricks數(shù)據(jù)洞察架構(gòu)下數(shù)據(jù)開發(fā)工作，我們的前期做的準(zhǔn)備如下：

• 數(shù)據(jù)存儲將Hive數(shù)倉數(shù)據(jù)遷移到OSS，數(shù)據(jù)同步繼續(xù)使用Sqoop定時執(zhí)行。
• 元數(shù)據(jù)管理從自建Hadoop集群遷移到阿里云RDS MySQL，后面隨著我們業(yè)務(wù)的擴展會轉(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ù)據(jù)，對于存量歷史數(shù)據(jù)我們是通過 SparkSQL 一次性 Sink Delta Lake 的表中，這樣我們流和批處理時只維護一張 Delta 表，所以我們只在最初對這兩部分?jǐn)?shù)據(jù)做一次 merge 操作。

同時為了保證數(shù)據(jù)的高安全，我們使用 Databricks Deep Clone 每天會定時更新來維護一張從表以備用。對于每日新增的數(shù)據(jù)，使用 Deep Clone 同樣只會對新數(shù)據(jù) Insert 對需要更新的數(shù)據(jù) Update 操作，這樣可以大大提高執(zhí)行效率。

CREATE OR REPLACE TABLE delta.delta_{table_name}_clone DEEP CLONE delta.delta_{table_name};

7、產(chǎn)生的效益

• 節(jié)省了 DB 從庫的成本，同時 Databricks 數(shù)據(jù)洞察全托管架構(gòu)我們節(jié)省了人力成本（省1運維+2名大數(shù)據(jù)）因此我們采用商業(yè)版 Databricks 數(shù)據(jù)洞察 Delta Lake 流批一體架構(gòu)之后，整體成本有很大節(jié)省。
• 得益于商業(yè)版 Databricks 數(shù)據(jù)洞察 Delta Lake 高效的執(zhí)行引擎，執(zhí)行效率上6-10的性能提升。
• 實現(xiàn)了計算和存儲分離，同時基于 DLF 元數(shù)據(jù)湖管理，可擴展性明顯提高。
• 商業(yè)版 Databricks 數(shù)據(jù)洞察提供了一整套批流處理的 Spark API 使我們研發(fā)工作高效便捷了很多。

8、后續(xù)計劃

• 基于 Delta Lake ，進一步打造優(yōu)化實時數(shù)倉結(jié)構(gòu)，提升部分業(yè)務(wù)指標(biāo)實時性，滿足更多更實時的業(yè)務(wù)需求。
• 持續(xù)觀察優(yōu)化 Delta 表查詢計算性能，嘗試使用 Delta 的更多功能，比如 Z-Ordering ，提升在即席查詢及數(shù)據(jù)分析場景下的性能。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的【实践案例】Databricks 数据洞察 Delta Lake 在基智科技（STEPONE）的应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。