**ビッグデータの道具を選ぶ前に、必要な結果、期限、正しさのルールから考えます。**データが大きいだけで分散処理フレームワークが必要になるわけではありません。
毎朝、前日の加盟店別売上が必要だとします。これは、決済を承認する前に不審な支払いを検出する処理とは異なります。どちらも大量のレコードを扱い得ますが、一方は定期処理を許容し、もう一方は素早い判断が必要です。
既存データ量、新規データの到着速度、必要なフィールド、保存期間を明確にします。売上レポートでは、返金を元の売上日と返金日のどちらに反映するか合意します。このルールがなければ、高速なパイプラインでも合計は誤ります。
正本と、遅れて届くレコードや修正の扱いも定めます。それによって過去の結果を確定できるか、後から改訂すべきかが決まります。
ファイル読み取り、DBクエリ、計算、ネットワーク転送、結果書き込みのどこに時間と資源を使うか測ります。無関係なレコードを早期に除き、必要な列だけ読みます。
すべてをメモリへ載せず、上限のある塊で処理します。1ワーカーで期限と費用を満たせるなら、それが最も運用しやすいかもしれません。マシン追加には調整と転送のコストがあるため、確認した限界を解くために使います。
| 要件 | 出発点 | 理由と責任 |
|---|---|---|
| 毎朝の完全なレポート | 定期バッチ | 有限の入力は照合と再実行がしやすい。期限までに終える必要がある |
| 日中も更新するダッシュボード | 増分バッチまたはストリーミング | 新規データを頻繁に処理し、過去の合計への修正反映を定義する |
| 各イベント直後の判断 | ストリーミング | 遅延を減らしつつ重複、遅着、復旧を扱う |
ストリーミングは到着データを継続的に処理することで、すべてが1回だけ順番どおりに届くという意味ではありません。日次レポートなら、本当により新しい結果が必要でなければバッチから始めます。
ワーカーが売上合計を書いた後、進捗記録の前に停止したとします。再起動時に同じレコードを処理し、金額を再加算すると売上が過大になります。
安定したレコードIDと安全に繰り返せる書き込みを使うか、対応していれば結果と進捗をトランザクションでまとめます。チェックポイントは完了した進捗です。結果の安全な保存より先に記録すると、障害後に仕事を飛ばす恐れがあります。後に記録するなら、その隙間を安全に再処理する必要があります。
復旧動作は設計の一部であり、最初の失敗後の後片付けではありません。
1ワーカーで足りないなら、独立実行できる部分へ入力を分割します。実際の偏りを確認します。極端に大きい加盟店がいると、他が終わっても1ワーカーだけ働き続けることがあります。
集約や結合には、シャッフルと呼ぶワーカー間のレコード移動が必要な場合があります。可能なら移動前にデータを減らし、出力先が合計負荷を受けられるか確認します。Sparkには関連技術がありますが、適用はクエリとバージョンによります。性能調整ガイドを参照してください。
保存形式もアクセス方法に合わせます。Parquetなどの列指向ファイルは特定列の分析走査に適し、索引付きDBは個々の業務レコード取得に向くことがあります。ファイルサイズだけでなく実測したアクセス要件で選びます。
信頼できる小さなデータセットと比較し、件数と業務合計を確認します。重複イベント、返金、遅着、出力保存と進捗記録の間の停止を含めます。
次に現実的な量と偏りで、実行時間、ピークメモリ、滞留、費用を測ります。売上レポートの成功は、正しく再現可能な合計が合意した期限までに届くことです。その条件を満たし、欠落や二重計上なしに復旧できる最も単純なパイプラインを選びます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する