データ アーキテクチャの基礎的な役割 (分析重視の世界)

軍隊にはこんな格言がある。 「アマチュアは戦術を議論するが、プロは兵站を研究する。」 チャンセラーズヴィルの戦いでのリー将軍の輝かしい活躍や、ポエニ戦争でのハンニバル将軍の天才性を考えると、この考えは一見驚く人もいるかもしれない。しかし、歴史上、リー将軍もハンニバル将軍もそれぞれの戦争に勝利していない。 その主な理由は物流、つまり軍隊に適切な時間と場所で食料、衣服、武器を供給し続ける能力でした。 素晴らしい戦術にもかかわらず、最終的に勝利を決定づけたのは兵站でした。 言い換えれば、戦術はフィールドにある資産を最大限に活用することを可能にしますが、ロジスティクスはそもそもフィールドに存在し、そこに留まることを可能にします。

私が軍事的なアナロジーを好きなのは、それが、今日データ駆動型ソリューションがよく表現される方法と類似していると思うからです。 ディープラーニング、ランダムフォレスト分類、勾配ブースティングなどの高度な AI 技術である「戦術」の魅力は、それらの高度な技術を可能にするデータ アーキテクチャ基盤の、それほど魅力的ではない「ロジスティクス」をしばしば覆い隠します。

データ アーキテクチャに関する議論の最初のステップは、「データ アーキテクチャ」の概念が何を含むかを定義することです。 当然のことながら、答えは微妙なものであり、階層化され多面的なものであることがわかります。 議論の基礎を築くために、まずは収集されたテレメトリ データの経路という観点から考えると役立ちます。 以下の図は、パイプラインとデータ アーキテクチャ基盤間のタッチポイントを強調した、高レベルのデータ パイプラインを示しています。

各データ要素の旅は、その作成から始まり、通常はある程度の前処理が行われてからシリアル化され、通常はクラウドにあるデータ コレクター/アグリゲータに送信されます。 次に、データ コレクター自体は (デシリアライズと取り込みの後)、データを永続データ ストアに配信したり、データ分析パイプラインに供給したりする前に、追加の処理と強化を実行する場合があります。 最後に、強化/分析された結果は、視覚化プラットフォームを使用して人間が利用できるようになり、自動システムによってフィードバック入力の形で利用され、自己調整または自己修復閉ループシステムに使用される場合もあります。

データ パイプラインのコンテキストが確立されたので、「データ アーキテクチャ」の意味を理解するという質問に戻ることができます。 最初の答えは、最も表面的なレベルでは、データ表現とシリアル化構文に焦点を当てています。 たとえば、データ イベントに「customer」というタイトルのオブジェクト フィールドが含まれている場合、構文ビューでは、そのデータが文字列として表されるか、整数 UUID として表されるか、あるいは他の何かとして表されるかが判断されます。

しかし、もう少し深く掘り下げてみると、2 番目の答えは単なる構文以上のもので、データのセマンティクス、つまりデータ コンテンツの明確で一貫した解釈に関するものであることがわかります。 ここでも、「顧客」フィールドを例に挙げて、構文上の質問に答えたと仮定します。つまり、実際にはデータ要素が文字列フィールドとして定義されていると仮定します。 次に、データ アーキテクチャは、意味/解釈に関する質問に答えられる必要があります。セマンティクスは個人の名前のものか、それとも会社名のものか? 人名の場合は、<姓> ですか、<名> ですか、それとも両方ですか?  一貫したセマンティクスを統一された構文と組み合わせると、データ パイプラインは、データ コンテンツの一貫した論理的解釈に基づいて、データのフィルタリングや集約などの機能を汎用的かつ堅牢に実行できるようになります。 さらに、作成されたデータが一貫した構文とセマンティクスに従っている限り、データ ストアは、さまざまなデータ作成パイプライン インスタンス間でフェデレーション データ クエリを簡単に実行することもできます。

最後に、さらに深く掘り下げると、多くの場合、データ アーキテクチャに 3 番目の機能、つまりテレメトリをコンテキスト化し、データ自体について推論するための語彙、つまりメタデータ語彙が重要になります。 これは、コンプライアンス、監査、あるいはデータ ウェアハウス内で管理されているデータの全体的な理解を必要とする内部ワークフローなど、エンタープライズ データ ガバナンスの要件のコンテキストでは特に重要です。 メタデータは多くの場合、データに対する注釈の形で提供され、注釈はデータ自体と同じ種類の構文および意味の一貫性に従います。 たとえば、メタデータ フィールドは、法的なデータ保持要件に準拠するために、データ ソースの ID、収集されたデータのデータ処理のタイムラインを記録するために使用される可能性があります。

データ記述スキーマの語彙集でメタデータ フィールドを使用するもう 1 つの方法は、データ要素の順序やプライバシーの機密性など、データ フィールド自体の側面について推論することです。 もう一度「顧客」データ フィールドの例に戻ると、データ スキーマのメタデータ注釈はデータ要素を一意としてマークし、データ ストリームのコンテキスト (小売購入トランザクションなど) における追加の注釈はデータ要素を必須およびシングルトンとしてマークできます。つまり、メタデータは、 customerIDフィールドが一意である (プライマリ データベース キーとして使用可能) 必要があり、各購入イベントには 1 つの顧客 ID が関連付けられている必要があることを示すために使用されます。 データ パイプラインのコンテキスト内でのメタデータ機能全体の有用性は、それらを活用してデータ コンプライアンスのための注釈を追加したり、データ強化語彙を提供したり、データ ウェアハウスの柔軟なガバナンス ワークフローを実現したりできることです。

まとめると、質問に対する答えは次のようになります。 「データ アーキテクチャとは何か」という問いは、少なくとも、収集されたデータに対して構文と意味の両方の一貫性を実現するフレームワークを提供することです。 さらに、堅牢なデータ アーキテクチャには、データに対する制約を指定するだけでなく、データ自体を推論する機能も備えた強力なメタデータ戦略も組み込まれている必要があります。 

明確な焦点領域として考慮され、適切に実行されると、データ アーキテクチャは優れた軍事物流インフラストラクチャに非常に似たものになります。 軍事分野と同様に、これは、その上に構築されるシステムのすべてのコンポーネントの効率性と堅牢性を高める基盤を提供し、より目に見えるシステムを最大限に活用できるようにします。 データ処理システムのコンテキストでは、データ アーキテクチャ基盤は、データ ガバナンスのためのより柔軟で強力なモデル、堅牢なデータ ウェアハウスを使用したデータ ソース間のより容易なデータ共有、およびビジネスの俊敏性を高めるための新しいデータ フィードを取り込むためのより応答性の高いアプローチの基盤を提供します。