亚马逊AWS官方博客
利用 StarRocks on AWS 实现高性能实时数据分析
介绍
数据分析已成为行业数据平台的核心需求。近年来，随着数据基础设施领域的技术飞速发展，用户对实时分析的需求不断增加，用户正在寻找能够实时进行刷新的仪表板系统、监控系统，即实时的 OLAP 解决方案。更多应用程序以秒为单位，同时将数据大小扩展到 PB 甚至更高来进行数据分析。
StarRocks 是专为跨行业数据分析场景而设计的下一代亚秒级 MPP 数据库，旨在提供任意数据规模的简单快速的数据分析。结合易于使用的数据加载管道和对数据源的丰富支持，StarRocks on AWS 可以帮助用户实现他们的目标。StarRocks Flink CDC 连接器的推出是为了简化实时数据加载管道，成为 StarRocks 数据加载领域的新成员。
在这篇博客中，我们关注两件事：
- StarRocks on AWS 如何在不牺牲查询性能的情况下实现数据实时更新。
- StarRocks on AWS 的查询性能。
通过 Amazon Cloudformation 在亚马逊云科技平台上部署 StarRocks
 |
图 1. StarRocks 基于亚马逊云科技的架构图
您现在已经可以通过 Amazon CloudFormation 在亚马逊云科技平台上轻松地部署 StarRocks 集群。通过利用亚马逊云科技全球基础设施，任何地方的任何人都可以通过几次点击在几分钟内启动 StarRocks 集群。
StarRocks 系统架构图
 |
图 2. StarRocks 系统架构图
StarRocks 的设计架构很简单：StarRocks 集群由前端（FE）和后端（BE）组成，可以通过 MySQL 客户端访问。
- FE 节点负责元数据管理、客户端连接器管理、查询规划、查询调度等。
- BE 节点负责数据存储、计算执行、压缩、复制管理等。
凭借这种简单的架构，同时没有任何第三方依赖，StarRocks 非常易于维护。
StarRocks on AWS 的实时数据更新解决方案
没有新数据就无法进行实时分析。然而，OLAP 数据库的实时数据更新并不像看起来那么容易。 StarRocks 引入了主键数据模型，以允许实时数据更新，同时对查询性能的影响最小。
StarRocks 主键模型 – 实现数据实时更新
数据实时更新：对于列式存储并非易事
为了加速大规模数据的复杂查询，现代 OLAP 数据库通常使用列式存储，以获得减少查询磁盘 I/O 和更多数据压缩等优点。使用列式存储，数据存储在按列分组的数据块中。从本质上讲，列式存储并不适合实时更新。由于仅物理访问几行会导致过量的 IO 访问，从而导致显着的性能开销。数据更新成为 OLAP 数据库领域的一项具有挑战性的任务。
StarRocks 主键模型：更新数据且不影响查询性能
StarRocks 1.19 版本引入主键模型，以提高数据更新性能。它旨在支持实时更新，同时将对查询性能的负面影响降至最低。主键模型要求表具有唯一的主键（传统 OLTP 数据库中的 Primary Key），并且支持通过主键对表中的行进行更新和删除操作。
主键模型：工作原理
主键模型确保每个主键仅存在一个记录（版本），从而完全避免查询时的合并操作：
- 当 StarRocks 收到记录的删除操作时，它会通过主键索引找到现有记录的位置，并在位图中将其标记为已删除。
- 查询时，扫描仪单独读取并过滤每个段，过滤位图中标记的行。
由于一个主键下只有单一版本的数据，在没有合并操作的情况下，查询时不影响谓词下推和索引的使用，保证了查询的高效执行。
查询性能：并发更新表与静态表
TPC-H 是决策支持基准。它涵盖面向业务的 ad-hoc 查询和并发数据修改。TPC-H 测试基准中的数据和对应的查询可以涵盖多个行业特征，具有普适性。TPC-H 架构总共包含 8 个表，数据大小可配置为 1GB 到 3TB。基准测试共包含 22 个查询，主要评价指标是每个查询的响应时间，反映系统处理查询的能力。
当使用主键模型进行查询时，与静态表相比，查询更新表的唯一额外开销是访问位图和过滤已删除的行。以下测试旨在查明更新任务对查询性能的影响到底有多大。
在这个具体实验中，我们针对 TPC-H 1 TB 数据集对 22 个查询进行了性能测试。实验包括以下 3 种被查询表的更新场景：
- 无数据更新
- 两个并发更新任务
- 十个并发更新任务
| 无数据更新 | 2 个并发更新任务 | 10 个并发更新任务 | |
| 时间开销 | 170.666 sec | 186.423 sec | 183.729 sec |
表 1. 基于主键模型在有数据更新和无数据更新下的性能表现
本次测试基于以上三个场景分别运行 3 次测试，基于三次测试的查询结果求和作为最后的查询响应时间，并把结果记录在表 1 中。根据测试结果，我们可以得出以下结论：
- 数据更新对查询性能的负面影响极小。
- 较高数量的并发更新不会对查询性能产生负面影响。
通过 StarRocks on AWS 从任意数据来源加载数据
实时数据同步pipeline
过去，要构建数据同步管道，如图 3 所示，必须有数据收集工具，例如 Debezium。收集到的数据流入消息队列，例如 Kafka，然后 Apache Flink 消费来自 Kafka 的数据写入下游目的地，下游目的地可以是各种数据库、数据湖和数据仓库。
这种 pipeline 带来了巨大的协作开销，因为在实际生产系统中，上游数据源、消息队列、Flink 和下游数据仓库通常由单独的团队维护。借助亚马逊云科技平台上的 StarRocks，加载实时数据变得更加简单。图 3 显示了当前 StarRocks 数据加载情况。
 |
图 3. StarRocks 数据加载
丰富的数据源支持
实时加载数据
您可以通过多种方式将数据实时加载到 StarRocks 中（图 3 中的红色矩形框）。
- 如果您喜欢直接将数据加载到 StarRocks 中而不进行预处理，您可以选择 Kafka 来执行 routine load。
- 如果您想通过预处理加载数据，例如创建宽表（join），您可以使用 Flink CDC 将数据加载到 Flink 中，使用 FlinkSQL 进行预处理，然后将数据加载到 StarRocks。以下是一个使用 Flink CDC 的例子。
什么是 Flink CDC
StarRocks 发布了 StarRocks Flink connector，作为一个 pipeline，让您可以轻松地将数据实时加载到 StarRocks 中。
 |
图 4. 没有 Flink-CDC 的 pipeline
Apache Flink 的 CDC 连接器是 Apache Flink 的一组源连接器，用于使用 CDC 从不同数据库获取变更数据。为了消除对图 4 中的数据收集工具和消息队列的需求，它使用了 Flink CDC 作业来简化数据管道。
如图 5 所示，Flink CDC 作业的工作原理如下：
- Flink CDC 从 MySQL 拉取增量数据
- 创建 MySQL CDC 表，并使用 FlinkSQL 来执行数据预处理任务
- 将预处理后的数据发送到下游的 StarRocks
 |
图 5. 使用 Flink-CDC 的 pipeline
基于 StarRocks on AWS 的查询性能
当谈到在亚马逊云科技平台上使用 StarRocks 进行查询时，我们想讨论两件事。
- StarRocks 利用其完全定制的 CBO（cost-based optimizer）拥有出色的查询性能，我们可能会在以后的博客中详细讨论。同时，StarRocks 支持复杂查询，特别是多表（join）查询，以确保星型或雪花型数据仓库查询成为可能。
- 您可以通过 StarRocks 直接查询本地存储中的数据，也可以将其用作计算引擎来查询数据湖中存储的数据。在图 6 中，我们演示了如何使用亚马逊云科技平台上的 StarRocks 分析数据湖中存储的数据，而无需将数据导入 StarRocks。
 |
图 6. 使用 StarRocks 进行数据湖分析
基于亚马逊云科技平台的性能基准测试
我们在亚马逊云科技平台上进行性能基准测试。通过 TPC-H 基准测试，我们比较了以下各项的性能：
- 通过 StarRocks 2.2 查询本地 SSD 存储（EBS GP2 SSD）
- 通过 StarRocks 2.2 查询 Hive 外表，查询数据存储于 Amazon S3 上
- 通过 Amazon EMR 上的 Presto 0.261 针对 S3 存储上的 Hive 进行查询
测试环境
| 实例类型 | vCPU | 内存(GiB) | EBS GP2 SSD | 对象存储 |
| 3 * m5.4xlarge | 16 | 64GB | 64GB | AWS S3 |
注意：三组测试所使用的计算环境相同。
软件版本
| StarRocks | Presto |
| V2.2 | Presto 0.261 on Hive |
查询
本博客使用了来自 TPC-H 基准测试的 22 个 SQL 查询。有关这些查询的更多详细信息，请参阅 StarRocks 社区的 TPC-H Benchmarking 官方文档。
测试结果
以下表格是 TPC-H 标准测试中的所有 22 个查询基于所 3 种不同解决方案的查询表现。结果如下图 7 所示。请注意，Hive 上的 Presto 在 22 个查询中的 2 个（查询 15 和 21）上超时（60 秒）。
| Query | StarRocks 2.2 Hive External table (ms) | Presto on Hive (ms) | StarRocks 2.2 Native EBS storage (ms) |
| Q1 | 4975 | 10032 | 1847 |
| Q2 | 1370 | 4804 | 134 |
| Q3 | 2422 | 7050 | 651 |
| Q4 | 2491 | 7905 | 449 |
| Q5 | 5435 | 15833 | 903 |
| Q6 | 2695 | 4193 | 51 |
| Q7 | 3775 | 10458 | 966 |
| Q8 | 4558 | 13606 | 573 |
| Q9 | 5290 | 14737 | 2442 |
| Q10 | 3769 | 5564 | 484 |
| Q11 | 1224 | 3905 | 160 |
| Q12 | 3238 | 6122 | 338 |
| Q13 | 3013 | 10685 | 1862 |
| Q14 | 3348 | 4811 | 187 |
| Q15 | 5470 | 60000 | 363 |
| Q16 | 1669 | 1885 | 234 |
| Q17 | 4217 | 33166 | 1011 |
| Q18 | 6393 | 44440 | 3593 |
| Q19 | 3492 | 7066 | 287 |
| Q20 | 3878 | 9378 | 754 |
| Q21 | 8531 | 60000 | 2998 |
| Q22 | 1072 | 3924 | 477 |
| Total | 82325 | 339564 | 20764 |
 |
图 7. TPC-H 100G 数据集测试结果
结论
基于亚马逊云科技平台部署的 StarRocks 解决方案专为实时数据分析而设计，支持物流管理和欺诈检测等场景，在这些场景中，必须对大规模数据集进行实时分析。 StarRocks 对本地存储的查询、StarRocks 对 Hive 外部表的查询、Presto 对 Hive 的查询（请注意，对于后两个场景，我们使用存储在 S3 中的相同数据）的基准测试结果显示，StarRocks 在所有 22 个查询中均优于 Presto。
此外，StarRocks on AWS 还针对快速增长的数据提供了可扩展的解决方案，以满足业务扩展需求。 Airbnb、Mobvista 等众多行业龙头企业已采用 StarRocks 作为其大数据平台的关键组成部分。