当前位置：首页 > news >正文

大数据技术7：基于StarRocks统一OALP实时数仓

news 来源：原创 2024/5/13 3:53:49

前言：大家对StarRocks 的了解可能不及 ClickHouse或者是远不及 ClickHouse 。但是大家可能听说过 Doris ，而 StarRocks 实际上原名叫做 Doris DB ，他相当于是一个加强版的也就是一个 Doris+ ,也就是说 Doris 所有的功能 StarRocks 都是有的，但是 StarRocks 有的这种加速的功能 Doris 目前是没有的。我们可以基于 Apache Doris 统一 OLAP 技术栈，满足庞大数据体量下的实时分析与极速查询。

1、什么是StarRocks？

StarRocks原名DorisDB，StarRocks 是 Apache Doris 的 Fork 版本。StarRocks 是新一代极速全场景 MPP (Massively Parallel Processing) 数据库。StarRocks 是一款高性能分析型数据仓库，使用向量化、MPP 架构、CBO、智能物化视图、可实时更新的列式存储引擎等技术实现多维、实时、高并发的数据分析。StarRocks 既支持从各类实时和离线的数据源高效导入数据，也支持直接分析数据湖上各种格式的数据。StarRocks 兼容 MySQL 协议，可使用 MySQL 客户端和常用 BI 工具对接。同时 StarRocks 具备水平扩展，高可用、高可靠、易运维等特性。广泛应用于实时数仓、OLAP 报表、数据湖分析等场景。

StarRocks 架构简洁，采用了全面向量化引擎，并配备全新设计的 CBO (Cost Based Optimizer) 优化器，查询速度（尤其是多表关联查询）远超同类产品。

StarRocks 能很好地支持实时数据分析，并能实现对实时更新数据的高效查询。StarRocks 还支持现代化物化视图，进一步加速查询。
多分布式 Join极速引擎，这个分布式 Join 目前就是 ClickHouse 比较缺乏的一个功能。如果了解 spark 或者了解 presto 的话，其实都应该知道这都是有的，就是说这个其实就是做 Shuffle ，就是把不同的 Key 给 Shuffle 到同一个 bucket 里边，然后再去做 Join ，然后右边实际上是一个更加高效的一种 Join 方式也就是提前的去做好了这个 bucket 的分类，也就是说同一个 Key，两张表相同的 Key ，全部落到同一个 bucket 的范围，然后这个 bucket 的之间肯定是没有 over lap ，所以可以放心的做这个Colocate joy ，在这个 spark 里面也叫 bucket join 。
使用 StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。
StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。StarRocks 还兼容多种主流 BI 产品，包括 Tableau、Power BI、FineBI 和 Smartbi。

2、使用Doris替换ClickHouse、Kylin和Druid

这里有一家电子商务SaaS提供商，其数据系统提供实时和离线报告、客户分割和日志分析服务。最初，他们为这些不同的目的使用了不同的OLAP引擎：

Apache Kylin用于离线报告：该系统为超过500万个卖家提供离线报告服务。其中的大型卖家拥有超过1000万注册会员和100,000个SKU，详细信息放在平台上的400多个数据立方体中。
ClickHouse用于客户分割和Top-N日志查询：这需要高频更新、高QPS和复杂的SQL。
Apache Druid用于实时报告：卖家通过组合不同的维度提取所需的数据，这种实时报告需要快速的数据更新、快速的查询响应和系统的强大稳定性。

这三个组件都有各自的痛点：

Apache Kylin在固定表模式下运行良好，但每次添加维度时，需要创建一个新的数据立方体并在其中重新填充历史数据。
ClickHouse不适用于多表join处理，因此需要额外的解决方案来进行联合查询和多表连接查询。在高并发场景下，它的表现低于预期。
Apache Druid实现了幂等写入，因此它本身不支持数据更新或删除。这意味着当上游出现问题时，需要进行完整的数据替换。如果您从头到尾考虑所有数据备份和移动，这样的数据修复是一个多步骤的过程。此外，新摄入的数据在放入Druid中的段之前将无法用于查询。这意味着存在更长的时间窗口，从而导致上下游之间的数据不一致。

由于它们共同工作，这种架构可能太难以维护，因为它需要在开发、监控和维护方面了解所有这些组件。此外，每次用户扩展集群时，他们必须停止当前集群并迁移所有数据库和表，这不仅是一个巨大的任务，而且会对业务造成巨大的干扰。基于上述架构痛点，友赞对市面上的架构进行了调研与选型，希望选择一款能够简化当前复杂架构、统一 OLAP 技术栈的引擎。他们除了分析 OLAP 性能本身对于业务的帮助，还需要评估架构改造所带来的收益成本比，思考架构进行迁移和重构之后所带来的 ROI 是否符合预期。

Apache Doris填补了这些空白。

查询性能：Doris擅长高并发查询和JOIN连接查询，并且现在配备了倒排索引以加速日志搜索。
数据更新：Doris的唯一键模型支持大容量更新和高频实时写入，而重复键模型和唯一键模型支持部分列更新。它还提供数据写入的恰好一次保证，并确保基表、物化视图和副本之间的一致性。
维护：Doris与MySQL兼容。它支持轻松扩展和轻量级模式更改。它配备了自己的集成工具，如Flink-Doris-Connector和Spark-Doris-Connector。

3、 StarRocks和ClickHouse压测性能对比

这里比较了两个组件在SQL和连接查询方案上的性能，并计算了Apache Doris的CPU和内存消耗。

2.1 SQL查询性能

Apache Doris在16个SQL查询中的10个中表现优于ClickHouse，最大的性能差距比例接近30。总体而言，Apache Doris比ClickHouse快2~3倍。

2.2 连接查询性能

对于连接查询测试，使用了不同大小的主表和维表。

主表：用户活动表（40亿行）、用户属性表（250亿行）和用户属性表（960亿行）
维表：100万行、1000万行、5000万行、1亿行、5亿行、10亿行和25亿行。

测试包括完全连接查询和过滤连接查询。完全连接查询连接主表和维表的所有行，而过滤连接查询使用WHERE过滤器检索特定卖家ID的数据。结果如下：

主表（40亿行）：

完全连接查询：Doris在所有维表的完全连接查询中均优于ClickHouse。随着维表变大，性能差距越来越大。最大的差距比例接近5。
过滤连接查询：基于卖家ID，过滤器从主表中筛选出了4100万行。对于小型维表，Doris比ClickHouse快2~3倍；对于大型维表，Doris比ClickHouse快10倍以上；对于大于1亿行的维表，ClickHouse会抛出OOM错误，而Doris则正常运行。

主表（250亿行）：