这篇博文是由 Notion 数据平台团队的软件工程师 Thomas Chow 和 Nathan Louie 于 2023 年 12 月 13 日发表的题为 Notion's Journey Through Different Stages of Data Scale 的 Hudi 现场活动的简短摘要。下面的视频剪辑给出了Notion 演讲的简短摘要，还可以查看演讲幻灯片^[1]或查看完整演讲^[2]。

Notion 数据平台团队的软件工程师 Thomas Chow 和 Nathan Louie 描述了随着数据规模和数据需求迅速升级，他们如何升级数据基础设施。管理的数据在短短三年内增长了 10 倍；如今压缩后的数据快照大小为 50TB，活动数据大小为数百 TB。他们新的和改进的数据架构正在显着节省成本，并解锁关键的产品和分析用例，包括 Notion 最新的、改变游戏规则的基于人工智能的生成功能。

了解概念

Chow 的重点是 Notion 的批处理和数据湖生态系统，他通过解释 Notion 数据模型的复杂性开始了演讲。作为一款协作文档产品，Notion 拥有一个“一切……都是一个块”的数据模型。所有这些块在后端都有类似的数据模型和架构，其中有关块的元数据适合不同块类型的相同结构。然而这些看起来相似的块可以呈现为截然不同的用户界面组件，从而赋予 Notion 其最终用户所熟知和喜爱的灵活性和可扩展性。请参见图 1 的示例。

Blocks 面临的挑战是它们所代表的数据规模：Notion 的数据倍增率为六个月到一年。这是令人震惊的，特别是考虑到 200 亿区块的起点。表 1 显示了增长率。

不仅数据规模迅速增加，对数据的需求也随之增加。因此 Notion 必须创新和发展其数据基础设施，并且他们在三年前开始的相对较短的时间内成功做到了这一点。

应对加倍：不断发展的 Notion 数据基础设施

在 2022 年之前，Notion 的整个数据基础设施都依赖于单个 PostgreSQL 数据库系统，如图 2 所示。它是公司一切的核心，从对实时产品的支持到分析。这对于早期来说是一个有效的解决方案。但随着公司的发展（数据规模、交易量和相关指标持续翻倍），团队开始达到这种配置的极限。

这促使从单个 Postgres 表转变为 15 个逻辑分片，如图 3 所示，这是 Notion 数据基础设施的重大飞跃。事实上它是如此重要，以至于基础设施团队值得发表一篇博客文章。分片有助于分布数据负载，但也使数据架构变得复杂，需要更复杂的数据管理和查询策略，特别是将数据移动到数据仓库时。

数据仓库面临的挑战

大约在这个时候，Notion 团队采用 Snowflake 作为数据仓库来支持他们的分析和报告需求，以及围绕机器学习不断增长的需求。他们希望在数据规模不断增长的情况下支持这些用例，而又不会压垮服务于实时产品的 Postgres 数据库。为此他们在提取、转换和加载 (ETL) 管道中镜像了分片数据库的格式。在 ETL 管道中，Postgres 数据将通过 Fivetran 摄取到 Snowflake 中，后者用作数据仓库。但随着管道中数据规模的增长，问题也随之增加。

在 ETL 管道的第一阶段，团队发现内存不足，并且在处理突发容量时遇到问题。这些爆发的频繁发生是由于用户与 Notion 的交互方式造成的，这种交互方式在一天中完全不统一。Thomas 解释说，“Fivetran 是一个[闭源]第三方产品，因此我们实际上可以调整的配置很少”来应对块更新量的频繁变化。

将数据加载到 Snowflake 中也具有挑战性，因为加载所需的时间很长，而且成本很高。鉴于同步每小时进行一次，有时需要一个多小时，而且经常会进入下一个同步周期，非常痛苦。

当团队努力寻找解决这些扩展难题的方法时，他们发现了一种可能提供线索的模式。他们注意到只有大约 1% 的块被更新插入（更新记录的操作，或者如果记录尚不存在则插入它）。因此，与通常的情况一样，与表的大小相比，总更新插入量实际上相当小，如图 4 所示。正是看到这种模式，促使 Notion 团队转向通用数据 Lakehouse 架构，该架构将更好地支持这种观察到的更新模式。

使用 Apache Hudi 解决挑战

该团队当时有多种架构选择 - Apache Hudi、Apache Iceberg 和 Delta Lake（Databricks 使用的内部 Delta Lakehouse 架构的开源版本）。经过仔细分析选择了Hudi，做出这一决定的一些原因如下：

• 增量处理能力：这对于每小时同步更新很重要，Hudi 在这一能力方面处于领先地位。

• 实现高效的随机更新插入：观察到的数据访问模式是 Notion 产品的核心——块编辑与新近度无关，而是几乎是随机的，因为它们基于用户对块的编辑。

• 开箱即用的 Postgres 集成：Debezium 变更数据捕获 (CDC) 平台与 Postgres 和 Hudi 一起开箱即用，这一点至关重要，因为这显着加快了实施速度。

• 通过 Bloom 过滤器进行高效索引：Bloom 过滤器对近随机更新插入行为的更好支持非常适合 Notion 团队的用例。

• 目录级分区：Hudi 的目录级分区非常适合已有的分片 Postgres 架构概念。

• 开源速度：Notion 团队对 Hudi 周围的开源社区的速度印象深刻，解决了他们对闭源第三方软件可能带来的灵活性限制的担忧。这包括通过开源社区与 Onehouse 团队建立关系，Thomas 称其“对于将这项技术引入 Notion 至关重要”，因为“不需要‘重新发明轮子’对于快速正确地启动和运行非常有价值”。

现在的数据湖基础设施

在决定采用 Hudi 后，Notion 彻底改造了他们的数据湖基础设施以利用它。新的基础设施将数据从 Postgres 摄取到 Debezium CDC，该数据通过 Kafka 传输，然后馈送到 Hudi 以针对 Hudi 数据集进行批量增量更新，最后推送到下游到 Apache Spark 管道以执行 ETL，如图 5 所示而且，除了针对大型数据集彻底改造其基础设施之外，Notion 团队还保留了之前针对较小数据集和第三方数据源的 Postgres、Fivetran 和 Snowflake 管道。

实施新的通用LakeHouse的回报是巨大的。由于整个系统的性能大幅提高，特别是替换了以前缓慢且昂贵的数据加载到 Snowflake 中，该团队立即节省了 125 万美元。该团队还在历史 Fivetran 同步速度方面取得了显着的性能改进，从需要一周缩短到需要两个小时，提高了 84 倍。这使得历史 Fivetran 能够重新同步，而不会耗尽实时数据库上的资源并影响 Notion 产品的性能。他们还能够使用 Hudi 的 DeltaStreamer 实现每四个小时增量同步。（他们甚至澄清说，如果他们愿意，他们可以增加节奏，因为 DeltaStreamer 中仍然有可用空间，但每四个小时就可以满足他们的需求。）也许最令人兴奋的改进是新架构支持大型语言模型的功能在切换之前实现起来即使不是不可能，也是极其困难的。

利用 Notion AI 推动 Hudi 之上的产品创新

Nathan 在 Notion 专注于数据湖生态系统和人工智能基础设施（特别是人工智能嵌入），他解释了通用数据湖架构如何解锁新的创新：问答人工智能。Notion 的 Q&A AI 功能使用户能够通过聊天界面提出 Notion AI 问题，并根据其（或其团队）Notion 页面和数据库的全部内容获得答复。

为了在使用 AI 进行回答时引用团队或用户的 Notion 工作区中的正确文档，团队需要有一个向量数据库来存储嵌入（高维向量空间中文本块的表示）。然后，他们可以查找相关文本以输入到大型语言模型的上下文中来回答用户。需要通过两种方式生成数据：

• 离线：每个工作区发生一次以引导矢量数据库，并且包含大批量作业。

• 在线：这些是通过 Kafka 广播的增量更新，用于处理新的块编辑并在写入时将它们发送到矢量数据库。

然而正如托马斯已经多次提到的那样，Notion 有大量的文档和块，因此也有大量的数据。幸运的是随着 Hudi 的采用，这个数据规模变得易于管理，如图 6 所示。

Nathan 解释说，Hudi 使团队能够定义大型、灵活的处理作业，从而使事情变得易于管理，而这对于 Fivetran 和 Snowflake 来说更具挑战性。此外 Hudi 启用的四小时同步频率为团队提供了良好的服务，因为一旦完成离线批处理，同步任何更新的实时数据的在线“追赶期”就在一天之内。这确保了数据湖房永远不会与生产数据库过于不同步。简而言之，现在可以快速且经济高效地处理 Notion 数据湖中的几乎所有数据——这是启用 Notion AI 的必备条件。

总结

在讨论 Notion 数据基础设施扩展、在短短三年内增长 10 倍以及需要满足新需求的历程时，Thomas 和 Nathan 谈到了广泛的见解和经验。这包括从扩展数据库系统和发明（然后重新发明）数据湖架构，到基于这些创新实现新的和以前不可行的产品功能的一切。还指出了 Hudi 的 Lakehouse 架构对其数据基础设施的好处，并指出 Hudi 为 Notion 节省了 125 万美元的成本并提高了性能。