# 30分でわかるデータ指向アプリケーションデザイン Navigation: [[Taro L. Saito]] | [[B-Tree]] | [[LSMツリー]] | [[列指向OLAPデータベース]] | [[分散トランザクション]] **登壇者**: [[Taro L. Saito]](『データ指向アプリケーションデザイン』監訳者) **イベント**: Data Engineering Study #18 / 2023-02-15 **スライド**: 37 ページ --- ## 概要 Martin Kleppmann 著『Designing Data-Intensive Applications』(邦題『データ指向アプリケーションデザイン』)の出版から5年が経過した時点で、監訳者の [[Taro L. Saito]] が原著の枠組み(データ形式、データ量、更新頻度、分散処理、トランザクション、データモデル、SLO)に沿って、その後登場した技術・論文・OSS を接続しながら要点を再構成した講演。原著が扱う「信頼性・スケーラビリティ・メンテナンス性」という3つの柱を、5年間の実例(Amazon Aurora、DuckDB/Parquet、Trino、2023年の Twitter 障害など)で再確認する構成になっている。 ## 主要メッセージ - 「データ指向」は「データの量・複雑さ・変化の速度」を中心に考える設計思想であり、オブジェクト指向とは軸が異なる訳語として原著のために作られた(p.2) - データ量・更新頻度に応じてフォーマット(テキスト/バイナリ/列指向)、インデックス構造(B-Tree/LSM ツリー)、分散手法(パーティショニング/レプリケーション/実体化ビュー)を選び分けるという原著の分類が、Parquet・RocksDB・Amazon S3・Amazon Aurora という具体的な OSS・クラウドサービスに対応づけて説明される(p.5-17) - 「テーブル」の意味は RDBMS の最新スナップショットから、時間とともに変化し派生する導出データ(derived data)へと変わってきており、dbt・Delta Lake・Iceberg・Apache Hudi がその依存関係と履歴を管理する新しいレイヤーとして位置づけられる(p.19-20) - SQL は RDBMS 専用のインターフェースから、Google F1・Meta(Velox)・Trino のようにストレージ実装を持たない分散クエリエンジンの共通言語へと役割を広げている(p.26) - 2023年2月の Elon Musk のツイート未配信問題(fanout service の過負荷、最大95%未配信)を題材に、部分障害に耐えるサービス設計・p99/p99.9 のような SLO 指標・冪等性の重要性を実例で説明する(p.30-32) ## 視覚的に重要な図表 **p.7 列指向データフォーマット(Columnar Format)** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-007.png]] Google Dremel のネスト構造分解(record-oriented vs column-oriented)、Parquet のカラム別 repetition/definition level テーブル、1ファイル内のページ分割とフッターインデックスの3点を並べて示す。 **p.10 ディスク上のインデックス構造: B-Tree** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-010.png]] `user_id=251` のルックアップを4階層の B-Tree で辿る例。各ノード100エントリなら1億エントリでも木の高さ4(log₁₀₀(100,000,000)=4)で到達できることを示す。 **p.11 発展形: Log-Structured Merge (LSM) Tree** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-011.png]] RocksDB の memtable→SST file→L0..Ln コンパクションの構造と、Amazon S3(SOSP 2021)の shardID ベース extent 配置を並べ、LSM ツリーが RocksDB 以外のストレージ基盤にも使われていることを示す。 **p.17 分散トランザクションの極み: Amazon Aurora(SIGMOD 2018)** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-017.png]] 左: Primary/Replica インスタンスが 3 AZ × 2 コピーの非同期 4/6 quorum で Amazon S3 へ分散書き込みする構成。右: Storage Node 内部でログレコードが Update Queue → Hot Log → Data Blocks へ処理され、Peer Storage Nodes と gossip で同期する詳細フロー。 **p.20 導出データ(Derived Data)の依存関係グラフ** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-020.png]] Treasure Data 社の実例として、`requests` テーブルを起点に数百のクエリ由来テーブルが複雑に連なる依存関係グラフ。dbt のようなツールがこの依存関係を記述・管理する必要性を視覚的に示す。 **p.30 具体例: ツイート配信の実装(Fanout Service)** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-030.png]] 初期 Twitter(読み込み時にグローバル DB 検索)から、投稿時にフォロワーのタイムラインキャッシュへ書き込む fanout 方式への改良を図解。Elon Musk の1.28億フォロワーが極端な fanout 数の例として挙げられる。 **p.31 128M followers の割に Elon Musk のインプレッションが低い問題** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-031.png]] 2023-02-11 の Elon Musk 本人のツイートを引用し、fanout service の過負荷で最大95%のツイートが未配信だったこと、部分障害でもサービス全体は停止しなかったことを信頼性・メンテナンス性・スケーラビリティの実例として提示する。 **p.32 SLO: システムのパフォーマンスをどう測るか** ![[_attachments/2023__DataEngineeringStudy__30bun-de-wakaru-data-shikou-application-design/page-032.png]] 平均値だけではデータ規模が大きい重要顧客の遅延が見えないことを示し、Amazon の p99.9 レスポンスタイム SLO 事例(100ms 悪化で売上1%減、2022年Q4のオンラインストア収入 $64B の1%=$640M)を紹介する。 ## 概念・実体への接続 - [[Taro L. Saito]](登壇者、監訳者) - [[B-Tree]](p.10 ディスク上のインデックス構造) - [[LSMツリー]](p.11 RocksDB/Amazon S3) - [[列指向OLAPデータベース]](p.7 Parquet/Dremel、p.14 Snowflake/Redshift の Compute-Storage分離) - [[分散トランザクション]](p.16-17 Aurora/Scalar DL) - [[Amazon Aurora (Database)]](p.17 分散トランザクションの極み) - [[DuckDB]](p.7 列指向フォーマットのエコシステム対応) - [[導出データ]](p.18-20 中心概念) ## 限界・不確実点 - スライドは37ページ全編に「原著の各章に対応する話題」を高速に横断するサーベイ形式のため、個々のトピック(LSM ツリーの書き込み増幅、Aurora の gossip プロトコル詳細等)の説明は導入レベルにとどまる - p.31 の Elon Musk ツイートは埋め込み画像内の引用であり、元ツイートの現存・削除状況は未確認 - 音声・動画の transcript は取得していないため、口頭でのみ補足された内容(質疑応答含む)は本ページに反映されていない - p.34-36 で言及される参考文献リスト(GitHub: ept/ddia-references)は URL のみの紹介であり、個別文献の内容はスライドから検証できない