共计 4056 个字符，预计需要花费 11 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【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 查问：数仓部门对数据的摸索
业务痛点
用户整体的数据集中在离线场景中，次要在面向利用零碎时存在一些离线减速需要。
场景一：多维分析
业务原有的多维分析的框架次要是基于 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 协定
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 跳转理解更多
