关于数据:实践案例Databricks-数据洞察-Delta-Lake-在基智科技STEPONE的应用实践

简介：获取更具体的 Databricks 数据洞察相干信息，可至产品详情页查看：https://www.aliyun.com/produc…
作者
高爽，基智科技数据中心负责人
尚子钧，数据研发工程师

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，晋升在即席查问及数据分析场景下的性能。

原文链接
本文为阿里云原创内容，未经容许不得转载。