网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
- 灵活多变: 相比数据量和性能,灵活性更重要
- 轻量: 架构要简单,最好能一个引擎搞定所有场景
- 高效: 使用门槛要低,各种业务都能快速接入使用
- 包容: 能良好地兼容大数据生态
具体的诉求是:
- 支持ROLAP、MOLAP分析场景
- 数据模型支持宽表、星型模型、雪花模型等
- 同时兼顾数据量(PB)、查询性能(秒级)、灵活性(导数与查询灵活多变)
- 数据时效性上支持离线批处理、实时流处理秒级可见
- 数据写入支持Append、Overwrite、Upsert、Delete
- 高可用、灵活扩缩容、低运维成本
- 较高的QPS(高并发)
- 支持分析Hadoop上的数据
在这种“既要又要还要”的诉求下,选型很困难。OLAP 常用的技术架构有预计算、MPP、索引。我们调研了这三类架构的典型 OLAP 引擎:
- **预计算架构:**代表引擎 Apache Kylin/Apache Druid ,查询性能优越,但缺少灵活性。
- MPP 架构:Presto/Apache Impala/SparkSQL,灵活性很好,但性能较差,一般在分钟级。
- 索引架构:ES/ClickHouse,单表查询性能优越,但是 Join 几乎不可用,只能用宽表模型。
单一技术架构的引擎很难满足需求,因此我们把目标瞄向混合架构引擎:同时具有预计算、MPP 计算、支持索引的引擎。目前市面上这类引擎不多,比较成熟的有 Apache Doris 和 StarRocks。最后选择 StarRocks,原因是 StarRocks 的社区更加活跃,产品的背后还有一支大胆创新的强大技术团队,响应非常及时,我们对 StarRocks 的未来更有信心。
如上图所示,我们的 OLAP 系统架构非常简单轻量,与大数据平台上下游都做了整合。
StarRocks原生提供丰富的数据导入方式,Http模式的 Stream load、读 HDFS的Broker load、读消息中间件的 Routing load、Flink Connector、DataX、外表支持等,方便和大数据生态完成数据集成。StarRocks查询支持最为通用的MySQL JDBC 协议,集成到各种BI,数据应用系统几乎无成本。
目前我们内部整合了 OLAP 系统,下线了 ClickHouse,统一使用 StarRocks 作为解决方案,已经在实时查询、报表分析、监控等业务场景中大力推广,支撑了数百 TB 数据,数十个业务方,数百万查询量/天,总体查询性能 99 分位 200ms。
三、StarRocks 经验沉淀
3.1 资源隔离,助力业务推广
3.1.1 面临的挑战
我们的 StarRocks 集群目前都是多业务共用,其中部分业务场景是大查询。例如 BI 报表一个Dashboard(数据看板)包含多个图表,打开 Dashboard时,所有图表一起加载,并且一般都是偏分析的SQL,资源开销较大。此时集群资源就有一个高峰,集群查询性能衰减,特别是小查询也会受到严重影响。下图中可以看到很多毛刺,都是大查询导致。
因为这个问题,难以保障数据基线 SLA,一段时间里我们不大敢把 StarRocks 大范围推广给业务使用。如果给每个业务搭建专用 StarRocks 集群,成本压力又太大。
StarRocks 2.2 版本开始支持资源隔离,支持配置资源组并分配资源 Quota,支持用户和资源组的绑定,可以有效将大查询业务场景隔离到专用的资源组,避免影响其他小查询。我们在 2022 年 Q2 上线了资源隔离功能,目前线上已经全部开启资源隔离,正在做OLAP业务推广。
3.1.2 整体效果
确认资源组能有效隔离大查询、保护小查询。
3.2 稳定优先,监控先行,优化运维
我们的集群稳定性 SLA 主要包括:集群可用性 SLA 3个9,集群查询性能 95分位 3s,BI 业务慢查询率 1.5%。
我们部署了社区提供的prometheus+grafana监控FE、 BE的metrics监控方案,同时配置了告警。
另外在实践过程中,有时会收到业务反馈的sql慢查询问题,排查其原因,主要可以分为两类:
- 表结构不合理:数据倾斜、分桶数量不合理,并行度不够。
- SQL 不合理:索引、物化视图无法命中,分桶、分区裁剪失效。
这些问题会影响查询性能和慢查询率SLA。为了发现和解决这些问题,做到提前感知、提前优化,我们需要监控所有的查询日志,并及时通知用户优化表结构和查询 SQL。
解决方案
StarRocks 查询状态监控。通过解析 audit.log 结合 explain SQL 的信息,统计每个慢 SQL的执行时间、内存使用、返回行数、扫描数据量等情况,对慢查询做到及时预警。主要流程可分为以下三个步骤:
1.解析audit.log
FE 的 audit.log 提供了查询类型,客户端 IP,查询用户名称,数据库名称,状态,扫描的数据大小,扫描的数据行数,结果数据行数,查询 ID(通过 ID 去 BE 日志找对应的查询资源),查询的 SQL;
2. 获取 Plan fragment
通过查询该 SQL 的逻辑执行计划(explain + sql);
3. 统计资源消耗
通过 fragment_id 查询当前物理执行计划所消费的资源:
最终实现方案如下图所示:
filebeat 采集 audit.log 和 be.INFO 日志发送到 Apache Kafka,然后 Flink SQL 聚合 query_id 和 fragment 的数据,并将数据写入到 MySQL。
整套监控系统已经在集团上线并平稳运行。上线后极大减轻了我们的运维工作,基本可以做到提前预防问题、发现问题、解决问题,有效保障了 SLA。
3.3降低门槛,不折腾用户
在以往的工作经验中,做平台的和上层用户会存在一些沟通障碍,用户往往不了解平台的架构,技术,能力,使用流程。平台技术做得再好,最终还是要通过服务用户来产生价值。为了能更好地服务用户,我们做了很多降低门槛的工作。
3.3.1 与现有的平台做打通
- **离线导数,**目前已经和离线调度系统打通,固化了一个离线作业类型,通过 Broker load 的方式导数,Hive 表可以一键订阅到 StarRocks。
- **实时导数,**目前用户可以通过 Flink-Connector-StarRocks 的方式,用 Jar 或者 Flink SQL 快速实现导数。
- Hive 外表,支持使用 Hive 外表的方式,直接用 StarRocks 查询分析 Hive 数据,省掉导数流程,适合某些临时性质的需求。
- 数据应用系统目前已经和 BI分析系统、自助分析系统打通,使用 MySQL JDBC 方式接入。
- 业务系统,目前提供 API 和 MySQL JDBC 两种方式给业务系统直接查询。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!