案例 | 火山引擎 EMR StarRocks 在旅游和广告行业中的应用

目前，火山引擎数智平台（VeDI）旗下产品 E-MapReduce（简称“EMR”）已上线 StarRocks 集群，持续为不同行业的企业客户带来业界领先的引擎性能和产品使用体验。

StarRocks 在业务侧可支撑报表系统的加速和查询，常用于广告投放效果分析、运营数据报表分析、DashBorad 看板等。 在用户画像分析的场景下，利用 Bitmap 位图技术，可以解析前端圈群过程，对复杂人群圈选进行提速。在实时数仓方面，通过内置的 routine load 导入功能可直接消费 Kafka 的消息队列，摄入到 StarRocks 提供给实时监控大屏等数仓应用场景，也可以同步 MySQL 等数据库的 Binlog 变更，实时同步到 Primary key 主键模型中同时提供高并发的查询服务。

此外，StarRocks 还支持联邦查询，可以无缝同步外部 Catalog，包括 Hive、Iceberg、Hudi、Delta lake 的外表，实现离线和实时的统一、湖和仓的联邦分析，满足跨引擎查询的功能。StarRocks 极速全场景数据分析，可提升整体分析效率，实现数据价值最大化。

在充分集成 StarRocks 技术特性的基础上，火山引擎 EMR StarRocks 提供了丰富的监控告警、扩容、参数和日志管理等功能，帮助用户提升运维易用性。作为 EMR 数据湖的加速引擎，EMR StarRocks 开箱即用，支持与火山引擎大数据开发套件 DataLeap、全域数据集成 DataSail 等云上生态产品无缝对接，满足用户一站式的数据开发和集成需求。

接下来，我们将用两个基于火山引擎 EMR StarRocks 的具体实践，为大家详细介绍离线加速和实时分析这两个典型应用场景。

案例 1：旅游行业中离线加速场景

业务背景

客户 A 是国内旅游行业中领先的休闲旅游公司，提供了包括自助、景区门票以及公司旅游、机票、酒店等在内的丰富产品和服务。在国内疫情影响逐渐消散的背景下，旅游业迎来了复苏的春天。客户 A 的业务场景迎来了比较大的机会点，对数据处理的也提出了更高的要求。

公司提供了一款面向企业内部业务人员，进行数据集成、数据清洗、数据可视化分析的产品。该产品打通各类业务数据，为业务人员提供多种数据分析方法，协助业务线提升数据分析效率，进而促活留存、增加营收，主要包含以下功能：

1. 决策看板：面向管理者的业务运行北极星指标
2. 自助分析：面向各个业务市场运营自动分析报表
3. Ad-hoc 查询：数仓部门对数据的探索

业务痛点

用户整体的数据集中在离线场景中，主要在面向应用系统时存在一些离线加速需求。

场景一：多维分析

业务原有的多维分析的框架主要是基于 Kylin+Saiku 的多维分析平台，会产生日报表和月报表。由于 Kylin 是预计算模型，需要事先构建维度模型，调度任务，然后持久化到 HBase 中。这套历史框架给客户带来了许多困扰：

1. Cube 定义成本高：增加一个 Cube 数据的成本较高，需要配置各种任务；
2. 运维成本高：Kylin 依赖组件多，需要管理 Hive/Spark，HBase，调度平台的可用性；
3. 存储膨胀：因为所有维度的数据都要生成，最全的场景会形成 2^n 的维度，造成在 HBase 和 Hive 中的存储资源占用特别多；
4. 计算延迟大：用户原有的构建流程，Kylin 每天调度超 500 minutes，到月初调度时会超过 12h。

场景二：Ad-hoc+自助分析

在 Hive 离线场景中，大数据量、低 QPS 的场景下，原有的架构上直接使用基于 Hive+Presto 的计算引擎选型。在这个数据架构下，客户遇到如下的问题和挑战：

1. 当离线批任务和 MPP 计算引擎是在混布模式下，MPP 对内存的使用要求较高，经常会带来节点不稳定性，并且没有统一的资源分配，会发生抢占，对稳定性是一个较大的挑战；
2. 在大数据量的场景上，Presto 的查询性能不满足要求，存在有几十秒的延迟响应。

基于火山引擎 EMR StarRocks 的"极速统一"解决方案

针对如上的问题和挑战，我们的目标是寻求尽可能少的 OLAP 引擎，利用在明细表上现场计算来解决 ETL 任务、数仓表过多等问题，同时兼顾在数据规模、查询 QPS、响应耗时等查询方面的需求。

StarRocks 数据库提供了兼容 MySQL 协议的能力，对 BI 工具的接入十分友好，同时提供了 Hive 外表+Multi Catalog 的方式，对离线数仓的 In-place 查询也在逐步的完善当中，提供了 CN 节点的模式。

• MySQL 协议

1. Saiku 作为一个比较历史悠久的 BI 系统，兼容了 Kylin 与 MySQL 等一些引擎，从 Kylin 上迁移到 StarRocks 的计算引擎上依然能够无缝的使用 Saiku 上的配置。

• In-place 查询

1. Multi Catalog：只需要创建一个 Hive 的 Catalog，与 Presto 的使用方式一致，然后直接可以读 Hive 上的表信息。
2. External Table：建立一个 Hive 外表，然后可以通过 Hive 外表进行对部分表的查询。
3. 这里目前的鉴权系统因为 StarRocks 与 Hive 本身的鉴权系统不兼容，所以基于 Catalog 的这种方式会查到所有的表，如果需要有权限限制的话，需要用外表的形式。
4. 该场景主要用于外表导入到内表 走 insert into select from table 的方式，和 Presto 原地查询的场景替换。

• 多维查询

1. StarRocks 的向量化引擎充分利用 CPU 的性能，可以做到在明细表不做预聚合的情况下，部分场景的性能比 Kylin 预聚合场景下的性能还要有优势。
2. StarRocks 本身的也有物化视图和聚合表模型，可以利用这些功能做进一步的内表性能提升。

案例总结

在近半年的使用过程中，多维分析的场景下，火山引擎 EMR StarRocks 在保持甚至超过 Kylin 性能的同时，极大降低了客户的运维压力，简化了数据开发的链路，并降低了存储和计算成本。

在 Ad-hoc 查询场景里，原来经常使用的 Presto 方案，在这个场景使用 StarRocks 的性能存在极大的提升，但是因为语法兼容和鉴权统一的问题，在逐步的使用 StarRocks 来分担一些热查询的流量。

案例 2 - 广告行业中的实时分析场景

业务背景

客户 B 是一家一站式的信息流广告投放公司，对接支持了国内外各种广告平台，包括抖音，快手等等。

公司内部研发了集合分析投放一体的运营平台，在投放策略的生效过程中，会存在一些维度数据需要实时更新，来保证策略的有效性，并且更新的 QPS 和时延要求都比较高。另外还会存在实时更新的数据与聚合分析的信息做一些 join 关联查询。

业务痛点

业务诉求：

1. 根据用户 id 在 ElasticSearch 中筛选查询明细数据，在 ElasticSearch 中用户 id 相关记录的更新 QPS 达到了十万级；
2. 对一些明细数据需要做秒级响应关联或聚合查询。

现有架构面临的挑战：

1. ElasticSearch 与 GreenPlum 的数据之间需要面临着数据同步的链路，增加了开发的成本；
2. GreenPlum 本身的查询性能无法达到预期，尤其是在高 QPS 的场景下，master 节点无法扩展，容易碰见单点瓶颈；
3. GreenPlum 本身的运维成本太大，扩容代价比较大，随着数据量增多，这种问题凸显。

基于火山引擎 EMR StarRocks 的实时场景解决方案

目前客户 B 在我们的建议下采用了新的架构，在新架构中使用火山引擎 EMR StarRocks 作为 GreenPlum 的升级方案。这样的方案主要是有以下几个方面：

1. StarRocks 在写入和查询性能上都有比较好的表现；
2. StarRocks 的主键能力能够承担部分 ElasticSearch 的点查点更新的场景；
3. StarRocks 有 Connector 能力，能够直接将 ElasticSearch 作为外表关联进行一些数据探索的能力，同时也支持了谓词下推等能力，使 StarRocks 与 ElasticSearch 的数据之间产生了很好的联系；
4. 因为在非常高的 QPS 的情况下，StarRocks 的能力还未能满足 QPS 和 latency 的要求，所以目前只是部分的更新和点查场景交给了 StarRocks，依然保留了 ElasticSearch 与 StarRocks 共存的场景；
5. StarRocks 的扩缩容能力较好，面对不断变化的业务负载有很好的管理。

案例总结

火山引擎 EMR StarRocks 在实时场景上有很好的业务满足能力。StarRocks 的主键能力，向量化查询都逐步在提升支撑实时数仓场景的效能，同时 StarRocks 也很好处理了与大数据生态的关联，增加了很多垂直领域上的数据源对接，这样的设计丰富了引擎本身的生态圈，并且会逐步实现极速统一的目标。

后续规划

目前火山引擎 EMR 产品上线 StarRocks 集群，增强了企业级能力，包括监控告警，集群运维，以及作业管理等能力，并共同见证了火山引擎 EMR StarRocks 在用户场景上不断发挥越来越重要的作用。未来我们会持续地投入社区共建中，开展多方面的引擎优化合作，并推进相关功能的商业化落地。

1. 深化云原生能力：例如不同角色的存算分离，包括 FE Stateless，BE 存算分离等；弹性伸缩能力，通过配置弹性策略自动调整集群计算资源，提高用户集群资源使用率，大幅降低用户成本；
2. 进一步与 EMR Hadoop/Spark 生态打通： 例如数据湖场景（包括 Hive 表）的结合，实时高 QPS 的能力构建（深度结合 ElasticSearch/HBase 的场景读写）;
3. 元数据+Query Profile 的企业级能力构建：例如将 StarRocks 的信息以更有优势的方式透传给客户，做数据治理和查询分析；
4. 可视化 Query Profiler 和 SQL 诊断模块：针对在线报表和数据仓库场景的查询语句具有关联表多、扫描数据量大、耗时长等特点，帮助用户识别慢查询，给出物化视图、索引、参数调优等查询加速建议。

点击火山引擎EMR跳转了解更多