阿里云 EMR StarRocks VS 开源版本功能差异介绍

阿里云 E-MapReduce Serverless StarRocks 版是阿里云提供的 Serverless StarRocks 全托管服务，提供高性能、全场景、极速统一的数据分析体验，具备开箱即用、弹性扩展、监控管理、慢 SQL 诊断分析等全生命周期能力。内核 100% 兼容 StarRocks，性能比传统 OLAP 引擎提升 3-5 倍，助力企业高效构建大数据应用。本篇文章重点介绍阿里云 EMR StarRocks 与开源 StarRocks 的对比与客户案例。

一、开源对比

阿里云 EMR StarRocks 与社区版本功能对比分为三个部分，首先是 StarRocks 内核及架构的差异；其次是在实例运维管理能力上的差异；接下来一部分就是关于数据的运维，也就是对 StarRocks 内部的数据应该如何管理的问题。通过阿里云 EMR StarRocks Manager，大家可以做很多与数据运维或业务运维相关的事情。

内核及架构对比

首先第一部分就是关于 StarRocks 内核的对比，阿里云 EMR 团队与 StarRocks 社区已经合作很长时间了，所以基本上会贡献给社区。但是如果是周边产品的集成或新加的一些功能还是暂时会放到 EMR StarRocks 商业化的板块中进行管理。一些商业化能力经过一些时间差也会逐步合并到社区版本中。

当前内核部分，第一个不同就是高 QPS 点查，在上万级别的 QPS 场景中，EMR Serverless StarRocks 做了一系列优化，能够保证高 QPS 下的性能的稳定性。接下来是现代物化视图，对于这个部分，EMR Serverless StarRocks 添加了物化改写的能力，用户去查询物化视图的时候，如果基表更新了，但是物化视图还没有更新的情况下，就能够快速去查询到实时更新的那部分数据，而用户的业务 SQL 是不需要改写的。还有一部分就是存算分离，存算分离主要是指数据湖当中的存算分离版本，在数据湖存算分离的版本下，EMR Serverless StarRocks 对数据湖部分做了大量优化，性能提升也极为明显，约为 20%~30%，极端情况下能到 70%，以上也是内核目前存在的比较大的差异点。

其次是数据湖的部分，在这一部分 StarRocks 重点结合 Paimon 做了大量的改造，包括集团内部也在进行业务试点的尝试，构建弹内的 StarRocks 加 Paimon 的数据湖场景。这部分的性能差异用户也能在 StarRocks 使用到最新的版本，最新版本中性能和功能都会较为完善。还有一部分就是和阿里云实时计算合作，加入了整库整表同步的功能，用户可以通过 Flink VVP 进行试用，也可以使用 Dataworks + StarRocks 进行实时写入和批量写入，同样也能实现整库整表同步更新。这一部分的功能也是和开源版本存在差异，因为它需要借助阿里云上的其他产品的能力去实现实时的写入，例如将 MySQL 的数据实时地导入到 StarRocks 当中，实现整库迁移。对于实现这样的效果，StarRocks 也将这一部分功能进行了集成。

以上就是目前在内核部分的大部分差异，基本上和社区在内核层面保持一致，但会增加一些功能帮助用户提升查询性能，或提升并发度和优化用户体验。

实例运维管理

在实例运维层面，如上图所示，在开源版本当中没有可视化的管理平台，在 EMR StarRocks 当中则有一整套的在线扩缩容、部署、集群运维管理系统。包括监控报警功能都是现成的。用户只需要使用开了 EMR StarRocks 的账号进行登录，即开即用。在 Serverless 版本中会有故障自动恢复，以及相应的一些自动恢复机制，保障各种节点自动恢复，不需要用户过多关注底层的机器资源故障或问题。以上也是 EMR Serverless StarRocks 免运维的部分，即集群的自动恢复能力方面，不需要用户使用过多人力进行机器运维。

另外一部分差异就在于弹性方面，目前用户对于弹性的需求较为明显，无论是 StarRocks 做数据湖分析，还是在传统的 StarRocks OLAP 报表分析场景当中，用户都会经常遇到偶发的波峰，而在夜晚耗费的资源就会比较少，有了弹性的能力就可以帮助用户更好的节省计算成本，具体发布见官方发布的公告，预计在 6 月初推出 CN 节点的弹性。当用户的业务有明显的波峰和波谷时，用户可以结合弹性更好地节省计算成本。

接下来就是小版本的自动升级，众所周知，StarRocks 迭代较快，非常活跃。用户经常面临的问题就是如何从 2.5.8 升级到 2.5.10，类似于以上的小版本升级。如果是自建的话，就需要自己手动做维护。在 EMR Serverless StarRocks 当中，就能够通过一键按钮，自动的进行小版本滚动升级，这也是 EMR Serverless StarRocks 较为受欢迎的点，因为 StarRocks 更新确实较为频繁。

另外还有一个在计划之中的特点就是 Multi WareHouse，开源版本目前并不会有 Multi WareHouse，但大概在 7 月底，平台会基于 Serverless StarRocks 3.3 版本推出 Multi WareHouse 能力， 帮助用户更方便地进行业务隔离。较为典型的场景就是有时需要将导入任务和查询任务分开，让他们分别使用不同的计算资源，以免由于导入任务忽然很大，导致 SQL 无法查询，或一个 SQL 查的很大，导致导入任务无法写入，以上是用户在使用 Serverless StarRocks 集群时经常会碰到的问题。

接下来是 Cluster Linking，在进行集群迁移或备份到新的集群的场景当中可以借助 Cluster Linking 工具。目前， Cluster Linking 还只是一个工具并没有完全产品化，因为基本上已经能够满足大部分场景。

以上就是关于 EMR StarRocks 与开源版本在集群或实例方面的能力差异。

StarRocks Manager

在 StarRocks  Manager 中提供了很多功能，提供 SQL Editor，用户在写 SQL，或是日常进行命令行操作时都可以使用 SQL Editor 工具，只需要在页面上连接实例，就能够打开 SQL Editor 进行相应的 SQL 操作或者查询。在线 SQL Editor 的主要优势就是方便用户进行在线查询或开发调试。

此外，Manager 层还提供了可视化数据库或数据表管理的功能，可以查看数据库或数据表，包括表的分区或其他相关信息，以上是源数据可视化的查看和管理的能力。

Manager 层还提供集群的实例健康报告，用户可以直接在控制台集群上查看健康报告。健康报告当中会帮助用户统一分析 SQL、导入任务、抓取源数据等等，健康报告会显示使用较多、使用资源较大、查询较为耗时的 SQL 语句；在导入任务方面同样也会分析导入任务占用资源较多的进程；在抓取源数据方面会给出小文件分布较多的表或分区的数据的位置，以上就是平台结合整个集群实例会给予用户的健康报告内容，以帮助用户做集群治理或业务层面的数据治理。

在慢 SQL 方面，EMR Serverless StarRocks 同样也提供相应的归因分析。在用户日常使用当中，会出现某个 SQL 运行得很慢的情况，用户不知道为什么运行得很慢，Serverless StarRocks 就会提供一套慢 SQL 的可视化信息分析，用户可以看到每个 SQL 的使用情况，包括运行慢的原因，需要如何解决等。以上所提内容会在 EMR Serverless StarRocks 最新的版本当中迭代支持。

在导入任务方面，无论是实时导入还是批量导入，或是其他各种导入任务的日常管理，也是 Serverless StarRocks 的痛点，平台会提供相应导入任务的相关管理界面，用户可以实时看到有什么任务在运行、任务故障的日志信息、错因、进度信息等。

安全及权限

接下来是权限可视化方面，EMR Serverless StarRocks 提供了基础的可视化权限配置，当然用户也可以直接通过命令行进行权限管理。

目前，可视化物化管理部分、血缘分析已经在设计中，在 Serverless StarRocks 3.x 之后的湖仓新范式的概念中，用户会越来越多的把许多数据处理或数据加工的任务放到 Serverless StarRocks 当中，则会面临一个问题就是血源关系是什么样的？以及倘若任务出现故障，影响故障的上下游是哪些？以上均是 StarRocks 3.x 之后的湖仓新范式的概念中用户应用到具体场景中会出现的问题，这两部分就是物化视图和血缘，预计在六到七月份做版本发布。

还有一部分是与 Cache 相关的，用户在使用 Serverless StarRocks3.x 版本之后，会进行到存算分离的架构当中，在这套架构当中用户会面临的问题是开始在哪里？有没有命中？哪些表命中了？哪些表没命中？哪些 SQL 命中了？哪些 SQL 没有命中？对于以上情况，平台都会提供 Cache 相关的一整套 Manager 能力，这套 Manager 能力主要就是解决在缓存当中会碰到的一系列问题。用户可以看到 SQL 中缓存的命中情况、命中的比例。对于数据表和数据库，用户也能够看到数据库或数据表缓存的数据量有多大，包括在健康报告当中也会给出缓存相关的分析信息，例如会给出哪些表使用较多需要进行缓存？或者哪些缓存现在是该命中的情况下没有命中，可能需要进行优化。以上内容也会在健康报告当中结合缓存的分析报告，给出用户相应的治理建议。内容对于存算分离场景下的缓存也是较为重要的，如果要把存算分离的架构用到最优，对缓存的管理就是第一步。

售后及支持

售后服务方面，如果是社区，用户则需要依赖于社区的版本支持；如果是 EMR Serverless StarRocks，就可以通过支持群或联系技术专家进行售前阶段及售后阶段的咨询，帮助用户尽快将业务落实到 Serverless StarRocks 上。如果在使用过程当中出现问题也可以寻找技术专家进行支持。

以上内容就是 EMR Serverless StarRocks 和社区版本的能力差异，也是 EMR Serverless StarRocks 产品希望能够帮助用户解决到的问题。用户在选型时可以进行综合评估，同时也能加入钉群进行反馈。 

二、客户案例

以下为 EMR Serverless StarRocks 典型客户案例，可供参考。

案例一：某在线教育客户- BI 自助/指标平台/多维分析/

首先是某在线教育客户，致力于做传统的 BI 报表、对内的运营分析报表、指标平台等业务系统的数据。这部分数据当中有 T+1 的，也有实时写入的。该用户要求指标能够灵活定义，各个维度之间能任意组合。该用户原先使用的解决方案，有 Presto/MySQL 方案，也有较为传统的 Hive、Spark，但基本上性能较差。EMR Serverless StarRocks 和 Spark 对比，性能有几倍的提升，该用户期望有更高性能的报表分析综合平台，就选择了 EMR Serverless StarRocks 路线。

其次，EMR Serverless StarRocks 支持 upsert 场景，传统平台和 Spark 不支持 upsert 场景， 当然目前结合一些湖格式用户也能够完成，但整体的弹性性能不如直接使用 EMR Serverless StarRocks 进行查询。如上图所示，该用户的整个数据架构就是将原始的数据、Binlog、日志实时地通过 Kafka、Flink 进行处理之后，实时写入到 Serverless StarRocks。以上是实时数据的链路，还有一部分数据量较大的数据使用离线的方式，通过小时级使用 Hive 加工之后，然后通过 BulkLoad 的形式上传到 Serverless StarRocks 当中，完成之后就在 Serverless StarRocks 内部形成了一整套的对业务相关的表的集合。基于这个集合就可以做上游的多维报表分析、自助 BI 报表平台或指标平台。以上功能基于 Serverless StarRocks 都会对该用户提供较大的性能提升，此外，相应的技术栈也会相对简单。在 OLAP 场景下将所有数据都交给 Serverless StarRocks 即可，以上就是某在线教育客户的场景，其实也是 Serverless StarRocks 最擅长的场景，即传统的 OLAP 报表分析。

案例二：某在线教育客户-实时事件分析

该案例的在线教育客户主要进行实时事件分析，即实时地将一些数据通过 Flink 直接写到 Serverless StarRocks 做事件分析。对于实时事件分析的场景，在之前用户会使用 Druid 方案当中一些相对较为复杂的结构，查询性能和 SQL 语法支持方面相对于 Serverless StarRocks 来说较弱。所以最后用户整体上使用了 Serverless StarRocks，用 Serverless StarRocks 替代了实时写入、实时查询、简单的域聚合等，在将所有东西嵌入到 Serverless StarRocks 之后，整体的查询性能有两倍以上的提升，SQL 的查询语法也是 Serverless StarRocks 所支持的，所以他的 SQL 灵活度也较高，可以随意使用一些组合，对用户实时写入、实时进行事件分析的场景较为适用。在日常生活当中能够见到的一些大屏也是实时写入的案例，同样使用的也是 Flink 加 Serverless StarRocks 的组合，对于类似的场景，使用这套组合也是极其稳定和保险的，同时也是 Serverless StarRocks 所擅长的核心场景。

案例三：某金融公司-OLAP 组件统一提速

本案例中该用户的初衷是对 OLAP 组件统一提速，这也和 EMR Serverless StarRocks 所宣传的概念一致。该客户是一个金融公司，对于金融公司来说可能会有较多的 OLAP 组件，就会存在相应隐患。较多的 OLAP 组件对于公司来说第一个缺点是运维较为复杂，第二个缺点就是存在大量实例，会消耗极大一部分的硬件资源成本，在某些场景当中并发会受限，慢 SQL 运行的也会比较慢，以上内容都是该用户所面临的痛点，总结起来就是组件过多难以维护，需要部署的集群过多成本较高。

最后该公司决定将整个 OLAP 相关的明细或数据等所有业务数据都关联到 EMR Serverless StarRocks 当中，通过 Serverless StarRocks 做统一的 OLAP 组件，在此操作之下对该用户的业务性能查询提升也是较为明显的，整体提升 40%左右，资源使用率降低达到 50%，主要在于 Tidb 方面节省的成本。在进行简单的数据处理加工时，进行预聚合的时间原来需要三十分钟，现在只需要三十秒，所达到的提升有原来的几十倍。所以对该用户来说，性能也提升了，成本也降低了，原来的预聚合场景的性能提升也非常快，所以消耗的资源也就变少了。

此案例也有越来越多的客户在选型时进行参考，尤其是在选择新业务的时候，基本上就会选择 Serverless StarRocks。对于用户来说，节省了成本，在后期的技术当中也能做得更为统一。本案例中的客户还希望实现对用户行为进行分析、监控、报警、用户画像的功能，该用户也就是期望所有 OLAP 相关的能力都可以由 Serverless StarRocks 统一管理和维护。

案例四：某游戏公司-广告投放

该用户是一个偏具体的场景，从技术角度来看，有两个数据量较大的表，数据写入频率也较高。在需要多表、专业的性能要求较高、写入的性能要求较高的场景下，就比较适用于 Serverless StarRocks，对用户来说，将这部分数据切到了 Serverless StarRocks，提升了整个数据链路的实时性，提升了整体的查询性能，业务使用查询性能提升也较为明显，成本也相对较低。

以上就是 EMR Serverless StarRocks 部分案例场景。

目前也存在一种现象，越来越多的用户会直接将相应的数据放到 Serverless StarRocks 进行建仓，进行存算分离的用户也越来越多，或使用 Serverless StarRocks 去构建一整套的小型数仓场景，即直接使用湖仓新范式直接去落地。

产品导航

• EMR Serverless StarRocks 版官网：https://www.aliyun.com/product/bigdata/starrocks
  

• 产品控制台：https://emr-next.console.aliyun.com/
  

• 产品文档：https://help.aliyun.com/zh/emr/emr-serverless-starrocks/
  

• 直播回放链接：https://developer.aliyun.com/live/254040
  

EMR Serverless StarRocks 钉钉交流群（群号：24010016636）