一、EMR Serverless StarRocks发展路径

首先回顾Serverless Spark在EMR的发展路径。右边图是典型的大数据的架构图,存储层一般用HDFS或者是SI协议的OSS，处理层一般分为批处理和流处理。批处理一般实时标准是spark，流处理实时标准一般是Flink。分析层处于一种百家争鸣的状态。

在StarRocks出事之前，常见的几款的Olap引擎包括ClickHouse，Druid，Presto， Impala。但在2021年9月份StarRocks开源之后，业界的趋势，以及整个Olap引擎朝着急速和统一的方向往StarRocks发展，业界里有很多典型的案例。对于EMR的思考是EMR的Olap的发展趋势。推出整个数据分析集群的类型，包括ck，stories，在2021年时引入StarRocks，发现StarRocks在整个Olap架构里处于领先的地位。

在2021年9月份开源之后，把团队的人员，重度的投入社区，向StarRocks方向发展，然后推出EMR的Olap的Serverless这款产品。随着支持的深入，发现社区发展太快的问题，在升级包括监控，告警，还有比较深入的特性里，半托管没法提供。在去年六月份正式发布StarRocks全托管的产品，在今年的八月份，随着StarRocks3.X的不断成熟，在内部打磨将近半年的时间，在八月份开始正式的商业化，EMR Serverless StarRocks1.0存算一体带来的成绩。大概有500家生产客户已经运行EMR Serverless StarRocks，覆盖20多个行业。

行业里面各种Olap的需求大多不是相似的，但有不同，从StarRocks的角度来看，已经基本上覆盖整个Olap所有的场景，包括高频检查，传统的Olap分析，大宽表分析，多表的joint分析，实时数仓。Serverless StarRocks在1.0里的存算一体的架构图，最底层是存储层。存储层一般提供ESSD的机型，也提供本地的SSD机型，OSS主要是数据的导入导出，还有备份的角色。

计算资源层采用比较经典的KYS加上ECS架构，KYS能够保证云操作系统的升级，rolling update，包括配置管理是非常的成熟，ECS保证客户的稳定性，每个客户都是独享的资源，能够最大的保证客户的稳定性。上边管控平台层。管控平台层包括实例的管理，监控与报警。元仓架构对客户的帮助非常大，通过搜集集群的运行日志，然后运行metrics对整个集群做比较关联的分析，导出非常有效的数据，然后赋能业务，包括集群的诊断分析，慢查询分析等。

二、EMR Serverless StarRocks 1.0存算一体架构

StarRocks存算一体核心功能是健康诊断，作业没有变化但是为什么集群负载变重，是不是SQL把整个集群的负载拉高，在开源里没有有效的方法，推出实时分析的能力，圈选一段时间,分析整个这段时间里对应的compaction任务，对应的后台任务，对应的导入任务和对应的查询任务，做大的排序，然后就可以知道这段集群里发生过什么。

技术依赖元仓技术，通过后台的日志分析整个的metrics，还有集群的关联分析，把整个系统做出来，然后离线就是通过T+1的离线报告，呈现出昨天SQL是什么样的大盘，比如慢SQL是多少，SQL的top query是什么，昨天的导入发生什么情况，有没有热库热表，把这些信息都传给客户。

第二个核心的功能是SQL调优的功能，全面的将整个SQL记录下来，然后做可视化的profile，根据历史的经验给诊断的建议，比如右侧比较复杂的SQL，是客户刚上线的SQL，看SQL是不是符合自己的预期，看整体的概览，整体的建议，也看算子是不是能够正常的运行，每个算子是不是做的比较重，SQL是不是有优化的空间。

物化视图是第三个核心的功能。物化视图是社区非常重点的方向，也是社区强推的一种方案，物化视图底层对应的是ETL的作业。上层对应是CPU的改写，能够进行透明加速。如果有实践经验，发现物化视图如果写的好或者写的不好的，对资源的耗费，对查询的有效性，对加速性有非常大的不同，所以提出三步骤，第一是把物化视图监控起来，然后把核心的指标透传给客户，客户根据指标看集群物化视图是不是符合预期。第二是检测出比较低效的物化视图，比如物化视图做出来但没有被访问，认为做的是比较低效的物化视图，然后内部也做更新的尝试，根据客户的SQL历史进行物化视图的推荐。比如有三张表，这三张表做join，然后三张表join被更多的SQL语句查询，是不是可以把SQL三张表做物化视图然后进行加速。

经过一年多的落地，看到存算一体有难以解决的问题。第一个是昨天的场，还有整个湖应该是一种业界的标准。Lake house也成为一种既定事实，无论在北美市场还是中国市场，所以在存算一体架构上，对于湖的访问实际是不太优雅的过程。第二是有工作流之间互相的影响，比如高频检查，要求整个的SLV是非常高的，然后物化视图带来的ETR作业，实际对整个的集群资源的使用量非常大，所以缺乏手段把他们有效的进行分开。第三是没法做整个的冷热数据分层，存算一起能够用SSD存整个数据，对于存储的数据量，还有存储的数据成本比较高。客户如果有非常典型的冷热方式，很多的情况下，客户目前能想到一种方案是先把热数据导到StarRocks里，然后不断的通过spark作业，或者通过其他的导出手段，把这些表降冷到OSS里，整个方案不是非常优雅的状态。第四是弹性，在存算一体里，计算跟存储是绑定的，如果对应出有弹性的资源，整个底下的tablet副本需要迁移，迁移过程实际是再平衡的过程，整体对于集群或多或少有影响。

StarRocks官方社区推荐的一套比较正确的使用范式，也是lake house架构，在上边把StarRocks看作仓，是存算一体里使用的非常正常的方案，比如 慢SQL用Flink CDC直接把数据镜像到StarRocks，然后做查询。可能已经有EMR或者有整个的离线大数据分析，已经有湖的格式希望用one copy，不希望导数据，直接用StarRocks去查数据，这是对应的湖的查询。右边是对于湖查询加速的过程，可以用物化视图，还有一种外表的物化视图，把外表当做一层表，然后经过物化视图，不断的把外表ETL到内表的过程，架构在存算一体里完成的是不优雅的。

三、EMR Serverless StarRocks 2.0存算分离架构

EMR Serverless StarRocks 2.0存算分离架构是解决整个场景比较终极的方案。存算分离的架构上面是Control Plane层。Control Plane层元仓分析包括健康报表，实时分析，还包括SQL诊断都用到元仓分析。

StarRocks存算分离的集群，从存算分离的角度上来看，已经没有BE的概念，叫CN的概念。CN的概念是compute node的概念，顾名思义是计算节点，没有存储数据的功能。计算和存储一旦分离开，整个能直接推理出来。有两个比较核心的特性，隔离性和弹性，隔离性在存算一体里没法做，物理隔离因为数据在那里，没法做整个物理上按照节点组来切开，一旦有弹性发生，实际在存算机一体里是对应的tablet的变化，弹性是比较重的。

最后一点是成本问题，存算一体里提供SRA必须要用三副本，三副本里的核心逻辑是可靠性和可用性。可用性是一台机器如果宕机，查询没有问题，因为还有两副本可以去提供服务，可靠性是一旦某一台机器的磁盘遭受损坏，可以通过另外两部分副本进行正常的导入，也可以通过另外两部分副本把数据恢复，所以存算一体里面必须要用三副本，但存算分离的架构推荐客户用单副本的缓存，再加上一部分的OSS，因为可靠性来看，直接推到OSS层，提供可靠性是完全够用的。可用性,一旦一台机器宕机，可以从OSS里拉数据，不会导致整个可用性的中断。

StarOS是操作系统的意思，起比较高大上的名字叫StarOS，它有核心对应的两部分，第一部分对应的是调度，第二部分对应的是缓存。假如在存算分离里面，一台机器宕机，或者进行弹性，整个对应的调度不一样，一台机器宕机之后，为不影响可用性会立马的进行重试，把整个的tablet，因为tablet和存储没有物理上的绑定关系，是逻辑上的绑定关系，逻辑上的绑定关系，tablet本来在CN1上，如果CN1宕机，会把tablet调到CN2，用CN2来算，所以整个调度由StarOS来完成。

弹性的调度包括感知调度和热点调度，实际会有场景的优化，客户从10个节点弹到20个节点，希望把整个集群全部的资源用上，还有一部分客户可以慢慢的用，而不是全用，因为前十个节点已经有缓存，业务是平滑的切换，不希望把10节点和20个节点全部用上，导致缓存迅速的失效。完成的思路是给配置到客户，根据不同业务的状况，调不同的参数，缓存管理可以把数据提前做缓存，缓存是partition级别,一张表里有冷的partition，还有热的partition，希望只查七天的数据，可以把七天的partition load到缓存里，对昨天的SQL进行缓存命中率的判断，这样能让客户看到缓存是不是有效的缓存，昨天做的缓存的load，预热的操作是不是有效的。

Multi-Warehouse是硬隔离，在存算一体里用的是软隔离的方式。软隔离是资源组的概念，资源组的概念是accounting，是技术，query到底跑多少的CPU，跑多少的IO，然后一旦达到限制，就会kill，让他不再继续跑，达到隔离作用。但是社区推很长时间，实际在客户落地里做的不是特别好，第一个是不好配置。

第二个是用起来整个的坑比较多，在IO的方向上，很难起到非常好的隔离效果，所以在存算分离里提供的是硬隔离，不同的节点形成不同的资源组，上面可以看到ETR的作业，然后看到Warehouse有检查的作业，客户从impala，从Presto，然后从CK直接切到StarOS，用存算分离，把impala做warehouse，把CK做warehouse，把Presto做warehouse，他们面对的场景不同，配置和缓存的策略包括弹性的策略都不一样，比如impala希望是一种半缓存的状态，因为需要的时效性并不高，可能配置一定的缓存盘就够，比如ck要求的是全缓存，做全缓存收益性非常大，整个在StarRocks全缓存跟存算一体的性能没有差距。

比如Presto，希望慢点，因为不需要完全的缓存，也不需要缓存，所以为节省成本不设缓存盘，在warehouse里可以做三个warehouse，然后设置不同的弹性，不同的缓存完成整个迁移的工作。多部门可以分开记账，因为混用到集群里，很多情况下记账是不清晰的状态，弹性是存算分离里最自然的结果。去掉整个存储和计算的绑定关系，弹性起来是非常清亮的。配置的步骤比较小，在warehouse里做基于时间的弹性，客户从8点到14点，原来的固有资源是500cu，在六小时里弹性出来500cu，弹出来之后，还会给客户事后的成本分析，就是弹性1000资源，这1000资源有没有很好的利用，这是客户最关心的，如果利用不好，明天可能弹700资源就够，如利用率特别大，明天还再多弹，因为整个是非常灵活的过程，整个的资源的使用量分析，包括后续推出的账单分析对客户非常有帮助。

然后是内表做的优化，在StarRocks里，从2022年，一直在做整个内核优化的商业版本，内核的优化整体来看，做工作包括检查，包括核心算子的方面，在TPCDS的TPCH的实体里有打榜，打榜在11月份、12月份进行公布，无论从性价比还是性能上，对整个现在的榜单的第一名有非常大的提升，在存算分离里最重要的是在OSS冷查阶段，对比开源社区有非常多的提高。

第一点把整个冷查的OSS，客户已经看不到OSS，不需要自己去指定bucket，有几个好处。第一个好处是客户不用关心整个的监控包括延时，带宽，都不需要管，完全托管给全托管产品就好。在OSS里也做很多优化，包括基于OSS最佳实践的特性的优化，文件的合并，异步化，文件最佳大小的适配，自适应的算法。

通过自适应的算法，在不同的workload里选取比较多的优化手段。自建StarRocks的存算分离版本门槛特别高，包括实际案例，看到IO非常的多，但数据量非常少，最后数据量是1GB，或者几兆B，很多情况下在做索引的获取，根据profile的分析里看到索引的优化，对整个的OSS冷查的阶段是至关重要的一部分。看几个客户的开源自建的对比。开源自建搬到全托管上，收益非常大，无论从性能，包括查询的稳定性，因为查询的稳定性有一种可能，今天跑的冷查可能是三秒钟，但明天可能会跑到20秒钟。这是实际发生过的案例。但如果迁到EMR Serverless StarRocks上，整个均值和方差非常小。看湖表的优化，湖表是这两天比较轰炸的主题，包括open lake都在讲湖的故事，无论选取三剑客还是选取阿里云的Paimon，无疑是做湖方面的优化，湖的优化讲究非常多，第一个是原数据的获取优化。客户如果使用StarRocks去查Paimon或者StarRocks去查iceberg，有比较大的直观的感受是有时查不动，虽然查出来的数据可能只有几条，或者是很小的数据量，但为什么会查不动，可以去debug一下profile。很有可能花在原数据上，如果一张表特别大的情况下，去获取整个原数据，原数据没有做非常好的治理，比如manifest没有做非常好的治理，那么拉取manifest去解析ever形式的manifest会有非常大的overhead，很多情况下导致优化器超时。冷查优化跟内表的冷查优化差不多，Paimon是阿里云推的，对整个的优化做的非常多。除此之外在图表的优化视图里做很多的优化。

湖表最常见的问题是Trino，即比Trino快，为什么会比Trino快？有三大核心，第一大核心是向量化计算，第二是新一代CPU的加持，还有是语言上的优势，用c++引擎对比java的引擎，优势比较大，是不是可以非常方便的从Trino切到StarRocks，答案是非常肯定，业界有非常多的伙伴做，究竟选择内表还是选择湖表，和snow flake和data break整个的故事是相关的，snow flake是以仓为主体。然后加大湖的投入，这是整个技术的发展过程。然后data break从day one就开始做整个的湖链路，无论是推at lake或者花重金收s berg。都是从湖上转仓的过程，现在业务发展到哪个阶段，或者整个的基础设施到哪一阶段，有不同的选择。

四、Demo基于Flink+StarRocks实现用户实时分析架构图

使用Flink+StarRocks实现实时的湖仓分析，平台提供极速的实时OLAP分析体验。使用Flink订阅原始数据，实时写入StarRocks，通过StarRocks物化视图进行查询加速。EMR Serverless StarRocks是开源StarRocks在阿里云上的全托管服务，可创建和管理StarRocks实例以及数据。支持存算分离架构，多计算组，弹性伸缩实例诊断，SQL分析诊断、自动升级等能力。可以结合实际业务场景灵活选择合适的版本，满足业务需求。多计算组是解决StarRocks资源隔离的完美方案。

可以将导入业务，AhHoc查询业务，报表系统等多个业务划分不同计算组，结合按需弹性，保证稳定性，也可大幅降低计算成本。结合弹性伸缩能力，可以按照不同的业务波峰波谷配置灵活的计算资源，有效降低计算成本。实施诊断可以针对高负载的时间段进行诊断分析。健康分析报告可以T+1给出实例分析报告，便于后续运维治理。StarRocks manager提供即开即用的SQL Editor，SQL Proflie和诊断分析。导入任务，物化视图、权限，元数据等数据运维功能，方便快速使用StarRocks和日常数据运维。

接下来演示如何使用StarRocks结合Flink写入数据湖的Paimon数据进行查询、分析和加速。第一步，在SQL Editor页面，通过执行SQL创建StarRocks Catalog映射DLF 2.0 Catalog，以读取数据源数据。第二步，通过StarRocks SQL直接查询数据库中的Paimon数据，实现用户留存率分析的查询。StarRocks提供极速的实时的湖仓分析能力，StarRocks是最快的实时湖仓分析引擎，其性能是presto和impala的3-5倍。

StarRocks提供便捷的慢SQL分析和诊断能力，可以大大提高日常数据运维效率。通过物化视图可以对数据进行预聚合和查询性能加速，整体的查询性能将会大大提升。EMR Serverless StarRocks重新定义实时湖仓分析。在最新版本的Serverless StarRocks里已经内置一些案例，包括TPCH， TPCDS，SSD，然后客户可以开箱即用的做这些案例。包括数据集里有1G或100G。并且后续会推出1T的测试，方便客户直接按照导引复现所有的案例。