一、StarRocks 产品介绍
EMR Serverless StarRocks 产品目前主要以全托管和半托管两种形态存在。虽然我们目前并不主力推广半托管形态，但该形态仍会持续提供，以满足部分用户在云端快速构建、部署和运维的需求。半托管版本采用开源模式，并在运维方面提供一定的支持。
相较而言，我们更倾向于引导用户使用全托管形态，因为它除了具备 StarRocks 所宣传的极速统一等特性外，还提供了全托管服务，在 serverless 环境下实现了免运维。
此外，还针对内核和管控方面做了许多数据运维管理工作，例如可视化分析 MySQL 的性能数据、导入任务管理、元数据管理以及外表元数据管理等。为了方便用户进行 Adhoc 场景操作，还提供了 SQL Editor 等工具。
结合云原生技术，产品提供了便捷的集群创建、扩缩容、升降配等功能。自动升级能力也让用户在版本切换时更加轻松。此外，我们还与数据湖、DLF 等云产品进行了集成，并支持与 Flink CDC 的 CDAS 能力，以便快速将 MySQL 数据库迁移至 StarRocks。
未来，还将与 MaxCompute 等阿里特色产品进行集成，以满足数仓用户的需求。总体而言，EMR 产品增值服务主要围绕数据运维和集群运维，旨在降低使用门槛、提高效率，为用户提供更便捷的云端体验。
EMR 产品主要包括三种形态，来满足不同场景的需求。首先，on ECS 半托管形态，该形态已逐渐成为主流，受到了广泛关注。其次，on ACK 形态，即基于 Kubernetes（K8S）的容器化形态，也在逐步完善和推广。此外，我们首次在 EMR 中引入了 Serverless 形态，以 StarRocks 引擎为代表，降低了用户在使用大数据处理引擎时的运维负担。
未来，我们将继续扩展 EMR 的 Serverless 形态，计划将 Spark 等更多技术纳入其中，以满足更多用户的需求。然而，需要注意的是，这些新增功能的研究与开发周期可能会较长。总之，EMR 致力于不断优化产品形态，为用户提供更加便捷、高效的大数据处理解决方案。
半托管模式，如上图中左半部分，主要帮助用户解决集群运维部署和售后支持方面的问题。这种模式仍存在一定的局限性。为此，我们推出了全托管模式，如上图中右半部分，它在半托管基础上，进一步将计算资源层（如 FE/BE）纳入托管，提升了数据运维相关能力。
在 manager 层面，实现了查询诊断分析、元数据管理、导入任务管理、SQL Editor 等功能。此外，还实现了权限可视化控制，并关注稳定性和运维问题的解决。例如，如何快速定位导入任务、物化视图等背后任务的管理，以及在出现问题时，如何通过可视化手段帮助用户快速定位并解决问题。
目前，我们有两种版本可供选择：入门版和标准版。入门版适用于对 StarRocks 不熟悉的用户，提供了一个有限的 12 CU 配置，供用户进行试用和体验。此外，我们还针对入门版展开了一些免费推广活动，用户可以适时尝试。
全托管模式致力于解决集群运维部署和售后支持问题，提供全面的诊断分析、元数据管理、SQL Editor 等功能，以及权限可视化控制。在稳定性和运维方面，着重优化了任务管理和问题定位能力，以帮助用户快速应对日常使用中可能遇到的问题。目前，有入门版和标准版两种版本供用户选择，入门版更适合初学者，并提供了一些免费推广活动。
只要是阿里云的正常账号，且此前未开通过 EMR 和 StarRocks 相关产品，均可免费开通入门版，感兴趣的用户可以参加相关活动。目前，该版本虽免费，但资源有限。例如，每小时 5000 CU 和 48000 GB 存储空间。以 12 CU 为例，用户可连续使用约 20 天。当然，我们也注意到部分用户的诉求，他们希望开设更大规格的版本。因此，我们计划在 12 CU 基础上增加 32 CU 规格，以满足这些用户的需求。用户可根据自身需求选择合适规格的版本，既可以简单测试性能，又不必担心资源浪费。
此外，我们还提供标准版，这是目前主要售卖的版本。如果用户在生产环境中使用，建议选择标准版。
我们将继续关注用户需求，优化产品版本和规格，为大家提供更好的使用体验。
StarRocks 致力于实现 OLAP 在整个大数据领域的统一。从阿里云 EMR 客户的视角来看，越来越多的用户将 OLAP 相关业务迁移至 StarRocks。许多客户场景下，StarRocks 逐渐替代了 Presto 和 Spark。然而，这个过程可能需要一些时间，特别是在等待 StarRocks 3.1 至 3.2 版本发布并稳定下来，以及产品化能力全面跟上之后。
在规模方面，StarRocks 目前可以替代大约十几台的 Hadoop 集群。这种规模的中小企业客户更倾向于采用 StarRocks，因为它可以实现技术栈的统一，降低维护成本。用户无需深入了解 Flink、Spark、Hive 和 HDFS 等开源大数据引擎，只需掌握 StarRocks 基本的 SQL 语法和表结构设计，即可轻松上手使用。
StarRocks 始终致力于简化大数据技术栈，提供统一的平台，使得用户可以更轻松地迁移和整合业务。随着 StarRocks 版本的不断更新和优化，我们相信它将在更多企业中得到广泛应用，成为大数据领域的重要力量。
二、StarRocks 功能介绍
接下来介绍一下产品的主要功能。
全托管服务主要围绕实例概念展开，这里的一个实例相当于一个集群。全托管服务为用户提供实例的基本管理功能，包括自动升级、可视化配置以及一键告警等。通过 serverless 架构，用户可以轻松创建和管理实例，无需关注底层基础设施的运维。
除实例管理功能外，全托管服务还具备数据运维层面的能力，包括 MySQL 诊断分析等。这些功能旨在帮助用户更高效地管理和维护数据库，提升运维水平。
全托管服务还为用户提供数据开发和 Adhoc 场景的支持，涵盖简单的数据分析、SQL 编辑器等能力。尽管目前这项功能尚处于初期阶段，但已具备基本的 SQL 运行和简单 SQL 运维能力，可以满足用户在数据处理、查询和分析方面的需求。
全托管服务在满足复杂 Adhoc 场景方面，目前尚需经过两三个迭代的产品升级以及添加元数据管理能力和可视化管理功能的过程。在这个过程中，用户对于统一查看外部 Catalog 元数据的需求也得到了关注。
针对这一需求，EMR 数据湖解决方案已经提供了从 DRF 系统中查看数据湖中所有元数据相关信息的功能。未来将实现内外表元数据以及外部 Catalog 统一视图的管理，从而进一步提升用户在复杂 Adhoc 场景下的数据处理和分析效率，为业务发展提供有力支持。
权限管理主要包括用户管理和访问控制。
对于全托管和半托管服务，我们并未做特殊的差异化处理。只有在 Flink VVP 的集成方面，提供了一些特殊的支持，因为 Flink VVP 的一些特性，无法合并到社区版本中。
此外，半托管服务主要在于可视化集群管理等功能，而全托管服务还具备例如 FEBE 免运维、小版本自动升级等一些独特的能力。
Serverless 版本更注重数据运维管理能力的提升。正如之前所提及的，元数据、MySQL 数据库以及导入任务管理等方面都是我们关注的重点。针对阿里云上众多中小客户在数据导入方面的痛点，我们计划在后续版本中优化数据导入速度，提升用户体验。目前还是以内部导入任务的管理为主。
未来，随着存算分离的实现，我们将结合物化视图来支持小型数据仓库场景。物化视图在数据仓库中的应用越来越重，因此我们也将重视物化视图的管理功能，尽管目前其优先级相对较低。
三、StarRocks 客户场景案例
接下来要介绍的案例主要是用 StarRocks 替代原有的 OLAP 平台。在近 200 个 EMR 现有用户中，大部分都是从 Presto、Impala 等旧引擎迁移而来。他们转向 StarRocks 的主要原因是性能提升，而且资源占用较少。例如，有些客户在运行时，StarRocks 资源仅需 Presto 的一半，便能达到相近甚至更佳的性能。因此，他们在降低成本和提高性能方面都得到了实惠，纷纷选择 StarRocks。
以一个在线教育客户为例，他们曾尝试过 Presto 和 MySQL，但由于数据量较大，整体性能差距明显。经过速度和其他方面的对比，他们最终选择了 StarRocks。
该客户典型的 BI 报表分析平台包含自定义报表和多维分析场景。整个数据链路如下：从 MySQL 或服务日志等来源通过 Kafka 传输，经过 Flink 处理后写入 StarRocks，最终完成数据应用。此外，为了保证热数据缓存和后续指标平台的运行，他们还需要将离线数据同步至 StarRocks，采用按天或小时级的数据同步策略。
客户在实时数据分析场景中，采用了 Kafka、Flink、StarRocks 等工具进行数据处理。数据从 Kafka 流入，经过 Flink 处理后写入 StarRocks。在 StarRocks 端，数据按照天进行分区，按照用户 ID 进行分桶，生成数据埋点详细表。此外，还创建了一些小时级物化视图，实现了简单的 ETL 流程。这种处理方式既不算是数仓，也不算是复杂的数据分析，而是提前进行了一些预处理，以满足后续固定维度的事件分析需求。
针对明细表，StarRocks 可以支持用户跟踪等场景，提供明细查询功能。在性能方面，相较于原有方案，StarRocks 实现了约两倍的提升。
这是一家互联网金融客户，他们曾使用过多款 OLAP 组件，如 CK、Impala 和 TiDB 等。然而，这些组件繁多，难以维护。此外，在 TiDB 上的并发性能受到限制，由于集群规模和成本等因素，某些场景下无法实现更多任务。因此，他们在寻求一种能够提高查询性能并降低资源消耗的解决方案。
针对这一需求，StarRocks 为其提供了约 40% 的查询性能提升，同时资源使用降低 50%。这主要针对传统报表场景和预聚合场景。原先在 TiDB 上的预聚合操作需耗时 30 分钟，而现在在 StarRocks 上仅需 30 秒，大大降低了资源消耗。
此外，StarRocks 提供了统一的组件，使得运维人员数量减少，降低了运维难度。客户希望未来能够将 OLAP 相关场景逐步统一到 StarRocks，实现技术栈的统一。他们计划在监控、报告、报警以及用户行为分析等场景中，替代原有方案，采用 StarRocks 进行处理。
这是一个采用数据湖存储架构的在线教育客户，他们使用了 Hudi 作为数据存储方案。数据从 Kafka 流入，通过 Flink 处理后，写入 Hudi 格式存储在数据湖中，如 SSR 等。然后，利用 StarRocks 以外表形式进行 OLAP 分析，替代了原有架构中的 Presto。
这是一家大型音频公司，他们在某一块独立业务上尝试使用 StarRocks。这一场景主要针对小型数据仓库，特点是数据量较小，规模在 7、8 TB 左右。为了避免物化视图稳定性问题，他们选择了 StarRocks 作为解决方案。
此外，这家公司的业务非常垂直，上层应用变化较快。因此，他们需要一种轻量级的方案，以便快速迭代。使用传统的 Hive 和 Spark 架构对于他们来说过于沉重，而 StarRocks 提供了一种更灵活的解决方案。
在新业务选型时，他们选择了 StarRocks 作为整套方案。尽管这类客户目前不多，但随着 StarRocks 3.0 版本的发布以及物化视图和稳定性问题的解决，更多类似客户将会采用这一方案。这也将成为未来规划中的重点推广场景，预计在今年下半年或明年开始实施。
这是一家专注于用户行为分析的游戏公司，他们面临的主要挑战是提高性能和降低成本，这也是许多客户目前所关注的问题。
该游戏公司的架构与之前提到的场景类似，从 Kafka 读取元数据，通过 Flink 处理后，写入 StarRocks 进行实时查询、业务报表和大数据展示等典型场景。这种架构充分利用了 StarRocks 的性能优势，满足了游戏公司对高效数据处理和分析的需求。
这是一个小型电商客户，他们原先使用 CK、麒麟等 OLAP 引擎。由于历史原因，他们需要处理多样化的场景，如运营分析报表、指标平台 Adhoc 查询以及实时大屏展示等。
为了提高性能，该电商客户在保留原有数仓体系的基础上，将 BI 报表分析部分迁移至 StarRocks。这一变革使得他们在实时查询、大数据分析等方面取得了显著的性能提升。
四、StarRocks 产品未来规划
至此，我们已经介绍了产品和一些典型客户场景。尽管目前实际应用场景相对简单，但一个显著的趋势是，越来越多的企业将原有 OLAP 引擎迁移至 StarRocks。这一趋势表明，StarRocks 凭借其高性能和稳定性，逐渐成为企业数据处理和分析的首选解决方案。
在 EMR的规划中，StarRocks 成为 OLAP 领域的重中之重。目前，EMR 中的所有 OLAP 业务重心都集中在 StarRocks。我们在 6 月 1 日正式开始商业化运营，随着 2.5 版本的发布，支持了传统 BI 场景和数据库分析场景。目前已经发布支持 StarRocks 存算分离版本，存算分离版本 beta 测试中。
未来的工作将主要围绕存算分离场景，包括替代 Presto 等产品。此外，我们计划在今年 Q3 发布一些运维增强功能，如智能诊断和实例汇总信息，以帮助维护集群稳定性并快速定位问题。
随着 3.1 版本的发布，弹性将成为一个重要特性。我们计划在 12 月份发布全托管版本的弹性功能。此外，我们还将针对云上资源，如云盘，优化性能和存储成本。在 manager 方面，我们将继续关注导入物化视图等能力。
总体而言，StarRocks 的未来规划将围绕 Lakehouse 场景展开，包括去年已经推出的数据库分析场景，以及即将推出的小型数仓场景。我们期待在 3.1 或 3.2 版本稳定后，进一步拓展 Lakehouse 场景。
以上就是本次分享的全部内容。感谢大家的关注，我们将继续努力，为大家提供更好的产品和服务。
