データアーキテクチャとは？

データ・アーキテクチャーの設計は、多くの場合、ビジネス要件とデータ・ニーズに基づいて行われ、データ・アーキテクトとデータ・エンジニアはこれらに基づいてデータ・モデルとその支持基盤となるデータ構造を定義します。この設計は通常、レポート作成やデータサイエンス・イニシアチブなどのビジネス・ストラテジーやビジネス・ニーズに対応しています。

組織がデータを拡張するにつれて、適切に構造化された適応性のあるアーキテクチャーの必要性が、最優先に対処する事項となっています。しかし、データ・リーダーの94%は、データアーキテクチャーが定義されていないことを最大の課題として挙げています。¹

最新のデータ・アーキテクチャーは、エンタープライズ・データを統合および標準化する上で役立ち、ビジネス・ドメイン間でシームレスなデータ共有を可能にします。また、リアルタイム・データ分析や生成AIなどの高度なユースケースのためのスケーラブルな基盤も提供し、チームがデータからより迅速かつ確実に価値を引き出せるよう支援します。

モノのインターネット（IoT）のようなテクノロジーによって新しいデータソースが生み出されても、適切に設計されたアーキテクチャーにより、データはライフサイクル全体を通じて管理しやすく、統合され、有用であり続けることができます。企業全体のシステムを接続することで、冗長性を削減し、データ品質を向上させ、サイロを排除するために役立ちます。

正しく機能すれば、データアーキテクチャーは単なる技術的構造ではなく、未加工データを再利用可能な資産に変える戦略的機能です。

データ・アーキテクチャーは、複数の重複する概念を統合したものです。以下は、ランドスケープを定義する際に役立ちます。

• プラットフォーム：データ・システムをホストおよび実行する基盤となるテクノロジー環境。これには、クラウド・ベースまたはオンプレミスのツールが含まれます。

• データ・モデル：システム内でデータがどのように構成されているかを詳細に表したもの。エンティティー、関係、および形式を定義します。

• フレームワーク：エンタープライズ・アーキテクチャーの設計と管理に使用される戦略的方法論。フレームワークは、データ・システムをビジネス目標に合わせて調整するための構造化されたアプローチを提供します。

• コンポーネント：アーキテクチャー内で特定の役割を実行する機能的要素。例としては、移動用のパイプライン、生データ保管用のデータレイク、メタデータ管理用のカタログなどがあります。

• パターン：一般的なアーキテクチャ上の課題に対する反復可能な解決策。データ・ファブリックやデータ・メッシュなどのパターンは、スケーラビリティ、ガバナンス、またはアクセシビリティを向上させるためのテスト済みの方法を表します。

最新のデータ・アーキテクチャーは、集中型または分散型という2つの主要なアプローチのいずれかに従う傾向があります。これらのモデルは、企業データの収集、保管、管理方法の指針となります。

集中型アーキテクチャーでは、単一のデータ・ガバナンスモデルで管理される統合型プラットフォーム（データレイクやデータウェアハウスなど）にデータが取り込まれます。これにより、冗長性が削減され、データ品質が向上し、構造化クエリ言語（SQL）やその他のリレーショナル・データベースを使用した構造化データ・モデリング がサポートされます。

分散型アーキテクチャーは、ビジネス・ドメイン間でデータの所有権を分散させます。チームは、多くの場合、非リレーショナル・データベース・システム（「NoSQLデータベース」とも呼ばれる）または独自のスキーマ、メタデータ、アクセス制御を備えたイベントベースのパイプラインを使用して、データをローカルで管理します。このアプローチは、リアルタイムのデータ統合と処理、データ・ストリーム、機械学習（ML）のユースケースをサポートします。

ほとんどの組織は、スケーラビリティ、データ統合、俊敏性のバランスをとるために両方のモデルを組み合わせています。このハイブリッド・アプローチは、さまざまなデータ・ソースをサポートし、データ・サイロを削減し、AWSやMicrosoft Azureなどのプラットフォーム上でクラウドネイティブなオペレーションを可能にする上で役立ちます。

組織がどのようなアーキテクチャー・モデルを採用するかにかかわらず、成功は基礎となるデータがどれだけ適切に構造化されているかによって決まります。ここでデータ・モデリングが役立ちます。

データ・アーキテクチャーはシステム間でデータがどのように流れるかに焦点を当てるのに対し、データ・モデリングはそれらのシステム内でデータがどのように構造化されているかに焦点を当てます。データ・モデルは、情報がアーキテクチャー内を移動する際に、その情報の形状、関係、制約を定義します。

データ・アーキテクチャーのドキュメンテーションには、通常、次の3種類のモデルが含まれます。

• 概念データ・モデル
• 論理データ・モデル
• 物理データ・モデル

「ドメインモデル」とも呼ばれる概念データ・モデルでは、システムに何が含まれるか、どのように構成されるか、どのBusiness Rulesが適用されるかを全体的に把握できます。これらのモデルは通常、プロジェクト計画の初期段階で作成され、エンティティー・クラス（データ・モデルで追跡される定義済み項目)、それらの特性と制約、それらの間の関係、および関連するセキュリティやデータ整合性の要件が含まれます。

論理データ・モデルは、概念モデルよりも抽象性が低く、特定のドメイン内のエンティティーと関係についてより具体的な詳細を提供します。正式なデータ・モデリング表記法に従って、データの種類や長さなどのデータ属性を定義し、エンティティーがどのように接続されるかを示します。重要な点として、論理モデルは依然としてテクノロジーに依存せず、システム固有の要件が含まれません。

物理データ・モデルは、データベースの実装方法表す3つのデータ・モデルの中で最も詳細なモデルです。これらは、テーブル構造、インデックス、ストレージ形式、およびパフォーマンスに関する考慮事項を定義します。これらのモデルは、構造化データがどのように保存され、アクセスされるかという技術的な側面に重点を置いており、スキーマの作成、構成、最適化をガイドするために使用されます。

データ・モデルは、システム内の情報の構造を形成します。そこから、より広範なアーキテクチャー・フレームワークが、モデルとその周辺のシステムがどのように実装されるかをガイドします。

データ・アーキテクチャーは、TOGAF、DAMA-DMBOK 2、Zachman Framework for Enterprise Architectureなどの一般的なエンタープライズ・アーキテクチャー・フレームワークから取得できます。

このエンタープライズ・アーキテクチャー方法論は、The Open Groupによって1995年に開発されました。そのアーキテクチャーは、次の4つの柱で構成されています。

• ビジネス・アーキテクチャーは、企業の組織構造、データ・ストラテジー、プロセスを定義します。

• データ・アーキテクチャーは、概念的/論理的/物理的データ資産と、そのライフサイクル全体にわたる保管と管理の方法を表します。

• アプリケーション・アーキテクチャーは、アプリケーション・システムと、それらが主要なビジネス・プロセスと相互にどのように関連しているかを表現するものです。

• テクニカル・アーキテクチャーは、ミッションクリティカルなアプリケーションをサポートするために必要なデータ・インフラストラクチャー（ハードウェア、ソフトウェア、およびネットワーク）を表します。

TOGAFは、データ・アーキテクチャーを含む企業のITアーキテクチャーの設計と実装のための完全なフレームワークを提供しています。

DAMA Internationalは、もともとData Management Association Internationalとして設立され、データと情報の管理の推進を目的とした非営利団体でした。データ管理知識体系DAMA-DMBOK 2は、データ・アーキテクチャーだけでなく、ガバナンスと倫理、データ・モデリングと設計、ストレージ、セキュリティー、統合もカバーしています。

このフレームワークは、もともと1987年に当時IBMの社員であったJohn Zachmanによって開発され、コンテキストから詳細まで6つのレイヤーのマトリックスを使用し、なぜ、どのように、何を、などの6つの質問にマッピングされています。データを整理し分析するための正式な方法にはなるものの、それを行うための方法は含まれていません。

データ・アーキテクチャーは、データの移動、保管、管理、アクセスの方法を管理する複数の相互依存するコンポーネントから構築されます。これらの要素はデータ・システムの運用基盤を形成し、取り込みから分析まですべてをサポートします。

データ・アーキテクチャー・コンポーネントは通常、4つの大きなカテゴリーに分類され、それぞれに複数のサブカテゴリーがあります。

データは外部および内部ソースから取得され、処理および保存のためにシステムに移動します。

パイプラインは、データを取り込み、変換し、元の地点から処理および保管される場所に転送します。これらのシステムは、抽出、変換、ロード（ETL）や抽出、ロード、変換（ELT）などのバッチ・パターンに従うことができます。また、ほぼリアルタイムでデータをストリーミングすることもできます。最近のパイプラインには、多くの場合、フローの一部として変換ロジック、品質チェック、およびスキーマ検証が含まれています。

アプリケーション・プログラミング・インターフェース（API）と事前に構築されたコネクタにより、データ・システム、アプリケーション、分析ツール間のシームレスな統合が可能になります。これらは、さまざまなプラットフォーム間のデータ・アクセスを合理化する標準化された方法を提供し、リアルタイムのデータ交換における中心的な役割を果たします。

データは一度取り込まれると、構造化および非構造化の両方のスケーラブルなシステムに保管され、その後の使用と分析のために利用できるようになります。

データウェアハウスでは、企業全体のさまざまなリレーショナル・データ・ソースからのデータを、一元的で一貫性のあるリポジトリー1つに集約します。抽出後、データはETLパイプラインを通過し、事前定義されたデータ・モデルを満たすためにさまざまな変換が行われます。データがデータウェアハウス・システムにロードされると、さまざまなBusiness Intelligence（BI）およびデータサイエンスアプリケーションをサポートするために使用できるようになります。

データ・マートは、単一のチームまたは利害関係者グループに関連するデータの小さなサブセットを含む、データウェアハウスの焦点を絞ったバージョンです。データ・マートは、対象範囲を狭めることで、より広範なウェアハウスのデータセットを扱うよりも、より迅速で的を絞った洞察を可能にします。

データレイクは、構造化・非構造化形式の両方を含む、未処理の生データを大規模に保管します。データウェアハウスとは異なり、データレイクでは事前のデータ・モデリングや準備が不要なので、ビッグ・データのワークロードに最適です。

データレイクハウスは、データウェアハウスとデータレイクの要素を1つのデータ管理ソリューションに統合したものです。低コストのストレージを高性能のクエリー・エンジンやインテリジェントなメタデータ・ガバナンスと組み合わせます。

データベースとは、データを保管、管理、セキュリティー保護するための基本的なデジタル・リポジトリーです。データベースの種類が異なれば、データを保管する方法も異なります。たとえば、リレーショナル・データベース（「SQLデータベース」とも呼ばれる）では、定義された行と列を持つテーブルにデータを格納します。NoSQLデータベースでは、キーと値のペアやグラフなど、データをさまざまなデータ構造として保管できます。

データが流れ、蓄積されていくと、ガバナンス・ツールによって、データがライフサイクル全体にわたって適切に整理され、安全で、検出しやすい状態が確保されます。

データ・カタログは、組織のデータ資産の集中型インベントリーです。メタデータを使用して、データセットの発信元、構造、所有権、使用履歴、品質など、各データセットに関するコンテキストを提供します。データ・カタログは、ユーザーがデータを検索して評価し、ガバナンスとコンプライアンスの取り組みをサポートし、チーム間のコラボレーションを促進するために役立ちます。

リネージュ・ツールは、システム間のデータの移動を追跡し、データがどのように変換され、どこから発生したかを示します。この可視性は、監査、トラブルシューティング、依存関係の理解において不可欠です。オブザーバビリティーは、パイプラインのパフォーマンスとデータ品質メトリクスを監視することで、リネージュを補完できます。 

最後に、データは、意思決定を促進するダッシュボード、クエリ、または組み込みツールを通じて、それを使用する人やシステムに届けられます。

Business Intelligenceプラットフォームは、視覚化とダッシュボードを通じてデータ・アクセスを改善できます。これらのツールは、技術者以外のユーザーが傾向を解釈し、KPIを監視し、データ駆動型の意思決定を行うサポートを提供します。

SQLエンドポイントやその他のクエリ・インターフェースを使用すると、アナリストやデータ・サイエンティストはデータを直接調査・分析できます。Apache SparkやIBM watsonx.dataなどのツールは、分散型データセット全体にわたって大規模なクエリを実行するために必要なコンピューティング・レイヤーを提供します。

一部のアーキテクチャーでは、アプリケーション、ワークフロー、またはAPIへのデータの直接配信がサポートされています。これらの組み込み型のデータ・プロダクトは、日常のオペレーションに洞察をもたらし、データ駆動型の意思決定を可能にします。

アーキテクチャー全体からのデータも、AIやMLワークフローに供給できます。多くの場合、トレーニング・データはデータレイクから供給され、パイプラインを通じて変換され、モデルの開発と再トレーニングに使用されます。これらのモデルは、製品、ダッシュボード、またはビジネス・プロセスにデプロイして、オートメーションと予測を強化できます。

データ・アーキテクチャーの実装には、ビジネス・ニーズをデータ・コレクション、構造、セキュリティー、アクセシビリティーのロードマップに変換することが含まれます。全く同じ実装はありませんが、ほとんどの場合、計画から実行へと移行する段階的アプローチに従います。

組織の規模が拡大するにつれて、柔軟でレジリエントな データ・アーキテクチャーの必要性も高まります。最新のデータ・アーキテクチャーでは、相互運用性、リアルタイムのアクセス、そしてデータを単なる資産ではなく製品として管理する性能が優先されます。また、APIを通じて、標準化、メタデータ管理、民主化をさらに進めることができます。

最新のデータ・アーキテクチャの主な特徴は次のとおりです。

• クラウドネイティブ設計により、柔軟な拡張性と高可用性を実現します。

• インテリジェントなデータ・パイプラインは、リアルタイム統合、データ・ストリーミング、コグニティブ分析を組み合わせます。

• 最新のアプリケーションとレガシー・アプリケーションの両方とシームレスにAPIベースで連携します。

• リアルタイムのデータ有効化には、検証、分類、ガバナンスが含まれます。

• 分離された拡張可能なサービスは、モジュール式の成長とオープンな相互運用性をサポートします。

• ドメインベースの組織は、イベントとマイクロサービスを使用してビジネス構造を反映します。

• 組み込みの最適化により、パフォーマンス、コスト、シンプルさのバランスをとります。

データ・インフラを近代化する組織は、今日のハイブリッド、マルチクラウド環境の複雑さを反映した新しいデータ戦略を採用しています。この転換は、データ・ファブリックやデータ・メッシュといった新しいアーキテクチャー・パターンを生み出しました。

データ・ファブリックは、ハイブリッド環境全体にわたるデータの統合と管理の自動化に重点を置いています。アクティブなメタデータと機械学習を使用して、システム間の関係を発見し、データフローを調整します。データ・ファブリックは、データ・プロダクトを自動的にプロビジョニングしてオンデマンドで提供できるため、運用効率が向上し、データ・サイロが減少します。

データ・メッシュは、アーキテクチャーをビジネス・ドメインと整合させることで、データの所有権を分散します。データ・メッシュでは、データ作成者（ソースに最も近い人）に、データを製品として扱い、消費者を念頭に置いてAPIを設計することを奨励しています。このモデルは、企業全体でボトルネックを排除し、スケーラブルなデータを民主化できるようサポートします。

これらのアプローチは異なりますが、相互に排他的ではありません。多くの組織は両方の要素を実装し、ファブリックの自動化を利用してメッシュの分散型ガバナンスを拡張しています。

適切に構築されたデータ・アーキテクチャーは、企業に次のような大きなメリットをもたらします。

• 冗長性の削減
• データ品質の向上
• 統合の実現
• データライフサイクル管理

異なるソース間でデータ・フィールドが重複していると、不整合、不正確さ、データ統合の機会の逸失につながる可能性があります。優れたデータ・アーキテクチャーにより、データの保存方法が標準化され、冗長性が軽減され、より質の高い総合的な分析が可能になります。

適切に設計されたデータ・アーキテクチャーは、適切に管理されていないデータレイク（別名、「データ・スワンプ」）の課題の一部を解決できます。データ・スワンプには、有意義な洞察を提供するための適切なデータ標準（データ品質やデータ・ガバナンスの実践など）がありません。データ・アーキテクチャーは、データ・ガバナンスとデータ・セキュリティー標準の強化に役立ち、適切なデータ・パイプラインの監視を可能にします。

データがサイロ化するのは多くの場合、データストレージの技術的な制限や企業内の組織的な障壁が原因です。今日のデータ・アーキテクチャーでは、さまざまな地域や職務が互いのデータにアクセスできるよう、領域をまたがるデータ統合が容易になることを目的にします。これにより、一般的なメトリクスをより良く一貫性を持って理解することにつながるため、データ駆動型の意思決定に役立つ、より全体的なビジネスへの視点を獲得できます。

最新のデータ・アーキテクチャーでは、時間の経過に伴うデータの管理方法に対応できます。通常、データは古くなってアクセス頻度が低下するにつれて、有用性が低下します。時間が経ったデータは、より安価で低速なストレージ・タイプへ移行できるため、レポートや監査でデータを利用できる状態を維持しつつ、高性能ストレージの費用を回避できます。