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