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

• 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 は問題が発生することを認識し、それを封じ込めるために必要なあらゆる対策を講じることができます。

反復

ここで、チームはコードとしてのデータに焦点を当てます。 サイクルのこの段階は、プロセスに重点が置かれています。 チームは、すべてのデータ開発に適用される反復可能で持続可能な標準を確保することで、パイプラインの最後に同じ信頼できるデータを得られるようにしている。

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

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

1.鮮度

鮮度は、データがどの程度最新であるか、およびデータが更新される頻度を表します。 データの古さは、データが更新されていない重要な時間的ギャップがある場合に発生します。 データ パイプラインが破損する場合、多くの場合、その原因は鮮度の問題です。

2. 配布

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

3.ボリューム

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

4. スキーマ

スキーマはデータの構成を記述します。 スキーマを変更すると、多くの場合、データが壊れます。 データの可観測性は、データが一貫して編成され、さまざまなシステム間で互換性があり、ライフサイクル全体にわたってデータの整合性を維持するのに役立ちます。

5. リネージュ

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

データの可観測性はデータ品質をサポートしますが、この 2 つはデータ管理の異なる側面です。

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

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

データの観測性とデータ ガバナンスは、相互にサポートし合う補完的なプロセスです。

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

強力なデータ ガバナンス プログラムは、データ可観測性の実践の価値を制限する可能性があるデータ サイロ、データ統合の問題、およびデータ品質の低下を排除するのに役立ちます。

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

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

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

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

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