この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
米国時間2021年07月21日〜22日の計2日間、オンラインで開催された「Subsurface LIVE Summer 2021」では、主催となるDremio社のサービスやクラウドデータレイクに関する各種サービスやプロダクトのセッションが展開されていました。
当エントリでは、その中から「Root Cause Analysis for Your Data Lake」(データレイクにおける「根本原因分析」)というセッションについてレポートします。
目次
セッション概要
セッション概要は以下の通り。
＜セッションタイトル＞
Root Cause Analysis for Your Data Lake
(データレイクにおける「根本原因分析」)
Root Cause Analysis for Your Data Lake
(データレイクにおける「根本原因分析」)
＜登壇者＞
Barr Moses - Co-founder and CEO @ Monte Carlo
Lior Gavish - CTO and Co-Founder @ Monte Carlo
＜発表内容＞
From null values and duplicate rows, to modeling errors and schema changes, data pipelines can break for millions of reasons. And once “data downtime” happens, we need to know what caused it so that we can fix it – fast.
It’s one thing to talk about root cause analysis in concept, but what does it look like in practice? In this talk, we pull back the curtain on how some of the best data teams are tackling data downtime across their data lake by walking through how to root cause a real-life incident across three main channels: your code, your operational environment, and the data itself.
(NULL値や重複した行、モデリング・エラーやスキーマの変更など、データ・パイプラインには様々な原因があります。そして、「データダウンタイム」が発生すると、その原因を知り、迅速に修正する必要があります。
根本原因の分析についてコンセプトを語ることは一つのことですが、それは実際にはどのようなものでしょうか？この講演では、コード、運用環境、そしてデータそのものという3つの主要なチャネルで実際のインシデントを根本的に解決する方法を説明することで、最高のデータチームがどのようにしてデータレイク全体のデータダウンタイムに取り組んでいるのかを明らかにします。)
セッションレポート
ここからはセッションレポートとなります。それぞれのトピックに関して要点をまとめる形で紹介。
「原因要因分析」が必要となる経緯
- 誰もがデータを頼りにしている
- 職種、何を欲しているのか、SQLやプログラムを扱えるレベル等
- 皆がデータが欲しがっているが、その内容は様々。
- データシステムの分散化・複雑化
- データのダウンタイムは過去最高(最悪？)になっている、これは深刻な問題
- データダウンタイム - データが部分的であったり、誤っていたり、欠落していたり、その他不正解であったりする期間のことを指す。
- データダウンタイムの詳細については下記エントリが詳しい。
- The Rise of Data Downtime. Has your CEO said the numbers in your… | by Barr Moses | Towards Data Science
- そこで「データレイクの根本原因分析」が必要になった
DevOps /SREにおける根本原因分析
-
「根本要因分析」(Root cause analysis)そのものについては下記を参照。
- 根本原因分析を成功させるもの：「壊れた原因を特定すること」。
- 理論的には(この原因は)幾つかのSQLを実行するのと同じくらい簡単にも見えるが実際はそうではない
- パイプライン全体に渡って分かりづらい形で現れ、複数の(場合によっては数百の規模の)テーブルに影響を与える可能性がある
- データの問題は以下の要素におけるイベントに起因する可能性が高い。これらの問題を素早く解決するには、これら3つのソースがそれぞれどのようにして壊れるかどうかを考慮した「全体的なアプローチ」が必要。
- ジョブ、パイプライン、またはシステムに送られるデータの予期しない変更
- データを変換するロジック（ETL、SQL、Sparkジョブなど）の変更
- ランタイムエラー、権限の問題、インフラストラクチャの障害、スケジュールの変更などの運用上の問題
リネージを見る
- 何が壊れているかを把握するには、問題を示しているシステムの「最も上流のノード」から確認していく必要がある → 「データリネージ」機能による対応
- 「リネージ」対応のポイント
- データの問題をトラブルシューティングする"全ての"メンバーが最新の(データ)リネージにアクセス出来ることを確認
- リネージには以下のようなものも含む
- BIレポート
- 機械学習モデル
- リバースETLシンク等のETL製品
- (可能であれば)フィールドレベルの要素
コードを見る
- 問題が発生した場合、テーブルに対して処理を行っているETLプロセスがどのように生成され、どのように影響を与えたかを理解する必要がある
- 直近、テーブルを更新したコードはどれ？そしていつ実行された？
- フィールド生成の際に計算が行われていた場合、その計算ロジックは適切か？
- ロジックの変更はあったか？その変更は問題発生に影響はあるか？
- 直近アドホックな処理はなされていたか？リカバリ等は行われていたか？
- 「コードを見る」対応のポイント
- データに関する問題について対応する"全て"の人が、そのロジック(SQLやPythonに至るまで)を素早くトレース出来ること
- 埋め戻しやアドホック更新を考慮に入れるために、「テーブルが最後に更新されたのはいつか」を把握できるようにしておく必要がある
データを見る
- 根本原因が特定出来ない場合、テーブル内のデータを調べて「何が原因となっている可能性があるか」をヒントを探す
- 有望となるアプローチ：「異常なレコードを持つテーブル内の他のフィールドが、データの異常が発生している場所に関する手掛かりをどのように提供するか」を調査
- 「データを見る」対応のポイント
- データの問題について対応する"全て"の人が、データを手軽にスライス及びダイシングして、問題が様々なセグメントや期間、及び他のデータの切り口とどのように関連しているかを確認出来るようにしておく
- データやスキーマに対する変更を可視化しておくことはとても大事
運用環境を見る
- 「データの問題」に関する多くの原因はETL/ELTジョブを実行する運用環境にあったりする
- ETLエンジンからのログとエラートレース情報を確認することで、下記質問の幾つかに答えることが出来る
- 関連するジョブにエラーはあったか
- ジョブ開始時間に遅れは発生していなかったか
- 実行時間の長いクエリやパフォーマンスの悪いジョブが原因で遅延が発生していないか
- 権限やネットワーク、インフラの問題や変更は直近無かったか
- ジョブスケジュールに変更は無かったか
- 「運用環境を見る」対応のポイント
- データの問題について対応する"全て"の人が、ETLジョブの実行方法を理解し、関連するログとスケジューリング構成にアクセス出来るようにしておくこと
- インフラ、セキュリティ、ネットワークの理解も役立つ
仲間を活用する
- 出来ることは全てやった。でもまだ問題が解決出来ていない...
- 次にやることは「データチームからのガイドを得る」こと：Slackに質問をぶつける前に、以下のことを自問する
- データセットで過去にどのような(同様の)問題が発生していたか？チームはこれらの問題を対応する上で何をしたか？
- 問題が発生しているデータセットの所有者は誰？詳細については誰に連絡すべき？
- 問題が発生しているデータセットの所有者は誰？詳細については誰に連絡すべき？
- 「仲間を活用する」対応のポイント
- データの問題について対応する"全て"の人が、データセットの所有権と使用法に関するメタデータにアクセス出来るようにしておき、誰に尋ねれば良いかを把握しておく
- 役立つドキュメントを含む「データインシデントの履歴」も有用
まとめ
という訳で、クラウドデータレイクイベント『Subsurface LIVE Summer 2021』のセッション「Root Cause Analysis for Your Data Lake」(データレイクにおける「根本原因分析」)のレポートでした。
今回紹介した内容は、データレイク及びデータ分析環境を運用・活用していく上で非常に大事なポイントであると思います。利用者が「便利だな」と思えるような機能や環境を提供出来るよう、我々としても頑張っていきたいと思います。
14
