Notion 如何處理 2000 億個數據實體？
從 PostgreSQL → Data Lake
本文最初發表於 https://vutr.substack.com。
介紹
如果你用過 Notion，你就會知道它幾乎可以讓你做任何事情 -- 記筆記、計劃、閱讀清單和項目管理。
Notion 非常靈活，可以定製用戶喜歡的模板。Notion 中的一切都是塊，包括文本、圖像、列表、數據庫行甚至頁面。
這些動態單元可以轉換成其他塊類型，也可以在 Notion 中自由移動。
Blocks are Notion’s LEGOs.
PG 統治一切
2021 年，他們擁有超過 200 億個區塊。
現在，這些區塊已經增長到兩千多億個實體，2021 年之前，他們將所有區塊都放在一個 Postgres 實例中。現在，他們將數據庫分割成 480 個邏輯分片，並將它們分佈在 96 個 Postgres 實例上，每個實例負責 5 個分片。
在 Notion，Postgres 數據庫負責處理從在線用戶流量到離線分析和機器學習的所有事務。
認識到分析用例的爆炸性需求，特別是他們最近推出的 Notion AI 功能，他們決定爲離線工作負載建立一個專用的基礎架構。
Fivetrans 和 Snowflake
2021 年，他們開始了簡單的 ETL 之旅，使用 Fivetran[1] 將數據從 Postgres 採集到 Snowflake，每小時使用 480 個連接器將 480 個分片寫入原始的 Snowflake 表。
但當 Postgres 數據增長時，這種方法就會出現一些問題：
-
Notions 用戶更新數據塊的頻率高於添加新數據塊的頻率。這種大量更新的模式會降低 Snowflake 數據攝取的速度和成本。
-
數據消耗變得更加複雜和繁重（人工智能工作負載）
Notion 開始建設內部數據湖。
The Lake
他們希望建立一個能提供以下功能的解決方案：
-
可擴展的數據存儲庫，用於存儲原始數據和處理過的數據。
-
爲任何工作負載提供快速、經濟高效的數據攝取和計算。特別是對於更新量大的塊數據。
2022 年，他們啓用了內部數據湖架構，該架構使用 Debezium 將數據從 Postgres 增量攝取到 Kafka，然後使用 Apache Hudi 將數據從 Kafka 寫入 S3。
對象存儲將作爲消費系統的終端，爲分析、報告需求和人工智能工作負載提供服務。
他們使用 Spark 作爲主要數據處理引擎，處理湖泊頂部的數十億個數據塊。從 Snowflake 遷移的數據攝取和計算工作負載可幫助他們大幅降低成本。Postgres 的變化由 Kafka Debezium Connector 捕捉，然後通過 Apache Hudi 寫入 S3。
Notion 之所以選擇這種表格格式，是因爲它能很好地應對更新繁重的工作負載，並能與 Debezium CDC 報文進行本地集成。
下面簡要介紹一下他們是如何實現該解決方案的：
-
Notion 在託管的 AWS Kubernetes (EKS) 上部署了這些連接器
-
該連接器可處理每秒數十 MB 的 Postgres 行更改。
-
每個 Postgres 表有一個 Kafka 主題。
-
所有連接器都將從所有 480 個分片中消耗數據，並將數據寫入該表的同一主題。
-
他們使用 Apache Hudi Deltastreamer[2]（一種基於 Spark 的攝取作業）來讀取 Kafka 消息並將數據寫入 S3。
-
大多數數據處理工作都是用 PySpark 編寫的。
-
他們使用 Scala Spark 處理更復雜的工作。Notion 還利用多線程和並行處理來加快 480 個分片的處理速度。
回報
-
2022 年，將數據從 Snowflake 遷移到 S3 爲 Notion 節省了 100 多萬美元，2023 年和 2024 年節省的費用將更爲可觀。
-
從 Postgres 到 S3 和 Snowflake 的總體攝取時間大幅縮短，小表的攝取時間從一天以上縮短到幾分鐘，大表的攝取時間則縮短到幾個小時。
-
新的數據基礎設施可提供更先進的分析用例和產品，從而在 2023 年和 2024 年成功推出 Notion AI 功能。
參考資料
[1]
Fivetran: https://www.fivetran.com/
[2]
Apache Hudi Deltastreamer: https://hudi.apache.org/docs/0.10.0/hoodie_deltastreamer/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/3gcXhTTR1OtDjw0MC82Prw