Notionが急成長に合わせてデータレイクを構築・拡張した方法

xguru · 2024-07-15T10:31:01+09:00

過去3年間で、Notionのデータはユーザー数とコンテンツの増加により10倍に増え、6〜12か月ごとに2倍のペースで増加しているこうした急成長を管理するため、Notion AI機能をはじめとする主要な製品および分析ユースケースのデータ要件を満たしながら、Notionはデータレイクを構築・拡張した Notionのデータモデルと成長 Notionで見えるすべてのものは「ブロック」エンティティとしてモデル化され、Postgresデータベースに一貫した構造、スキーマ、および関連メタデータとともに保存されるこのブロックデータは6〜12か月ごとに2倍に増加し、2021年初頭には200億件超のブロック行があり、現在は2,000億件超のブロックが存在する 2021年時点のNotionのデータウェアハウスアーキテクチャ Fivetranを使ってPostgres WALからSnowflakeへデータを取り込むシンプルなELTパイプラインにより、専用データインフラを開始した 480のシャードに対して毎時実行される480のコネクタを設定し、480の生Snowflakeテーブルに書き込み、それらのテーブルを分析、レポート、機械学習ユースケース向けの1つの大きなテーブルにマージしたスケーリング時の課題 Postgresのデータ増加に伴い、複数の問題に直面した運用性: 480のFivetranコネクタを監視・管理するオーバーヘッドが非常に大きくなった速度、データ鮮度、コスト: Notion特有の更新中心ワークロードにより、Snowflakeへのデータ取り込み速度が低下し、コストが増加したユースケース対応: データ変換ロジックがより複雑かつ重くなり、標準的なデータウェアハウスが提供する標準SQLインターフェースの機能を上回るようになった Notionのインハウスデータレイクの構築と拡張内部データレイクの目標生データと処理済みデータを大規模に保存できるデータストアを確立する特にNotionの更新中心のブロックデータについて、すべてのワークロードに対して高速でスケーラブル、運用可能かつコスト効率の高いデータ取り込みと計算を可能にする AI、検索、および非正規化データを必要とするその他製品のユースケースを支援する SnowflakeとFivetranを完全に置き換えることや、厳しいレイテンシ要件を持つオンラインユースケースをサポートすることは意図していないデータレイクのハイレベル設計 Debezium CDCコネクタを使ってPostgresからKafkaへ増分更新データを収集し、その後Apache Hudiを使ってこれらの更新をKafkaからS3へ書き込むこの生データを使って変換、非正規化、エンリッチを行い、その後、処理済みデータを再びS3または下流システムに保存して、分析・レポート要件とAI、検索、その他製品の要件を満たす設計上の判断データストアおよびレイクの選定: S3をデータストア兼データレイクとして使用し、すべての生データと処理済みデータを保存し、データウェアハウスおよびその他のプロダクト向けデータストアを下流に配置する処理エンジンの選定: オープンソースフレームワークであるSparkを主要なデータ処理エンジンとして選択するスナップショットダンプより増分取り込みを優先: 通常運用中は変更されたPostgresデータを増分で収集して継続的にS3へ適用し、まれなケースではS3でテーブルをブートストラップするためにPostgres全体のスナップショットを一度だけ生成する増分取り込みの簡素化: Kafka Debezium CDCコネクタを使って増分変更されたPostgresデータをKafkaへ配信し、Hudiを使ってKafkaからS3へ増分データを取り込む処理前に生データを収集: 単一の信頼できるソースを確立し、データパイプライン全体でのデバッグを簡素化するため、オンザフライ処理なしで生のPostgresデータをS3へ収集するデータレイクの拡張と運用 CDCコネクタおよびKafka設定: Postgresホストごとに1つのDebezium CDCコネクタを設定し、AWS EKSクラスターにデプロイした Hudi設定: Apache Hudi Deltastreamerを使ってKafkaメッセージを処理し、S3上でPostgresテーブルの状態を複製した Sparkデータ処理設定: ほとんどのデータ処理ジョブでPySparkを活用し、ツリー走査や非正規化のようなより複雑な作業ではSparkの高い性能を活用したブートストラップ設定: Debezium Connectorを設定してPostgresの変更をKafkaへ収集し、AWS RDSが提供するS3へのエクスポートジョブを使ってPostgresテーブルの最新スナップショットをS3に保存した後、Sparkジョブを作成してS3からそのデータを読み込み、Hudiテーブル形式で書き込んだ結果 2022年春にデータレイクインフラの開発を開始し、同年秋に完了した 2022年には100万ドル超の純削減効果があり、2023年と2024年にはそれに比例してさらに大きな削減効果が生まれた PostgresからS3およびSnowflakeまでのエンドツーエンドの取り込み時間は、1日超から、小規模テーブルでは数分、大規模テーブルでも最大数時間まで短縮されたデータレイクにより、2023年と2024年にNotion AI機能を成功裏にローンチできた

(notion.so)

21 ポイント投稿者 xguru 2024-07-15 | 2件のコメント | WhatsAppで共有

過去3年間で、Notionのデータはユーザー数とコンテンツの増加により10倍に増え、6〜12か月ごとに2倍のペースで増加している
こうした急成長を管理するため、Notion AI機能をはじめとする主要な製品および分析ユースケースのデータ要件を満たしながら、Notionはデータレイクを構築・拡張した

Notionのデータモデルと成長

Notionで見えるすべてのものは「ブロック」エンティティとしてモデル化され、Postgresデータベースに一貫した構造、スキーマ、および関連メタデータとともに保存される
このブロックデータは6〜12か月ごとに2倍に増加し、2021年初頭には200億件超のブロック行があり、現在は2,000億件超のブロックが存在する

2021年時点のNotionのデータウェアハウスアーキテクチャ

Fivetranを使ってPostgres WALからSnowflakeへデータを取り込むシンプルなELTパイプラインにより、専用データインフラを開始した
480のシャードに対して毎時実行される480のコネクタを設定し、480の生Snowflakeテーブルに書き込み、それらのテーブルを分析、レポート、機械学習ユースケース向けの1つの大きなテーブルにマージした

スケーリング時の課題

Postgresのデータ増加に伴い、複数の問題に直面した
運用性: 480のFivetranコネクタを監視・管理するオーバーヘッドが非常に大きくなった
速度、データ鮮度、コスト: Notion特有の更新中心ワークロードにより、Snowflakeへのデータ取り込み速度が低下し、コストが増加した
ユースケース対応: データ変換ロジックがより複雑かつ重くなり、標準的なデータウェアハウスが提供する標準SQLインターフェースの機能を上回るようになった

Notionのインハウスデータレイクの構築と拡張

内部データレイクの目標
- 生データと処理済みデータを大規模に保存できるデータストアを確立する
- 特にNotionの更新中心のブロックデータについて、すべてのワークロードに対して高速でスケーラブル、運用可能かつコスト効率の高いデータ取り込みと計算を可能にする
- AI、検索、および非正規化データを必要とするその他製品のユースケースを支援する
SnowflakeとFivetranを完全に置き換えることや、厳しいレイテンシ要件を持つオンラインユースケースをサポートすることは意図していない

データレイクのハイレベル設計

Debezium CDCコネクタを使ってPostgresからKafkaへ増分更新データを収集し、その後Apache Hudiを使ってこれらの更新をKafkaからS3へ書き込む
この生データを使って変換、非正規化、エンリッチを行い、その後、処理済みデータを再びS3または下流システムに保存して、分析・レポート要件とAI、検索、その他製品の要件を満たす

設計上の判断

データストアおよびレイクの選定: S3をデータストア兼データレイクとして使用し、すべての生データと処理済みデータを保存し、データウェアハウスおよびその他のプロダクト向けデータストアを下流に配置する
処理エンジンの選定: オープンソースフレームワークであるSparkを主要なデータ処理エンジンとして選択する
スナップショットダンプより増分取り込みを優先: 通常運用中は変更されたPostgresデータを増分で収集して継続的にS3へ適用し、まれなケースではS3でテーブルをブートストラップするためにPostgres全体のスナップショットを一度だけ生成する
増分取り込みの簡素化: Kafka Debezium CDCコネクタを使って増分変更されたPostgresデータをKafkaへ配信し、Hudiを使ってKafkaからS3へ増分データを取り込む
処理前に生データを収集: 単一の信頼できるソースを確立し、データパイプライン全体でのデバッグを簡素化するため、オンザフライ処理なしで生のPostgresデータをS3へ収集する

データレイクの拡張と運用

CDCコネクタおよびKafka設定: Postgresホストごとに1つのDebezium CDCコネクタを設定し、AWS EKSクラスターにデプロイした
Hudi設定: Apache Hudi Deltastreamerを使ってKafkaメッセージを処理し、S3上でPostgresテーブルの状態を複製した
Sparkデータ処理設定: ほとんどのデータ処理ジョブでPySparkを活用し、ツリー走査や非正規化のようなより複雑な作業ではSparkの高い性能を活用した
ブートストラップ設定: Debezium Connectorを設定してPostgresの変更をKafkaへ収集し、AWS RDSが提供するS3へのエクスポートジョブを使ってPostgresテーブルの最新スナップショットをS3に保存した後、Sparkジョブを作成してS3からそのデータを読み込み、Hudiテーブル形式で書き込んだ

結果

2022年春にデータレイクインフラの開発を開始し、同年秋に完了した
2022年には100万ドル超の純削減効果があり、2023年と2024年にはそれに比例してさらに大きな削減効果が生まれた
PostgresからS3およびSnowflakeまでのエンドツーエンドの取り込み時間は、1日超から、小規模テーブルでは数分、大規模テーブルでも最大数時間まで短縮された
データレイクにより、2023年と2024年にNotion AI機能を成功裏にローンチできた

2件のコメント

befree 2024-07-16

もしよろしければ、上記の内容に関連する文書や参照された資料を教えていただけますでしょうか？