作者：滴滴 OLAP 开发工程师 刘雨飞
小编导读：
滴滴于 2022 年引入了 StarRocks。经过一年多的努力，StarRocks 逐渐替代了原有技术栈，成为滴滴内部主要的 OLAP 引擎。截至 2023 年 12 月，滴滴已经成功建立了超过 40 个 StarRocks 集群，每日查询量在千万量级，拥有超过 3000 张数据表。这一强大的基础设施已广泛支持了滴滴公司几乎所有的业务线，包括网约车、单车、能源、货运等多个领域。
⚠️ 关于滴滴统一 OLAP 引擎的详细内容已在“StarRocks 统一 OLAP 引擎在滴滴的探索实践”进行了详细讲解，本文将着重探讨 StarRocks 物化视图在滴滴的实际应用。
高并发精准去重
实时数据洞察的拦路虎
实时数据洞察在业务管理中的重要性无可替代。在滴滴内部，网约车实时看板是公司最关键的业务监控工具之一，包含着超过 20 个重要的业务指标，如实时呼叫量、冒泡数量和 GMV 等。这些实时看板数据对于业务、数据和运营团队至关重要，提供了即时见解，帮助我们更好地了解业务的状态和趋势。
通过实时监测这些数据，我们能够迅速应对市场波动，做出及时决策，例如：
- 实时呼叫量变化可帮助我们满足高峰需求，缩短乘客等待时间，提高司机收益；
- 冒泡数量波动可提示哪些地区需增加司机资源，满足潜在乘客需求；
- 然而，关键业务指标的计算通常需要大量的精确去重操作，尤其在高峰访问期间，这可能会对资源造成巨大压力，也是众多 OLAP 系统一直以来的挑战之一。为了平衡计算成本，许多系统牺牲了准确性，提供模糊去重的方法，这也是滴滴过去基于 Druid 的指标计算方案所采用的策略。
但是，模糊去重方法存在计算误差，这意味着我们可能无法完全准确地反映业务的实际情况，从而难以实现更精细化的运营决策。此外，即便为了降低资源消耗而牺牲了准确性，模糊去重节省的资源在高并发场景下仍旧是杯水车薪。在大规模促销活动期间，高并发查询可能导致 Druid 集群的稳定性问题，引发性能下降、响应时间延长甚至系统崩溃，这对一个依赖实时数据的业务来说是不可接受的。
因此，我们迫切需要一种新的解决方案，在可控的资源开销下，实现高并发的精确去重，以更好地支持业务运营和决策。StarRocks 的物化视图帮助我们实现了这一目标。
StarRocks 物化视图 让精准去重的落地和加速不再是纸上谈兵
实时看板场景具有以下显著特点：
高基数的精确去重。看板需要面对日增量上亿规模的明细数据，并针对明细数据进行大量 count(distinct()) 计算。并且，在实际应用中，精确去重的用户、订单 id 通常是字符串，这对计算资源造成了巨大挑战。
支持灵活的维度筛选。看板查询提供了多种筛选条件，包括时间、城市、业务线等超过十个维度字段的组合。每天的真实查询可能会涉及上千种维度组合。 查询并发高。尤其在大促期间，数据开发以及业务运营都会密切关注业务瞬时变化趋势，高峰时期可能有上千规模的用户盯盘。指标数据按照分钟级别刷新，每次刷新会触发大约几十次查询计算，则高峰时期可能有数百 QPS，对集群负载要求非常高。如果每次查询都直接使用原始明细数据进行计算，将消耗大量计算资源，这在成本上是难以接受的。
这样的业务场景对查询引擎提出了非常高的要求。自 2022 年起，滴滴已经在网约车、单车、能源、货运等多个领域应用了 StarRocks，我们也在密切关注社区的新功能。异步物化视图是针对透明查询加速、高并发场景研发的利器，自其发布之后，我们就开始了这个场景的测试验证。尝试物化视图主要是由于其以下几个特点：
-
物化查询结果：物化视图可以通过 SQL 查询来将计算结果缓存下来。缓存下来的结果可以被看作是一张物理表，相比 index（同步物化视图），在高并发的场景下表现更加优秀。
-
托管刷新流程：相较于手动维护导入任务，物化视图的刷新不仅可以定时触发，还能够根据数据变更做到分区级别的增量刷新，降低刷新成本。
-
透明查询改写：物化视图支持智能的透明改写，能够将物化的结果更大范围的应用到更多查询加速上。用户无需感知物化视图的存在，即可加速查询体验。
StarRocks 实时精确去重最佳实践
在结合业务特点和 StarRocks 的物化视图能力，我们设计了整个看板场景的加速优化链路。以下是设计的主要思路：
为了最大限度地降低去重操作对 CPU 的消耗、加速去重，我们的整体思路是：
- 数据预处理：利用全局字典进行数据类型转换，用最小的代价做精确去重
最上游的数据来自数据仓库，经过清洗加工后，通过 Flink 实时同步到 StarRocks。在 StarRocks 内部，首先进行一次全局字典转换。特别是对需要进行去重的指标列，将其从 String 类型映射为 BIGINT 类型，以便后续使用 BITMAP 类型进行上卷计算。
- ODS 层：利用明细模型存储原始数据
接下来，在 StarRocks 内部进行数据建模，生成原始明细表并形成 ODS 层–StarRocks 明细模型层。
- DWD 层：利用同步物化视图构建增量聚合层
在 DWD 层，我们创建了同步物化视图对不同维度组合进行上卷去重。同步物化视图类似于索引（Index），它具有较高的时效性，并且数据满足强一致性。在精确去重场景，同步物化视图可以通过存储 BITMAP 类型的中间计算结果，使后续单次明细查询性能明显提升，同时还为下一步异步物化视图的更新提供便利。
- ADS 层：利用异步物化视图构建透明加速层
在 ADS 层，我们创建了异步物化视图，这些视图使用定时刷新机制。虽然时效性相对较差，存在一定的数据更新延迟，但由于存储的是最终计算结果，查询速度非常快。这可以被视为持久化的查询缓存。
- 加速策略：利用智能改写能力透明提速
通过分析历史查询模式来构建增量聚合层的同步物化视图，在此之上进一步将最高频的查询定义为透明加速层的异步物化视图。同步和异步物化视图都支持透明的查询改写，依照这样的构建逻辑，用户基于原始明细表查询时，会遵循异步物化视图->同步物化视图->原始明细表的优先级来进行查询加速，从而保证了查询整体的实效性。
接下来展开讲解每一部分是如何构建的。
数据预处理：利用全局字典进行数据类型转换，用最小的代价做精确去重
StarRocks 支持两种类型的去重方式：Hyper-loglog 和 BITMAP。对于需要精确去重的指标，我们使用 BITMAP 类型。
StarRocks 内部采用了 Roaring BITMAP 的实现方式，字段类型要求在 INT(64) 位以内，并在数据连续性较好的情况下性能表现更佳。如果数据具有连续递增的特性，相较于完全随机的 ID 性能优势可达数倍以上。因此，滴滴在 StarRocks 中实现了高基数全局字典的功能。
第一步：创建全局字典表（主键模型表）
这里利用到 StarRocks 主键模型表的部分列更新以及自增列功能。文档请见：
https://docs.starrocks.io/zh-cn/latest/using_starrocks/query_acceleration_with_auto_increment
创建全局字典表：数据存储在 StarRocks 内部具有自增 ID 列的主键表中。表的主键使用需要去重的 STRING 字段，而 ID 列则是自增的 BIGINT 列。这样每一个需要被去重的 STRING 字段都会有一个对应的 BIGINT 值与之对应。
连续递增的数据生成：在写入 STRING 列数据时，自增 ID 列会自动生成连续递增的 BIGINT 值。并且，通过 StarRocks 的 partial_update 部分列更新功能，可以保证 BIGINT 列只在第一次写入时生成，后续即便写入相同的 STRING 值，对应的 BIGINT 也不会被更新。确保数据写入的幂等性，从而保证数据可以无限次地重复写入。
第二步：字典映射函数
我们实现了字典映射的函数 dict_mapping，其入参包括字典表表名和主键值。它可以在计算时实时查询字典表，并返回生成的 ID 值。为了提高性能，我们使用了 StarRocks 的主键索引进行加速，相比于基于直接扫描，性能提升非常显著。这个函数目前已经贡献回社区，欢迎大家使用。
第三步：Flink 数据写入
对 Flink 的 flink-starrocks-connector 进行改造，数据写入分为两步：
首先，将数据写入字典表，包括抽取需要写入字典表的列，以确保数据写入并落盘，同时提交事务以使其可见。
随后，将数据写入明细模型表。在写入时，StarRocks 支持设置参数和使用函数进行预处理。使用第二步的字典映射函数 dict_mapping 对需要去重的字段进行重新映射，将原本的 string 类型映射为字典表中 ID 列的值。
通过这一流程，实现了在 StarRocks 中的全局字典功能，用于高效处理需要精确去重的指标计算。这个优化方案显著提高了性能并降低了计算成本，使得处理高基数去重变得更加高效和可扩展。
DWD 层：利用同步物化视图构建增量聚合层
在增量聚合层我们创建了同步物化视图。同步物化视图同样提供了基于 BITMAP 和 HLL 算法的去重方式。我们可以方便地利用 BITMAP 聚合函数来创建同步物化视图。同步物化视图创建完成后，后续查询语句中的子查询 count(distinct order_id) 会被自动改写为 bitmap_union_count(to_bitmap(order_id)) 以便查询命中物化视图。例如：
CREATE MATERIALIZED VIEW mv_dwd AS
SELECT dt, time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`, city, source_type, bitmap_union(to_bitmap(order_id))
FROM base_table
GROUP BY dt, ts, city, source_type;
同步物化视图不仅可以作为异步物化视图的中间计算结果，加速异步物化视图的刷新，也可以承载一部分异步物化视图未命中的查询对其加速。
ADS层：利用异步物化视图构建透明加速层
在增量聚合层我们创建了异步物化视图。这里以简化后的订单表为例，介绍如何通过创建异步视图来实现查询加速。订单表包括分区日期、数据时间、城市、渠道、业务线等维度字段，以及需要去重的字段业务订单 ID。
在数据表中，我们使用time_slice函数将时间粒度取整为 5 分钟，并按照 5 分钟区间粒度进行数据聚合。聚合的维度包括城市、渠道等可累加的维度。这个聚合视图的好处在于，当用户需要查询 5 分钟粒度的数据，并且查询条件与视图中的聚合维度完全匹配时，可以直接使用这个视图进行查询加速，而无需查询原始底表的明细数据。示例如下：
CREATE MATERIALIZED VIEW `mv_ads`
PARTITION BY (dt)
DISTRIBUTED BY HASH(`ts`) BUCKETS 1
REFRESH ASYNC START(“2023-06-28 21:00:00”) EVERY(INTERVAL 30 SECOND) PROPERTIES (
"partition_refresh_number" = "3" )
AS SELECT
`dt`,
time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`, `city`,
`source_type`,
count(DISTINCT `order_id`) AS `order_num`
FROM `base_table` GROUP BY
`dt`,`ts`,`city`, `source_type`;
同样的操作可以重复进行，设置不同的区间聚合粒度（如 1 分钟、10 分钟、30 分钟等），并按照不同的维度列组合，创建多张异步视图。这样可以满足不同用户、不同维度组合的查询需求，实现了对应实时看板的查询加速效果。 在上述过程中，需要创建的异步物化视图数量可以通过以下方式进行优化，以降低视图建设的成本：
- 区分出可累加维度和不可累加维度
根据订单表中维度列的查询特点，可以将维度列分为可累加维度和不可累加维度。可累加维度指的是包含隶属关系的维度。例如，“城市”属于可累加维度，因为它隶属于“全国”这个概念；而订单状态是不可累加维度，因为每个订单都在不同状态之间流转。
- 对于可累加维度，仅创建必要的异步视图
对于可累加维度，只需创建一个基于该维度的异步物化视图，不需要为每个不同的可累加维度组合创建单独的视图，因为结果是可以复用的。例如只需要创建针对“城市”聚合的物化视图，当需要计算“全国”范围的结果时，可以在城市的结果上进一步计算而来。如果所有维度都是可累加维度，则理论上只需要一张物化视图就可以解决。
- 对于不可累加维度，根据不同组合创建异步视图
对于不可累加维度，需要根据不同的不可累加维度创建异步物化视图。这些视图将单独处理每个不可累加维度的数据，以满足特定查询条件。
通过以上优化策略，如果数据表中有 M 个可累加维度列和 N 个不可累加维度列，那么只需要创建 2^(N-M) 个异步物化视图，而不是 2^N 个。这样可以大幅减少视图数量的同时满足绝大多数查询条件的加速需求，降低了建设和维护的成本，提高了系统的可维护性和效率。
加速策略：利用智能改写能力透明提速
StarRocks 提供了物化视图的透明加速功能，使用户可以无需手动选择使用哪张表，而是通过自动改写查询来实现加速，同时保持查询的语义一致性和性能提升。
假设有以下查询示例：
SELECT
ts,
SUM(order_num)
FROM(
SELECT
time_slice(`table_time`, interval 5 minute) AS ts,
count(DISTINCT `order_id`) AS `order_num`
FROM
`base_table`
WHERE
(...)
GROUP BY
`dt`,
`ts`,
`city`,
`source_type`
) sub
WHERE
dt = '2023-07-01'
GROUP BY
ts;
在这个查询中，内层子查询对数据进行了 5 分钟粒度的聚合，并包含了多个可累加维度。外层查询对子查询的结果进行了进一步的聚合。基于这个查询，可以建立以下三张异步视图：
视图1：包括 5 分钟粒度聚合、可累加维度分区(dt)、日期(ts)、城市(city)、渠道(source_type)。
CREATE MATERIALIZED VIEW `mv_1`
PARTITION BY (dt)
DISTRIBUTED BY HASH(`ts`) BUCKETS 1
REFRESH ASYNC START(“2023-06-28 21:00:00”) EVERY(INTERVAL 30 SECOND) PROPERTIES (
"partition_refresh_number" = "3" )
AS SELECT
`dt`,
time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`,
`city`,
`source_type`,
count(DISTINCT `order_id`) AS `order_num`
FROM
`base_table`
GROUP BY
`dt`,
`ts`,
`city`,
`source_type`;
视图2：在视图1的基础上，增加了业务线（product_line）作为可累加维度。
CREATE MATERIALIZED VIEW `mv_2`
PARTITION BY (dt)
DISTRIBUTED BY HASH(`ts`) BUCKETS 1
REFRESH ASYNC START(“2023-06-28 21:00:00”) EVERY(INTERVAL 30 SECOND) PROPERTIES (
"partition_refresh_number" = "3" )
AS SELECT
`dt`,
time_slice(`table_time`, INTERVAL 5 minute, floor) AS `ts`,
`city`,
`source_type`,
`product_line`,
count(DISTINCT `order_id`) AS `order_num`
FROM
`base_table`
GROUP BY
`dt`,
`ts`,
`city`,
`source_type`
`product_line`;
然后，StarRocks 的透明加速功能会自动识别查询条件，将查询自动改写为适用于这些视图的形式，以保持查询结果的一致性。例如：
- Case 1：如果 WHERE 条件为空，则命中视图1，并自动改写查询以使用该视图加速。
- Case 2：如果 WHERE 条件包含 city IN (…)，则命中视图1，并相应地改写查询。
- Case 3：如果 WHERE 条件包含 product_line=?，则命中视图2，并自动改写查询以使用该视图。
- Case 4：如果 WHERE 条件包含多个业务线查询，不支持累加，无法命中视图2，但如果有创建同步视图的话，可以进行上卷加速。
通过这种方式，StarRocks 可以根据查询条件自动选择适当的视图进行加速，而无需用户手动介入，从而提高了查询性能并简化了用户操作。这保证了查询的语义一致性和性能提升。
总结与规划
设计方案的核心在于权衡，而方案的成功关键在于综合性能的提升。对于看板类查询，其并发性非常高，但查询模式相对固定。大多数查询都是相似甚至重复的。因此，整体方案的思路在于在一定程度上牺牲灵活性，以保障查询性能的极致提升。相较于基于明细直接计算，基于 StarRocks 物化视图对业务监控看板进行加速优化的优点显而易见：
- 单次查询耗时降低 80%，资源消耗减少 95%；
- 在相同规模的集群上，支持的查询 QPS 提高了 100 倍。
当前，线上通过物化视图支持了上百并发的精确去重查询，彻底解决了 Druid 仅能支持几十并发模糊去重的问题，相较于原有架构 QPS 提升了 10 倍。然而，方案也存在一些明显的不足之处，包括：
- 数据链路相对复杂，需要人工配置视图，维护复杂度较高，成本较高；
- 异步视图的定时刷新策略无法保证数据强一致，并且即使在没有看板访问时也会刷新，对计算资源有一定浪费
未来，我们会联合社区进一步优化物化视图，提高效率：
-
提升 BITMAP 的计算性能。这可以包括修改 StarRocks 的 BITMAP 分桶策略为 range 分桶，从而不需要对 BITMAP 的中间结果进行 shuffle 就可以得到最终结果。另外，使用 Roaring BITMAP 的 fastunion 函数来提高大量 BITMAP 的合并速度。
-
优化异步视图在改写计算环节的资源消耗。对于同底表相关的所有视图，在分区数据一致性和版本一致性等方面，都存在提升的空间。
-
在易用性方面进行改进。由于看板查询都是基于平台配置的，自动生成的查询 SQL，因此通过分析历史查询记录，提取高频查询，进行物化视图的自动创建，可以减少人工参与，从而更有利于实现技术的更大规模应用和推广。这将使整个系统更加智能和用户友好。
并且，社区也在研发更加高效的全局字典，通过将字典表直接缓存在 BE/CN 的内存上，以降低查询字典时的网络开销，以满足除精确去重之外的更多场景。
