分析性能提升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在大数据处理领域的强大实力和灵活性。