提效10倍：基于Paimon+Dolphin湖仓一体新架构在阿里妈妈品牌业务探索实践

1. 业务背景

阿里妈妈品牌广告数据包括投放引擎、下发、曝光、点击等日志，面向运筹调控、算法特征、分析报表、诊断监控等应用场景，进行了品牌数仓能力建设。随着业务发展，基于Lambda架构的数仓开发模式，缺陷日益突出：

数据开发效率低，面向一些业务场景，需要同时开发离线和实时两套任务，开发和运维成本增加。
存储成本增加，需要维护离线和实时两份存储，存储代价大。即使实时数仓开发，也需要将存储在TT的各层数据回流ODPS，用作数据备份和case排查，增加了额外存储开销。
计算资源消耗大，离线和实时任务需要消耗ODPS和Flink计算资源。

通过数据湖+OLAP湖仓一体架构，对传统数据链路进行升级。流批一体的开发模式，不仅节省了人力开发运维成本，降低计算存储资源消耗，许多业务场景下数据时效性和查询效率显著提高。

2. Paimon湖存储

Apache Paimon从Apache Flink社区内部孵化出来，是新一代的湖格式，创新性地使用LSM结构，将实时更新引入Lakehouse架构中。

2.1 相关概念

🏷 Schema

Paimon表元数据，包含表字段定义和配置参数等。

🏷 Snapshot

数据快照，捕获表在某个时间点的状态。用户可以通过最新的快照来访问表的最新数据。

🏷 Manifest

存储Snapshot的文件增删记录信息。

🏷 Partition

Paimon采用与ODPS相同的分区概念来分离数据。

🏷 Bucket

分区表或非分区表数据组织细分为存储桶，可以有效读写数据。

🏷 Data Files

数据文件按分区和存储桶分组，每个存储桶目录包含变更日志文件。Paimon支持使用 orc、parquet、avro作为数据文件格式。

2.2 为何选择Paimon？

Paimon依托Flink社区，生态更加开放，向下支持盘古、OSS等存储，向上支持Flink、Spark等计算引擎，以及各类OLAP引擎。Paimon功能很完善，支持流读流写和批读批写，支持主键表更新，聚合表和部分更新表等能力，是一种读写性能好、存储成本低的湖存储格式。

3. Dolphin相关能力

Dolphin作为OLAP查询引擎，在Paimon湖存储之上沉淀了许多能力，包括产品化和性能优化等技术能力。

3.1 产品化能力

🏷 极光

极光是基于Dataworks插件化框架打造，面向广告领域的一站式研发平台，可通过极光界面创建、写入、查询Paimon表。用户不用关心表的具体参数配置，如有特殊需求，也可以自定义配置。通过极光面向用户透出Paimon+Dolphin的整体能力。

🏷 FBI报表

FBI是用于数据分析和可视化展示的通用工具，可以帮助用户快速搭建各类报表进行数据分析。

通过定义Dolphin作为数据源，用户自己写好业务SQL，可以在FBI报表查询Paimon数据，使用上非常简单。

🏷 黄金眼监控

黄金眼是一个智能化监控系统，包括数据可视化、智能监控告警等功能。黄金眼支持用户使用Paimon作为数据源，通过调用Dolphin提供查询服务。用户按照黄金眼数据接入规范写入Paimon表，在黄金眼界面选择查询条件并展示结果信息。

3.2 技术能力建设

3.2.1 非精确UV计算

PV/UV是常用的数据分析指标，精确UV往往会消耗大量的计算资源，近似UV能满足多数业务场景需要。

Paimon通过定义theta_sketch聚合函数，可以实现非精确UV计算，用作基于Flink任务的数据生产消费场景。

Dolphin扩充了Paimon的非精确UV计算能力，定义了一种新的聚合函数hll_sketch，将UV的近似结果结合OLAP分析场景使用。使用步骤如下。

定义paimon表

写入paimon表参数定义包括merge-engine和fields.xxx.aggregate-function，将后者定义为hll_sketch。

go 复制代码

CREATE TABLE IF NOT EXISTS `brand_lakehouse`.`brand`.`uv_table`
(
  `order_id` STRING NOT NULL,
  `uv` BYTES,
  PRIMARY KEY (order_id) NOT ENFORCED
) 
WITH (
  'fields.uv.aggregate-function' = 'hll_sketch',
  'merge-engine' = 'aggregation'
)
;

flink写入paimon表

go 复制代码

insert into `brand_lakehouse`.`brand`.`uv_table`
select
    t.pid as pid
    ,HllSketchFunction(CAST(t.aid as BIGINT)) as uv
from brand_ob_midlog
    ,LATERAL table (BrandOBMidLogCommonParser(content)) as t
;

Dolphin查询

go 复制代码

select hll_sketch_get_estimate(hll_sketch_in(cast(encode(uv,'base64')as cstring)))
from uv_table 
where pid = 'xxx';

3.2.2 支持SST格式扩展

Paimon支持orc、parquet、avro等列存和行存格式，适用于各类分析场景。虽然Paimon可以定义主键表，但对于QPS稍高（1000以上）的点查场景，查询性能不高。Dolphin支持创建和写入sst格式的Paimon表，以适配对QPS要求更高的业务场景。

使用上仅需要定义文件格式file.format=sst，并结合PRIMARY KEY字段定义。

go 复制代码

CREATE TABLE `brand_lakehouse`.`brand`.`brand_aid_behavior_table`
(
    aid       STRING
    ,behavior STRING
    ,dt       STRING
    ,PRIMARY KEY (aid, dt) NOT ENFORCED
) 
WITH (
    'maxcompute.life-cycle' = '3'
    ,'bucket' = '100'
    ,'bucket-key' = 'aid'
    ,'consumer.expiration-time' = '24h'
    ,'merge-engine' = 'deduplicate'
    ,'changelog-producer' = 'lookup'
    ,'write-mode' = 'change-log'
    ,'snapshot.time-retained' = '8h'
    ,'file.format' = 'sst'
)
;

INSERT into `brand_lakehouse`.`brand`.`brand_aid_behavior_table`
SELECT
    aid
    ,behavior
    ,DATE_FORMAT(now(), 'yyyyMMdd') as dt
from brand_midlog
;

3.2.3 查询性能优化

Dolphin可以通过hsf接口查询Paimon表，对外提供高性能查询能力。

查询性能相比Flink、Odps等计算引擎，查询rt更低；相比Holo、StarRocks等OLAP引擎，优势明显。

高QPS低RT性能

分布式多节点（以100个节点16 core64G内存存储pangu hdd为基准）可承接流量：

4. 品牌数据链路升级

4.1 业务场景

品牌数据面向不同业务场景，对于数据时效性以及业务查询范式有所不同。

4.2 业务改造升级

面向品牌数据的新老任务，我们通过paimon+dolphin湖仓一体架构进行链路升级，主要工作涉及基础数据入湖和业务逻辑实现。对于能直接通过查询明细层Paimon表满足业务的使用场景，直接通过调用Dolphin查询接口或极光将数据透出；对查询性能要求更高或业务表征逻辑较为复杂的使用场景，通过构建物化层或编写复杂业务逻辑写回Paimon表，再对外透出加工后的数据。

4.2.1 数据入湖

品牌数据链路主要包括引擎日志数据、曝光点击等网关数据。

Paimon表的写入模式（write-mode)有change-log和append-only两种。change-log主要用于主键表数据的写入、更新、删除，append-only只支持数据的插入，不支持primary key，类比TT、Kafka的写入模式。

对数据质量要求较高的业务场景，我们使用change-log模式，结合merge-engine设置来实现业务数据去重。对于数据量很大但对质量要求稍低的场景，采用append-only模式。

主键表

go 复制代码

CREATE TABLE `alimm-brand-lakehouse`.`brand`.`brand_imp_acc_log`
(
    pkey                       STRING
    ...
    ,dt                        STRING
    ,hh                        STRING
    ,PRIMARY KEY (dt, hh, pkey) NOT ENFORCED
) PARTITIONED BY (`dt`, `hh`)
WITH (
    'bucket' = '100'
    ,'write-mode' = 'change-log'
    ,'merge-engine' = 'first-row'
    ,'maxcompute.life-cycle' = '180'
    ,'bucket-key' = 'pkey'
    ,'changelog-producer' = 'lookup'
    ,'consumer.expiration-time' = '24h'
    ,'snapshot.num-retained.min'='3'
    ,'snapshot.num-retained.max'='5'
)
;

INSERT INTO `alimm-brand-lakehouse`.`brand`.`brand_imp_acc_log`
SELECT
    pkey
    ... 
    ,DATE_FORMAT(now(), 'yyyyMMdd') as dt
    ,DATE_FORMAT(now(), 'HH') AS hh
from brand_imp_acc_log
    ,lateral table(BrandLogParserUDTF(content)) as T(...)
;

Append表

go 复制代码

CREATE TABLE IF NOT EXISTS `alimm-brand-lakehouse`.`brand`.`brand_sn_trace_log`
(
    campaign_id         BIGINT
    ...
    ,dt                 STRING
    ,hh                 STRING
) 
PARTITIONED BY (dt, hh)
WITH (
    'maxcompute.life-cycle' = '30'
    ,'bucket' = '1000'
    ,'bucket-key' = 'session_id'
    ,'consumer.expiration-time' = '24h'
    ,'write-mode' = 'append-only'
    ,'snapshot.time-retained' = '24h'
    ,'changelog.time-retained' = '24h'
    ,'partition.expiration-time' = '30d'
    ,'partition.timestamp-formatter' = 'yyyyMMdd'
    ,'partition.timestamp-pattern' = '$dt'
    ,'snapshot.num-retained.min'='3'
    ,'snapshot.num-retained.max'='5'
)
;

INSERT into `alimm-brand-lakehouse`.`brand`.`brand_sn_trace_log`
SELECT
    campaign_id
    ...
    ,DATE_FORMAT(now(), 'yyyyMMdd') as dt
    ,DATE_FORMAT(now(), 'HH') as hh
from brand_sn_ht_trace_log
    ,lateral table(BrandSNParseUDTF(content)) as T(campaign_id, ...)
;

4.2.2 业务升级

场景1 品牌履约实时报表

通过品牌履约报表，查看履约中需要交付的指标完成进度，及时发现有交付风险的订单，并分析大盘整体交付指标完成进度分布。

以前数据链路基于odps表实现，数据时效性为小时级。每年双十一大促期间，需要值班同学在0点放量时盯盘，确保品牌广告正常投放，数据时效性差增大了各方人力成本。通过paimon+dolphin对原有链路进行升级，数据时效性由1小时 降低到8分钟，并在第一时间发现投放链路可能存在的问题。

业务查询范式比较复杂，经过Dolphin优化查询性能，性能提升了50%。

注：上图为升级后的数据链路，以前链路未画出，可以理解为各部分数据均为odps表。

场景2 品牌多目标调控

品牌广告多目标调控包含售卖组/投放计划维度，全投放周期/天级/小时级的指标曝光/点击/TA/N+reach的诸多指标。由于涉及整个投放计划周期的指标计算，在数据链路上采用了Lambda架构实现。通过paimon对原数据链路进行升级，从计算和存储上实现流批一体，结合paimon自带聚合和部分更新能力，极大简化了数据开发流程。计算、存储资源以及开发成本均降低了50%以上。由于业务场景对QPS要求较高，经过Dolphin优化，支持QPS从50提高到700，rt从1s降低到100ms，性能提升10倍以上。