2 得物-StarRocks存算分离在得物的降本增效实践

丁凯剑 得物StarRocks负责人，8年OLAP研发经验，StarRocks Active Contributor，Apache Druid Committer Clickhouse在大数据量下的困境 从Clickhouse到StarRocks存算分离 OLAP引擎在得物客服、风控、供应链、投放、运营、A/B实验等大量业务场景，在报表、日志、实时数仓等应用场景都有广泛的应用。 使用多种OLAP引擎 引入和使用OLAP引擎的过程中业务选择当时最适合的引擎，现存云上Hologres、ADB、Clickhouse和自建Clickhouse、StarRocks五种引擎产品 最终只保留1到2个引擎 先把一套超过4000核的最大，业务最复杂的智能运营平台Clickhouse集群迁移到存算分离的StarRocks Clickhouse在大数据量下 线上Clickhouse集群面临瓶颈 超过4000核 存储超过500TB日常需要查询日/周/月/季/年环比/同比，查询时间跨度长集群负载接近上限 Clickhouse单机规格已是顶配，没有升配空间 建立了40+物化视图 按指定字段分桶的表，扩容后需要重导数据才能保证正确性，需要一周的停服扩容和导入 由外部代码主动管理、创建物化视图、改写sql去查询物化视图在需要重刷历史数据时，由外部代码管理的物化视图的重刷复杂 只能搭建一个主集群一半大的备份集群，存储最核心的数据，与主集群构成双活来分流部分查询，来减小主集群负载，这样增加了50%+成本。 基于StarRocks降本增效 不需要把所有的数据都存储在本地盘，而只需要缓存常用数据大量使用物化视图，减少基表实际需要存储在datacache中的数据量命中datacache时性能与存算一体相同 数据存储在远端，不担心丢失比3副本存算一体降低2/3存储成本 扩缩容无需均衡，扩容新节点可以马上利用 Clickhouse StarRocks 1.支持的join类型有限 1.支持各种join类型且符合标准SQL语法的预期 2.Join不正确使用分布式表和local表会有性能或正确性问题 2.不区分分布式表和local表，专注业务即可 3.物化视图无侵入透明改写，并保证与基表数据一致性 3.手动改写SQL利用物化视图 4.离线导入并发可控，资源可控 4.离线导入效率不高 4.物化视图只基于单表，方便在各种joinsql语句中复用5.一个物化视图包括尽量多的指标，查询时一次性查多个指标6.materialized_view_rewrite_mode=‘force‘让一个查询中多个countdistinct也能命中物化视图 1.不命中物化视图时，在资源组中限制大表时间跨度超过8天就不允许查询 2.approx_count_distinct改写成hll_union_agg(hll_hash(col))让查基表与查物化视图的结果完全一致 3.使用明细物化视图减少数据读取量 1.通过在FE中记录SQL结构，在外部实现基于单表的物化视图推荐程序 1.跳过物化视图与无关表的匹配，优化选择性能，耗时减少50%2.提早剔除一些不包含查询需要的列的物化视图，减少了后续匹配测试的开销，耗时减少70%3.优先选中key列匹配查询过滤条件的物化视图，再优先选行数最少的物化视图 2.能做到对表/物化视图字段的在过滤条件中的命中次数进行统计，用来判断哪些字段做排序键能适配更多的查询 3.3版本刚发布时不少场景下物化视图不能被命中 社区帮助修复一些问题，我们也修复了8个命中问题，包括这页所有优化，都已经提交PR并merge了 3.能做到对单表的子语句用到的指标和维度列进行分析，找到有高收益的潜在物化视图，并且排除已经存在的物化视图 1.支持刷新顺序为从新分区到老分区，最近的数据能最快得到加速2.修复了force刷新不生效的问题3.修复物化视图在image创建后被非预期inactive，重启后被强制刷新的问题4.反馈给社区修复fast schema evolution导致的MV非预期刷新问题 4.物化视图启用collocategroup 智能运营原本并不直接查询Clickhouse，而是经过中间的ONE DSL平台翻译DSL(一种类SQL)为ClickhouseSQL后发给Clickhouse 现在ONEDSL增加StarRocks翻译类型，智能运营仍然经过ONE DSL平台翻译DSL为Clickhouse/StarRocks SQL后发给后端引擎 智能运营每个接口指定DSL目标翻译类型，ONEDSL平台转发翻译后SQL给Clickhouse或者StarRocks，按接口灰度可以逐个的迁移和随时单独回滚 兼容Clickhouse常用函数 实现Clickhouse式的别名引用 select id asid_alias, sum(a) as b,concat(b, ',', '_') fromtblgroup byid_alias 1.仿造TrinoAstBuilder实现ClickhouseAstBuilder，新增sql_dialect=clickhouse选项 可以在select的后段引用前段定义的别名 2.兼容了业务方用到的72个函数，业务方95%的SQL不需要修改 3.可以做到一个Clickhouse函数对应一个StarRocks函数或者多个函数的组合，并且将来新增一个Clickhouse函数映射是非常简单的。 Clickhouse表/物化视图转换工具 在引擎之外将Clickhouse建表和建物化视图的DDL转为StarRocksDDL 实现Clickhouse用法的ArrayJoin函数 StarRocks原生写法select u fromtbl,unnest(array_ column); ArrayJoin写法select arrayJoin(array_column) fromtbl; 在select语句中实现unnest列转行的效果 Clickhouse的ArrayJoin语法仍然不支持 1.修复多个场景的物化视图命中问题和优化物化视图选择策略性能2.分区字段查询带函数导致物化视图分区裁剪失败3.优化数值与字符串类型隐式转换，对应SQL性能提升20倍4.优化date/datetime被当做字符串使用时的规则，从而命中稀疏索引命中，对应SQL性能提升30倍5.减少查询时存算分离staros的rpc调用次数+简易rpc结果缓存，查询耗时普遍减少3s+ 在原有迁移过来的40+物化视图之外，又增加100+物化视图。最大的3张表占总存储的50%，对应了60+物化视图 迁移过来的表结构有不少不合理之处优化表和物化视图的排序键、分桶键、分桶数量符合查询特性。极端情况查询性能提升150倍 优化查询性能-指导用户写更好SQL 换种写法优化plan 去除join key上不必要的函数调用 极端情况提升250倍 业务方join on upper(query)上，但表的数据其实都是小写，去除upper函数再join提升至少一倍性能。 把limit提前到join语句里 减少了join的行数，降低70%耗时 1.支持指定custom_query_id，并可以异步kill query2.根据表名获取物化视图列表和物化视图的具体列信息API3.资源水位API4.SQL复杂度因子API 1.成本收益：智能运营底层AP引擎费用下降40%，存储费用下降4/52.性能和体验收益：查询耗时下降一半;查询成功率从98.57%提升到99.44%3.数据时效性收益：在双跑期间Clickhouse的基线SLA达成率是99.42%，StarRocks的基线SLA达成率是100%4.稳定性收益：集群因为单节点异常导致集群不可用的时间从15min缩短到30s内 我们与社区保持了密切的接触，获得了社区大量帮助 我们会提交一些重大issue，同时也贡献我们的修复给社区。迁移过程中共提交PR 28个，已merge 24个(pr列表) 1.智能物化视图推荐2.StarRocks大版本统一，引擎统一收敛到StarRocks3.StarRocks容器化部署和弹性资源4.Flink写入StarRocks进行整体规划5.应用湖仓一体6.更多得物应用场景拓展 Thank you!