分析性能提升 40%，阿里云 Hologres 流量场景最佳实践

在互联网和移动分析时代，流量数据成为了企业洞察用户行为、优化产品决策和提升运营效率的关键资源。流量数据主要来源于用户在使用 APP、小程序或访问网站等媒介平台时产生的各种操作行为，如点击、浏览、注册、下单等。这些行为数据通过数据埋点技术被采集，随后进入数据加工与清洗流程，以确保数据质量。经过 ETL 链路处理后，数据被存储在实时数据仓库中，以便用于后续的数据服务和分析。

一、流量分析场景及痛点介绍

1.1 流量分析场景介绍

流量的数据可以分析的维度非常多，常见的流量分析场景包括：用户行为分析、流量转化分析、广告效果分析、广告归因分析、AB 实验分析、算法模型分析、实时风控分析等。

最常见的数据埋点事件模型是基于用户在产品中的各种操作行为而构建的一种数据模型，其核心在于将用户行为抽象为 Event 实体，并通过五个关键要素来全面描述这些事件：Who（谁）、When（何时）、Where（何地）、What（做什么）、How（怎样）。

1.2 流量分析场景中数仓模型

在流量分析数仓建模中，主要存在两种模型方法以适应不同的数据处理和查询需求：

强 Schema 模型（宽表模式）：其特点为列和类型是比较固定的，数据经过严格的 ETL（提取、转换、加载）清洗过程，以匹配数仓的宽表模型。适用于对数据一致性、完整性有严格要求，且需要频繁进行复杂查询的场景。

弱 Schema 模型（弱 Schema 模式）：数据以原始形态直接加载到数仓，处理过程相对简洁，类似于 ELT（提取、加载、转换）模式。适用于数据模式频繁变化，或需要保留原始数据以便后续分析的场景。

1.3 流量分析场景面临的挑战

数仓团队配合统一埋点平台处理数据，数据开发同学一般在 Flink 中将数据打平，以宽表强 schema 的模式存储在 Doris/ClickHouse 等数仓中，提供数据的查询分析。在业务侧面临的主要挑战可以归结为三个方面

• 开发效率低

埋点测和 Flink 代码和数仓开发都需要定义超长宽度列的字段，数据类型长度，约束等等

• 运维效率低

上游埋点信息会周期性的变化，字段的增加，删除，导致 flink 代码和数仓频繁调整代码

• 业务响应慢

业务的新增需求，涉及到数仓团队，研发团队，协同发布代码，业务响应周期长

除了业务侧，流量埋点分析在实时数仓平台技术本身也带来了诸多挑战，主要集中在数仓模型、存储扩展能力、写入能力、查询能力以及高可用能力这五个方面。

• 数仓模型

流量埋点场景的日志字段比较多，需要弱 schema 的处理埋点到处理和存储分析的高效灵活处理

• 存储扩展能力

流量埋点场景的日志数据量大达到上 PB 级别，单表单分区都是几十亿，上百亿的规模，存算分离

• 写入能力

数据量太大，需要高吞吐的实时写入能力和离线导入能力足够强。

• 查询能力

任意多维度 OLAP 查询性能，任意选择不定周期范围的 UV 计算，漏斗分析，留存分析，路径分析的性能

• 高可用能力

大数据量的场景，不同业务查询之间的隔离机制，高可用能力，保证服务的稳定性能力

二、阿里云 Hologres 流量分析场景核心能力

Hologres 是阿里云自研的一款一站式实时数仓产品，Hologres 以其高性能的实时 OLAP 分析、灵活的存储计算能力、高效的点查能力、先进的数据处理特性、便捷的数据湖交互式分析、高效的数据同步与兼容性，为用户提供了一站式的实时数仓解决方案。其核心技术和能力包括：

• 高性能实时 OLAP 分析

支持高性能的实时写入与更新，写入即可查，显著提升了数据被发现和挖掘的时效性

提供多种存储模式，包括列存与行列共存，以及丰富的索引策略，满足不同业务场景需求。

采用分布式存储，并行化逻辑。

支持主键更新，局部更新。

通过向量化引擎、轻量协程等处理，提供了高性能的查询。

• 配备多种线上服务

支持行列共存，支持高 QPS 的 KV 点查功能，使一份数据同时支持多维分析与 KV 点查。

适配向量检索（如 Proxima），实现读写分离，保障高性能与高 QPS 查询与 OLAP 分析的隔离。

• 支持数据湖与数仓的交互式分析

支持阿里云数据湖与数仓（如 MaxCompute、OSS）中的表进行秒级交互查询，无需数据移动，实现数据快速加速。

实现了每秒数百万行数据的高效同步，自动发现元数据，提升用户生产与开发效率。

• 丰富的生态兼容

依托 PG 生态，兼容主流 BI 工具，支持在数仓上进行查询分析、可视化等操作。

支持 PostgreSQL 的开发语法，提供标准 SQL 能力和丰富的 BI 工具扩展性，生态能力强。

2.1 Fixed plan 高性能写入与更新

Hologres 在实时写入能力上得到了显著提升，特别是通过 Fixed plan 模式实现了高效的数据写入。该模式能够在数据写入过程中进行深度优化，直接面向存储引擎进行批量的数据写入。

在 128C 的实例上，我们测试了四种不同的写入场景，具体性能表现如下：

• 盲写（append only 模式）：每秒可达 230 万 RPS。

• 写入包含主键且采用 insert or ignore 模式：每秒可达 200 万 RPS。

• 按主键进行 upsert 操作：每秒可达 80 万 RPS。

• 写入包含主键且数据已存在时，基于大数据量进行 upsert 操作：每秒可达 70 万 RPS。

这些写入能力展示了 Hologres 在当前流量场景下，能够满足高性能数据写入的需求。

2.2 多种性能优化，V2.2 版本性能测试结果提升 100%

Hologres 在 TPC-H 标准测试中取得了全球排名第一的优异成绩，相比第二名领先了约 23%，这一成绩充分展示了 Hologres 在该领域的卓越技术实力和竞争优势。

Hologres V2.2 版本提升了查询优化器和查询引擎的能力，V1.1 版本使用 96CU 在 TPC-H 1T 的总查询耗时为 223.08 秒，在 V2.2 版本中，测试结果为 111.53 秒，性能提升 100%，测试结果可参考官网文档。

2.3 计算组模式（Warehouse）实现弹性与高可用

Hologres 自 2.0 版本后，持续优化以提升用户使用的便捷性和系统稳定性。目前，通过计算组模式，Hologres 实现了在 1.x 版本上读写隔离以及读读隔离基础上进一步支持了写写隔离。用户可以根据需求自由划分资源，例如用于离线导入、ET 加工、Flink 实时写入等，同时支持专门的计算组进行 OLAP 查询和高 QPS 检查。所有计算组底层共享存储，支持多实例 region 部署，数据自动复制，提高了性价比和故障隔离能力。并且实现了资源的物理隔离，当遇到性能瓶颈或资源不足时，可灵活进行弹性扩缩容。此外，若某 Warehouse 因复杂 SQL 等原因导致资源满载，影响生产环境，可迅速将查询切换到其他计算组，确保业务稳定不受影响。

2.4 流批一体 Dynamic Table

即将推出的 Hologres Dynamic Table 支持流批一体场景的能力，特别是在广告归因等流量分析领域，将极大提升实时与离线数据处理的一体化能力。Hologres Dynamic table 作为核心，能够实现实时计算与批处理在同一 SQL 和同一数据源表上的无缝融合，从而完善流批处理场景。可以通过单一引擎处理流与批数据，减少组件依赖，提升运维效率和计算处理效率。在流量数据处理中，Dynamic table 能够支持自动的数仓分层预聚合计算，从 DW 明细层到 DWS 轻度汇总，再到 ADS 应用层，显著提升开发、管理和成本控制效率。

2.5 多种流量分析场景函数

Hologres 在流量场景的分析能力上表现优异，尤其在漏斗分析、留存分析、标签画像分析以及用户行为标签分析等方面支持完善。与开源产品如 ClickHouse、Doris 相比，Hologres 在漏斗留存路径分析、标签画像分析等方面具有显著优势，并提供了丰富的函数支持，如按汇总、按天展开、自然日等形式的留存分析。此外，Hologres 还支持 Roaring Bitmap 函数，有效助力 UV 等大规模数据的计算。同时，Hologres 还提供了强大的 BSI 函数支持，进一步提升了用户使用的便捷性和高效性。

三、流量分析场景最佳实践

接下来分享我们在流量分析场景的一些最佳实践。

3.1 基于 Hologres 的一个典型的实时数据处理架构

数据收集：通过埋点技术收集用户行为数据。

消息队列：将收集到的数据发送到消息队列（如 Kafka 或阿里云的 DataHub），以便异步处理和扩展。

实时处理：利用实时流处理框架（如 Flink）消费队列中的数据，进行实时处理。

数据存储：将处理后的数据存储到实时数仓产品（如 Hologres）中，支持快速查询和数据分析。

数据服务与可视化：基于实时数仓，提供数据存储服务，并支持数据可视化，帮助用户更直观地理解数据。

• 数仓模型设计-弱 Schema 模式

在基于 Hologres 的流量分析的数仓模型中，强烈推荐使用弱 Schema 模式。这允许在定义数仓模型时，将常用列独立出来作为高频常规检索字段，而将使用频率较低的列整合到 JSONB 类型中。这种灵活性有助于提高开发效率和应对数据变更。

鉴于流量数据量大，查询时通常不会进行全量数据查询，而是按周期（如最近 1 天、7 天、30 天等）进行。因此，建议充分利用 Hologres 的冷存能力，将查询频次较低的数据存储在冷存中，以降低存储成本。同时，冷存也能保证在查询性能不受影响的前提下，有效管理大量数据。

由于埋点数据大多以事件为标准，因此事件名称是一个很好的过滤条件。建议在 Hologres 中创建包含事件名称的聚合索引，以提高查询效率。同时，采用列存方式存储数据，并结合动态分区管理（如 TTL 设置），以优化查询性能和数据管理。

• JSONB 半结构化数据虚拟打宽

针对 JSONB 数据，我们实施了一个优化特征，旨在提升开发、运维及业务迭代的效率，同时解决 JSONB 管理上的不足。该特征主要包括：

JSONB 数据虚拟打宽：我们每天对 JSONB 数据进行虚拟打宽处理，生成一个视图。这个视图动态地列出 JSONB 中的所有字段，使得用户在查询时可以直接查询这个视图，而无需关心 JSONB 内部的具体结构。

通过虚拟打宽生成的视图，用户可以像查询传统宽表一样查询 JSONB 数据，几乎无需改造现有查询逻辑。这一特性在替换数据存储系统（如从开源产品迁移到 Hologres）时尤为重要，因为它显著降低了迁移成本。在迁移过程中，即便原系统使用 400 列存储，而新系统可能只需要 60 列作为主表存储，其余字段仍可通过 JSONB 和视图灵活管理，确保了查询的连续性和效率。

3.2Hologres 在特定分析场景中的应用

• 用户事件分析

接下来看几个典型的场景，如在事件分析中，用户可以根据分区选择任意的时间周期，并指定事件名称来进行查询。核心关注点在于计算这些事件每天的独立用户数（UV）。Hologres 在这方面展现了强大的计算能力，特别是在其 2.1 版本后，通过极致优化了 count distinct/uniq 算子，能够高效处理大规模数据（如几十亿条记录）的 UV 计算。这种查询通常在毫秒级内完成，即使在数据量极大时，也能在秒级左右返回结果，体现了 Hologres 在查询效率上的显著优化和保障。

• 留存分析

通过留存分析，可以观察用户在不同时间段（如第一天、第二天、第 n 天）的登录情况，从而了解用户的回访率和产品的用户粘性。这种分析对于评估产品性能和指导优化决策至关重要。为此，Hologres 提供了强大的留存分析函数，使得 SQL 开发变得简单易行，同时保障了查询性能的高效性。这些功能使得技术团队能够更加便捷地进行留存分析，从而做出更精准的产品优化和决策。

• 漏斗分析

漏斗分析作为数据分析中的一个重要案例，用于观察数据在不同阶段的转化率和行为模式。例如，在电商场景中，可以分析从点击到下单、再到支付尾款的转化率；在游戏行业中，则可以分析从下载游戏到登录游戏的用户比例。Hologres 提供了全面的漏斗分析函数，支持全局汇总和按天展开查询，用户可以在一个表格中查看全量数据或按天的漏斗情况。此外，经过 Hologres 执行引擎的优化，漏斗分析相关的函数性能相比之前版本有了显著提升，在迁移自开源版本时，性能提升可能达到 40%以上。这些功能和性能优化使得 Hologres 成为了实现高效漏斗分析的理想工具。

• 路径分析

Hologres 当前版本支持强大的路径分析功能，该功能在流量场景中尤为重要。路径分析能够详细记录用户的访问路径，包括用户进入产品后的每一步操作，有助于深入了解用户行为模式。通过路径分析，可以清晰地看到每一步操作的流入和流出情况，为业务提供精细化的运营数据支持。这些数据不仅能帮助企业了解产品的访问情况，还能指导产品的迭代和优化方向。

• 归因场景模型

在广告和游戏行业中，归因模型是评估广告效果和优化投放策略的重要参考。归因模型通过分析广告触点（如点击）与转化事件（如下单）之间的关系，来确定广告渠道的效果。下图详细阐述了归因模型中的几个关键步骤，包括识别触点事件和转化事件、设定有效转化周期（如 15 天或 30 天）、基于用户 ID 关联触点与转化事件，并计算转化路径上的权重分配。

在归因计算中，会面临数据量庞大和查询开销大的挑战，特别是当需要关联两个大型表（如触点表和转化表）时，会产生大量的笛卡尔积运算，消耗大量 CPU 和内存资源。因此，归因计算的效率高度依赖于数据库系统的 JOIN 能力。

Hologres 在归因场景中具有显著优势，其 LOCAL JOIN 和 Runtime Filter Join 等特性能够显著提升查询和 JOIN 的效率，使得在大数据量下也能保持较好的计算效果。

• 单表归因思路

在单表归因的实践中，将点击数据和转化数据统一存储在 Hologres 数仓层面的策略。这一策略通过数仓层面的数据处理能力，实现数据的关联和归因路径的识别。为了实现高效的数据关联和归因计算，充分利用 Hologres 的索引能力和 LOCAL JOIN 能力的重要性。这些能力有助于快速匹配相关数据，并在匹配后进行窗口计算和排序，以确定归因路径。

• 多表归因思路

在 Hologres 之上，可以用两个表之间的关联去做分析，还可以做多表关联、多表归因。由于广告的数据量非常大，借助强大的实时处理引擎 Flink 与 Hologres 结合来做实时的归因。

Hologres 不仅支持 OLAP 查询，还具备高效的在线分析能力，特别是在处理高 QPS 的点查时表现优异，Flink SQL 的设计应充分利用 Hologres 的点查能力。

• 长周期 UV 计算

在长周期 UV 计算中，有两种常见的处理模式。第一种模式涉及处理大规模数据集，当数据量达到千万或亿级别时，通常需要进行两表关联，即将事实表与维度表进行关联，以计算特定 UV 值。在此场景下，由于数据量大且并发要求高（QPS 大于 10），对系统的性能和处理能力提出了较高要求。

第二种模式则针对日数据量较小的场景，采用单表查询的方式，直接基于事件表进行 UV 计算。虽然在这种场景下 QPS 同样可能较高（如十个以上、二十个以上），但由于数据量相对较小，系统可以通过优化查询性能来满足计算需求。

实时 roaringbitmap 实现步骤如下图所示：

游戏行业长周期留存计算的挑战：需要计算长周期的留存情况，即从角色创建之日起，在接下来任意一年内的每一天的登录留存。这种计算涉及长周期任意两天之间的 bitmap 交集，计算复杂度高，且传统的 case when 表达式会导致 SQL 代码冗长、复杂，影响开发效率和计算效率。

Hologres 的 JSON 函数优化：利用 Hologres 的 JSON 函数来优化这一计算过程。具体方法是，首先将 ndays（天数）和指标值转换为 JSON 格式的数据，然后在外层使用 Hologres 的 JSONB 处理函数进行展开和计算。

建议游戏行业的开发人员关注并尝试这种优化方法，以提升数据处理效率和开发效率。

在宽表处理过程中，常常会遇到因数据关联导致的数据量膨胀问题，这不仅增加了计算难度，还严重影响了查询效率。为了优化这一挑战，我们可以采取将细粒度数据（如商品或品牌信息）以数组形式嵌入到宽表中的策略，从而避免不必要的数据膨胀。这种方法不仅保持了数据的完整性，还显著减少了数据冗余。此外，利用 Hologres 提供的复杂数据类型（如数组）和高效的 ARRAY Bitmap 索引功能，我们可以对数组进行快速的交、并、差等运算，极大地提升了查询性能，据估计性能提升可能高达 80%以上。这一优化策略为处理宽表时遇到的数据膨胀和查询瓶颈问题提供了切实可行的解决方案，展示了 Hologres 在大数据处理领域的强大实力和灵活性。

如果大家对实时数仓 Hologres 产品感兴趣，可以在阿里云官网搜索体验和免费试用。

以上就是本次分享的内容，谢谢大家。