一、StarRocks 背景介绍

1、StarRocks 定位

StarRocks 的定位两个比较关键的点，即极速和统一：

1. “极速”是指其可以做到极致的性能，大大提升 OLAP 场景下查询的效率。 从StarRocks 1.0版本开始打造的目标就是极致的速度，利用 CBO 及向量化的基础技术能力打造了一整套的极速底层计算框架。

2. “统一”起始于StarRocks 2.0，它包含两方面的内容：

   1. 首先，从业务场景来说，它融合了 OLAP 侧所有计算引擎所能覆盖的核心场景，如 OLAP 多维分析、实时分析、高并发查询、Ad-hoc 查询。从场景上来说，它使用一套技术栈架构统一 OLAP 层实现“统一”，工作运维人员只需重点维护一套架构即可，这样可以节省运维成本。

   2. 其次，StarRocks 极力推动的“统一”愿景，涵盖了对 OLAP 功能的深度融合与对数据湖生态的广泛适配。在当前数据湖盛行的趋势下，特别是如 EMR 这类数据湖系列产品，StarRocks 展现了其独特价值。它不仅顺应了数据湖开放、灵活的特点，还通过其高性能引擎，直接赋能于湖上数据的即时分析与高效查询，无需数据迁移或额外加工，极大简化了数据分析流程。更进一步来说，StarRocks 为数据分析提供了更加高效的利器，最初大家更多会使用 Impala 或 Trino、Druid、Kylin 等手段进行数据湖或数据仓库的加速分析，如今这些功能都可以在 StarRocks 上实现。StarRocks 主要的收益来自于其性能。与 Trino 相比，其性能约有3~5倍的提升。这也体现了 StarRocks 的定位，即极速。

在 StarRocks 3.x 后，其存储层可以使用 HDFS 存储或 OSS 等对象存储，也可以在批处理或流处理之后再写入 StarRocks 做上层的数据加速分析。

2、StarRocks 社区快速迭代

StarRocks 社区非常活跃，阿里云与 StarRocks 的紧密合作也已持续近三年。阿里云有很多在 StarRocks 社区活跃的人员，包括很多类似于 TSC 角色的人员也持续在社区做大量的贡献。

StarRocks 1.0版本实现了极速的特性，实现了对传统 OLAP 的高性能查询；StarRocks 2.0开始更多地兼容各类场景和生态，如数据湖分析场景；并开始大力融合更多的格式，如 json、Map/struct 等格式。此外，在融合更多场景之后出现了资源隔离 resource group 软隔离的能力，以初步解决多场景的资源隔离问题。

在2023年，StarRocks 正式发布了3.x版本，该版本实现了核心的存算分离架构，这一技术进步为 StarRocks 的应用场景扩展奠定了坚实基础。通过这一优化，StarRocks 得以在保持高性能的同时，灵活适应更多样化的工作负载，如数据预处理场景、数据湖分析、数据仓库建模，湖仓建模等场景，也就是 StarRocks 湖仓新范式的概念。StarRocks 3.x 版本所倡导的“湖仓融合”模式，是一种面向现代数据管理需求的策略升级。它在不牺牲性能的前提下，实现了存储与计算资源的解耦与灵活配置，为用户提供了既具备数据湖的灵活性，又兼具数据仓库分析效能的综合解决方案，是数据分析架构演进中的一个重要里程碑。

3、StarRocks 应用场景

StarRocks 广泛适用于六大类场景：
第一，日常工作中的报表分析，服务于客户、运营团队、管理层等多角色，尤其擅长满足高实时性报表分析需求。
第二，支持数据的实时写入与查询，适用于大屏展示及动态监控系统。
第三，构建用户画像，助力精准营销，通过标签筛选细分市场，深化渠道分析。
第四，订单分析、销售预测、订单追踪等实时写、实时查的业务场景，或是销售相关的业务场景，以及常见的 Ad-hoc 查询、自助报表平台，比如结合 StarRocks 的极致性能使用阿里云的 Quick BI 或 DataV 制作报表。
第五，建立指标管理平台也可以通过 StarRocks 做底层的数据加速查询。
第六，StarRocks 3.x后发展出了数据仓库等 ETL 场景。如垂直业务，若业务量较大，则某个小的垂直业务会使用 StarRocks 做数据仓库，这种新业务的突出特点就是其业务变化较为频繁，需要 StarRocks 极速的响应，同时也有效避免了传统数仓建立完整的标准分层的过程，可以快速进行数据的加工和处理，响应业务的实时变化。
此外，从业务场景看，还有数据湖上的分析。严格来说，以上提到的六类场景中除数据仓库之外，都与数据湖分析相关。以往可能会使用 Trino 进行分析，在 StarRocks 3.x后，就可以使用 StarRocks 进行数据湖的查询和分析，整体性能提升有3-5倍。

二、StarRocks3.x特性介绍

1、存算分离

（1）架构升级

在早期的2.x及1.x版本架构（见上图左侧）中，系统由前端节点（FE）和后端节点（BE）组成。BE 节点承担双重职责：一方面执行数据计算任务，另一方面管理本地数据存储，确保数据高可用性通过维持每份数据的三个副本。
自StarRocks 3.0起，架构显著升级，实现 BE 节点的功能拆分。数据存储层被外置到 OSS 或 HDFS 等系统上，阿里云用户倾向于选择效益高、存储成本低廉的 OSS 服务。这一调整使计算节点（CN）专注于数据处理任务，转变为无状态设计，增强了系统的灵活性与可扩展性，并能有效利用缓存数据加速查询响应，这对于 StarRocks 擅长的高实时性 OLAP 场景尤为重要，确保了 cache 数据的必要性和高效利用。同时，FE 节点保持与前代版本的兼容性。后续内容将进一步探讨存算分离后，Warehouse 层面能力的增强与优化。
（2）收益体现

存算分离前，存储成本占总开支（计算+存储）的30%-40%，尤其在大数据量下更为显著。而StarRocks 3.0后，通过将三副本减至单副本并采用 OSS 存储，存储成本节省可达70%-80%。尽管增加 cache 盘带来一定开销，但相比原先的多副本存储费用，增加的成本微乎其微。简言之，改用 OSS 单副本存储配合局部 cache，大幅削减了存储成本。
在计算成本控制方面，StarRocks 集成 Warehouse 管理和弹性分析功能，尤其当采用 EMR Serverless StarRocks 时，能充分利用其新推出的弹性能力。该能力根据时间或负载调整计算节点数量，在高峰期增加节点以应对高并发需求，低谷期则减少节点以节约资源，有效实现成本优化，达到按需计费的高效经济运行模式。
就可靠性而言，StarRocks 依托 OSS 服务的高可用架构，确保数据安全无忧。计算层面，无状态的 CN 节点设计支持弹性扩展，实现资源的随需启用，进一步增强了系统的稳定性和效率。
资源隔离是 StarRocks 的一大改进点，尤其是在存算分离后，CN 节点能够实施更精细的管理。CN 节点通过分组形成独立的资源单元，每个组专属于特定的 Warehouse，避免了资源争抢现象，如同上图展示。这意味着导入作业、Ad-hoc 查询和固定报表等任务可被分配给不同的 Warehouse，实现物理上的隔离，每个 Warehouse 既能独立运作又能弹性伸缩，针对如 Ad-hoc 查询在流量波动大的情况下自动调整资源，减少不必要的计算开销。这一设计针对 StarRocks 追求的极速与统一性，有效解决了资源竞争的潜在痛点，确保数据导入、查询操作以及其他业务间互不干扰，通过多 Warehouse 机制在存算分离框架下，达成了高效且有序的资源调度与利用，进一步巩固了其在高性能数据分析领域的优势地位。
在性能考量上，存算分离场景下未命中缓存时，性能比存算一体略逊，比例约为1:3。但若能有效利用本地缓存，即使需保留一份数据副本导致轻微的存储成本上升，总体费用仍远低于存算一体方案。更重要的是，当查询完全命中本地缓存时，其性能可媲美存算一体架构。因此，存算分离不仅在保证性能不减的前提下降低了成本，还强化了资源隔离和弹性伸缩能力，进一步优化了整体系统效能与成本效益。
存算分离带来的关键益处在于显著降低了存储成本，这为 StarRocks 处理更庞大的数据集打开了新的可能。随着StarRocks 3.x及以后版本的“湖仓新范式”确立，其应用范畴超越了传统的OLAP领域，延伸至更多样化的计算与分析场景，展现出更强的灵活性与扩展性。

2、Multi-Warehouse

Multi-Warehouse 设计确保了硬件资源的物理隔离，涵盖 CPU、内存、网络及磁盘I/O等关键领域，为不同工作负载提供专属资源池。结合资源弹性伸缩能力，有效管控计算成本。该能力目前仍未上线，EMR Serverless StarRocks 正式版本计划于2024年6月发布。

3、极速统一的湖仓分析

在StarRocks 2.5中已经有了湖仓分析的能力，如读 Hive 表、HDFS 表，或湖格式相关的一些表（如 Iceberg、Paimon）等读取相关的能力。在 StarRocks 3.x之后重点对 Hive Catalog 进行了统一，即在湖仓使用体验、场景支持等方面进行了增强。

首先，通过统一的 Catalog，同时管理和分析外表的数据。以往我们需要对 Hive 和 Paimon 分别建立一个 Catalog，而在3.x后，用户可以通过1个 Catalog 把 Hive、Paimon，以及湖格式相关的表进行统一管理，很大程度上降低了用户对外表 Catalog 的维护难度，利于用户随时进行湖分析。
其次，StarRocks 3.x开始支持湖上的写入能力。它支持将 StarRocks 加工、计算后的数据重新写回到湖上。
此外，3.x的版本之后提供了一套新的 RBAC 权限机制。相较于3.x版本，2.5版本提供的较为简单，且很多流程较为困难。而3.x版本的权限体系的建立较为标准化，同时适用于外表和内表，实现了权限和安全部分内外表的统一，更加便捷。外表无需再通过 ranger 等方式管理，当然3.x也提供了 ranger 相关的能力，对外表和内表进行管理，虽然应用相对较少，但其已具备了这项能力。

4、极致数据湖分析性能

3.x后在 Catalog 的使用、管理、拓展新场景等方面均提供了更好的能力，在性能上也有进一步提升。我们经常需要建立数据湖，如查询 HDFS、OSS 上的一些数据，该场景下 StarRocks 的性能比 Trino 快3-5倍。其核心的关键技术是 StarRocks 的全面向量化（底层所有算子的向量化），包括CBO、延迟物化等技术点，这保证数据湖分析场景下的极致性能查询。
StarRocks 最擅长的，也是阿里云与社区在早期的版本中共建的特性，即 EMR 数据湖产品上做数据湖分析。因此，StarRocks 在数据湖分析的性能上有巨大的提高。同时，要达到同样的性能，StarRocks 数据湖分析场景使用的资源相对于 Trino 或 Presto 也要更少，可以节省1/3左右的资源。因此，越来越多的客户开始把 Impala、Trino、Presto 等传统的数据湖分析场景的计算引擎切换为 StarRocks，实现性能和成本的双赢。
另外，上图中的 Block cache 也值得注意。 在使用数据湖分析时，如认为性能提升3-5倍远还不够。要获得更极致的性能，还可以使用其 Block cache。在 Block cache 开启的情况下，数据湖的查询约有额外3倍的提升。这样，其性能基本可与 StarRocks 的内表持平。

5、Trino兼容，无缝切换

前面提到了 Trino 迁移的场景。原来用户做数据湖分析，大多使用 Trino 或 Presto 等引擎。 StarRocks 在3.x版本后推出的一个特性是 Trino gateway 或理解为 Trino SQL 的转译，可以通过 hint 的语句 set sql_dialect = “trino”，启用该语句后，就会自动按照 Trino 的语法进行解析，其兼容度约在90%以上（除一些特定函数不兼容）。常用函数及SQL语法层面兼容，只要启用即可将原来 Trino 相关的业务平滑迁移到 StarRocks 3.x。

6、数据建模 透明查询加速

数仓建模与湖仓新范式强相关，StarRocks 有现代化物化视图的管理能力。物化视图其实是从2.5版本就开始发展了，但在3.x之后稳定性、性能、能力等方面有很大提升，如透明加速能力。
透明加速是指用提前建立物化视图，原业务在 select a 转移 b 两个表时，只要提前预置了物化视图，其很大程度上会提升客户 select a 转移 b 场景的性能。而业务使用方则无感知，该透明加速能力在数据湖分析及传统的 OLAP 场景提速的条件下都可以考虑使用，其物化视图能力提升其查询性能。该功能与原来的分析场景结合也较为紧密。
从3.x之后，StarRocks 社区在强调湖仓新范式。按照传统数仓，会分为 ADS、DWS、DWD、ODS 四层，但在3.x的湖仓新范式概念中，不建议进行太细的分层。因为，在大量的数据场景下，可以使用 StarRocks 直接查底层 ODS、DWD 相关的表，也可以满足日常机器查询 Ad-hoc 场景的分析，或对报表查询性能要求较低的场景下，可以直接分析原始的数据，无需提前把部分内容做加工预处理，可根据实际业务情况进行相应的取舍。
在3.x后，可以使用 StarRocks 的物化视图管理机制，通过物化视图相关的能力，如设置定时刷新能力，这样免去了原本复杂的 ETL、调度等相关管理的能力，可以通过物化视图实现类似原来 ETL、调度的能力。当然，不建议像传统数仓，分很多层，建很多任务，定时调度非常复杂的场景。但如果是做简单的加工，分少量的层的场景，则可以考虑使用物化视图加刷新的能力简化复杂的 ETL 功能。同时，3.x也支持从湖上直接加载数据到内表的场景，即可以基于外表建立 catalog 的物化视图，通过物化视图把外表变成内表，进行提速，包括像建仓分层场景等。假设湖是 ODS，则要把 ODS 上的数据通过物化视图把外表的数据写入到内表，放到 DWD，然后再做一些建仓分层，简单的可以分两层。在以上提到的数仓数据建模的场景使用的特性就是物化视图。

三、基于 StarRocks 构建湖仓新范式

StarRocks 讲述的湖仓新范式，是指它既能连接湖，也能连接仓，即通过 StarRocks 进行湖和仓的融合。假设有很大的湖或仓，垂直业务即可使用 StarRocks 快速打通这两套业务。或对于小的业务，如业务数仓的体量在100TB以下，甚至可以完全考虑用 StarRocks 构建一整套新的湖仓体系。

1、统一开放的 Lakehouse 架构

它与开源的Lake house架构相似，如下图所示：

计算节点（CN 节点）类似开源的 Spark 和 Flink，负责整体的数据计算。
FE 节点负责元数据，和计划相关，FE 节点类比于阿里云的 DLF、AWS 的 Glue 或开源的 HMS。
对于 StarRocks 自身，StarRocks 内表有一套自己的 Table format 和 File format，这套 Format 现在仍属于内表，仍未开放，这两项基本也可以与开源社区类比。
存储层，用户可以使用 OSS 或者 HDFS 等存储构建整个湖的存储介质。
StarRocks 3.x推出了湖仓 Lakehouse，其技术架构与开源的 Lakehouse 架构完全对齐。该过程实现了各服务之间的完全解耦，使得每层的资源配置可以更加灵活，按需使用。

2、湖仓新范式的概念

第一，我们可以将数据实时写入 StarRocks（包括更新），直接使用物化视图进行预处理后，提供给业务系统直接查询使用。
第二，我们可以将数据实时写到湖上（使用湖格式），通过 StarRocks 可以直接通过物化视图对湖上数据进行加工写入 StarRocks，也可以通过 StarRocks 进行数据加工后写回湖上(这个是新特性，还在不断迭代)。
第三，离线场景下，也可以通过 Spark 或其他的数据集成工具（Dataworks）把数据从湖上写入 StarRocks。
这些链路目前都是可以打通的。因此，基本上可使用 StarRocks 作为 Lakehouse 的核心计算引擎，帮助用户快速进行数据的分析和处理。
物化视图机制极大简化了湖仓建模流程，省却了繁琐的 ETL 步骤，直接促进数据湖的即时分析与高效查询。StarRocks 凭借其强大的加速能力，无论是在数据湖环境还是传统数据仓库场景下，均能显著提升数据处理与分析的速度。StarRocks 湖仓新范式的能力，无缝融合数据湖与数据仓库的能力，实现湖上数据的直接读取并在 StarRocks 内部构建高效数据仓库，为用户提供了一站式、高性能的湖仓融合解决方案。

3、极致的湖仓分析性能

无论分析湖或是分析仓（用户可能使用开源或 Spark 构建仓，写到 HDFS，可能将湖存到OSS），如果要对这些湖和仓上的数据进行分析，以往用户可能会使用 Trino/Impala 等开源的引擎，在3.x之后，我们期望也确实有很多客户把这部分业务迁移到 StarRocks，因为其收益很明显。如上图所示。假设原本使用 Presto 查询，性能为1倍；使用外表查，性能可提升3倍；如果再加一层 local cache，性能可提升6倍；若期望更极速的性能，则可以把外表的数据直接写到 StarRocks 内表，性能可提升10倍。该性能的提升是平均值，特定场景的提升会优于这个值。这就是 StarRocks 目前最擅长、也是性能提升非常明显的一个业务场景，即极致的湖仓分析的性能。
若与 Presto/Trino 等相比，两者有明显的一些能力差异。

因此，要进行湖上的分析，用户就会把业务从 Presto、Trino 迁移到 StarRocks。因为，无论从能力或性能，以及成本收益上来说，StarRocks 都要远优于 Presto、Trino。

4、湖仓分析架构

分析湖仓新范式的整套架构可以看到，在湖仓分析架构中有两种用法。

第一种如下图左侧所示：使用 StarRocks 做数据湖的查询加速，首先使用外表将数据写到湖上，然后直接使用 StarRocks 做报表或分析。这个过程相当于使用 StarRocks 进行了提速，相较于使用 Spark 查询，性能可提升5倍左右。因此，数据湖的查询加速采用直接查询。
第二种如上图右侧所示。该种方式采用间接查，即先将数据写到湖上，然后使用物化视图加工，写入 StarRocks 内表，再去查询。这种查询方式性能约提升10倍。换言之，该过程是通过数据湖、StarRocks 构建写入内表，内表再做数据入仓的分层建模。
若使用 EMR Serverless StarRocks 后面提供的弹性能力,也会帮助用户实现计算资源的零负载、零成本。这样，在日常使用过程中，就可以根据实际的使用，制定弹性计算相关的规则实时弹出相应的计算资源。同时，也会提供全方位的负载诊断和 SQL 层面诊断的能力。
Cache 管理能力，后续的内容中将会对该部分知识进行讲解，即 StarRocks 在缓存方面做了相应的优化，以帮助用户做外表查询以及存算分离之后的查询。Cache 管理的优劣直接影响最终的查询性能，因此，Cache 管理在湖仓分析的场景下也非常重要。

5、数据仓库批处理场景架构

使用 StarRocks 建仓的场景主要包括两种。

一种是左侧 All in StarRocks，是指从数据写入的源头开始就写到 StarRocks 内表，写完后再通过物化视图做上层的分层调度。另一种用法是 All in DataLake，如上图右侧所示。该链路目前仍不够完整，但这可能是后续发展过程中较为常见的场景。该方法首先将数据写到湖上，然后通过 StarRocks 物化视图或外部 insert、all right 加上调度工具进行加工，再用 StarRocks 处理，处理完成后再写回湖上，如 Paimon、Iceberg 等。目前，社区已经支持写回 Iceberg，Paimon 和其他的湖格式在后续的版本中会相继被支持。
StarRocks 在3.x后进行了与 Spill 相关的算子落盘，保证了整个 ETL 的稳定性。
All in StarRocks 可以结合 Flink VVP 产品，实现 CTAS/CDAS 场景，实现 MySQL 的整库同步，也可以使用 Dataworks 的实时数据集成实时写入的场景，使用会更顺滑。

四、EMR Serverless StarRocks 产品介绍

1、适用场景及其与开源的差异

EMR Serverless StarRocks 发展至今已有近三年的时间，逐渐从半托管发展至如今的全托管，它实现了几大重要特性。在开源版本中，包括 OLAP 多维分析、即席分析、数据湖分析，这些分析场景在 StarRocks 上都可以实现高并发的点查，以及实时写、实时查，或构建实时数仓，以及构建简单的小型数仓，并结合湖构建湖上的数仓。

全托管产品从“极速”的角度进行了些优化，如针对主键的表或点查的 QPS，以及部分性能的提升，这主要是在存算分离的场景下。同时，在资源拉起和配置默认的情况下，较于开源版本 Doris，StarRocks 的性能要优于它2~3倍，这也是 EMR 选择 StarRocks 作为全托管 OLAP 引擎的原因。
从“统一”的角度，StarRocks 也进行了优化。这一部分，更多地倾向于湖格式相关的内容，如与 Paimon 的集成，该集成使得湖格式的性能及能力更优。同时，还包括查询改写、物化视图，查询改写可以帮助用户在数据分析时提升查询性能，降低运维难度。
此外，阿里云在平台层面做了易用性和云原生的集成，如与 DataWorks 的深度集成，可以使用 DataWorks 实时地将数据写到 StarRocks，可以离线批量写，也可以整库同步数据到 StarRocks，实现数据的入仓或入湖。利用 StarRocks 的小型建仓场景，也可以通过 DataWorks 的调度实现。这样的集成可直接供给用户使用，无需自行搭建。EMR StarRocks 平台还提供了导入可视化、元数据可视化、权限可视化、数据审计、即开即用的能力，降低用户的运维和使用成本。同时还会提供一些健康诊断分析的内容，如集群健康报告，帮助用户更好地管理和使用集群。此外，还有一些 SQL 的归因分析等能力。
在云原生方面，其云上资源即开即用、分钟级交付以及扩缩容的性能均有极致的保障，还包括 Multi-Warehouse 和弹性伸缩（后续上线），Cache manage 提供可观测性能力，后续会提供 Cache 可管理的能力，帮助用户在存算分离和数据湖分析的场景下更好地管理 Cache 相关的内容。
全托管还有一个突出特点，即免运维和 SLA 保障，该技术由阿里云全方位托管。

2、产品架构

如上图，EMR StarRocks 最底层，可以使用 OSS 存储或云盘存储，无论何种存储方式，可以使用开源的湖格式，也可以使用 StarRocks 内表，最终都可以使用 StarRocks 进行相应的分析，再结合 Warehouse 进行资源隔离，以及资源的弹性。StarRocks 还提供了一些产品能力，如即开即用的 SQL Editor、导入任务、权限管理、诊断审计，以及实例的基本管理、配置管理、监控告警，还包括 StarRocks 面临最大的问题—自动升级。它可以实现自动升级，这项能力也可以实现全自动升级，只需点击按钮即可实现无感知的升级。

3、创建实例-3个版本说明

在实际使用 Serverless StarRocks 过程中可能还会面临一定的问题，即其有三个版本。这三个版本包括存算一体，存算分离和数据湖分析，它们适用的场景不同。

如果是查询性能要求较高的 OLAP 场景，比如 OLAP 场景是 toC 情况，它会要求毫秒级别的响应，则使用存算一体版本。但该版本也会存在限制，即无法实现弹性，无法进行 Warehouse 资源隔离。其优点在于其性能的极致。
存算分离版本目前仍处于 beta 阶段，但其能力基本不存在问题。它采用了 StarRocks 3.x架构。若要搭建简单的小型数仓，或做内部的报表（要求是秒级以上的响应），即可使用存算分离的版本。它可以提供弹性、Warehouse，以及 cache 管理的以及近远端 IO、cache 的分析报告。
数据湖分析可以平替 Trino/Presto 场景，只能使用外表相关能力，但其在管控平台层面的能力基本上与存算分离保持一致，也可以进行弹性和 Multi-Warehouse。
因此，关于版本的问题，需要用户结合自身业务场景，在创建 StarRocks 集群时自行选择适用于自身业务场景的版本。

4、实例管理

关于实例的基本管理，控制台部分可以直接看到。

它包括实例的扩缩容配置、云盘的扩缩容配置，以及黑、白名单，公网的开通，自动升级等能力，还有可视化的配置管理、监控告警（相关的图表告警模板）、审计（控制台的操作审计、数据审计，这些审计可以在一键开启审计日志后，在 StarRocks 的审计日志表中查询）。

5、健康报告

SQL 相关的健康报告，可以排查慢 SQL 或占资源较多的 SQL。

热表和导入任务分析会分析相关的使用较频繁或小文件较多的表，或是导入任务占用资源较大，或是不符合预期的导入任务的数据，这些都可以在该健康报告中看到相应的统计分析报告，帮助用户进行实例治理或数据治理。

6、即开即用的 SQL Editor 工具

在 Manager 中可以看到，在创建实例后连接实例时即可在 Manager 中看到 SQL Editor，可以方便用户编写 SQL、做 Ad-hoc 查询或开发调试。SQL Editor 可以解决日常的这些运维场景。

7、可视化导入任务

导入任务的可视化，即所有相关的导入任务，无论是 Broker Load，或是 Routine Load，或是 Steam Load，这些导入任务的所有信息都可以在 manager 的导入任务中查询，以及报错信息。

8、可视化元数据管理

Manager 中还可以看到元数据的信息，包括缓存的分布情况、存储分区分桶。

9、SQL 诊断分析与归因

会给出 SQL 的 profile，可以可视化地查询慢 SQL，以及慢的原因和慢的处理方式。

10、安全及权限便捷管理

提供了权限管理的可视化管理能力，也可以使用开源的命令行维护。

直播回放链接：https://developer.aliyun.com/live/253996