01公司 OLAP 分析现状

1. 使用广泛

OLAP（在线分析处理）已成为当今互联网领域，包括快手在内的众多企业，提取数据价值以辅助公司决策的关键工具。在快手内部，OLAP 的应用极为广泛，它横跨了从离线到在线的各类业务场景，以及公司各个业务线条。实际上，这一技术几乎覆盖了快手所有的业务范畴，每日处理的查询量高达数十亿次，为企业的战略决策提供了强有力的数据支撑。

2. 分析加工流程

当前，在整个公司内部乃至整个互联网行业，普遍遵循着一种数据处理与分析的流程。以快手为例，其主要采用的是 OLAP 分析引擎——ClickHouse。整个数据分析与处理的链路如下：首先，我们处理的数据源包括结构化数据、半结构化数据以及非结构化数据，这些数据通过数据同步进入数据湖，基本上位于 ODS（Operational Data Store，操作数据存储）层。接着，利用 Hive 或 Hudi 等工具进行 ETL（Extract, Transform, Load，即数据抽取、转换和加载）处理，数据会依次流经 DWD（Data Warehouse Detail，明细数据层）、DWS（Data Warehouse Summary，汇总数据层）到达 ADS （Application Data Store，应用数据存储）层。然而，由于数据湖中的 Hive 和 Hudi 在性能上基本无法满足技术需求，特别是针对 BI 分析，因此数据还需要同步到以 ClickHouse 或 Doris 为代表的数据仓库中。其他公司也可能使用 Doris 或类似的数据仓库。最后，在这些数据仓库的基础上，构建分析看板、BI 报表查询等数据分析应用。这大致构成了一个标准的数据生产与分析流程。

3. 现有分析加工流程面临的问题

尽管现有加工流程相对稳定且成熟，但在实践过程中我们也发现了不少问题。主要问题之一是数据入仓代价较大。由于直接在数据湖中分析性能较慢，因此大部分数据需要导入到如 ClickHouse、Doris 等分析引擎中以提高性能。然而，这导致了数据存储的冗余，增加了成本浪费。同时，数据在湖中生产完之后，需要另起一个同步任务进行同步，使得数据就绪时间延后。此外数据同步需要消耗分析引擎的资源，影响查询的稳定性。为了提高查询性能，数据公司需要投入大量精力来设计 ADS 模型和进行数据导入，使得整个加工链路变得复杂。

另一个问题是数据治理成本较高。报表和看板下线后，大部分数据工程师并不清楚这些数据是否仍在使用，因此原来的导入任务需要继续运行。这导致了资源的浪费，并且在需要人工治理时还需要进行额外的沟通和协调工作。此外，优化查询性能的门槛也较高，需要对索引、二级索引、物化视图以及 bucket 字段等进行针对性地选择和设计。这部分工作需要在生产阶段就确定下来，但由于其主要在查询时起作用，因此需要数据工程师去了解实际的查询细节，这增加了数据生产的复杂性和门槛。

4. 打造基于 Doris 湖仓一体分析系统

当前，我们面临着一些挑战，作为分析引擎的研发团队，我们必须要解决这些问题。鉴于业界湖仓一体和数据编织理念的流行，我们借鉴这些先进理念，对整个分析系统进行了重构，打造了基于 Doris 的湖仓一体分析系统。在重构过程中，我们特别注重分析性能的提升，确保新系统的性能能够媲美甚至超越原有的数据仓库，因为业务的性能损失是不可接受的。同时，我们也致力于提高数据交付能力和数据治理能力，以满足业务对数据高效、准确处理的需求。这是我们的主要目标。

02湖仓一体分析系统架构

1. 结合湖仓各自优点-打造湖仓一体分析系统

为了达成这个目标，我们重构了一个湖仓一体的分析系统架构。湖仓一体，顾名思义，就是将数据湖的优势与数据仓库的优势相结合，共同构建成一个系统。这个系统的独特之处在于，数据引擎能够直接分析湖中的数据，同时性能达到甚至超越原有数据仓库的水平。这就是我们打造湖仓一体架构的目标，旨在实现数据处理与分析的高效与卓越。

2. Doris 在提高数据湖查询性能做了哪些工作

有了目标之后，接下来最重要的就是选择一个合适的执行引擎，这需要考虑业界的发展趋势以及公司在技术实现上的需求。虽然我们之前主要做 CK（ClickHouse），对它比较了解，但最终还是选择了 Doris。这是因为 Doris 在数据湖方面已经做了大量工作，为提升性能付出了很多努力，这可以减轻我们的工作量。具体来说，Doris 已经完成了元数据缓存、Parquet native reader、文件本地缓存等优化工作。此外，它还进行了 CBO（Cost-Based Optimization）优化、外表的异步物化，以及通过一致性哈希算法分发任务来提高缓存命中率。这些都是 Doris 为了优化查询数据湖中数据所做的努力。

3. 结合实际情况在 Doris 现有功能上做的调整

尽管 Doris 已经进行了一些优化，但在考虑我们的实际工作场景时，还是做出了一些调整。首先，关于元数据缓存，我们决定将其存储在外部系统中，以确保FE 尽可能保持无状态，并使缓存数据能够实现全局共享。这样做还方便进行缓存管理，包括控制缓存的生命周期，从而降低因不可控的淘汰策略导致的查询性能风险。

为了实现这一点，我们将元数据存储在一个外部缓存系统中，并引入了业界流行的分布式缓存文件系统 Alluxio 做数据缓存。Alluxio 提高了缓存的稳定性，因为它具有高可用性，即使一台机器宕机，也不会导致性能损失。我们在 Alluxio 中存储了两份副本以保证高可用性，并且它能够将数据缓存到 BE 节点的本地，从而进一步加快查询性能。

此外，我们还对外表统计信息进行了处理，将其存储在一个外部系统中，并使用 Spark来收集这些信息。这样，统计信息也可以实现全局共享。在生产过程中，我们指定了一些排序索引，并利用 Parquet 文件中数据的有序性，通过谓词下推来尽可能过滤掉无用的 rowgroup。为了提高过滤效率，我们还调整了 rowgroup 的大小，使其比标准稍小一些。

最后，我们还引入了 bucket 表，因为 Doris 本身支持生成 Colocation Aggregate 和 Colocation Join，这样可以避免 shuffle 操作，从而提升查询性能。我们也把这一特性引入到了我们的系统中。

4. 新的问题

经过改造，入湖入仓的难题得以解决，Doris 现在能直接查询湖中的数据，性能接近原数据仓库水平。然而，为提升性能所做的调整，如排序字段、bucket 字段及 rowgroup 大小的优化，对查询性能影响显著，但这些需在生产前确定。这些优化对查询至关重要，但生产数据工程师可能未意识到其重要性，导致了设计上的盲点，增加了他们与上下游团队沟通的工作量。

此外，引入数据源和数据缓存后，如何确保缓存与底表数据的一致性成为新挑战。这需要持续的保障措施，因为数据不一致可能引发严重的数据故障。因此，我们需加强这一方面的管理，确保数据的一致性和准确性。

5. 生产与消费角色的分离

尽管已有一些进展，但加工链路复杂性和数据治理成本高的问题依然未解。深入分析后发现，这些问题的根源在于 ADS 层模型的生产与消费角色分离。具体而言，模型的设计和生产主要由数据工程师负责，他们根据业务需求来构建模型；而模型的消费则涉及运营、产品、数据分析及业务研发等多个团队，这些团队紧密关联业务场景。

这种分离导致了一个关键问题：当业务需求或场景发生变动，可能导致某些 ADS 模型不再需要或需要调整，但这些信息往往不能及时反馈给数据工程师。因此，关于模型是否需要下线或进行治理的决策，仍需由我们主动发起，并经过数据工程师与业务团队之间的沟通协商，这一过程耗时费力，增加了额外的人力成本。

6. 消费驱动生产

为解决上述问题，我们在湖仓一体分析系统中引入了自动物化功能，这一创新旨在实现消费驱动生产，即根据消费需求灵活调整生产模式。自动物化功能完全屏蔽了数据工程师的参与，交由引擎自主管理，确保 ADS 模型的自动化生成与优化。

我们通过两种方法推断出合适的 ADS 模型：一是基于历史查询数据，分析查询模式以定制模型；二是利用专家的先验知识，设定规则辅助模型生成。这种全局视角的优势在于能够综合所有查询行为，设计出更加合理高效的 ADS 模型，包括排序字段、bucket 字段及聚合维度指标的优化。

数据工程师仅需交付 DWS 层（明细层）模型，其余 ADS 模型及看板报表则由系统自动根据查询需求生成。引擎会根据最优物化策略自动路由查询，实现查询加速。对于长期无查询的物化视图，系统会经过冷却期后自动下线并释放资源。

此外，引擎能够实时监控物化生产过程，从任务启动到结束，所有元数据变更都会同步到我们的缓存系统中，包括元数据缓存和统计信息的收集，确保物化信息的及时更新。

值得注意的是，并非所有查询都能直接命中物化视图。对于未能命中或数据量较大的查询，系统会将其路由至 Spark 执行，以确保大查询的稳定性和资源分配的合理性，同时保持小查询的快速响应能力。

7. 整体流程

我们的湖仓一体分析架构主要由三大核心部分组成：以 Doris 为核心的分析计算执行层，以及缓存管理和自动物化两个子系统。这一架构全面支持数据分析流程，从数据源同步到 ODS、DWD、DWS，直至报表配置与生成。

在数据工程师完成 DWS 层数据交付后，工作重点转向报表配置。此时，自动物化系统接管任务，基于报表需求生成 ADS 层数据，并存储于分布式缓存 Alluxio 中。用户查询时，Doris 优先从缓存中读取数据，以加速响应。若数据量庞大，查询将智能回退至 Spark 处理，或直接从 HDFS 读取 DWS 层数据，确保查询效率与稳定性。

整个流程对用户完全透明，无需关心查询引擎的选择与数据来源，实现了全自动化执行。这就是我们的湖仓一体分析架构，一个高效、灵活且易于管理的数据分析解决方案。

最后，以 Doris 为核心执行引擎，协同缓存管理与自动物化两大子系统，共同构建了我们高效、全面的湖仓一体分析系统。

03缓存系统

1. 引入缓存的必要性

我们先探讨一下缓存系统的必要性，特别是在性能提升方面的作用。从几个方面来看，首先是 schema 信息（表结构）和 partition 信息（分区信息），在传统的数据仓库引擎如 Doris、ClickHouse 中，这些信息存储在内存中，格式优化以加快查询速度。但在湖仓一体的环境中，这些信息通常存储在 Hive Metastore 中，可能导致性能不稳定，因为 Metastore 还需服务于生产等其他需求，访问量大时可能出现响应延迟。

再者，partition 信息的获取也可能通过复杂的 join 操作从 Metastore 中筛选，这一过程既复杂又耗时。另外，文件列表信息（split 信息）通常存储在 HDFS 上，查询时需与 HDFS 节点通信，这同样增加了负载和不确定性，影响查询时效性。

最后，存储方式方面，虽然本地文件存储（如 Doris、CK 所用）速度快但运维复杂，而湖仓一体多采用 HDFS，面临不稳定性和跨网络传输慢的问题。

综上，为解决这些问题，我们需要实施元数据缓存和数据缓存。接下来，我们将详细探讨这两部分的具体实现方式。

2. 表信息

（1）表信息缓存及同步

关于表 schema 信息的缓存逻辑，简述如下：

用户在平台上需要查询表时，首先需将这些表注册到我们的系统中。注册过程中，系统会从 Hive Metastore 同步对应的表结构信息到缓存服务（Meta Server）中，并持久化存储于后端系统。此外，缓存服务会持续监听 Hive Metastore 中的 schema 变更（如添加、删除列或表），一旦检测到变化，便同步更新至缓存中并持久化。

为了将最新的 schema 信息同步至 Doris 的 FE 组件，我们实现了一个外部表同步的 daemon 进程。该进程会周期性地从 Meta Server 中拉取最新的 schema 信息，并更新到 FE 的内存 catalog 中，从而保持数据同步。

为确保数据一致性，我们还设计了一个周期性的一致性校验机制。该机制会定期检查 Hive Metastore 与缓存服务中的数据是否一致，以应对可能的数据遗漏或不一致问题。

（2）表信息持久化格式

关于表信息的持久化及同步过程，简述如下：

表信息在 Hive Metastore 中持久化存储，并通过 DB 和 Table 的索引以及常用字段进行快速检索。针对 Hive Metastore 的变更，由于内部版本问题，我们未采用官方的 EventListener 机制，而是选择监听 MySQL 的 binlog 来实现。

在同步过程中，我们实现了一个名为 ExternalMetaSynchronizer 的组件，该组件周期性地从 Meta Server（即缓存服务）中同步增量的表结构信息，并更新到 Doris 的 FE（Frontend）组件中。FE 在接收到这些信息后，会进行类似 MetastoreEvent 的处理，以确保表结构信息的正确性和一致性。

综上所述，这就是表 schema 信息的缓存机制以及从 Meta Server 同步到 FE 的完整过程。

3. 分区信息

（1）分区信息缓存及同步

接下来讨论分区信息。分区信息是查询中重要的组成部分。当 Hive Metastore 监听到分区变更时，系统会首先从 HDFS 获取对应的 split（数据分片）信息。获取后，这些信息会被重新组织并进行数据预热，预热完成的数据会被存储在分布式缓存 Alluxio 中。

预热过程结束后，分区信息会被持久化到 Meta Server 中。在查询时，FE 组件处理 SQL 查询时，会重写原有的从 HDFS NameNode 获取 split 的逻辑，改为直接从 Meta Server 中获取已经预计算好的 split 信息。

此外，为确保数据一致性，系统还会周期性地校验缓存中的分区信息与 Hive Metastore 中的信息是否一致。

（2）分区信息持久化格式

分区信息在缓存中的格式设计主要基于 DB 和 Table 的索引，以优化查询效率。其中，有几个关键点需要特别注意：

Last Modify Time：这是从 Hive Metastore 中获取的最后修改时间，用于缓存版本控制。在缓存系统（如 Alluxio）中，每个缓存版本都对应一个数据目录，以区分不同时间点的数据状态。
Use Cache：这是一个控制字段，用于设置缓存的生命周期。用户可以根据实际需求，指定缓存数据的保留时间（如 30 天），以区分热数据和冷数据。热数据（高频查询数据）将存储在缓存中以提高访问速度，而冷数据则直接从 HDFS 读取，以节省存储成本。
PK Name & PK Value：这是分区字段名和对应的值，用于唯一标识 Hive 中的分区。这些信息在缓存中被保留，以便快速检索和定位分区数据。
HDFS Files：这是分区下对应的 split 信息，即 HDFS 中该分区的数据文件列表。这些信息在缓存中被组织和管理，以便在需要时快速访问 HDFS 上的数据。
综上所述，分区信息在缓存中的存储格式旨在通过索引优化查询性能，同时通过生命周期管理实现冷热数据的分层存储，以平衡访问速度和存储成本。

4. 数据预热在新增分区处理流程

接下来重点讨论预热流程。预热是确保查询性能的关键步骤，它确保在查询执行前，相关数据已被加载到 Alluxio 缓存中。预热完成后，Alluxio 中对应的路径以“Snapshot”开头，后跟 HDFS 的实际路径，并附加了版本信息，以保持与 Hive Metastore 中的版本同步。

此版本控制机制防止了并发问题，如 Hive 中数据被删除后，在 Alluxio 中仍尝试访问旧数据的情况。加载数据时，Alluxio 虽然指定了读取目录，但实际上是从 HDFS 的分区路径上加载正式数据，确保了数据的准确性和一致性。这一流程确保了预热的有效性和数据的可靠性。

5. 获取 split 处理流程

在查询过程中，当 SQL 语句包含分区信息（如 p_date 和 p_hour）时，FE会分析这些分区条件，并从 SQL 中提取出分区键（PK name）和对应的值。基于这些分区信息，FE 会生成一个查询 split 的过程。

在查询 split 时，FE 会利用缓存中的分区信息（包括 PK name、PK value、HDFS 文件位置、最后修改时间、是否缓存等），根据分区键和值匹配到对应的 split 信息。这些 split 信息包含了数据的位置（location）、HDFS 文件详情、以及是否已缓存等关键数据。

接下来，FE 会根据是否启用缓存（即是否走缓存）的决策逻辑来判断。如果决定使用缓存，FE 会构造出 Alluxio 中的完整路径，并从 Alluxio 中读取数据；如果决定不使用缓存，则直接从 HDFS 中读取数据。

一旦确定了数据来源（Alluxio 或 HDFS），FE 就会复用现有的查询逻辑来执行查询。这就是整个 split 处理流程，它确保了查询能够高效地利用缓存数据或直接从 HDFS 读取数据。

6. 耗时比对

关于缓冲机制，我们主要关注元数据的缓存和数据读取的缓存。在 get split 阶段，虽然增加了约几十毫秒的延迟，但这对于用户体验来说并不显著，因为整体查询时间仍然保持在亚秒级，不会从秒级恶化到分钟级。因此，业务上线后，用户几乎感受不到这一性能变化。

查询性能方面，除了 get split 阶段增加的耗时外，其余逻辑完全复用了 Doris 现有的能力。这使得整体查询性能依然能够保持在较高水平，通常在百毫秒到五六百毫秒之间。

综上所述，我们为提升性能所做的缓冲工作，包括元数据缓冲和数据读取缓冲，虽然在一定程度上增加了 get split 的耗时，但并未对整体查询性能造成显著影响。

04自动物化系统

1. 必要性

接下来讨论自动物化的必要性，它旨在减少工作量，加速数据表的交付效率。从业务需求出发，数据处理链路长且交付周期长，主要因为构建 ADS 表需要深入理解业务需求并与业务团队反复沟通，这占用了大量时间。

此外，查询的复杂性也是一个挑战，选择合适的查询引擎并优化数据组织方式（如索引、二级索引、分桶字段等）对查询性能至关重要，但这些配置在生产环境中实施起来颇具难度。

从平台角度来看，数据治理的复杂性也增加了资源浪费的风险。因此，引入自动物化机制成为解决这些问题、提高数据交付效率和查询性能的关键途径。

2. 现有模式不适合公司内部的实际情况

在实现自动物化时，我们面临了几个实际情况的考量。首先，尽管 Doris 支持将外部表（如 Hive 表或其他数据湖中的表）物化为内表，但考虑到公司内部数据量大、表数量多（可能达数万或数十万张），以及每天产生的数据量可能达到数十 TB 至数百 PB，完全依赖 Doris 进行物化处理会对其造成巨大压力，可能影响稳定性。

其次，公司内部的数据看板有严格的 SLA 要求，确保关键数据在特定时间（如上午 9 点或 10 点前）就绪。这要求物化数据的产出也需有 SLA 保障，而这通常需要借助 Doris 之外的系统来实现。

再者，我们倾向于将物化视图存储在外部系统（如 Hive 或 Hudi）中，以保持数据生产和消费的闭环在数据湖中。这样既能减少 Doris 集群的负载，又能更好地管理数据。

最后，当物化无法命中大查询时，我们计划将这些查询路由到 Spark 进行处理。这是因为大查询通常不是高频查询，且用户对其处理时间有预期。通过将这类查询交给 Spark 在后台运行，我们可以避免浪费 Doris 的宝贵资源，确保小查询和高优看板得到更好的性能保障。

3. 整体实现思路

为了实现自动物化，我们计划将 Doris 的生产管理部分剥离，并在外部系统中实现物化的发现、管理和生产。这样，我们可以复用 Doris 的查询能力，特别是物化改写的识别、改写和匹配功能。关键在于元数据的同步，我们计划通过扩展和继承 MTMV，实现一个 KwaiMTMV 系统，以确保 Doris 与外部物化系统之间的元数据能够保持同步。这一改造完成后，将形成一个完整的自动物化系统，涵盖物化的整个生命周期，从生产到最终的查询识别。

4. 物化主要两种方法

物化发现主要有两种方法，目前实现的是第一种较为简单的专家规则法。在这种方法中，数据工程师可以设定规则，指定需要物化的指标、维度以及聚合方式。用户也可以通过输入特定的 SQL 语句来指定物化内容。

另一种方法是历史查询的自动识别，它基于全局视角，通过分析历史查询来自动发现值得物化的表。这种方法旨在识别出全局最高频的查询算子进行物化，以提高物化的复用率。同时，它还能根据查询需求设置二级索引和分桶字段，以优化查询性能。这些操作对用户和数据工程师都是透明的，引擎会根据查询变化自动调整物化策略，无需人工干预。

5. 物化元数据信息持久化格式

物化元信息的持久化格式是确保物化延续性的关键，它涉及物化生产的发现与 Doris 查询改写之间的元数据交互。这种元数据主要包括两部分：物化 SQL 和基表信息。

物化 SQL 记录了物化表（ADS 层）的生成逻辑，即它是如何根据原始数据表（底表）计算得出的。这部分信息对于理解和维护物化表至关重要。

基表信息则指明了物化表所依赖的底层数据表，即物化过程中所使用的数据源。记录这些信息有助于确保物化过程的准确性和可追溯性。

通过将物化 SQL 和基表信息以适当的格式持久化存储，我们可以有效地管理物化表的元数据，实现与 Doris 查询改写的无缝对接，从而确保物化过程的延续性和稳定性。

6. 物化生产和消费

（1）物化生产关键技术实现

依托公司内部现有的生产流程，我们实现了一个服务来自动化处理物化信息的注册和生产任务的生成。该服务根据物化信息自动生成生产任务，并注册到公司的离线调度平台上，实现每日的例行生产调度。我们专注于生产逻辑的实现，并确保生产完成后任务能顺利注册并进行调度。

当依赖的底表发生变化时，系统会根据血缘关系自动生成并调度物化任务进行重新生产，这一过程也复用了现有的能力。对于高优先级任务，我们可以将其调度到高优生产队列中，并配备报警监控以确保生产过程的稳定性。

此外，为了支持大数据量的物化生产，我们利用 Spark 或 Hudi 进行离线生产，确保能够处理大规模数据。同时，我们还实现了一些 Java UDF 来处理物化过程中涉及的复杂指标计算，这些 UDF 能够将中间结果序列化后存储于 Parquet 文件中，并在读取时反序列化以完成最终的指标运算。这些技术共同构成了我们的物化生产体系。

（2）物化消费-元数据获取和查询改写

物化消费环节涉及物化视图的注册与查询使用。在 Doris 系统中，物化的元信息会被周期性地从 Meta Store 同步到 FE 的 Master 节点。由于我们实现的是外表机制（而非原生支持的内表），我们采用了 KwaiMTMV 来包装这些外表，并注册到 MTA 服务中的 MTMV 管理系统中，以实现与 Doris 原生物化系统的兼容。

当查询请求到达时，系统首先通过获取可用物化视图来判断是否可以利用物化来加速查询。如果查询涉及的是 Kwai MTMV 类型的物化视图，系统会将原始的 OLAP 扫描更改为 Logic File Scan 中的 MVscan 类型，以适应外表的扫描方式。随后，系统将该逻辑封装到查询的上下文中，并继续执行剩余的查询逻辑，最终利用 Doris 自身的物化改写流程生成执行计划。这一过程确保了物化视图能够被有效利用，同时保持了与 Doris 原有物化机制的兼容性。

（3）物化消费的实际改写效果

以上是一个物化视图的实际改写效果示例。在这个例子中（EXPLAIN OPTIMIZED PLAN SELECT p_date,COUNT(DISTINCT author_id) FROM hive.kscdm.dim_ks_photo_extend_daily WHERE p_date=‘20240618’ GROUP BY p_date），我们针对一个 Hive 表进行了去重指标的运算，即对一个 auth ID 进行去重。为了实现高效查询，我们提前构建了一个物化表，该表通过生成 bitmap 并序列化后存储于 Parquet 文件中。

从最终的执行计划可以看出，查询在扫描阶段采用了 FileScan 算子，特别针对的是这个物化表。在处理 bitmap 时，我们使用了自定义的 UDF（用户自定义函数）来从 Parquet 文件的二进制数据中反序列化 bitmap。这一步骤成功地将二进制数据转换为可操作的 bitmap 对象。

随后，系统利用 bitmap 进行了 union 和 count 操作，以完成去重指标的上卷运算。这个过程完整地展示了在去重场景下，物化视图如何通过改写查询计划来优化性能。最终，查询命中了物化视图，显著提升了查询效率。

至此，我们已经介绍了物化视图的整个流程，包括生产、发现、注册、查询改写以及实际使用效果。

7. 后续计划

未来在物化视图方面，我们还有多项待完成的任务。首先，我们计划实现基于历史 SQL 的自动化发现，以减少数据工程师的手动配置工作，提高效率和准确性。

其次，我们将致力于优化物化视图的索引配置，以减少元数据操作和 IO 延迟。虽然我们已经做了一些索引工作，但与数据仓库（如 Doris、CK）中的二级索引相比，Parquet 等格式的索引能力仍显不足。因此，我们需要进一步研究和实现配置级别的索引优化，以提升查询性能。

此外，我们还将探索更丰富的物化类型，特别是针对复杂指标的物化，以满足更多元化的需求。这些工作将是我们未来在物化视图领域持续努力的方向。

本文来自公众号：DataFunSummit