帆软网站开发,个人社保网上服务,网站建设培训心得,免费空间建网站作者#xff1a;滴滴 OLAP 开发工程师 刘雨飞 小编导读#xff1a; 滴滴于 2022 年引入了 StarRocks。经过一年多的努力#xff0c;StarRocks 逐渐替代了原有技术栈#xff0c;成为滴滴内部主要的 OLAP 引擎。截至 2023 年 12 月#xff0c;滴滴已经成功建立了超过 40 个 … 作者滴滴 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 ASSELECT dt, time_slice(table_time, INTERVAL 5 minute, floor) AS ts, city, source_type, bitmap_union(to_bitmap(order_id))FROM base_tableGROUP 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_1PARTITION BY (dt)DISTRIBUTED BY HASH(ts) BUCKETS 1REFRESH 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_2PARTITION BY (dt)DISTRIBUTED BY HASH(ts) BUCKETS 1REFRESH 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 的内存上以降低查询字典时的网络开销以满足除精确去重之外的更多场景。 本文由 mdnice 多平台发布
