Upgrade to Pro — share decks privately, control downloads, hide ads and more …

実践的データ基盤への処方箋 輪読会 / round-reading-jissennteki-data-kiban

実践的データ基盤への処方箋 輪読会 / round-reading-jissennteki-data-kiban

2022/02/18 「実践的データ基盤への処方箋」 輪読会の資料です。

Shuichi Ohsawa

February 18, 2022
Tweet

More Decks by Shuichi Ohsawa

Other Decks in Technology

Transcript

  1. 目次 3 • 2-13 : データウェアハウスには抽出や集計に特化した分析用DBを採用する • 2-14 : 分析用DBはクラウド上で使い勝手が良い製品を選ぶ

    • 2-15 : 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける • 2-16 : 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する • 2-17 : ワークフローエンジンは「専用」か「相乗り」かをまず考える
  2. 目次 4 • 2-13 : データウェアハウスには抽出や集計に特化した分析用DBを採用する • 2-14 : 分析用DBはクラウド上で使い勝手が良い製品を選ぶ

    • 2-15 : 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける • 2-16 : 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する • 2-17 : ワークフローエンジンは「専用」か「相乗り」かをまず考える
  3. オペレーショナルDBではなく分析用DBを採用する 5 • オペレーショナルDBと分析用DB、2種類のデータベースがある • オペレーショナルDBの例:Amazon Aurora • 分析用DBの例:Amazon Redshift

    • どちらもデータをテーブルに格納、SQLでクエリ実行、GROUP BY、MIN/MAXなどの集計関数も使えるが、Redshiftはデータの抽出や 集計といった処理に特化している • データ基盤のデータウェアハウスには分析用DBを採用する • オペレーショナルDBを採用してしまうと、データ抽出や集計が遅くて使い物にならないか、コストが高くつく • オペレーショナルDBと分析用DBの違いは次ページ以降 (コメント) • OLTP、OLAPではなくオペレーショナルDBと分析用DBと表記した理由はなんだろう
  4. オペレーショナルDBはデータ操作に強い 6 • 例:Webサイトのバックエンドに、ユーザが行ったデータの参照・更新・挿入・削除といった操作 • 製品例:Oracle、SQL Server、MySQL、PostgreSQL etc • マネージドサービス例:AWS

    RDS、GCP Cloud SQL etc • オペレーショナルDBの特徴・性質 • 応答速度を重視、少量のデータを頻繁に操作することが求められる • 例:1,000万行10GBの全データの中の、1行1KBのデータを、10ミリ秒で操作する • テーブルのデータを行ごとに格納し、行へのアクセスが 高速になるように作られている(行指向) • 列の値の平均をとったり、合計するといった集計操作は苦手 P.127 図2-32より
  5. 分析用DBはデータの抽出と集計に強い 7 • 例:オペレーショナルDBのデータやCSVを夜間バッチでロード、BIツールに抽出、レポート作成ジョブで全件集計 • 製品例:Amazon Redshift、GCP BigQuery、Snowflake • 分析用DBの特徴・性質

    • 応答速度よりもスループット(単位時間あたりの処理速度)を重視する • 例:オペレーショナルDBにある売上テーブルを30分かけてロードし、その後1時間かけて全件集計、売上レポートをつくる • テーブルのデータを列方向に格納し、抽出や集計の計算に最適化 • 少量のデータへの素早い操作や、特定の1行だけを更新する処理は苦手 • 列方向の操作に強い分析DBを 「列指向データベース」「カラムナデータベース」とも呼ばれる P.129 図2-34より
  6. 目次 8 • 2-13 : データウェアハウスには抽出や集計に特化した分析用DBを採用する • 2-14 : 分析用DBはクラウド上で使い勝手が良い製品を選ぶ

    • 2-15 : 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける • 2-16 : 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する • 2-17 : ワークフローエンジンは「専用」か「相乗り」かをまず考える
  7. 分析用DBの一覧 10 • 提供形態(クラウド or オンプレミス)× Hadoopベースかどうかで分類できる • ① :

    歴史的に登場が古い、重厚長大で敷居が高い • ② : Hadoopによって導入の敷居が低くなった、システムの複雑さ・運用の難しさが課題 • ③ : マネージドHadoopによって複雑な環境構築が自動化、データ増加に対してスケーラブルに対応 • ④ : Hadoopの欠点を克服したクラウドDWH製品が現在の主流 P.130 表2-4より
  8. 初期コストの低いクラウド上の分析用DBがおすすめ 11 • 「初期コストの低さ」を第一に優先すべき • 最初からシステム規模を推定することはほぼ不可能 • ① オンプレミスDWH製品は、高額(数千万円~億単位)の初期投資が必要になる •

    ② オンプレミスHadoopは、サーバの購入が必要で高額(数千万円程度)の初期投資が必要になる • ③ or ④(クラウド上の分析DB)は基本的に従量課金であり、初期費用を必要としない
  9. クラウド上の分析用DBはデータソースと同じクラウド上の製品が自然な選択肢 12 • 「データソースがどのクラウドにあるか」がクラウドの分析用DBの中から選ぶ判断基準の一つ データソースと分析用DBが同じクラウドにあることのメリット 1. ネットワーク通信が同一クラウド内で完結 • データ転送速度が高速 •

    データ転送料金がかからない(同一リージョンの場合) 2. クラウドにあるデータ転送・共有サービスの恩恵を受けられる • クラウドによってはデータソースから分析用DBに簡単にデータ転送できる仕組みを持っている • 例:AWS Glue、Cloud Data Fusion • フェデレーション機能を利用することで、分析用DBからデータソースに直接クエリすることができる
  10. クラウド上の分析用DBの選び方 13 • AWSにおいてどの分析用DBを選択したらよいか • Redshift、Athena、EMR、Snowflake、Cloudera • データ基盤構築の初期段階、S3にデータがあり気軽に分析したい場合 → Athena

    • データ基盤を拡大していく場合 • 他AWSサービスとの連携しやすさを重視する場合 → Redshift • 処理単位の課金モデルやWebブラウザでの使いやすさを重視する場合 → Snowflake • GCPの場合は、基本的にBigQueryを採用する • データソースがAWSにあるが、BigQueryを採用する事例が多く見られる (コメント) Redshiftでの今までのつらさと、BigQueryのパフォーマンスや事例の多さから採用することが多そう(自分もそう)
  11. 目次 15 • 2-13 : データウェアハウスには抽出や集計に特化した分析用DBを採用する • 2-14 : 分析用DBはクラウド上で使い勝手が良い製品を選ぶ

    • 2-15 : 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける • 2-16 : 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する • 2-17 : ワークフローエンジンは「専用」か「相乗り」かをまず考える
  12. 分析用DBに優しいSQLを書こう 20 • 全件を削除する場合は、DELETEではなくDROPする • DELETEは列指向圧縮されたファイルの書き換えを発生させる • テーブルの一部を更新する場合は、更新した内容を持つ新たなテーブルを用意し、置き換える • UPDATE、DELETEは列指向圧縮されたファイルの書き換えを発生させる

    • CTAS(CREATE TABLE AS SELECT)構文を用いて、新たにテーブルを作り、テーブル名をリネームする • データを入れるときは、1件ずつINSERTするのではなく、複数件まとめてロードする • 1件ずつINSERTされると、列指向圧縮のデータを作り変える必要がある • INSERTではなくロードする機能を使う (コメント) データ利用の観点から SELECT * ~を止めるようにしたい
  13. 目次 21 • 2-13 : データウェアハウスには抽出や集計に特化した分析用DBを採用する • 2-14 : 分析用DBはクラウド上で使い勝手が良い製品を選ぶ

    • 2-15 : 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける • 2-16 : 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する • 2-17 : ワークフローエンジンは「専用」か「相乗り」かをまず考える
  14. 自前でワークフローを制御するのは大変 23 • ワークフローエンジンを使わずに、WindowsのタスクスケジューラやLinuxのcrontabなどを 使うこともできるが大変 • スケジュールそのものが動かなかった場合の制御 • スクリプト言語で実行順序を列挙して起動順序を制御する場合 •

    処理中に異常終了した場合の復旧作業として、途中から再開するのが大変 • 処理が増えてくると可読性が低くなり、全容を把握できなくなる • 異常終了に対する通知やカスタマイズ機能が欲しくなる • 異常終了したらSlack通知したい • 「この処理の異常終了は1週間無視」「この文字列を含む場合は無視」等 • ワークフローエンジンによって、これらの問題やスクリプト言語で対処できない複雑な作り込みに対応できる
  15. 目次 25 • 2-13 : データウェアハウスには抽出や集計に特化した分析用DBを採用する • 2-14 : 分析用DBはクラウド上で使い勝手が良い製品を選ぶ

    • 2-15 : 列指向圧縮を理解して分析用DBが苦手な処理をさせないように気をつける • 2-16 : 処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する • 2-17 : ワークフローエンジンは「専用」か「相乗り」かをまず考える
  16. データ基盤専用にする場合は使いやすいものを選ぶ 27 • データ分析は試行錯誤をどれだけ早く回せるかが鍵 • 普段SQLを書いて分析しているデータ基盤の利用者が、マニュアルを読めばワークフローを作って デプロイできる程度が目安 • 製品例 :

    Apache Airflow • Airbnb社が中心となって開発したオープンソースのワークフローエンジン • Web画面やAPIなどを通じて操作可能 • Pythonで記述でき、プラグインも多数用意されている • マネージドサービス • GCP : Cloud Composer • AWS : Amazon Managed Workflows for Apache Airflow(MWAA)