データエンジニアリングの設計パターン

第4章. べき等デザインパターン

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

データエンジニアリングの各活動は、最終的にエラーにつながる。ありがたいことに、正しく実装されたエラー管理デザインパターンは、エラーのほとんどに対処する。そう、すべてではなく、ほとんどである。しかし、なぜなのか？

一時的な故障からの自動リカバリーの例を見てみよう。エンジニアリングの観点からは、再試行回数を設定する以外に何もすることがないので、これは素晴らしい機能だ。しかし、データの観点からは、この素晴らしい機能は一貫性という重大な課題をもたらす。再試行されたタスクor演算子は、ターゲット・データストアで既に成功した書き込み演算子を再生する可能性があり、最良のシナリオでは重複につながる。重複はコンシューマ側で削除できるので、重複は最善のシナリオである。しかし、逆の場合を想像してみよう。再試行されたアイテムは重複を発生させ、それが同じデータであることさえわからないため、削除することができない！悪夢とデータセットの悪評を歓迎しよう。

うまくいけば、この章で紹介する冪等性デザインパターンを使って、これらの問題を軽減できるかもしれない。しかし、それらがデータエンジニアリングにどのように適用されるかを知る前に、idempotencyの定義を思い出してみよう。これを説明するのに最適な例は、absolute 関数だ。入力引数が負の数でも正の数を返す単純なメソッドだ。なぜべき等なのか？関数を何度呼び出しても、常に同じ結果が得られるからだ。つまり、absolute(-1) == absolute(absolute(absolute(-1))) 。

データエンジニアリングの文脈における冪等性も同じ目的を持っている。データ処理ジョブを何度実行しても、重複のない、あるいは重複が明確に識別できる一貫した出力が得られるようにする方法だ。ところで、重複を避けることは常に可能というわけではない。トランザクションプロデューサをサポートしていないメッセージングシステムにデータを生成した場合、再試行でも重複エントリが生成される可能性がある。しかし、idempotent処理のおかげで、コンシューマはそのようなレコードを識別することができる。

この章では、データ工学における様々な冪等性のアプローチについて学ぶ。データセットを完全に上書きできる場合、あるいはサブセットしか利用できない場合の対処法を学ぶ。また、データベースを活用してidempotency戦略を実装する方法についても学ぶ。最後に、データセットは不変性を保ちつつも冪等性を維持するデザインパターンを紹介する。

そして、パターンを見る前に最後にもうひとつ：2018年、最先端の論文「Functional Data Engineering」でidempotencyを流行らせたMaxime Beauchemin（ ）をここに特殊化して残しておきたい：バッチデータ処理のためのモダンなパラダイム」である。

上書き

第一のべき乗ファミリーは、データ削除のシナリオをカバーしている。新しいデータを書き込む前に既存のデータを削除するのは、最も簡単なアプローチである。しかし、大きなデータセットでこれを実行すると、計算量が多くなることがある。そのため、削除を処理するために、データまたはメタデータベースのソリューションを使うことができる。

パターン高速メタデータクリーナー

メタデータ 、データファイルと対話する必要がないため、 ...