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

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