更多技能沟通、求职时机，欢迎关注字节跳动数据渠道微信大众号，回复【1】进入官方沟通群

日前 ，火山引擎数智渠道（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 查询：数仓部分对数据的探究

事务痛点

用户整体的数据集中在离线场景中，首要在面向运用体系时存在一些离线加快需求。

场景一：多维剖析

火山引擎 EMR StarRocks 场景案例分享

事务原有的多维剖析的结构首要是根据 Kylin+Saiku 的多维剖析渠道，会产生日报表和月报表。由于 Kylin 是预核算模型，需求事先构建维度模型，调度使命，然后耐久化到 HBase 中。这套历史结构给客户带来了许多困扰：

  1. Cube 界说本钱高：增加一个 Cube 数据的本钱较高，需求装备各种使命；
  2. 运维本钱高：Kylin 依赖组件多，需求办理 Hive/Spark，HBase，调度渠道的可用性；
  3. 存储膨胀：由于一切维度的数据都要生成，最全的场景会形成 2^n 的维度，形成在 HBase 和 Hive 中的存储资源占用特别多；
  4. 核算推迟大：用户原有的构建流程，Kylin 每天调度超 500 minutes，到月初调度时会超越 12h。

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

火山引擎 EMR StarRocks 场景案例分享

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

  1. 当离线批使命和 MPP 核算引擎是在混布方法下，MPP 对内存的运用要求较高，常常会带来节点不稳定性，并且没有一起的资源分配，会产生抢占，对稳定性是一个较大的应战；
  2. 在大数据量的场景上，Presto 的查询功用不满意要求，存在有几十秒的推迟呼应。

根据火山引擎 EMR StarRocks 的”极速一起”解决计划

针对如上的问题和应战，咱们的方针是寻求尽可能少的 OLAP 引擎，运用在明细表上现场核算来解决 ETL 使命、数仓表过多等问题，一起兼顾在数据规模、查询 QPS、呼应耗时等查询方面的需求。

火山引擎 EMR StarRocks 场景案例分享

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 相关查询。

事务痛点

火山引擎 EMR StarRocks 场景案例分享

事务诉求：

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

现有架构面临的应战：

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

根据火山引擎 EMR StarRocks 的实时场景解决计划

火山引擎 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跳转了解更多