ETL における自動化の度合いが多すぎる

ETL (抽出、変換、ロード) パイプラインの自動化は諸刃の剣です。一方で、退屈で反復的なタスクから解放され、ワー​​クフローが加速され、人的エラーの可能性が減ります。しかし、その一方で、自動化が多すぎるということもあります。つまり、生活をシンプルにするはずだったものが、結果的に生活をより複雑にし、硬直させ、さらには管理不能なものにしてしまうということです。

では、どこで線を引くのでしょうか?効果的な自動化とオーバーエンジニアリングの間で適切なバランスを取るにはどうすればよいでしょうか?楽しく、共感できる方法でこれを探ってみましょう。

自動化の黄金の約束
場面を設定しましょう。あなたは、さまざまなソースから生データが大量に流入するデータ プロジェクトに取り組んでいます。アプリケーションからのログ、マーケティングからの CSV、サードパーティ ベンダーからの JSON ファイル – 混沌としていますよね? ETL パイプラインが役に立ちます。生データを抽出し、使用可能な形式に変換して、アナリストが問題なくクエリできるウェアハウスにロードします。

自動化は自然にあなたの親友になります:

Airflow または他のオーケストレーターを使用してジョブをスケジュールします。
一般的な変換には事前に構築されたライブラリを使用します。
パイプラインを監視してエラーにフラグを立てます。
Glue または Databricks ジョブをオンデマンドでスピンアップします。

しかし、この友人が歓迎を超えて滞在したらどうなるでしょうか?

過剰自動化: シンプルさが複雑になるとき

1. ビジネス理解のない自動化

チームが手動介入を恐れているため、考えられるすべてのエッジケースを自動化しようとしていると想像してください。列の欠落、スキーマの進化、パーティションの失敗、奇妙なファイル形式など、考えられるすべてのデータ変換を処理するスクリプトを作成します。

すぐに、パイプラインは Rube Goldberg マシンに似てきます。ジョブ、スクリプト、再試行、エラー ハンドラーが複雑に絡み合った、誰も完全には理解できないマシンです。なぜ？自動化がビジネスの優先順位や実際のニーズと一致していなかったためです。

結果:

何かが壊れた場合、トラブルシューティングは悪夢になります。
新入社員はあなたの台本をぼんやりと見つめ、「なぜまたそれが必要だったのでしょうか?」と尋ねます
要件の小さな調整は、大きな見直しにつながります。

教訓: すべての問題に自動化が必要なわけではありません。自動化することが重要なことと、手動で処理する方が簡単なことは何かを理解します。

1. ツールとフレームワークの過剰使用

最新のデータ エコシステムでは、ETL ワークフローの自動化を「支援」するツールが不足することはありません。

オーケストレーション: Apache Airflow、Prefect、Dagster。
変換: dbt、Glue、Spark、Talend。
データ検証: 大きな期待、期待

ある時点で、誰かが「なぜすべてを使用しないのですか?」と言います

突然、Airflow によって dbt ジョブがトリガーされ、Spark ジョブが呼び出され、検証のために Great Expectations に出力が記録されます。素晴らしいですね。ただし、次のような非常に多くのツールを階層化しています。

問題をデバッグするには、5 つのダッシュボード間を移動する必要があります。
各ツールには癖があるため、デプロイメント パイプラインは脆弱になります。
メンテナンスは、最初にパイプラインを構築するよりも時間がかかります。

教訓: 実行可能な最小限のスタックを使用します。ツールが増えても自動化が向上するわけではありません。

1. 自動化すべきではないものを自動化する

何かを自動化できるからといって、自動化する必要があるわけではありません。例を見てみましょう:

ケース 1: ETL ジョブ内のスキーマの不一致を自動的に処理する。素晴らしいことのように聞こえますが、データ スキーマが予期せず変更された場合、本当にパイプラインを黙って続行させたいですか?

ケース 2: 人間の介入なしに「問題のある」データ行を自動的に削除します。確かに、パイプラインは成功しますが、レポートには欠落したデータがあり、何が問題だったのか痕跡はありません。

ETL の一部の側面、特に判断や監視が必要な側面は、人間に任せたほうがよいでしょう。

レッスン: 明確で決定的なルールがある場合は自動化します。灰色の部分は人間の介入に任せてください。

過剰自動化による実際の恐怖の物語

1. 実行を停止できなかったパイプライン

あるチームは、データ処理パイプラインが「決して失敗しない」ことを保証するために、再試行メカニズムを自動化しました。机上では、それは理にかなっています。何か問題が発生した場合は、問題が解決するまで再試行してください。

彼らが予想していなかった事: アップストリーム ファイルの不良により、パイプラインが無限再試行ループに入り、クラウド リソースが消費され、多額の請求が発生しました。ああ！

1. パラメータ化による死亡

ETL パイプラインを「汎用」にするために、データ チームは 100 個のパラメーターを導入しました。新しいチームメンバーは、有意義な作業を行うよりも、どのパラメータを調整するかを理解することに多くの時間を費やしました。

皮肉なことに、過剰にパラメータ化されたパイプラインは、より単純なハードコードされたバージョンに比べて柔軟性が劣っていました。

1. アラートが暴走しました

チームは監視を自動化し、大小を問わずあらゆる ETL 障害についてアラートを送信しました。 1 か月以内に、アラートはバックグラウンドノイズになりました。重大なエラーが発生した時には、すでにノイズを無視していたため、誰も気づきませんでした。

適切なバランスを保つ: 健全な自動化の原則
では、ETL 自動化の行き過ぎを防ぐにはどうすればよいでしょうか?次の原則に従ってください:

1. シンプルから始めて徐々に構築していきます

自動化する前に、次のことを自問してください。

このプロセスは自動化を正当化できるほど頻繁に行われていますか?
失敗のコストと手動介入のコストはどれくらいですか?

最小限の自動化から始めます。問題点を観察し、その部分だけを自動化します。

1. 失敗と手動による監視を受け入れる

パイプラインを完璧にしようとするのではなく、障害が表面化して分析できるようにしてください。何が問題だったかについて明確な洞察を提供するダッシュボードとログを構築します。一か八かのシナリオまたはあいまいなシナリオには手動介入を導入します。

1. KISS 原則に従います (シンプルにしてください、愚かです)

ETL パイプラインは次のことを簡単に行うことができます。

理解しました。
デバッグ。
延長します。

さらに自動化を追加すると、これらのいずれかが複雑になる場合は、その必要性を再考してください。

1. ビジネス ニーズに合わせて自動化を調整する

ETL 自動化を常にビジネス目標に結び付けます:

アナリストやエンジニアの時間は節約されますか?
データの品質と信頼性は向上しますか?
運用コストは削減されますか?

答えが「いいえ」の場合は、過剰自動化している可能性があります。

結論: 自動化は目的ではなくツールとして
ETL 自動化は、データ チームに負担をかけるのではなく、データ チームに権限を与えることを目的としています。それは手段であり、最終的な目標ではありません。自動化が行き過ぎると、ワークフローに複雑さ、硬直性、脆弱性が生じます。

重要なポイント: 意図的に自動化する。あらゆる意思決定の背後にある理由を理解し、プロセスをシンプルに保ち、人間による監視の余地を残してください。場合によっては、過剰に設計された自動化による混乱よりも、少しの手作業の方がはるかに優れていることがあります。

それで、次に「これも自動化してみよう」と思ったら、立ち止まって自問してください。「これは必要ですか？それとも Rube Goldberg マシンを構築していますか?

」

シンプルにしてください。管理しやすい状態にしておきましょう。人間味を保ってください。

以上がETL における自動化の度合いが多すぎるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。