根本原因こそが最終到達地点です。これらは、因果関係の起点のイベント（いわば最初のドミノ）であり、ほとんどの問題がこれで説明できます。データ問題の根本原因が発生しないなら、近接原因も発生しません。根本原因は近接原因すべての直接原因です。
もちろん、根本原因は常に明確ではなく、相関関係も常に厳密ではありません。自分の答えに自信が持てない場合に、確率論的な方法で真の自信スコアを確認する方法は、次のような思考実験をしてみることです。上司から次のように言われたと想像します。「チームは君の仮説に従って動く。実稼働前のチェックは誰もしない。すべては君が仕切る。間違いがあれば、すべて君の責任となる」信頼スコアを0～100で表すとどのくらいですか？70未満の場合は、調査を続けてください。
一般的な根本原因データの問題には、次のようなものがあります。
1. ユーザーエラー: まず、ユーザーエラーから始めましょう。こうしたエラーは一般的なものだからです。おそらく誰かが間違ったスキーマや間違った値を入力したために、パイプラインがデータを読み取らなかったか、あるいは処理は正しくても値が誤っていることを意味し、タスクが失敗している可能性があります。
2. 不適切にラベル付けされたデータ： テーブル上で行が移動し、正しいはずのラベルが間違った列に適用されることがあります。
3. データ・パートナーが配信に失敗する： これも非常に一般的なことです。完全なシステムを構築することはできますが、見えないものを制御することはできません。データの問題がソースデータにある場合、完全に良いパイプラインでも誤動作を引き起こすことになります。
4. コードにバグがある： 新しいバージョンのパイプラインがある場合によくあることです。これは、GitやGitLabなどのバージョン管理ソフトウェアを使用するとすぐに理解できます。実働コードを以前のバージョンと比較し、その以前のバージョンでテストを実行します。
5. OCRデータエラー： 光学スキャナーがデータを間違って読み取り、異常な値（または値の欠落）が発生します。
6. 旧式のデータの問題： データ・セットが古くなり、有効期限が切れています。
7. 重複データの問題： ベンダーがデータを提供できないことがよくあるため、パイプラインが先週のデータに対して処理を実行しました。
8. 権限の問題: システムにデータを取得したり、トランスフォーメーションを実行したりするための権限が不足していたため、パイプラインが失敗しました。
9. インフラストラクチャー・エラー： おそらく、使用可能なメモリーまたはAPI呼び出し制限の最大限度に達したか、Apache Sparkクラスターが実行されなかったか、あるいはデータウェアハウスの速度が異常に遅いため、データなしで処理の実行が続いています。
10. スケジュールの変更： 誰か（または何か）のためにスケジュールが変更された結果、パイプラインが予定通りに実行されない、または実行自体がされないことがあります。
11. 偏りのあるデータ・セット: 選別が非常に困難です。これを確定する方法は、いくつかのテストを実行して、データが同様の真のデータ・セットと比較して異常であるかどうかを確認するか、そのデータがどのように収集または生成されたかを把握すること以外にはありません。
12. オーケストレーターの障害：パイプライン・スケジューラーがジョブのスケジュールまたは実行に失敗しました。
13. マシンの中のゴースト（データ・エクス・マキナ）： 本当に知ることができません。その事実を認めるのは困難ですが、いくつかのことについては真実です。最善の策は、文書化して、より多くのデータを収集し、相関関係を導き出すことができるように次の段階に備えることです。
そしてもちろん、根本原因が完全に明確ではないという現実もあります。多くの事柄は相関関係にあり、おそらく相互に依存していますが、明確な答えは存在しません。また、変更を加えた後、データの問題は解決しましたが、その理由はわかりません。
そのような場合は、他の場合と同様に、ログに仮説をメモします。いつでもログに戻り、履歴データのテストを続け、そして新しい問題や説明可能な原因に注意してください。
