『実践的データ基盤への処方箋』第2章データ基盤システムのつくり方 メモ
分散処理の必要性
処理するデータの量が多い場合は分散処理が必要
集計だけでなく、収集や蓄積でも分散処理が必要
データソースごとに収集方法は異なる
データ収集はデータ基盤の中で取り扱いが最も難しいです
観点その1:
ストレージからファイル収集orデータベースからテーブル収集？
→いずれかによって、運用上考慮すべき点も異なります
同一のデータソース内でも…
観点その2: データベースはどれほどの負荷に耐えられる？
観点その3: データの量
観点その4: データに個人情報が含まれるか？
データソースの種類：
ファイル、API、Webサイト、データベース、
ログ、端末データ…
※本の中ではそれぞれのデータソースに対する収集方法が紹介されました。ここでは、データベースのみを取り上げました。
SQLを利用したデータベース収集
SQLを利用したデータベースからのデータ収集
データベースへの負荷に注目しよう
データベースのデータソースとしての特徴
データの構造を決められます
データの一貫性を保つ機能があります
→企業活動にとって重要なデータを蓄積する場所は
データベースそして、それらのデータは意思決定に用いられやすい
→データはアクセスしやすい形でデータ基盤に蓄積する
のがよい
データベースからデータを収集する方法
SQL利用
ファイル経由
更新ログ収集
それぞれを見ていきます。
SQL利用
テーブルの大きさごとに収集方法が異なります。
テーブルが小さい場合は、SELECT文→データ取得→格納
テーブルが大きい場合はフェッチを使用
収集が予定時間内に終わらない場合の収集方法
ーテーブルの一部を収集するテーブルへの処理がinsertのみの場合
追加されたレコードのみ収集テーブルへの処理がinsertとupdateの場合
更新されたレコードを収集→データレイクに保存→主キーをもとにデータウェアハウス上のレコードを更新データ収集ではインデックスを使用
インデックスの有効な列に対して絞り込み条件を指定
これにより低負荷で高速に対象のレコードを特定できます
上記の方法でも間に合わない場合の収集方法
ーSQLを並列実行各収集ワーカーがSELECT文のWHERE句を指定し、
テーブルを分担して収集ただし、この方法により処理が速くなるには前提条件がある
つまり、並列処理により
ストレージの負荷が分散されることが条件です。
全てのデータが単一のストレージに格納されていると、
処理は速くなりません。むしろ遅くなります。
SQLによる収集はデータベースへの負荷が大きいので、
レプリカを用意するデータ収集に伴うデータベースの負荷とは？
キャッシュ汚染=キャッシュ上のデータがデータ収集のSQLにより必要のないデータに書き換わること
長時間クエリ＝データベースのリソースを大量に消費するクエリ
一時ファイルによるディスク圧迫＝
データを並び替える処理をする際、並び替える対象のデータのサイズが大きいと、そのために必要なデータがメモリに収まりきらない→一時ファイルを生成
この一時ファイルが大きすぎる→ディスクの空き容量を圧迫→システムが不安定化
では、これらの負荷を回避するための方法は？
ーデータベースを
オンラインリクエスト処理用とデータ取得用
の2つ用意しますデータ取得用データベースとして、
レプリケーションという機能で
レプリカを作ります
でもレプリカを用意できない場合の方法は？
ーデータをファイルにエクスポートレプリカの準備は費用や手間がかかる…
→代替手段として
データをファイルにエクスポートして
ファイル経由でデータを収集実現の手順の骨子
ファイルシステムの準備
収集処理の順序をコントロールするための
ワークフローエンジンの準備
デメリット
エクスポートするファイルのサイズが
テーブルのサイズより大きくなるデータベースへの負荷がある程度存在
さらなる代替案としては、
ファイルシステムをダンプファイルにすることも一択です。
更新ログ経由のデータベース収集
どういうこと？
データに対する操作が記録された「更新ログ」を収集
→更新ログを復元用データベースに取り込み
→復元用データベースがデータベースと同一の中身
になったら、収集処理でデータレイクにデータを収集例：
メリットは？
収集するデータ量が少なくなる
→データ収集速度が向上
→必要なネットワーク帯域が小さくなる
→データベースへの負荷が比較的小さい
デメリットは？
大抵、専用の製品の導入が必要
収集の仕組みが複雑化
収集対象のテーブルの列や行の選択ができない
更新ログ経由の収集をしたいなら、
CDCツールがおすすめほぼリアルタイムにデータベースのデータを収集できます。
デメリット
仕組みが複雑化
取得対象のデータベースが更新・削除される場合、データレイクや分析用データベースに対する負荷が高い
処理が停止した際に再実行が困難
ETL製品を選ぶポイント
ETL製品の分類方法
提供形態の観点
オープンソース
有償製品
クラウド
行える加工の複雑さの観点
具体例：異なるデータソース同士のデータの結合ができるか？
ETL製品の選定時の注目するとよい点
利用予定のコネクタの機能
具体例：MySQLコネクタ
WHERE句による条件式を指定した収集ができるか？
前回との差分のみ収集できるか？
ソースコードレベルでデバッグしやすいか？
収集時のエラーは、データの内容に起因しがちなため
(例：データがない場合はnull値が入っていると思っていたら
空文字だった)
→コネクタのソースコードを読み、
データの抽出・加工過程を確認
→エラーの原因をより早く特定できる
プログラミングレスの製品か？
ただし、開発に響くデメリットはあります。
すなわち、
プログラミングで開発するタイプに比べて
処理の変更点が分かりづらい点です。
データレイク
データは加工する際、加工に失敗して損失するリスクがあります。
→データを蓄積するなら、加工しないで置いておく方式が良いです
ただし例外はあります。
データ基盤に機密情報を蓄積できない場合です。
→匿名化などの加工をしてから、
データレイクに蓄積します
製品の選定時の着眼点
データを損失しないための冗長性はどれほどか？
容量を拡張できるか？
収集したデータをファイルで蓄積するケース
データベースに格納が難しいバイナリファイル
例：音声、画像、動画クラウドなら、オブジェクトストレージ
を使うことになります無限に近いデータ容量
堅牢性が高め
オンプレミスなら、
分散ストレージを使うことになります
収集したデータがCSV, JSONデータのケース
オブジェクトストレージに蓄積も可能ですが、
データウェアハウスで利用する分析用DBに
直接入れるのも可能です
データレイクはオンプレミスよりクラウドがおすすめ
従量課金制だから費用がニーズ相応で済みやすい
堅牢性がより高い
運用人件費がより安い
データウェアハウス
データベース製品の種類
オペレーショナルデータベース
分析用データベース
それぞれの特徴は以下の通り
分析用データベースへの命令方法
全件を削除ーDROP (DELETEではない)
テーブルの一部を更新ー更新後の内容を持つ新しいテーブルを用意し、置換 (UPDATE, DELETEではない)
データの挿入ー複数件まとめてロード
(一件ずつINSERTしない)
ワークフローエンジン
ワークフローとは、
一連のデータの流れ
すなわち、
データ収集→データウェアハウス生成→データマート作成
→データ活用 の流れです。ワークフローエンジンとは、
ワークフローを管理する製品。
主な管理内容は、起動時刻と起動順序の制御。
例：
ワークフローエンジンは
複数台のサーバにまたがって冗長構成をとれます
→一部の処理が異常終了しても、
異常終了した処理を途中からやり直せます(再実行/re-run)
以上です。
ファイルやAPIからのデータ収集の方法もいつか
まとめたいと思います。
拙文をお読みいただきありがとうございました。
気軽にクリエイターの支援と、記事のオススメができます！