2.李睿博.pdf

1、云器科技 李睿博通用增量计算：通用增量计算：新一代数据架构的核心引擎新一代数据架构的核心引擎个人简介个人简介 19 年从业经验 20092023 在阿里云工作，是阿里云第一代员工。致力于分布式系统、大数据引擎等相关研发工作。曾主导阿里云某大数据产品湖仓一体的研发及标杆客户落地。2023 年底以合伙人身份加入云器科技，负责 Lakehouse、Studio 研发相关工作，主导通用增量计算的标杆客户落地。目录目录0 1AIAI 时代最佳的数据架构时代最佳的数据架构0 2通用增量计算原理及关键技术通用增量计算原理及关键技术0 3案例：小红书数仓的生产新范式案例：小红书数仓的生产新范式0 1 AIAI

2、 时代的数据架构时代的数据架构延续十年的问题-不可能三角 前 AI 时代的数据体系尚未完成收敛-由多种系统/组件拼装的 Lambda 系统仍然是生产主流-不可能三角及其导致的数据冗余仍然广泛存在 AI 时代对数据体系提出了更高要求-更高的数据一致性要求-更高的实时性要求-更高的多模、性能要求批处理系统：从离线到分析 头部厂商已经有各自的增量计算实现-Databricks 的 delta live table（刚刚开源）-Snowflake 的 dynamic table 开源社区以及多数厂商仍旧在力大砖飞-没有改变全量计算的模型-开源 gluten+velox 被广泛关注并尝试 单纯性能的提升

3、使得离线引擎某些条件下也能承担分析需求关键点关键点设计目标设计目标细节设计细节设计设计目标设计目标吞吐率（throughput）优先以扩展性为前提（Scalability），吞吐率（throughput）优先的设计。数据新鲜度（Freshness）不作为方向。驱动方式驱动方式主动计算主动计算。作业主动发起计算。计算模型计算模型全量计算全量计算（不理解数据的变化）。每次作业下发，数据版本被锁定。引擎不理解数据的变化，不能处理增量。存储模型存储模型静态存储批处理模式与存储模型解耦，但无论哪种模式，仅支持对静态数据数据表达的计算。数据建模数据建模常用标准维度建模建模区分事实表和维表。采用时间分区存储

4、，一般按天分区。所有表的计算均按分区对齐。语言表达语言表达标准SQL+UDF批处理语言表达能力全面且丰富。在数据库基础上扩展UDF支持，丰富了语言标准。从流计算到流批一体 Flink 是流计算的生产事实标准-无边界数据、无序数据、窗口、水位等概念的抽象，checkpoint、state 的工程实现，以 Freshness 为目标来看，是非常优秀的设计-SQL 开发成为主流，但是流表本质是个管道，无法脱离作业上下文，不具备建模能力-生产上在离线 ETL 场景仍然难以撼动 Spark 的江湖地位 有新的挑战者出现（如 RisingWave），提供部分新能力（如中间表可访问），尚待成熟关键点关键点设

5、计目标设计目标细节设计细节设计设计目标设计目标 新鲜度（freshness）优先以扩展性为前提（Scalability），数据新鲜度（Freshness）优先的设计。驱动方式驱动方式 被动计算被动计算。由数据驱动。计算模型计算模型 流计算模型（增量的一种特化）一种基于window的管道式处理模式，输入和输出都是管道模式（不包含全量数据）。存储模型存储模型 Pipe管道模型有表的概念，但仅表达Schema，输入/输出数据是pipe的表达，因此不支持访问全量/增量/某一版本数据建模数据建模 无不支持直接中间数据落盘，中间数据不可全量/重新访问，不具备标准数仓建模的能力。更像是个流水线模型。语言表达

6、语言表达 非标准SQL+UDF非标准SQL，额外引入EventTime、watermark、window、Trigger等概念，使用复杂，背离标准SQL，很难复用/统一从 MPP 数仓到湖仓一体 Presto/Trino/ClickHouse 迁移 Doris 体系的趋势明显 主打湖仓一体，存算分离-和面向分析场景优化的离线系统关键技术趋同-Cache 的大小和利用效率成为影响性能的关键 在相对简单的短链路上近实时方案涌现-实现路径呈现多样化 某些条件下可以承担 ETL 需求 支持手工定义 materialized view 用于加速查询下一代数据架构-打破 Lambda，实现真 Kappa