ETLの理解

第4章 パイプラインの問題とトラブルシューティング パイプラインの問題とトラブルシューティング

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

これまで述べてきたように、ETLの第一の目的は、ビジネス価値を提供することである。しかし、この目標は、リカバリに時間がかかることを特徴とする脆弱なシステムによって阻害されることが多く、イノベーションと価値創造よりもトラブルシューティングにリソースが過剰に配分されることになる。

従って、適切に設計されたETLパイプラインは、堅牢性と保守性を備え、高いデータ品質、効率的なエラー処理、効果的な問題の特定といった重要な特性を具現化しなければならない。エンジニアリングの巧拙にかかわらず、システムには失敗がつきものである！

失敗を想定した計画とは、パイプラインを設計することを意味する：

• 保守や拡張が容易である。つまり、エラーの迅速なトリアージや新機能の開発が可能である。

• エラーをリアルタイムで処理し、失敗から回復するための自動化された方法を提供する。

• 学習と経験に基づく改善の枠組みを取り入れる。

このアプローチは保守性を確保し、ETLシステムのもう一つの重要な側面であるスケーラビリティとシームレスに結びつける。

ETLパイプラインがレジリエンスと進化するビジネスニーズへの適応性の両方を確保するための課題と戦略を取り上げる。

メンテナンス性

問題とトラブルシューティングの章では、主にメンテナンス性--文字通り、すでに作ったものをメンテナンスする能力--について取り上げている。

エンジニアとして、私たちは時にソリューションだけを目標にすることがある。私たちは、最小実行可能プロダクトと80/20原則を大々的に提唱しているが、ビジネス価値を推進する本番システムで協業する場合、それらのシステムを維持し、拡張 する能力（第5章のトピック）は必須である。パイプラインを維持できないことは、チームに直接的・間接的な犠牲を強いることになる。前者の方が明らかに重要だが、後者の方が戦艦を沈める可能性が高い：

直接経費

高価なものが欲しければ、大抵の場合、お金を出し、それについてきちんと説明しなければならない。金利がゼロに近く、ベンチャーキャピタルの資金がリオ・グランデ川のように流れていた頃、多くの人がクラウド・コンピューティング、ストレージ、DataOpsといったもののコストを見落としていた。効率性はパターン設計から始まる。悪いパターンは、組織全体の効率が低いことを意味する。

保守性の低いETLシステムは、非効率な演算子や長い実行時間という形で、高い直接コストを発生させる。これは、選択したプロバイダーから高額な請求が発生するだけでなく、ジョブが遅くなり、チームからのデータが遅れる結果となる。

間接費

間接コストは直接コストをはるかに上回る可能性がある。故障が多く、常にトリアージが必要なシステムを作成することは、リソースの配分にとって悲惨なことだ。チームの時間とエネルギーは、最も貴重な商品である。

勤務時間の大半をDAGの修正、アラート対応、消火活動に費やすことは、忙しそうに見えるかもしれないが、一般的には持続不可能で非生産的である。勝利するチームは、機能開発とデータの民主化に集中できる効率的なシステムを構築している。非効率的なシステムは、火災訓練や眠れない夜を増やし、重要なものの構築に費やす時間を減らすことになる。