在当今这个数据洪流的信息时代下，数据已跃升为企业不可或缺的核心资产。深度挖掘并提炼数据内在价值，成为支撑企业战略决策的重要依据。在此背景下，快手建立了 OLAP 系统，该系统在快手应用极为广泛，每天承载近 10 亿的查询请求，为内外多个业务场景提供数据服务。具体场景包括：
存在的问题
最初，快手 OLAP 系统整体技术架构由离线数据湖和实时数仓这两部分组成， 离线数据湖核心引擎为 Hive/Hudi，实时数仓核心引擎为 ClickHouse 。OLAP 系统数据源种类非常丰富，全面覆盖结构化、半结构化、非结构化的数据类型，这些数据同步到到数据湖进行 ODS 、 DWD、DWS、ADS 层处理，处理后的数据同步至实时数仓，由数仓对外提供 BI、报表、查询等数据服务。
虽然这套架构已在快手内部稳定运行许久，但随着需求的变化、数据的不断累积， 湖仓分离这一架构带来的问题逐渐显现 ：
此外，随着 ClickHouse 在业务中使用越来越深，查询性能出现瓶颈。排序字段、二级索引、物化视图以及哈希字段的选择和创建对 Clickhouse 查询性能有显著影响，但局限于 Clickhouse 的语言、系统适配性等因素，开发人员的学习及操作门槛都比较高，查询调优的难度比较高。
升级目标及选型
在上述问题驱使下，快手希望引入湖仓一体架构来解决上述问题，希望数仓可直接分析湖中数据，而不需要进行繁琐复杂的数据传输，避免传输及传输过程中引发的数据问题。在该目标的指引下，快手快速锁定 Apache Doris，尽管 Apache Doris 定位于实时数据仓库，但在过去版本中， Apache Doris 一直不拘于数据仓库的能力边界，在湖仓一体方向进行了诸多探索，逐步形成了湖仓一体解决方案 ：
基于 Apache Doris 的湖仓一体架构
快手基于 Apache Doris 升级为湖仓一体分析平台，新架构如图所示：
从下至上，主要分为以下几个层级：
另外，快手还开发了两个服务，使得整个分析平台更加智能化和自动化：
在数据查询层中，使用 Apache Doris 替换原先的 Clickhouse，为快手带来了如下收益 ：
接下来重点介绍整个湖仓一体架构中，缓存服务和自动物化服务方面的功能和实践经验。
缓存服务与优化
湖仓一体架构下，缓存层主要用于避免远程数据访问可能发生的网络延迟高、网络抖动、带宽不足等问题，提升数据访问的性能和稳定性。缓存的内容大致可以分为 元数据缓存 和 数据缓存 。针对这两种缓存，快手结合 Doris 的系统架构和特性做了适配和优化。
01 元数据缓存
元数据缓存的内容包括库、表、列、分区、文件等元信息。而且元数据缓存服务，除了对缓存信息的存储外，更重要的是能够及时感知元数据的变化，如 Schema 的变化、分区的增删，文件的变更等等。通过实时的变化感知，才能保证元数据的一致性和查询的时效性。
Apache Doris 内置支持了元数据的缓存能力，支持基于 Hive Metastore Event 的元数据增量同步能力，能够很方便的提供高性能、高时效性的元数据缓存服务。然而，由于快手的元数据服务需要与除 Hive Metastore 外的其他系统（如 Alluxio）进行交互，因此无法单纯依赖 Doris 内置的元数据缓存能力。为此，快手基于 Doris 的内置方案自主研发了 Meta Server，作为统一的元数据服务。
如上图所示，Meta Server 负责监听其他服务中的元数据变化，如 Hive Metastore 中的 Schema 变化，Alluxio 中的缓存变化等，并将这些信息持久化到后端的 Meta Store 中。同时，Meta Server 会将元数据定期的推送给 Doris FE 的 Catalog 中，并通过元数据校验服务来保证两边数据得一致性。
此外，针对分区信息缓存策略，快手也结合 Alluxio 的缓存能力进行了改造。
如上图所示。Meta Server 监听到分区变化后，从访问 HDFS 获取最新的文件（Split）列表，持久化存储到 Meta Store 中，并通知 Alluxio 进行缓存预热。而 Doris 在查询时，可以直接访问 Meta Store 获取文件列表。
通过 Meta Server 服务， 实现了查询引擎（Doris）、元数据服务（Hive Metastore）、数据缓存服务（Alluxio） 三方联动 ，在提供高效的元数据访问的同时，也提升了数据缓存的时效性。
02 数据缓存
数据缓存服务支持数据内容以文件形式存储在缓存系统中，以提供本地化的数据访问性能。
Doris 支持内置和外置两种数据缓存服务 。内置数据缓存不依赖第三方系统，可以提供开箱即用的缓存能力。而快手为了能够将缓存服务能够和公司内部的其他业务系统更灵活的对接，采用了基于 Alluxio 的外置数据缓存服务，其对外提供 HDFS 兼容的 API，使得 Doris 可以很方便的对接到 Alluxio 文件系统上，像访问 HDFS 一样访问 Alluxio 中的文件。
同时，为了减少数据访问的延迟，快手在上述基础上重点开发了缓存预热功能。缓存预热是非常重要的步骤，预热后的数据存储在 Alluxio 中，提高了查询响应速度。
上一节已经介绍了缓存的元信息如何存储到 Meta Store 中。Doris 会根据查询语句中的分区条件，从 Meta Store 中获取文件列表，并通过 is_cached 字段判断数据是否已经被缓存，并自动选择从 Alluxio 或者 HDFS 中读取。
03 优化效果
通过元数据缓存，与直接从 Hive Metastore 和 HDFS 中获取相比， 平均耗时由 800 毫秒降低至约 50 毫秒 ，并且查询耗时并未出现较大波动。
自动物化系统
物化视图是数据仓库系统中的一项重要能力，不仅能够提供数据的分层加工功能，还可通过透明改写实现智能查询加速。快手在内部一直使用物化视图，但初期面临数据加工链路复杂和治理成本高等问题。经过深入分析，发现根本原因在于 ADS 模型的生产和消费由不同角色负责：
因此在数据的分层加工上，快手自研了 自动物化服务，实现消费驱动生产 ，主要流程如下：
物化视图包括构建、刷新和改写流程，Doris 本身支持相对完善的物化视图功能。但快手选择在外部系统（自研自动物化服务）中实现构建和刷新操作，由 Doris 支持透明改写能力，而非全部采用 Doris 能力，主要原因如下：
基于以上考虑， 快手结合 Doris 的物化视图透明改写能力和自研的物化服务，实现了 KwaiMTMV 自动物化系统 。该方案的优势如下：
接下来分别从 物化发现、物化生产和物化消费 这三个方面，系统的介绍 Apache Doris 和物化视图的结合使用。
01 物化发现
物化发现旨在利用不同方式，为用户推荐合理的物化视图。这里采用了如下两种方式：
通过人工和系统自动分析两种方式，可以得到合理的物化视图定义。同时也会将这些物化视图定义存储在 Meta Server 中，并和对应的基础表做关联，以便后续的物化生产和消费。
02 物化生产
基于物化发现得到的物化视图定义，将提交至作业调度平台进行构建。调度平台会根据基表数据的变化和血缘关系，自动调度物化生产任务。同时，它还会自动调整物化生产作业的优先级，确保高优先级任务按时完成。
此外，调度平台中实现了一批 Java UDF，能够将某些指标的聚合中间结果序列化为二进制格式并写入数据文件（如 Parquet/ORC）。Doris 还可以复用这些 UDF，在查询时对二进制数据进行反序列化，从而完成对指标列的上卷运算。
03 物化消费
物化消费，主要分为物化视图注册和物化视图改写阶段。
如上图所示，在物化视图注册阶段，Doris 会定期从 Meta Store 中同步生成的物化视图信息，并在 Doris 中注册类型为 KwaiMTMV 的物化视图对象。在查询改写阶段，扩展了 Doris 的物化视图改写能力，使其能够识别 KwaiMTMV 类型的物化视图，并进行查询改写。
如下是对 author_id 指标进行去重的外表查询的改写结果示例。可以看到 Doris 将 count distinct 算子改写为了更高效的 Bitmap 算子，并将目的表改写到了合适的物化视图表上。
04 使用效果
引入自动物化系统后，不仅加快了数据模型的交付速度，还显著提升了查询效率。以下是实际测试 SQL 的提升效果：
上图直观展示“数据行数”和“查询耗时”这两个维度在物化前后的对比。百万到百亿级别的数据经过物化处理后， 行数压缩至少达 11 倍 。在查询耗时方面，针对百亿级别以下的数据， 物化后均可实现毫秒级响应，查询性能相比物化前提升至少 6 倍 。
湖仓数据查询优化
除缓存服务和物化视图服务外，快手在实际使用过程中总结了一些湖仓查询的优化经验：
结束语
引入 Apache Doris，使快手成功从湖仓分离架构升级到湖仓一体架构。通过 Apache Doris 替换 Clickhouse，实现了统一存储和链路简化，无需数据导入、Doris 能够直接访问湖仓数据。同时，结合 Doris 的物化视图改写能力和自动物化服务，可实现高性能的数据查询以及灵活的数据治理。后续，快手将会进一步探索 Doris 在湖仓一体下的应用实践。具体包括：
今日好文推荐
下载量超 5000 万的知名应用，开发团队“全军覆没”，从此发版人唯剩老板一个
腾讯被曝隐藏专业职级，不希望以职级论英雄；要求加薪减工时、职位“世袭”？！印度三星离谱罢工；“拒绝跑步被辞退”当事人道歉|Q资讯
突发！上交所系统被买崩了？股票交易量火爆挤瘫系统，IT 部门天塌了！
AIGC 使编程平民化，将会是软件行业的一场“灾难”？|专访 Uncle Bob
