传统OLAP架构，解决的更多是离线分析场景的需求，随着大规模数据服务场景的增多，业务侧不断有新的诉求提出，对数据分析的时效性要求变高，当前架构中存储和计算资源耦合，不同业务、时段及用户对二者要求往往不同，导致集群响应不够及时等问题。本文重点分享OLAP在火山引擎EMR上的云原生能力及在火山相关客户中的应用实践。
本文来源于火山引擎 EMR 团队大数据工程师琚克俭在【DataFunSummit 2023：OLAP 引擎架构峰会 - OLAP 最佳实践论坛】的同名主题分享。
首先分享一下EMR产品的优势，以及可服务的场景。
EMR在各个云厂商中是标准产品，随着产品迭代，EMR产品也在不断丰富，特别是伴随OLAP场景兴起，EMR也集成了OLAP场景下的能力。火山EMR提供了存算分离、冷热分层、按需弹性等能力，这些能力的实现基于火山已有的基础设施，包括对象存储、ECS等，在此基础上资源整合，形成了开源生态。EMR产品面向的场景主要是4类：
- IDC上云：此前用户接触比较多的包括CDH或HDP等产品，火山提供了包括EMR及数据开发、数据集成等比较完备的生态；
- 数据湖：不仅是湖存储这种模式，基于火山的对象存储，做了弹性存算分离的架构，同时，也自研了透明加速的能力，引入Job Committer逻辑；提供冷热分层，基于表查询做行为，形成自动的数据冷热判断，进而进行数据自动的冷热迁移；
- 实时数仓：这个场景是今天分享的主题，在OLAP领域有诸多产品，类似Presto、ClickHouse、StarRocks、Doris等，目前火山主推的主要有StarRocks和Doris这两个OLAP引擎；
- 开源切换：火山EMR是面向开源，在此基础上面向用户需求，如被私有架构或开源产品Lockin、无法二次技术创新等问题，进行技术共建。
这部分重点分享火山OLAP云原生的能力。
OLAP云原生：企业级运维
OLAP云原生提供了两种形态，半托管及全托管。半托管针对自主能力及研发能力比较强的用户，火山提供运维平台，用户可自主进行火山EMR大数据及OLAP能力的运维管理，自主进行如业务系统部署等操作。全托管是高SLA保证的运维形态，面向中小型客户，减轻客户运维压力。
OLAP云原生：极致弹性
在云上最主要是弹性能力，在这方面，火山提供了EMR Stateless理念，可实现集群级别的弹性伸缩。将用户在火山上做的集群、相关配置、Query进行持久化，集群释放后，相关状态均会进行留存，当想恢复集群时，即可基于上述状态、Query，对集群重新建立，也就是无状态化集群。其次，基于ECS方式集成更多能力，如ECS包含了停机不收费能力，在EMR上也可以集成相关能力，优化成本管理。此外，火山也实现了基于时间和负载的弹性伸缩的方式。
OLAP云原生：成本管理
火山目前支持StarRocks/Doris此类OLAP集群与Hadoop/Spark集群的混合部署，可以更好地进行成本和性能的平衡。这种方式下，EMR的Master节点与Hadoop或Doris/SR的Master节点进行混合部署，采用这种方式主要是考虑SR/Doris需要建立在高性能存储/节点上，而Hadoop/Spark更多是低成本考量，基于此，相关Master节点进行混合部署，而存储或计算节点依然单独部署，既保证了资源利用率，又保证了隔离性和生产稳定性。
火山支持StarRocks/Doris智能的冷热数据管理。其核心架构基于火山对象存储方式，这个场景未来将具有更广泛前景。目前StarRocks/Doris都有存算分离方式的趋势，通过对象存储来实现成本管理的优化。冷热数据管理可能更具有技术预研性。目前冷热数据管理主要应用在湖仓一体场景下，SR/Hadoop集群对数据访问场景下，TOS本身可进行冷热策略管理，StarRocks/Doris自身也可以进行冷热分区管理和数据自动迁移。
OLAP云原生：面向查询的智能分析
大小查询及查询的稳定性等是实际生产中需要解决的问题，在火山主要通过作业及对作业的分析来实现面向查询的智能分析。StarRocks/Doris的作业管理主要是在内存中实现的，没有持久化，重启或异常时，作业面临丢失风险。针对作业进行分析诊断，比如，一个比较大的Query，哪个算子影响了Query，如何找到、优化算子，是诊断分析的主要工作。从流程上来看，左侧图展示第一步，从作业列表中找到Query，找到后进行算子分析还是做建表优化，亦或是大小表转换，这是第二步（右侧）诊断分析的工作。
这一部分将重点分享火山生态下不同客户的应用实践。
实时场景下某新广告客户
客户相关背景情况：使用开源的Greenplum，存放近3个月的数据，用于在线报表查询；在线和离线数据存储在不同地方，读取离线数据需要先读取到在线存储中。
客户核心痛点：实时性及查询性能问题，原有Gp模式需每15分钟批量写入最新数据到在线数据存储；实时更新能力；在线报表业务的联合多维分析性能不佳。
针对用户情况火山提供了Doris+ES方案，通过客户现有MySQL+Kafka业务数据库经过DataSail，进入Doris及ES。其中，Doris可适配不同的connector，ES在更新场景下对数据实时性要求比较高，特别是点更新场景，保证数据的实时性。
原有服务中Doris一般采用外表形式，每新增一个表均需Create External Table，我们进行了Catalog方式的开发，只需要定义源端资源（ES的链接），即可实现对源表使用。
这方面的优化包括列裁剪、filter下推、Agg下推等。这其中，重点介绍RuntimeFilter join优化。Doris与ES关联列表的查询场景下，我们期望有ES点查的能力并下推到ES中去，在一些场景下，Doris未能充分利用RuntimeFilter，无法实现join场景下的下推，我们尝试了包括Outer join转换成inner join，也发现了更多可以实现RuntimeFilter下推的方式。
该用户数据体量并不大，相关数据均存储在实时数仓中，大数据的更新（持续几十分钟）也在OLAP上实现，上述需求对系统压力比较大。我们使用了Doris的资源隔离能力。Doris资源隔离能力主要有三种，一种是节点级隔离能力，给节点打Tag，把任务分配给不同的Tag。这种方式虽然是物理隔离，但会牺牲资源利用率；第二种是单Query隔离，可以设置内存或CPU的资源隔离；第三种是针对用户设置隔离。
该用户原始采用Gp方式，在面对很多小任务数据导入需求时，SR/Doris原有的load方式对MySQL数据导入的load语法并不支持，我们就开发了MySQL load的语法，实质依然是Scream Load方式，外部进行了语法转换。
相关功能上线后，我们将用户原有Gp集群减少了一半，从性能来看，相关工作取得了比较明显的效果。
离线场景下某互联网旅游行业用户
客户背景情况：使用SR用于旅游客户的运营活动分析，历史架构是Hadoop+Presto+Kylin的大数据体系。
客户面临问题：数据规模增速高于业务增速，急迫的降本压力；Presto与Hadoop混布，稳定性差；Presto本身的性能问题和JVM GC内存使用；Kylin依赖多套大数据系统，维护成本高。
客户解决方案：使用SR将Presto+Kylin替换，采用Hadoop+SR。
从Kylin使用情况可以看出，存储资源放大比较严重，数据查询频率低，存储基本处于无用状态；Kylin预计算的资源使用量和延迟比较大；Kylin对接了包含计算、HBase及调度等多个系统，维护工作大。此外，Kylin还对接了BI系统，相关数据主要提供BI工具使用，相关架构的替换还需要考虑BI兼容性问题。
相关架构升级后，SR与MySQL及BI工具的适配性好；性能好，无物化视图的情况已经比kylin的场景要好，在创建物化视图之后性能更优；存储成本低，默认存储压缩，存储成本减少近10x；与Hive的In Place数据查询兼容。
在湖仓架构升级中，SR架构选型的主要原因就是Catalog的动态添加。SR本身也在进行Trino的语法兼容，用户原有几千个sql可以无缝衔接。升级后，相比于Trino查询SR有比较明显的提升，可以节省2/3的计算资源。
在湖仓场景下，SR/Doris自身对CN节点的支持，使我们具备了Task节点的扩缩容，Task节点不存储数据，是无状态的，可以实现快速扩缩容。
- 实时引擎：在前述案例分享中，用户采用了Doris+ES方案，用户场景是高QPS写入、点查及点更新场景，但目前SR/Doris在高QPS场景下由于version+compact的架构设计，对性能均有比较大的损耗。火山目前在这方面，计划引入行列混存及WAL+MemTable的写入，提升高并发及点查能力。
- 云原生升级：目前SR/Doris都在进行CN节点优化，但现在的支持度上更多是支持外表数据的优化，在湖仓场景上使用；未来，可以实现BE存储节点和CN节点的顺滑交互；此外，SR目前也开放了存算分离的方式，未来也将向产品化方向努力。
- 离线引擎：重点实现一套存储，一套元数据，多套计算引擎，轻量化ETL的场景。
以上是本次分享全部内容，其中涉及的功能均已在火山引擎EMR产品上线，欢迎大家开通使用。