データ系統

データ系統とは、データがシステム全体でどのように生成、変換、転送、使用されるかを時間の経過とともに追跡するプロセスを指します。 ^[1]データの起源、変換、移動を文書化し、そのライフサイクルの詳細な可視性を提供します。このプロセスにより、ユーザーは問題を根本原因までさかのぼって追跡できるため、データ分析ワークフローのエラーの特定が簡単になります。 ^[2]

データ系統により、データフローの特定のセグメントまたは入力を再生できるようになります。これは、失われた出力のデバッグや再生成に使用できます。データベース システムでは、この概念は、データに影響を与える入力、エンティティ、システム、プロセスの記録を維持することを伴うデータ来歴と密接に関連しています。

データの起源は、データの起源と変換の履歴記録を提供します。これにより、依存性分析、エラー検出と回復、監査、コンプライアンス分析などのアクティビティが容易になります。生成された証拠は、データ依存性分析、エラー/侵害検出、回復、監査、コンプライアンス分析などのフォレンジックアクティビティをサポートします。「系統は、なぜ起源なのかの単純なタイプです。」^[3]

データ ガバナンスは、ガイドライン、戦略、ポリシーを確立することでメタデータを管理する上で重要な役割を果たします。データ品質測定とマスター データ管理によってデータ リネージュを強化すると、ビジネス価値が高まります。データ リネージュは通常、グラフィカル ユーザー インターフェイス(GUI) で表されますが、このインターフェイスにメタデータを収集して公開する方法はさまざまです。メタデータ収集アプローチに基づいて、データ リネージュは、構造化データ、プログラミング言語、ビッグ データシステム 用のソフトウェア パッケージを含むものの 3 つのタイプに分類できます。

データ リネージ情報には、データ変換に関する技術メタデータが含まれます。強化されたデータ リネージには、データ品質テスト結果、参照データ、データ モデル、ビジネス用語、データ管理情報、プログラム管理の詳細、データ ポイントと変換に関連するエンタープライズシステムなどの追加要素が含まれる場合があります。データ リネージ視覚化ツールには、多くの場合、ユーザーが特定のユース ケースに関連する情報に集中できるようにするマスキング機能が含まれています。異なるシステム間で表現を統一するには、メタデータの正規化または標準化が必要になる場合があります。

表現は、メタデータ管理の範囲と関心のある参照ポイントによって大きく異なります。データ リネージは、データのソースと参照ポイントからの中間データ フロー ホップを後方データ リネージで提供し、最終宛先のデータ ポイントとその中間データ フローを前方データ リネージで提供します。これらのビューは、ソースから最終宛先までの関心のあるデータ ポイントの完全な監査証跡を提供する参照ポイントのエンドツーエンド リネージと組み合わせることができます。データ ポイントまたはホップが増えると、このような表現の複雑さは理解できなくなります。したがって、データ リネージ ビューの最も優れた機能は、不要な周辺データ ポイントを一時的にマスクすることでビューを簡素化できることです。マスク機能を備えたツールを使用すると、ビューのスケーラビリティが実現し、テクニカル ユーザーとビジネス ユーザーの両方にとって最高のユーザー エクスペリエンスで分析が強化されます。データ リネージを使用すると、企業は特定のビジネス データのソースをトレースしてエラーを追跡し、プロセスの変更を実装し、システム移行を実装して、時間とリソースを大幅に節約することもできます。データ リネージにより、ビジネス インテリジェンス BI プロセスの効率を向上させることができます。^[4]

データ リネージを視覚的に表現することで、企業環境におけるさまざまな変更やホップを経てソースから宛先までのデータ フローと移動を視覚的に把握できます。これには、途中でデータがどのように変換されるか、表現とパラメーターがどのように変化するか、各ホップの後にデータがどのように分割または収束するかが含まれます。データ リネージの単純な表現は、点と線で表示できます。点はデータ ポイントのデータ コンテナーを表し、点を結ぶ線はデータ コンテナー間でデータが受ける変換を表します。

データ リネージは、ビューの粒度に基づいてさまざまなレベルで視覚化できます。非常に高レベルでは、データ リネージは、データが宛先に到達する前にやり取りするシステムとして視覚化されます。最も細かいレベルでは、データ ポイント レベルの視覚化によって、データ ポイントの詳細とその履歴動作、属性プロパティと傾向、およびデータ リネージ内の特定のデータ ポイントを通過したデータの データ品質を提供できます。

データ リネージの範囲によって、データ リネージを表すために必要なメタデータの量が決まります。通常、組織のデータ ガバナンスとデータ管理では、組織の規制、エンタープライズ データ管理戦略、データの影響、レポート属性、および重要なデータ要素に基づいて、データ リネージの範囲が決まります。

Google Map Reduce ^[5] 、Microsoft Dryad ^{[6] 、} Apache Hadoop ^[7]（オープンソースプロジェクト）、Google Pregel ^[8]などの分散システムは、企業やユーザーにそのようなプラットフォームを提供しています。しかし、これらのシステムであっても、ビッグデータ分析は、関係するデータ量が原因で、実行に数時間、数日、または数週間かかることがあります。たとえば、Netflix Prize チャレンジの評価予測アルゴリズムは、50コアで実行するのに20時間近くかかり、地理情報を推定する大規模な画像処理タスクは、400コアを使用して完了するのに3日かかりました。^[9]「大型シノプティックサーベイ望遠鏡は、毎晩テラバイトのデータを生成し、最終的には50ペタバイト以上を保存すると予想 されており、バイオ インフォマティクス分野では、現在、世界最大の12のゲノムシーケンシングハウスがそれぞれペタバイトのデータを保存しています。 ^[10

ビッグデータ分析は、大規模なデータセットを調査して、隠れたパターン、未知の相関関係、市場動向、顧客の嗜好、その他の有用なビジネス情報を発見するプロセスです。データの変換と分析には、他のアルゴリズムの中でも特に機械学習が使用されます。データのサイズが大きいため、データに未知の特徴がある可能性があります。

データの大規模で非構造化の性質、これらの分析パイプラインの複雑さ、および長い実行時間は、管理とデバッグの大きな課題をもたらします。これらの分析における 1 つのエラーでさえ、特定して削除することは非常に困難です。段階的なデバッグのためにデバッガーで分析全体を再実行することでデバッグすることもできますが、必要な時間とリソースの量によりコストがかかる可能性があります。

実験に使用する関連データソースへのアクセスが容易になり、科学コミュニティ間でデータを共有したり、企業でサードパーティのデータを使用することが増えたことにより、監査とデータ検証も大きな問題となっています。^{[11] [12] [13] [14]そのため、}データ集約型スケーラブルコンピューティング（DISC）を よりコスト効率よく分析する方法が、それらの継続的な効果的な使用に不可欠です。

EMC/IDCの調査によると、^[15] 2012年には2.8ZBのデータが作成され、複製されました。さらに、同じ調査では、デジタルユニバースは現在から2020年まで2年ごとに倍増し、2020年には一人当たり約5.2TBのデータが存在するとされています。現在の技術に基づくと、これだけの量のデータを保管するには、データセンターのエネルギー使用量が増加することになります。^[16]

非構造化データは通常、従来の行と列のデータベースに存在しない情報を指します。非構造化データ ファイルには、電子メールメッセージ、ワード プロセッサ ドキュメント、ビデオ、写真、オーディオ ファイル、プレゼンテーション、Web ページ、その他の多くの種類のビジネス ドキュメントなど、テキストやマルチメディアコンテンツが含まれることがよくあります。これらの種類のファイルは内部構造を持つ場合がありますが、含まれるデータがデータベースにうまく収まらないため、「非構造化」と見なされます。企業内の非構造化データの量は、構造化データベースの増加の何倍もの速さで増加しています。ビッグ データには構造化データと非構造化データの両方が含まれますが、IDC はビッグ データの 90% が非構造化データであると推定しています。^[17]

非構造化データソースの根本的な課題は、非技術系のビジネスユーザーやデータアナリストにとって、分析に役立てるために、その内容を理解し、準備することが難しいことです。構造の問題だけでなく、この種のデータの膨大な量も、このような困難さの一因となっています。このため、現在のデータマイニング技術では、貴重な情報が省略されることが多く、非構造化データの分析は手間と費用がかかります。^[18]

今日の競争の激しいビジネス環境では、企業は必要な関連データを迅速に見つけて分析する必要があります。課題は、大量のデータを調べて必要な詳細レベルに高速にアクセスすることです。粒度が高くなるにつれて、課題は大きくなります。考えられる解決策の 1 つはハードウェアです。一部のベンダーは、大量のデータを迅速に処理するために、メモリの増加と並列処理を使用しています。別の方法は、データをメモリ内に配置し、問題を解決するために多くのマシンを使用するグリッド コンピューティング アプローチを使用することです。どちらのアプローチでも、組織は膨大な量のデータを調査できます。このレベルの高度なハードウェアとソフトウェアを使用しても、大規模な画像処理タスクのいくつかは数日から数週間かかります。^[19]データ処理のデバッグは、実行時間が長いため非常に困難です。

高度なデータ検出ソリューションの3番目のアプローチは、セルフサービスのデータ準備と視覚的なデータ検出を組み合わせたもので、アナリストはTrifacta、Alteryxなどの新しい企業が提供するインタラクティブな分析環境で、データを同時に準備して視覚化することができます。^[20]

データ系統を追跡する別の方法は、Excelなどのスプレッドシートプログラムを使用することです。これらのプログラムは、ユーザーにセルレベルの系統、つまりどのセルが他のセルに依存しているかを確認する機能を提供します。ただし、変換の構造は失われます。同様に、ETLまたはマッピングソフトウェアは変換レベルの系統を提供しますが、このビューでは通常データが表示されず、論理的に独立した変換（異なる列で動作する変換など）と依存している変換を区別するには粒度が粗すぎます。 ^[21]ビッグデータプラットフォームは非常に複雑な構造を持ち、データは広範囲に分散されています。通常、ジョブは複数のマシンにマッピングされ、結果は後で削減操作によって結合されます。ビッグデータパイプラインのデバッグは、システムの性質上非常に困難になります。データサイエンティストにとって、どのマシンのデータに外れ値や未知の機能があり、特定のアルゴリズムが予期しない結果をもたらすのかを突き止めることは簡単な作業ではありません。

データの起源またはデータ系統を使用すると、ビッグ データパイプラインのデバッグが容易になります。そのためには、データ変換に関するデータの収集が必要です。以下のセクションでは、データの起源について詳しく説明します。

科学データの来歴は、データとその出所の履歴記録を提供します。ワークフローなどの複雑な変換によって生成されるデータの来歴は、科学者にとって非常に価値があります。^[22]来歴から、祖先データと派生に基づいてデータの品質を確認し、エラーの原因を追跡し、派生を自動的に再実行してデータを更新し、データソースの帰属を提供できます。来歴はビジネス分野にも不可欠であり、データウェアハウス内のデータソースにドリルダウンしたり、知的財産の作成を追跡したり、規制目的で監査証跡を提供したりするために使用できます。

分散システムでは、データフローを通じてレコードをトレースし、元の入力のサブセットでデータフローを再生し、データフローをデバッグするために、データ来歴の使用が提案されています。これを行うには、各出力を導き出すために使用された各演算子への入力セットを追跡する必要があります。来歴には、コピー来歴や方法来歴などいくつかの形式がありますが、^{[14] [23]}必要な情報は、Cui らによって定義された単純な形式の理由来歴、または系統です。 ^[24]

PROVは2013年のW3C勧告であり、

出所とは、データや物の作成に関与したエンティティ、活動、人物に関する情報であり、その品質、信頼性、信用性を評価するために使用できます。PROV ドキュメント ファミリは、Web などの異種環境で出所情報を相互運用可能に交換できるように、モデル、対応するシリアル化、およびその他のサポート定義を定義します。
「PROV 概要、PROV ドキュメント ファミリの概要」^[25]

出所は、データや何かの作成、影響、配信に関与した人々、機関、エンティティ、および活動を説明する記録として定義されます。特に、情報の出所は、情報が信頼できるかどうか、他のさまざまな情報源とどのように統合するか、再利用時にその発信者にクレジットを与える方法を決定する上で重要です。Web などのオープンで包括的な環境では、ユーザーは矛盾や疑わしい情報を見つけることが多いため、出所はユーザーが信頼の判断を下すのに役立ちます。
「PROV-DM: PROV データ モデル」 ^[26]

直感的には、出力 を生成する演算子の場合、系統は の形式の 3 つ組で構成されます。ここで、はを導出するために使用されるへの入力の集合です。^[3]出力を導出する入力を見つけるクエリは後方トレースクエリと呼ばれ、入力によって生成される出力を見つけるクエリは前方トレースクエリと呼ばれます。^[27]後方トレースはデバッグに役立ち、前方トレースはエラーの伝播を追跡するのに役立ちます。^[27]トレースクエリは、元のデータフローを再生するための基礎も形成します。^{[12] [24] [27]}ただし、DISCシステムで系統を効率的に使用するには、演算子とデータの複数のレベル (または粒度) で系統をキャプチャし、DISC 処理構造の正確な系統をキャプチャし、複数のデータフローステージを効率的にトレースできる必要があります。 ${\displaystyle T}$${\displaystyle o}$${\displaystyle \{i,T,o\}}$${\displaystyle i}$${\displaystyle T}$${\displaystyle o}$

DISC システムは、複数のレベルの演算子とデータで構成されており、系統のさまざまなユースケースによって、系統をキャプチャする必要があるレベルが決定されます。系統は、ファイルを使用して、{IF i、M RJob、OF i } 形式の系統タプルを提供することで、ジョブのレベルでキャプチャできます。また、レコードを使用して、たとえば、{(k rr、v rr )、map、(km、vm )} 形式の系統タプルを提供することで、各タスクのレベルでキャプチャすることもできます。最初の形式の系統は粗粒度系統と呼ばれ、2 番目の形式は細粒度系統と呼ばれます。異なる粒度にわたって系統を統合すると、ユーザーは「MapReduce ジョブによって読み取られたどのファイルがこの特定の出力レコードを生成したか」などの質問をすることができ、データフロー内の異なる演算子とデータ粒度にわたるデバッグに役立ちます。^[3]

DISCシステムでエンドツーエンドの系統を捉えるために、演算子とデータの包含階層の概念を導入するIbisモデル^{[28]を使用します。具体的には、Ibisは演算子を別の演算子に含めることができると提案しており、2つの演算子間のそのような関係は}演算子の包含と呼ばれます。演算子の包含とは、包含されている（または子）演算子が包含している（または親）演算子の論理操作の一部を実行することを意味します。^[3]たとえば、MapReduceタスクはジョブに含まれています。同様の包含関係はデータにも存在し、データ包含と呼ばれます。データ包含とは、包含されているデータが包含データのサブセット（スーパーセット）であることを意味します。

データ系統システムは、積極的と怠惰のいずれかに分類できます。^[27]

積極的収集システムは、実行時にデータ フローの系統全体をキャプチャします。キャプチャする系統の種類は粗粒度または細粒度ですが、実行後にデータ フローに対してそれ以上の計算は必要ありません。

遅延系統収集では、通常、実行時に粗粒度の系統のみをキャプチャします。これらのシステムでは、キャプチャする系統の量が少ないため、キャプチャのオーバーヘッドは低くなります。ただし、細粒度のトレース クエリに応答するには、入力のすべて (または大部分) でデータ フローを再生し、再生中に細粒度の系統を収集する必要があります。このアプローチは、ユーザーが観察された不良出力をデバッグしたいフォレンジック システムに適しています。

熱心な細粒度系統コレクションシステムは、遅延コレクションシステムよりもキャプチャのオーバーヘッドが高くなります。ただし、洗練された再生とデバッグが可能になります。^[3]

アクターはデータを変換するエンティティです。Dryad の頂点、個々の map および Reduce 演算子、MapReduce ジョブ、またはデータフロー パイプライン全体である可能性があります。アクターはブラック ボックスとして機能し、アクターの入力と出力は関連付けの形式で系統をキャプチャするためにタップされます。関連付けとは、アクターの入力と出力を関連付ける 3 つ組です。このように、インストルメンテーションはデータフロー内の系統を一度に 1 つのアクターごとにキャプチャし、各アクターの関連付けのセットにまとめます。システム開発者は、アクターが読み取るデータ (他のアクターから) と、アクターが書き込むデータ (他のアクターに) をキャプチャする必要があります。たとえば、開発者は各ジョブによって読み取られたファイル セットと書き込まれたファイル セットを記録することで、Hadoop Job Tracker をアクターとして扱うことができます。^[29]${\displaystyle \{i,T,o\}}$${\displaystyle i}$${\displaystyle o}$${\displaystyle T}$

関連付けは、入力、出力、および操作自体の組み合わせです。操作は、アクターとも呼ばれるブラック ボックスで表されます。関連付けは、データに適用される変換を記述します。関連付けは、関連付けテーブルに格納されます。各固有のアクターは、関連付けテーブルによって表されます。関連付け自体は、{i, T, o} のようになります。ここで、i はアクター T への入力のセット、o はアクターによって生成された出力のセットです。関連付けは、データ リネージの基本単位です。個々の関連付けは、後でまとめられ、データに適用された変換の履歴全体が構築されます。^[3]

ビッグ データシステムは、分散システムに新しいハードウェアまたはソフトウェア エンティティを追加することで容量を増やします。このプロセスは、水平スケーリングと呼ばれます。分散システムは、複数のハードウェアおよびソフトウェア エンティティで構成されていても、論理レベルでは単一のエンティティとして機能します。システムは、水平スケーリング後もこの特性を維持し続ける必要があります。水平スケーラビリティの重要な利点は、オンザフライで容量を増やすことができることです。最大の利点は、水平スケーリングをコモディティ ハードウェアを使用して実行できることです。

系統ストアのアーキテクチャを作成する際には、ビッグデータシステムの水平スケーリング機能を考慮する必要があります。系統ストア自体もビッグデータシステムと並行してスケーリングできる必要があるため、これは不可欠です。系統ストアの数と系統ストアを格納するために必要なストレージの量は、システムのサイズと容量の増加に伴って増加します。ビッグデータシステムのアーキテクチャでは、単一の系統ストアを使用するのは適切ではなく、スケーリングも不可能です。この問題の当面の解決策は、系統ストア自体を分散することです。^[3]

最良のシナリオは、分散システム ネットワーク内のすべてのマシンにローカル リネージ ストアを使用することです。これにより、リネージ ストアを水平方向に拡張することもできます。この設計では、特定のマシンのデータに適用されたデータ変換のリネージは、その特定のマシンのローカル リネージ ストアに格納されます。リネージ ストアは通常、関連付けテーブルを格納します。各アクターは、独自の関連付けテーブルによって表されます。行は関連付け自体であり、列は入力と出力を表します。この設計により、2 つの問題が解決されます。リネージ ストアの水平方向の拡張が可能になります。単一の集中型リネージ ストアを使用した場合、この情報はネットワークを介して伝送する必要があり、ネットワーク レイテンシが増加します。分散型リネージ ストアを使用すると、ネットワーク レイテンシも回避できます。^[29]

関連付けの観点で保存された情報は、特定のジョブのデータ フローを取得するために、何らかの方法で結合する必要があります。分散システムでは、ジョブは複数のタスクに分割されます。1 つ以上のインスタンスが特定のタスクを実行します。これらの個々のマシンで生成された結果は、後で結合されてジョブを完了します。異なるマシンで実行されているタスクは、マシン内のデータに対して複数の変換を実行します。マシン上のデータに適用されたすべての変換は、そのマシンのローカル リネージ ストアに保存されます。この情報を組み合わせて、ジョブ全体のリネージを取得する必要があります。ジョブ全体のリネージは、データ サイエンティストがジョブのデータ フローを理解するのに役立ち、データ フローを使用してビッグ データパイプラインをデバッグできます。データ フローは 3 段階で再構築されます。

データ フロー再構築の最初の段階は、関連テーブルの計算です。関連テーブルは、各ローカル系統ストア内の各アクターに対して存在します。アクターの関連テーブル全体は、これらの個別の関連テーブルを組み合わせることで計算できます。これは通常、アクター自体に基づいた一連の等価結合を使用して行われます。いくつかのシナリオでは、入力をキーとして使用してテーブルを結合することもできます。結合の効率を向上させるために、インデックスを使用することもできます。結合されたテーブルは、処理をさらに続行するために、単一のインスタンスまたはマシンに保存する必要があります。結合を計算するマシンを選択するために使用されるスキームは複数あります。最も簡単なのは、CPU 負荷が最小のマシンです。結合が発生するインスタンスを選択する際には、スペースの制約も考慮する必要があります。

データ フロー再構築の 2 番目のステップは、系統情報から関連グラフを計算することです。グラフはデータ フローのステップを表します。アクターは頂点として機能し、関連はエッジとして機能します。各アクター T は、データ フローの上流および下流のアクターにリンクされています。T の上流アクターは T の入力を生成するアクターであり、下流アクターは T の出力を消費するアクターです。リンクを作成する際は、包含関係が常に考慮されます。グラフは、3 種類のリンクまたはエッジで構成されます。

最も単純なリンクは、2 つのアクター間の明示的に指定されたリンクです。これらのリンクは、機械学習アルゴリズムのコードで明示的に指定されます。アクターが上流または下流のアクターを正確に認識している場合、この情報を系統 API に伝えることができます。この情報は、後でトレース クエリ中にこれらのアクターをリンクするために使用されます。たとえば、MapReduceアーキテクチャでは、各マップ インスタンスは、出力を消費するレコード リーダー インスタンスを正確に認識しています。^[3]

開発者は、各論理アクターにデータフローアーキタイプをアタッチできます。データフローアーキタイプは、アクタータイプの子タイプがデータフロー内でどのように配置されるかを説明します。この情報を利用して、ソースタイプとデスティネーションタイプの各アクター間のリンクを推測できます。たとえば、MapReduceアーキテクチャでは、マップアクタータイプはリデュースのソースであり、その逆も同様です。システムはデータフローアーキタイプからこれを推測し、マップインスタンスをリデュースインスタンスに適切にリンクします。ただし、データフローには複数の MapReduce ジョブがある場合があり、すべてのマップインスタンスをすべてのリデュースインスタンスにリンクすると、誤ったリンクが作成される可能性があります。これを防ぐために、このようなリンクは、包含 (または親) アクタータイプの共通アクターインスタンス内に含まれるアクターインスタンスに制限されます。したがって、マップインスタンスとリデュースインスタンスは、同じジョブに属している場合にのみ互いに​​リンクされます。^[3]

分散システムでは、実行時に指定されない暗黙的なリンクが存在する場合があります。たとえば、ファイルに書き込んだアクターと、そのファイルから読み取る別のアクターの間には暗黙的なリンクが存在します。このようなリンクは、実行に共通のデータセットを使用するアクターを接続します。データセットは最初のアクターの出力であり、アクターの入力はそれに続きます。^[3]

データ フロー再構築の最終ステップは、関連グラフのトポロジカル ソートです。前のステップで作成された有向グラフは、アクターがデータを変更した順序を取得するためにトポロジカルにソートされます。関係するさまざまなアクターによる変更のこの記録は、ビッグ データパイプラインまたはタスクのデータ フローを追跡するために使用されます。

これは、ビッグ データのデバッグで最も重要なステップです。キャプチャされた系統が結合され、処理されて、パイプラインのデータ フローが取得されます。データ フローは、データ サイエンティストや開発者がアクターとその変換を詳細に調べるのに役立ちます。このステップにより、データ サイエンティストは、予期しない出力を生成しているアルゴリズムの部分を把握できます。ビッグ データパイプラインがうまくいかない場合、大きく分けて 2 つの原因が考えられます。1 つ目は、データ フローに疑わしいアクターが存在することです。2 つ目は、データに外れ値が存在することです。

最初のケースは、データフローをトレースすることでデバッグできます。系統とデータフローの情報を一緒に使用することで、データ サイエンティストは入力がどのように出力に変換されるかを理解できます。プロセス中に、予期しない動作をするアクターをキャッチできます。これらのアクターは、データフローから削除するか、新しいアクターを追加してデータフローを変更できます。改善されたデータフローは、その有効性をテストするために再生できます。障害のあるアクターのデバッグには、データフロー内のアクターに対して粗粒度の再生を再帰的に実行することが含まれますが、^[30]長いデータフローの場合はリソースが大量に消費される可能性があります。別のアプローチは、系統ログを手動で検査して異常を見つけることですが、^{[13] [31]}は、データフローの複数のステージにわたって面倒で時間がかかる可能性があります。さらに、これらのアプローチは、データ サイエンティストが不良出力を発見できる場合にのみ機能します。既知の不良出力なしで分析をデバッグするには、データ サイエンティストは、一般的に疑わしい動作がないかデータフローを分析する必要があります。ただし、多くの場合、ユーザーは予想される通常の動作を知らず、述語を指定できません。このセクションでは、マルチステージ データフロー内の障害のあるアクターを特定するために系統を遡及的に分析するデバッグ方法について説明します。平均選択性、処理速度、出力サイズなどのアクターの動作の突然の変化は、異常の特徴であると考えています^{[不均衡な意見? ]。}系統は、時間の経過や異なるアクター インスタンスにわたるアクターの動作のこのような変化を反映できます。したがって、系統をマイニングしてこのような変化を特定することは、データフロー内の障害のあるアクターをデバッグするのに役立ちます。

2 番目の問題、つまり外れ値の存在も、データフローを段階的に実行し、変換された出力を調べることによって特定できます。データ サイエンティストは、残りの出力と一致しない出力のサブセットを見つけます。これらの不良出力の原因となっている入力は、データ内の外れ値です。この問題は、データから外れ値のセットを削除し、データフロー全体を再生することで解決できます。また、データフロー内のアクターを追加、削除、または移動して機械学習アルゴリズムを変更することでも解決できます。再生されたデータフローが不良出力を生成しない場合は、データフローの変更は成功です。

データ リネージ手法の利用は、ビッグ データパイプラインのデバッグに対する新しいアプローチですが、プロセスは簡単ではありません。リネージ ストアのスケーラビリティ、リネージ ストアのフォールト トレランス、ブラック ボックス オペレーターのリネージの正確なキャプチャ、その他多数の考慮事項など、多くの課題に対処する必要があります。これらの課題は、それらの固有のトレードオフを考慮しながら、データ リネージ キャプチャの現実的な設計を開発するために慎重に評価する必要があります。

DISCシステムは、主に高スループット向けに設計されたバッチ処理システムです。分析ごとに複数のジョブを実行し、ジョブごとに複数のタスクを実行します。クラスターで同時に実行されるオペレーターの総数は、クラスターのサイズに応じて数百から数千の範囲になります。これらのシステムの系統キャプチャは、DISC 分析のボトルネックにならないように、大量のデータと多数のオペレーターの両方に拡張できる必要があります。

系統キャプチャ システムは、系統をキャプチャするためにデータ フローを再実行しないように、フォールト トレラントである必要があります。同時に、DISC システムの障害にも対応する必要があります。そのためには、失敗した DISC タスクを識別し、失敗したタスクによって生成された部分的な系統と、再開されたタスクによって生成された重複した系統の間で系統の重複コピーを保存しないようにする必要があります。系統システムは、ローカル系統システムの複数のインスタンスがダウンしても適切に処理できる必要があります。これは、系統の関連付けのレプリカを複数のマシンに保存することで実現できます。レプリカは、実際のコピーが失われた場合にバックアップのように機能します。

DISC データフローの系統システムは、きめ細かなデバッグを可能にするために、ブラックボックス演算子全体の正確な系統をキャプチャできなければなりません。これに対する現在のアプローチには、データフローを数回再生して最小セットを推測することにより、ブラックボックス演算子の指定された出力を生成できる入力の最小セットを見つけようとする Prober ^[32]や、バイナリ書き換えによってNoSQL演算子の系統をキャプチャして動的スライスを計算する動的スライス^{[33] など}があります。このような手法は高精度の系統を生成しますが、キャプチャやトレースにかなりの時間オーバーヘッドが発生する可能性があり、代わりに精度をいくらか犠牲にしてパフォーマンスを向上させることが望ましい場合があります。したがって、キャプチャやトレースに大きなオーバーヘッドをかけずに、任意の演算子から合理的な精度で系統をキャプチャできる DISC データフローの系統収集システムが必要です。

トレースはデバッグに不可欠であり、デバッグ中にユーザーは複数のトレースクエリを発行できます。したがって、トレースのターンアラウンドタイムが短いことが重要です。Ikeda et al. ^{[27] は、} MapReduce データフローに対して効率的な後方トレースクエリを実行できますが、さまざまな DISC システムに汎用的ではなく、効率的な前方クエリを実行しません。Pig [35]の系統システムである Lipstick [34] は、^{後方トレース}と前方トレースの両方を実行できますが、Pig と SQL 演算子に固有であり、ブラックボックス演算子に対して粗粒度のトレースしか実行できません。したがって、汎用 DISC システムとブラックボックス演算子を含むデータフローに対して効率的な前方トレースと後方トレースを可能にする系統システムが必要です。

特定の入力またはデータフローの一部のみを再生することは、効率的なデバッグと what-if シナリオのシミュレーションに不可欠です。池田らは、更新された入力を選択的に再生して影響を受ける出力を再計算する、系統ベースのリフレッシュの方法論を提示しています。^[36]これは、不正な入力が修正されたときに出力を再計算するデバッグ中に役立ちます。ただし、ユーザーは、不正な入力を削除し、エラーの影響を受けた出力の系統を再生してエラーのない出力を生成する場合があります。これを排他的再生と呼びます。デバッグにおける再生のもう 1 つの用途は、段階的なデバッグのために不正な入力を再生することです (選択的再生と呼ばれます)。DISC システムで系統を使用する現在のアプローチでは、これらに対応していません。したがって、さまざまなデバッグ ニーズに対応するために、排他的再生と選択的再生の両方を実行できる系統システムが必要です。

DISC システムにおけるデバッグの主な懸念事項の 1 つは、障害のある演算子を特定することです。数百の演算子またはタスクを含む長いデータフローでは、手動による検査は面倒で、法外な場合があります。系統を使用して検査する演算子のサブセットを絞り込んだとしても、単一の出力の系統が複数の演算子にまたがる場合があります。必要な手動検査の量を最小限に抑えるために、妥当な精度で障害の可能性がある演算子のセットを大幅に絞り込むことができる、安価な自動デバッグ システムが必要です。

• 有向非巡回グラフ
• 永続ステージング領域、ソース テーブルまたはクエリの変更履歴全体を追跡するステージング領域