Paimon在之家的业务实践

背景

在使用Paimon之前，之家的实时/离线数仓分别使用不同的技术方案：

• 离线数仓的方案是使用Hive将数据加工成天/小时级别的表

  这个方案非常成熟，几乎所有数据仓库团队成员都能熟练掌握。对于业务方而言，其开发和维护成本较低。但是这种方案生成的表通常会有较长时间的数据延迟（如天或小时），数据新鲜度相对较低。此外，在夜间可能还会出现大量的ETL任务竞争资源，导致资源紧张。

• 实时数仓采用的方案是基于Flink、Kafka，关系型数据库和Redis等技术栈，并结合StarRocks做实时OLAP

  由于数据都是实时处理，因此可以保证数据的新鲜度，一般情况下延迟能做到秒级。然而，当SQL比较复杂时，尤其是存在多个Group by, Join算子时，会导致Flink处理的回撤流翻倍，Flink状态体积非常庞大，使用大量的计算存储资源。这种场景在任务的开发和维护方面可能会带来较大的挑战。任务的开发周期也因此会较离线的方案长很多。

在20年底，我们开始调研Iceberg通过流式湖仓的方式在存储上作为实时和离线数据的统一存储方案。Iceberg架构非常的简洁健壮、集成Flink可以做到分钟级别的数据延迟、并且通过自身维护元数据减少了Hive MetaStore的压力、可以灵活且高效地处理表结构变更、支持排序索引等功能可以有效地提升查询效率等优点非常多。但是经过一段时间的使用后，我们发现Iceberg更适合批处理场景，在流场景的一些必要功能的缺失比如增量且有序读取，实时任务在线schema变更，缺少部分更新导致无法满足我们流式湖仓的需求。

我们在23年开始调研Apache Paimon，Paimon提供了类似于Iceberg的简洁健壮的架构，并且功能非常强大。与Flink也集成得非常完善，提供了增量且有序的数据读取、部分更新等能力，结合Flink CDC可以实现整库同步，在线Schema变更等，满足了我们对于流式湖仓的需求。而且Paimon作为一个相对较新的数据湖，没有太多的历史负担，这对于其他数据湖来说这一点有着非常巨大的优势。

我们最终使用了Paimon作为存储流批一体的解决方案。实时和离线数据共享同一份存储，这样做降低了开发和维护的难度，提高了数据仓库的整体数据新鲜度。此外，我们还通过使用StarRocks建立物化视图和使用Sort Compaction功能等技术手段来进一步提升查询效率，节省计算资源。

业务实践

在下文中将给大家分享之家基于Paimon的业务实践：

1. 新用户转化分析

• 使用Paimon主键表的部分更新功能

• 使用StarRocks建物化视图加速Paimon表的查询

2. 流量日志入湖

• 使用Paimon的Append表

• 使用Paimon的Sort Compaction功能加速Paimon表的查询，提升查询效率，减少资源消耗

3. 资源入湖

• 使用Paimon主键表的Upsert功能

一. 新用户转化分析：

新用户转化分析是一种对新用户在产品中行为变化的分析方法，通过观察新用户在其首次进入APP的行为，分析他们在后续阶段的转化过程。这种分析对于理解产品的用户采用情况、改进用户体验、提高用户留存率等方面具有重要的意义。为了实时获取新用户进入之家APP后在同步落地页的转化情况，需将用户的行为路径和订单数据关联，通过综合分析新用户在产品或服务中的行为，可以更加全面地改进产品体验，并制定更具针对性的策略，从而提高用户转化率。在这个场景中，我们使用到了Paimon的部分更新功能，按照用户ID部分更新对应主题的数据。

实现

1. 够建新用户宽表

CREATE  TABLE if not exists new_user_transform (
                user_id String,
                new_user_type String,
                channel_name String,
                land_page String,
....
                primary key (deviceid,dt) not enforced
                ) partitioned by (dt)
                WITH (
                'bucket-key' ='deviceid',
                'bucket' = 'xx',
                'full-compaction.delta-commits'='5',
                'merge-engine' ='partial-update',
                'partial-update.ignore-delete'='true',
                )

2. 处理数据写入到Paimon

2.1 通过Flink的interval window 计算新用户在5分钟内进入过的承接页

CREATE TEMPORARY VIEW new_user_view AS
select
l.deviceid,
r.page_id as land_page
from
(select time_ltz, deviceid, channelid, proctime
from  new_user) l
left join
(select  page_id, deviceid, time_ltz
from user_page_view_log) r
on upper(l.deviceid) = upper(r.deviceid)
and r.time_ltz > l.time_ltz and r.time_ltz < l.time_ltz + INTERVAL '5' MINUTE

2.2 通过Paimon的部分拼接功能将数据拼接到Paimon表

宽表字段由多个数据源提供，直接使用 Union All 的方式进行拼接， 数据在存储层进行 Join 拼接，与计算引擎无关，不需要保留join算子的状态，节省资源。

insert into new_user_transform
select user_id ,user_info,CAST(NULL AS STRING),CAST(NULL AS STRING) from new_user_view
union all
select user_id,case(NULL AS STRING),order_info,case(NULL AS STRING) from order
union all
....

2.3 在StarRocks构建Paimon物化视图

此外，为了提升拼接后的宽表的查询效率，我们开发了基于Paimon外表的StarRocks的物化视图功能。目前基于Paimon外表的物化视图功能已经贡献给了StarRocks社区，会在StarRocks 3.2版本发布

CREATE MATERIALIZED VIEW  new_user_trans_mv COMMENT "laxin_toufang_by_loudou_mv" DISTRIBUTED BY RANDOM    PARTITION BY (`pdt`) REFRESH DEFERRED MANUAL  PROPERTIES(  "replication_num" ="5", "storage_medium"="HDD") as
select  str2date(dt,'%Y-%m-%d') pdt, hour,  COALESCE(new_user_type,'all'),  
COALESCE(channel_type,'all'),
 COALESCE(new_channel_name,'all'),  
 COALESCE(land_page,'all'),
 count(distinct  deviceid) as uv,  
 count(distinct case when entry_show = '1' then deviceid else null end) as entry_show,
 count(distinct case when entry_click = '1' then deviceid else null end) as entry_click,
 count(distinct case when page_show = '1' then deviceid else null end) as page_show,
 count(distinct case when page_click = '1' then deviceid else null end) as page_click,
 count(distinct case when is_login = '1' then deviceid else null end) as is_login
 FROM  paimon_catalog_fdm.rt_feature_db.laxin_toufang_by_loudou where 
 new_user_type is not null and channel_type is not null 
 and new_channel_name is not null and land_page is not null 
group by grouping sets((dt,hour), (dt,hour,new_user_type), (dt,hour,channel_type),
(dt,hour,new_channel_name), (dt,hour,land_page),
(dt,hour, new_user_type, channel_type, new_channel_name, land_page),  
(dt,hour,new_user_type, channel_type, new_channel_name),
(dt,hour, new_user_type, channel_type, land_page),
(dt,hour,channel_type, new_channel_name,land_page),
(dt,hour,new_user_type, channel_type),
(dt,hour, new_user_type, new_channel_name),
(dt,hour, new_user_type, land_page),
(dt,hour, channel_type, new_channel_name),
(dt,hour,channel_type, land_page),
(dt,hour,new_channel_name, land_page));

2.4 手动刷新物化视图

除了自动按增量分区刷新物化视图，用户还可以选择手动刷新物化视图。

REFRESH MATERIALIZED VIEW new_user_trans_mv 
partition start ("2023-11-10") end ("2023-11-11") 
WITH SYNC MODE;

2.5 最终效果：

• 1天的宽表在10秒左右刷新完成

• 查询每天的物化视图效率在亚秒级

   

3.收益：

• 时效性:  宽表时效性从天级别提升到分钟级别

• 开发效率：开发效率提升5倍以上

• 使用资源：因为Join的数据不再需要维护在状态中，Flink写入任务使用的资源节省了60%

二. 流量日志入湖

将之家的流量日志基表打宽入湖，可以提升数仓日志清洗的时效性SLA。在提升数据时效性的同时，为提升特定事件的分析查询效率，通过Paimon的排序合并（Sort Compaction）功能，可以根据统计信息快速定位event_id所在的数据数据文件，排序后，不用读取分区所有的数据文件，可减少计算引擎的使用资源， 极大提升查询效率。这里使用了Paimon的append only表近实时追加流量日志。

Sort Compaction

这里因为event_id存在热点问题，为了保证排序分桶均匀，使用event_id，device_id两个字段排序。因为使用的最左匹配策略，所以不会影响基于event_id字段的查询效率

./bin/flink run-application -t yarn-application -D execution.runtime-mode=batch paimon-flink-action.jar \
compact \
--warehouse viewfs://xxxx\
--database pmon_dw \
--table pmon_user_log \
--partition dt=2023-11-10,hour=23 \
--order-strategy order \
--order-by event_id,device_id \
--table-conf read.batch-size=2048 

在Paimon的元数据中会维护event_id的统计信息，如下图所示：在按照event_id排序后，会根据统计信息判断出 evnet_id = 'sight_b'的数据只存在File1、File2中，所以只查询数据文件File1，File2即可。在查询Paimon表的plan阶段可以根据统计信息很高效的命中文件，Hive不用查询分区内的所有文件，从而节省查询使用的资源、提高查询效率。

收益：

1. 数仓流量日志清洗SLA提升1小时+

2. 天分区的数据使用Hive通过查询不同数量级的event_id，资源节省再显著降低的同时，查询效率也得到显著提升

三. 资源入湖

背景：

资源指在推荐和搜索系统中用于展现给用户浏览观看的文章，视频，帖子，车家号等不同种类的内容。这些内容分别来自不同的生产方，不同的数据源。在传统的数仓处理流程汇中，我们采用常规的离线同步业务数据的方式，形成ODS接入层数据。而后，针对接入层的各类来源信息，通过hive，spark等离线计算引擎，完成数据的归总，最终形成资源数据模型。这种传统的方式受限于整套组件的机制，形成常规的天级数据更新模式。这种方式可以获取昨日数据，单也不可避免的无法满足获取当日数据的需求。

为了解决这类问题，我们通过使用Flink的实时处理数据，结合paimon的数据湖近实时存储。使用到Paimon表upsert的功能，近实时以分钟级别的方式更新实时数据。以数湖的方式，既可以满足离线昨日数据，也可以满足当日新增数据获取的目的。

业务规模：

• 资源数据来源8套不同业务线的内容生产方，每套业务线数据平均包含200余个属性字段，合计超过1500个不同属性的逻辑处理

实现逻辑：

• 通过参考数仓宽表层的处理模式，将大量数据进行合并，形成50个核心属性，其余属性通过可扩展json的形式进行存储，完成整体数据落地。保证业务方可以根据需求获取到每一个参数

• 主键由业务表主键与业务类型拼接生成，保证不同业务之间不会互相倍覆盖

CREATE  TABLE if not exists resource_extend_info (
                pk string
                biz_id string,
                biz_typle string,
                ...
                extinfo string
                primary key (pk) not enforced
                ) 
                WITH (
                'bucket' = 'xx',
                'bucket-key' ='pk',
                'full-compaction.delta-commits'='5',
                'target-file-size'='256 mb',
                )

将不同类型的资源数据写入到Paimon业务库

insert into resource_extend_info
select pk ...，extinfo from article
union all 
select pk ..., extinfo from post
union all
.....

收益：

1. 数据新鲜度从天级提升到分钟级别

   通过数据实时接入和宽表层的实时入湖，数据使用方从原有的天级离线模式，可以提升到分钟级数据新鲜度，这是之前数仓场景无法比拟的。湖仓模式打破了原有离线的工作模式，让下游算法在模型计算的时候可以取到最新的样本，提升模型的时效。

    

2. 下游业务方平滑过渡，无需业务大量开发调整

   基于paimon的数据湖可以直接让下游开发者，无需脱离现有的hive离线数仓环境，直接使用hive环境读取paimon数据表，就可以获取到最新的当日的数据。这让下游算法，数据分析人员，可以0成本的过渡到数湖，无需学习成本。

    

Paimon优化实践

1. 支持代理用户

在之家实时计算平台，目前是使用同一个Haoop用户Flink去提交Flink任务，Checkpoint也通过一些规则被同一用户管理。为了能让平台的Flink用户将数据写到其他团队的数据集市，我们在Paimon的Catalog添加了代理用户的配置。

CREATE CATALOG my_catalog WITH (
    'type' = 'paimon',
    'warehouse'='xxx',
    'metastore' = 'hive',
    'uri' ='xxx',
    'proxyUser'='xxx'
)

实现：

• HDFS:  直接通过ugi代理即可

• Hive客户端：

    可以参考Spark的org.apache.spark.deploy.security.HiveDelegationTokenProvider实现，动态代理Hive的客户端。

2.优化写入任务内存占用

2.1 Writer算子:

• 关闭较大列的数据字典

• 调低orc文件的读/写 batch size

• 在checkpoint阶段如果文件数量到达阈值，先等待合并任务完成，避免大量小文件堆积到L0层

2.2 Commiter算子:

• Manifest添加Full Compaction机制

• 截断Manifest统计信息

• 单独设置committer 算子内存

2.3 JobManager:

• 修复由于writer状态未及时更新，导致Jobmanager中的list state膨胀导致mom

最终收益：

• 目前Paimon在之家的部分更新场景最大的主键表每天增量数据10个TB，单字段大小2-4MB的主键表

   

• 线上写入Paimon的Flink任务稳定性显著提升

   

• 在使用了社区在内存方面的优化同时，我们提出的在内存方面的优化已经全部被社区采纳，在Paimon 0.5以上版本开箱即用，目前0.5以上的版本已经是非常稳定的版本

未来规划

1. 之家实时计算平台集成 Paimon Web 项目

   目前在之家，我们通过实时计算平台实现了Paimon表的写入集成工作。接下来，我们计划将这一部分功能提取出来，通过将社区的Paimon Web项目集成到之家实时计算平台，来管理 Paimon 表和写入任务。

    

2. 支持StarRocks基于Paimon外表的增量数据构建物化视图 （目前是基于变更分区）

   我们计划实现基于Paimon的增量数据刷新物化视图，相比于目前基于Paimon的增量分区的方案，可以缩短物化视图的刷新时间，提升刷新效率。

    

3. 使用Paimon 定期生成标签功能替换离线拉链表的加工流程

   在之家每天夜里会有上万个拉链表的加工任务，占用两个小时的加工时间。Paimon定期生成标签功能相较于加工拉链表会更加轻量，我们计划使用Paimon定期生成标签功能去缩短夜里加工任务的耗时，提升夜里加工任务的时效性SLA。

‍

王刚

■ 汽车之家高级大数据开发工程师

■ 主要负责之家实时计算，Kafka，数据湖，向量检索平台及引擎的开发维护工作。

‍

李乾

■ 汽车之家高级大数据开发工程师

■ 主要从事数据仓库领域的开发工作。目前负责之家实时数仓相关数据建设工作。

‍

范文

■ 汽车之家高级大数据开发工程师

■ 主要负责数仓建设，业务数据开发，数仓数据治理，数据湖开发，资源内容特征等工作。