共计 4607 个字符，预计需要花费 12 分钟才能阅读完成。
作者：余辉，滴滴出行 OLAP 团队负责人 / 专家工程师；李明皇，滴滴出行高级软件开发工程师
倒退历程
滴滴的 OLAP 零碎晚期由用于实时监控零碎的 Apache Druid（以下简称 Druid）和离线减速应用的 Apache Kylin（以下简称 Kylin）逐渐倒退起来。在 2018 年后开始全面倒退，过后次要应用 Druid、Kylin 和 Presto 等引擎，用于承接实时监控、实时看板和数据分析等场景。随着业务使用量和业务复杂度的晋升，原有的这些引擎因为性能、稳定性、易用性、保护老本等起因，曾经无奈满足各种简单的应用需要，查问性能和稳定性难以满足。
在 2020 年后引入过后业界宽泛应用的 ClickHouse 引擎。ClickHouse 是一款开源 OLAP 的列存数据库，号称比 MySQL 快 100-1000 倍，最大的特色是高性能的向量化执行引擎，单机性能强悍。通过 ClickHouse，反对了过后网约车、逆风车、青桔单车、橙心优选等多个业务线经营看板、实时剖析等场景。通过长时间的倒退和迭代，ClickHouse 和 Druid 成为过后滴滴外部次要的 OLAP 引擎，也初步让 OLAP 产品在滴滴外部发展壮大。
选型
随着在滴滴外部应用 OLAP 场景的一直减少，次要涵盖监控报表、日志剖析、离线减速和实时数仓这四个场景。原有的基于 ClickHouse 和 Druid 建设的 OLAP 零碎裸露的问题越来越多。次要有：
- 保护艰难：在 OLAP 场景中保护的引擎和组件有 5 个之多，每个引擎应用形式，运维形式不一样。导致难以保护，难以倒退。
- 应用不便：不同引擎特点不同，它们针对的场景比拟繁多，用户难以依据业务场景正确抉择引擎。另外，对于 ClickHouse 从能用到用好难度很大，经常出现查问性能未达预期。
- 稳定性压力大：引擎多投入人力无限，问题频频产生，无无效解决方案。很多业务场景混合在一个集群中，短少资源隔离机制，服务稳定性难保障。
- 用户需要难以满足：局部用户有批改和删除数据的需要，现有引擎无奈满足。对于高 QPS 场景，复杂度高查问场景、Join 等场景，查问性能不能满足需要。
（上图为引进 StarRocks 之前的 OLAP 现状）
针对下面这些问题，咱们于 2022 年开始引入 StarRocks。StarRocks 是新一代全场景 MPP 数据库，应用向量化、MPP 架构、CBO、智能物化视图、可实时更新的列式存储等技术，实现多维、实时、高并发的数据分析。StarRocks 在 GitHub 上已有 4.7k Star，并且增长迅速，社区也十分沉闷。在国内各大互联网公司也有较为宽泛的应用。
其次要特点有：
- 简洁的分布式架构：StarRocks 采纳简洁的分布式架构，能够程度扩大以解决大规模数据和高并发查问。它将数据分片存储在多个节点上，实现了数据的并行处理和查问。
- 高性能查问：因为采纳了列式存储、分布式架构和向量化引擎，StarRocks 可能提供优良的查问性能。它反对多种查问操作，包含聚合、排序、连贯和过滤等，实用于简单的剖析查问，并且反对较高的 QPS。
- 灵便的数据模型：StarRocks 反对多维度数据模型，能够不便地进行多维度剖析。它提供了丰盛的数据类型反对和灵便的数据模型设计，实用于各种数据分析需要。并且反对更新和删除。
- 易于应用和治理：StarRocks 提供了易于应用的治理界面和命令行工具，不便用户进行集群的配置、监控和治理。它还反对资源隔离，能够比拟容易的定位和解决用户之间查问影响导致的问题。
- 对立的湖仓架构：StarRocks 原生反对对立治理数据湖和数据仓库，反对联邦查问，可作为数据湖引擎的加速器，提供对立查问服务。能通过一套技术计划解决实时剖析与湖仓剖析。
在引入 StarRocks 后，后期次要在平台和引擎两方面发展建设。通过一年多的建设和推广，StarRocks 逐步代替 Druid 和 ClickHouse，成为滴滴外部的最次要 OLAP 引擎。
在业务和规模方面：
StarRocks 集群数大概 30+，数据量达 300TB+，日均查问 QPS 400w+。服务公司内部网约车、逆风车、两轮车、金融、能源等多个业务线。
平台建设方面：
买通数据链路和上下游生态，包含实时、离线数据导入自动化等；建设云原生管控平台，提供高效的运维治理和业务交付能力。
引擎建设方面：
在稳定性上，通过容器化、资源隔离、双链路机制等形式，对不同稳定性要求的用户提供针对性的稳定性保障伎俩。
在易用性上，将慢查问监测告警性能和查问分析器凋谢给用户，让用户有方法感知到慢查问，并且能针对性的调优。
在性能上，重点推广物化视图，通过预处理技术为用户提供更好的查问性能和更低的老本。
StarRocks 在滴滴的实际
MAS 监控报警业务
业务背景
MAS 监控报警业务是针对客户端 APP，通过埋点采集数据，用于剖析客户端 APP 性能或性能上的问题，为团体泛前端提供线上问题感知及定位能力，并继续赋能泛前端稳定性建设和保障工作。
MAS 监控报警零碎业务挑战：
数据量大 ：笼罩团体大部分业务线，数据摄入条数 45w/s，每天数据量 12TB。
监控维度筛选灵便 ：反对多种工夫粒度，多个埋点组合，反对自定义筛选字段。
性能和稳定性要求高 ：查问耗时要求小于 1s，稳定性要求 99.9%。
此零碎原先应用 Druid 作为底层存储引擎，应用中存在下列问题：
- 查问存在性能瓶颈，有肯定概率呈现查问超时，影响报警的时效性；
- Druid 集群老本高，大概须要 60+ 台机器，运维老本高；
- Druid 集群查问容易受其余用户影响，导致查问超时或报错，稳定性有余。
迁徙过程
通过后期的调研和测试，StarRocks 能够解决 Druid 中的有余，将 MAS 监控报警业务从 Druid 降级到 StarRocks 上，能够提供更好的查问性能，更低的老本和更高的稳定性。在降级 StarRocks 的过程中，针对业务应用场景，在数据建模是依据 StarRocks 特点采纳了深层优化伎俩，次要有：
聚合模型 ：剖析类告警场景中应用大量的聚合计算，选用聚合模型对查问后果预计算，晋升查问响应工夫。
分辨别桶 ：常见的查问都是依照工夫和 APP 维度进行，正当抉择工夫分区和 app_name 分桶，无效缩小单次查问扫描数据量，晋升查问性能。
UV 指标 ：告警场景中关注的指标大部分是 UV 计算，关注的是指标变化趋势，采纳 HLL 类型估算 UV 指标，能晋升查问性能。
预处理 ：应用物化视图，减速将常见的指标查问，按分钟粒度上卷。能够无效升高查问时扫描数据量。
数据导入 ：应用 Stream Load，相比 Druid 导入形式能升高数据导入老本。
成果收益
MAS 监控报警零碎从 Druid 迁徙到 StarRocks 之后，在查问性能和老本上有显著收益。在查问性能晋升和集群规模放大的双重影响下，以及 StarRocks 自身资源隔离和易于运维治理的性能下，服务的稳定性也有更好的保障。
降级后的性能收益：
•查问性能晋升 4 倍
•查问 P90 耗时从 500ms 晋升到 150ms
降级后的老本收益：
•集群规模从 60+ 节点降落到小于 10 节点
•数据存储量降落约 40%
•综合老本降落 80% 以上
02 金融数据门户建设
业务背景
金融数据门户是滴滴外部金融产品数据平台，次要为金融业务团队提供以数据驱动精细化经营的数据分析性能，解决传统报表对管、产、运领导不够灵便的弊病，想通过 OLAP 零碎搭建一套反对全链路外围指标、维度下钻，异动剖析等性能组合的数据解决方案。对 OLAP 引擎的要求有：反对自定义工夫维度；反对全链路指标，联动剖析。查问秒级返回。其中每日数据量大概有 10 亿条。
建设过程
通过后期的调研和测试，选用了 StarRocks 作为金融数据门户的 OLAP 引擎。将 10 亿级数据量下，反对秒级即席剖析查问剖析作为指标。通过上面四个方面优化伎俩以达成。
业务建模 ：通过对金融业务查问场景的需要和数据了解，设计适合的表模型。在满足业务查问和剖析的要求的同时，使表的数据结构与存储构造有利于 StarRocks 查问。
数据分布 ：通过正当的分区和分桶设计，将海量的数据按查问的要求均分到集群各个节点的 tablet 中。使单次查问的数据量在正当范畴并且能充分利用集群的计算资源。
查问减速 ：为了进一步晋升查问性能，精心设计前缀索引和 ZoneMap 索引，以保障在查问中可能无效命中，起到大量过滤有效数据的要求，同时在要害查问条件上减少 BloomFilter 与 Bitmap 索引，进一步过滤无关数据，晋升查问性能。
预处理 ：在索引无奈笼罩的的优化场景外，通过应用物化视图加 Bitmap 对指标预处理，晋升查问的响应工夫。通过应用 Bitmap，以及将原来随机 ID 转换成间断递增 ID，进一步提速高基数去重指标的查问性能。
成果收益
通过 StarRocks 提供低耗时的查问剖析解决方案后，金融数据门户零碎得以提供更为丰盛和精密的业务性能。外围业务指标拆分成了卡片、维度下钻、指标树的形式出现，可能疾速帮忙业务通过数据来掌握业务的现状，数据价值可能失去很好的体现。
将来瞻望
通过一年多 StarRocks 的建设和实际，StarRocks 在滴滴外部曾经成为 OLAP 场景中的次要引擎。随同着大量业务从原有的 ClickHouse 和 Druid 引擎上迁徙到 StarRocks 上，也使得 StarRocks 能取代 ClickHouse 和 Druid，对立滴滴外部的 OLAP 引擎成为可能。应用 StarRocks 的 MPP 分布式、向量化查问引擎劣势、和联邦查问能力搭建对立 OLAP 平台。解决原有的 OLAP 大数据生态畛域，在老本，性能、实效性、易用性及灵活性等方面的各种问题。
以下几个 Feature 是咱们认为可能解决这些问题的要害，也是咱们后续在社区重点关注的方向：
物化视图 ：物化视图是解决 OLAP 场景中查问性能问题的要害伎俩之一。在海量的数据分析中秒级查问响应的要求下，物化视图的预处理技术，是从老本和性能上的最佳解决方案。物化视图预处理技术在 OLAP 的位置相当于 MapReduce 在离线数据处理中地位。目前咱们在很多场景中应用物化视图，也获得很好的成果，后续将沉淀物化视图在不同场景下的最佳实际。
存算拆散 ：存算拆散架构是大数据处理和剖析畛域重要个性之一，能够满足不同的业务需要和数据处理场景。StarRocks 在应用存算拆散后，老本能够降落 90%；计算节点变成无状态之后，能够通过疾速弹性的形式来进步计算的容量，以应答重大流动期间突增的数据分析需要。目前 StarRocks 存储老本绝对过高，还不具备独自减少计算资源能力。
湖仓一体 ：湖仓一体是 StarRocks 社区以后倒退的方向，在 StarRocks 具备存算拆散和数据湖剖析能力之后，StarRocks 自身曾经造成了一个分层构造的 Lakehouse 的架构，可能将 HDFS、Apache Hive、Apache Hudi、Apache Iceberg 对立在一起，利用 StarRocks 自身的技术劣势来晋升查问性能。另一方面，物化视图也能够在其中起到简化湖仓建模，实现查问减速等重要作用。通过引入湖仓一体，能够更容易将实时和离线剖析对立到一起，实现对立数据口径，简化数仓开发的效用。同时也为亚实时数据分析场景提供更好的解决方案。
如对本篇文章有趣味，能够点击下方链接观看余辉老师在 StarRocks & Friends 杭州站的分享：
https://www.bilibili.com/video/BV18u411p7mt/?spm_id_from=333….
