データ・オブザーバビリティーとは

データのオブザーバビリティーとは、データの健全性とデータ エコシステム全体のその状態を真に理解することです。 これには、問題を説明するだけの従来の監視を超えたさまざまなアクティビティが含まれます。 データの可観測性は、データの問題をほとんどリアルタイムに特定、トラブルシューティングおよび解決するのに役立ちます。

データの信頼性を左右する中心的な課題である「不適切なデータ」への対処には、データ・オブザーバビリティツールの活用が不可欠です。これらのツールは、自動モニタリング、アラートの振り分け、トラッキング、比較、根本原因の分析、ロギング、データ・リネージュ、サービスレベル合意（SLA）の追跡を可能にし、これらが連携することで、データの信頼性を含むエンドツーエンドのデータ品質の把握を支援します。

データ・オブザーバビリティー・ソリューションの実装は、データを使用して洞察を得たり、機械学習モデルを開発したり、イノベーションを推進したりする現代のデータ チームにとって特に重要です。 データが潜在的な負債ではなく、貴重な資産であり続けることを保証する。

データ・オブザーバビリティーは、エンドツーエンドのデータ ライフサイクル全体を通じて一貫して注入される必要があります。 そうすることで、関係するすべてのデータ管理活動が標準化され、チーム全体で一元化されるため、組織全体の問題や影響を明確かつ途切れることなく把握することができる。

データ・オブザーバビリティーは、データ運用（DataOps）の実践を可能にするデータ品質ムーブメントの自然な進化です。

単純明快ですが、ほとんどの組織は自社のデータは信頼できないと考えています。

• 82%がデータ品質への懸念がデータ統合プロジェクトの障壁になっていると回答¹
• 経営幹部の80%は自社のデータを信頼していません²

この不良データの影響を過小評価することはできません。2022年5月、Unity Softwareは大規模顧客から不良データを取り込んでいたことがわかり、これにより会社の株価が30%急落し³、最終的に1億1,000万ドルの収益損失が発生しました⁴。

従来、手遅れになるまで不良データを特定することは困難でした。 アプリケーションがダウンしてすぐに何千人ものユーザーに影響を与える場合とは異なり、企業は長期間にわたって、気付かないうちに不良データを操作する可能性があります。 例えば、Salesforceのダッシュボードが読み込まれていない場合、営業チームはすぐに気づくだろうが、ダッシュボードに不正なデータが表示されていることを把握するのにどれだけ時間がかかるかわからない。

データの可観測性は、不正なデータの侵入に対する最善の防御策です。 データ パイプラインを監視して、データが完全、正確、タイムリーに配信されるようにします。これにより、データ チームはデータのダウンタイムを防ぎ、データ SLA を遵守し、表示されるデータに対する企業の信頼を維持できます。

最新のデータ システムはさまざまな機能を提供し、ユーザーがさまざまな方法でデータを保存したりクエリしたりできるようにします。 もちろん、追加する機能が増えるほど、システムが正しく動作することを確認することはより複雑になります。 この合併症には次のようなものがあります。

これまでのデータ基盤は、少量のデータ、主に限られた社内ソースからの業務データを扱うことを前提に構築されており、データが大きく変化することは想定されていませんでした。現在では、多くのデータ製品が社内外のデータに依存しており、その収集量と速度の大きさから、予期せぬドリフトやスキーマ変更、変換の不整合、遅延などが発生することがあります。

外部データ・ソースから取り込むデータが増えるほど、多様な形式のデータを変換、構造化、集約して活用できる状態にする必要があります。さらに厄介なのは、データ形式が少しでも変わると、厳密にコード化されたロジックが新しいスキーマに対応できず、下流で連鎖的な障害を引き起こすことです。

複雑な取り込みパイプラインにより、このエンドツーエンドのプロセスを簡素化するツールの市場が生まれ、主に取り込みと抽出、変換、ロード (ETL)/抽出、ロード、変換 (ELT) プロセスが自動化されます。 これらを組み合わせることで、分析業界が「最新のデータ スタック」 (MDS) と呼ぶデータ プラットフォームが得られます。 MDS の目標は、エンドユーザー (通常はアナリスト) がデータを使用できるようになるまでの時間を短縮し、エンドユーザーがそのデータの活用をより迅速に開始できるようにすることです。 ただし、自動化が進むほど、データの配信方法を制御できなくなります。 これらの組織は、データが期待どおりに配信されることをより確実にできるように、カスタム データ パイプラインを構築する必要があります。

データ操作 (DataOps) は、企業が製品をより効率的に作成および保守できるように、アジャイルな配信パイプラインとフィードバック ループを可能にするワークフローです。 DataOps を使用すると、企業はプロトタイピングから製品導入まで、分析プロジェクトのすべての段階で同じツールと戦略を使用できます。

DataOpsサイクルは、DataOpsワークフロー内のデータ管理を改善するために必要な基本的なアクティビティの概要を示しています。 このサイクルは、検出、認識、反復という3つの異なる段階で構成されています。

このサイクルは検知から始めることが重要です。DataOpsの原則は、そもそもデータ品質を重視する姿勢に基づいているためです。

DataOps サイクルのこの最初の段階は検証に重点を置いています。 これらには、データ ウェアハウスの開始以来使用されてきたものと同じデータ品質チェックが含まれます。 彼らは、列スキーマと行レベルの検証を検討していました。 基本的には、すべてのデータセットがデータ・システムのビジネス・ルールに準拠していることを確認することになる。

検出段階に存在するこのデータ品質フレームワークは重要ですが、その性質上、反動的です。 データレイクやデータウェアハウスにすでに保存されている（そしておそらくすでに活用されている）データが、期待する形になっているかどうかを知ることができるのだ。

また、既知のビジネス・ルールに従ってデータセットを検証している点にも留意することが重要です。問題の原因を把握できなければ、エンジニアが従うべき新たなビジネス・ルールを策定することはできません。この認識が、ソース・データを起点にデータ・ライフサイクル全体と直結する、継続的なデータ・オブザーバビリティーを用いたアプローチへの需要を高めています。

認識は、DataOps フェーズの可視性に重点を置いた段階です。 ここでデータ ガバナンスに関する議論が登場し、メタデータ ファーストのアプローチが導入されます。 データエコシステム全体のパイプラインとデータセットのメタデータを一元化して標準化することで、チームは組織全体の問題を可視化できます。

メタデータの一元化は、組織がデータのエンドツーエンドの健全性を認識できるようにするために重要です。 これにより、データの問題を解決するためのより積極的なアプローチに移行できるようになります。 「ドメイン」に不正なデータが入っている場合は、データ システムの上流の特定の時点までエラーを追跡できます。 例えば、データ・エンジニアリング・チームAは、データ・エンジニアリング・チームBのパイプラインを見て、何が起こっているのかを理解し、問題を解決するために協力することができる。

その逆も同様です。 データ エンジニアリング チーム B は、問題を検出し、それがダウンストリームの依存関係にどのような影響を与えるかを追跡できます。 つまり、データ エンジニアリング チーム A は問題が発生することを認識し、それを封じ込めるために必要なあらゆる対策を講じることができます。

ここで、チームは「Data as Code（DAC）」の実践に注力します。このサイクルの段階では、プロセスに重点が置かれています。チームは、すべてのデータ開発に適用できる再現性と持続可能性のある標準を確立し、パイプラインの最終段階で常に信頼できるデータを得られるようにしています。

問題の検出、上流の根本原因の認識、反復のための効率的なプロセスによって、データ プラットフォーム全体の健全性の段階的な改善が可能になりました。

データ可観測性戦略を適切に実行すると、データの品質、意思決定、信頼性、組織全体のパフォーマンスの向上に貢献するさまざまなメリットが得られます。 例えば、次のようなユースケースです。

データ可観測性の 5 つの柱を組み合わせることで、データの品質と信頼性についての貴重な洞察が得られます。

「鮮度」とは、データの最新性と更新頻度を示すものです。データが一定期間更新されないと、重要なタイム・ギャップが生じ、データの「陳腐化」が発生します。データの鮮度に問題があると、データ・パイプラインの障害につながることがあります。

データのフィールドレベルの健全性の指標である分布は、データが許容範囲内にあるかどうかを指します。予想される分布からの逸脱は、データ品質の問題、エラー、または基礎となるデータ・ソースの変更を示している可能性があります。

ボリュームとは、さまざまなプロセスやパイプラインを通じて生成、取り込み、変換、移動されるデータの量を指します。また、データテーブルの完全性についても言及します。データ量が期待される閾値を満たしているかどうかは、重要な指標です。

「スキーマ」とは、データの構造を示すものです。スキーマを変更すると、データの破損が発生しやすくなります。データ・オブザーバビリティーは、データが一貫して整理され、異なるシステム間でも互換性を保ち、ライフサイクル全体を通じて整合性を維持できるよう支援します。

リネージュの目的は、「どこで?」という質問に答えることです。データが壊れたとき。 データをソースから最終位置まで調べて、何が変更されたか、変更された理由、途中でどのように変更されたかを含む変更を記録します。 リネージュは、ほとんどの場合、視覚的に表されます。

データ・オブザーバビリティーはデータ品質をサポートしますが、この2つはデータ管理の異なる側面です。

データ可観測性のプラクティスは、データセット内の品質の問題を指摘することはできますが、それ自体で良好なデータ品質を保証することはできません。 そのためには、データの問題を修正し、そもそもの発生を防ぐための努力が必要です。 一方、データ観測可能性イニシアチブを実施しなくても、組織が強力なデータ品質を持つことは可能である。

データ品質モニタリングは、データ セットの状態が運用アプリケーションや分析アプリケーションでの使用目的に十分であるかどうかを測定します。 その判断を行うために、精度、完全性、一貫性、有効性、信頼性、適時性などの品質のさまざまな側面に基づいてデータが検査されます。

データ・オブザーバビリティーとデータ・ガバナンスは、相互にサポートし合う補完的なプロセスです。

データ・ガバナンスは、組織のデータが利用可能で、一貫性があり、安全であること、およびデータが内部標準とポリシーに準拠して使用されていることを保証することを目的としています。ガバナンス・プログラムには、データ品質向上の取り組みが組み込まれているか、データ品質向上の取り組みと密接に結びついていることがよくあります。

強固なデータ・ガバナンス体制は、データ・オブザーバビリティーの価値を損なう要因となるデータのサイロ化、データ統合関する問題、およびデータ品質の低下を解消するのに役立ちます。

データの可観測性は、データの品質、可用性、系統の変化を監視することでガバナンス プログラムに役立ちます。

すべてのデータ観測性が同じように作成されるわけではありません。 達成できるコンテキストのレベルは、どのようなメタデータを収集して可視化できるかによって異なります。 これは、データ可観測性の階層として知られています。 各レベルは次のレベルの基礎となり、より細かい粒度の可観測性を達成できるようになります。

運用とデータセットの健全性を可視化することは、データ・オブザーバビリティー・フレームワークの健全な基盤です。

データセットの健全性の監視とは、データセット全体を監視することを指します。 データが固定された場所にある間、データの状態を認識できるようになります。これは「保存データ」と呼ばれます。

データセットの監視は、次のような質問に答えます。

• このデータセットは予定通りに到着しましたか?
• このデータセットは必要な頻度で更新されていますか?
• このデータセットで予想されるデータ量は利用できますか?

運用監視とは、パイプラインの状態を監視することです。 このタイプの監視により、データが変換され、パイプライン内を移動している間のデータの状態を把握できます。 このデータ状態は「移動中のデータ」と呼ばれます。

パイプライン監視は、次のような質問に答えます。

• パイプラインのパフォーマンスはデータセットの品質にどのような影響を与えますか?
• どのような条件で実行が成功したと見なされますか?
• 湖や倉庫に到達する前にデータセットを変換しているのはどのような操作ですか?

データセットとデータ パイプラインのモニタリングは通常、2 つの異なるアクティビティに分けられますが、可観測性の強固な基盤を実現するには、それらを結合しておくことが不可欠です。 これら 2 つの状態は高度に相互接続されており、互いに依存しています。 これら 2 つのアクティビティを別のツールまたはチームにサイロ化すると、データの健全性を高レベルで把握することがさらに困難になります。

列レベルのプロファイリングは、この階層の鍵です。 列レベルのプロファイリングは、そのための強固な基盤が構築されれば、行レベルだけでなく列レベルでも、組織の新しいビジネスルールを確立し、既存のビジネスルールを実施するために必要な洞察を与えてくれる。

このレベルの認識により、データ品質フレームワークを非常に実用的な方法で改善できます。

これにより、次のような質問に答えることができます。

• 列の予想される範囲はどれくらいですか?
• この列の予想されるスキーマは何ですか?
• このコラムはどのくらいユニークですか?

ここから、可観測性の最終レベルである行レベルの検証に進むことができます。 これにより、各行のデータ値が調べられ、それらが正確であることが検証されます。

このタイプのオブザーバビリティでは、次の点に注目します。

• 各行のデータ値は予期した形式になっていますか?
• データ値は予想どおりの長さですか?
• コンテキストを考慮すると、エンド ユーザーにとって役立つ十分な情報がここにありますか?

組織が行レベルの検証でトンネルビジョンを取得すると、木を見て森を見ることが難しくなります。 運用およびデータセットの監視から始まる可観測性フレームワークを構築することで、問題の根本原因とその下流への影響に焦点を当てながら、データの健全性に関する全体像のコンテキストを取得できます。

以下は、可観測性パイプラインを構築するために通常必要となる主な手順です。 このプロセスには、さまざまなツールやテクノロジーの統合、および組織内のさまざまなチームのコラボレーションが含まれます。

• 主要指標の定義:まず、追跡する必要のある重要な指標を特定します。 これには、データ品質指標、データ量、レイテンシー、エラー率、リソース使用率などが含まれます。 どの指標を選択するかは、特定のビジネスニーズとデータパイプラインの性質によって異なります。
  
  
• 適切なツールを選択する：次に、データの収集、保存、分析、アラートに必要なツールを選択する。 オープンソースを含め、選択するツールが既存のインフラと互換性があり、運用規模に対応できることを確認する。
  
  
• ライブラリを標準化する：チームが同じ言語を話し、問題についてオープンにコミュニケーションできるインフラを整備する。 これには、APIやデータ管理（データウェアハウスへの問い合わせ、データレイクからの読み書き、APIからのデータ取得など）やデータ品質に関する標準化されたライブラリが含まれる。
  
  
• データパイプラインのインストゥルメンテーション:インストルメンテーションには、データ収集ライブラリまたはエージェントをデータパイプラインに統合することが含まれます。 これにより、パイプラインのさまざまな段階から定義済みのメトリクスを収集できます。 目標は包括的な可視性を実現することなので、すべての重要な段階を確実に把握することが重要です。
  
  
• データ・ストレージ・ソリューションを設定する：収集したメトリクスは、データの増加に合わせて拡張できるデータベースまたは時系列プラットフォームに保存する必要があります。 選択するストレージ・ソリューションが、データの量と速度に対応できることを確認してください。
  
  
• データ分析ツールを実装します：これらのツールは、保存されたメトリクスから洞察を導き出すのに役立ちます。 より詳細な分析には、直感的な視覚化を提供し、複雑なクエリーをサポートするツールの使用を検討してください。
  
  
• アラートと通知の設定:事前定義されたしきい値を超えた場合や異常検出が発生した場合に自動アラートを送信するシステムを確立します。 これにより、チームは問題に迅速に対応し、潜在的なダウンタイムを最小限に抑えることができます。
  
  
• インシデント管理プラットフォームとの統合：問題の検出に加えて、観測可能性は問題の効果的な管理にも関与する。 観測可能なパイプラインをインシデント管理システムと統合することで、対応ワークフローを合理化することができる。
  
  
• 観測可能性パイプラインを定期的に見直し、更新する：ビジネスが進化するにつれて、データと要件も進化します。 可観測性パイプラインを定期的に確認して更新することで、必要な洞察とパフォーマンスを継続的に提供できるようになります。

オブザーバビリティパイプラインの構築は、継続的な学習と改善のプロセスです。 小規模から始めて、経験から学び、オブザーバビリティ機能を徐々に拡大することが重要です。