モダン・データ・プラットフォームはテクノロジーだけでなく、DevOpsやDataOps、そしてアジャイル哲学にも支えられています。DevOpsとDataOpsの目的は全く異なりますが、双方ともプロジェクトの作業サイクルを加速させることを目的としたアジャイル哲学に似ています。

DevOpsは製品開発に重点を置いているのに対し、DataOpsはデータからビジネス価値を提供する分散データ・アーキテクチャー・システムの開発と保守に重点を置いています。

アジャイルは、スピードと効率を促進するソフトウェア開発の哲学ですが、「人間」の要素を排除しているものではありません。コミュニケーションを最大限に活用する方法として対面での対話を重視する一方で、エラーを最小限に抑える手段として自動化も重視しています。

モダン・データ・プラットフォームにおける第1の基盤レイヤーはストレージと処理です。

モダン・データ・ストレージ・システムは、データの保管場所や処理方法など、データを効率的に使用することに重点を置いています。最もよく使用されている2つのストレージ形式はデータ・ウェアハウスとデータレイクですが、データ・レイクハウスとデータ・メッシュの普及も高まっています。

データ・ウェアハウス

データ・ウェアハウスは、明確に定義されたユースケースで構造化データを管理するように設計されています。

データ・ウェアハウスの使用は、データの保管にデータベースが使われていた1990年代にまで遡ります。当時使われていたデータ・ウェアハウスはオンプレミス型で、ストレージ容量が非常に限られていました。

2013年頃、データ・ウェアハウスはクラウドに移行し始めるとすぐに拡張性が可能になったのです。クラウドベースのデータ・ウェアハウスは、コンピューティング能力と処理速度を最適化できるため、データ・ストレージ・システムとして好まれ続けています。

使用するデータ・ウェアハウスを適切に機能させるには、データの収集、再フォーマット、クリーニングを行った上でそのウェアハウスにアップロードする必要があり、再フォーマットできないデータは失われる可能性があります。

データレイク

2008年1月、YahooはHadoop（NoSQLベース）をオープンソース・プロジェクトとしてApache Software Foundationにリリースしました。データレイクは元々Hadoop上に構築されたスケーラブルなもので、オンプレミス用に設計されていましたが、一方で、Hadoopエコシステムは非常に複雑で使いにくいものでした。そんな中、データレイクは2015年頃からクラウドに移行し始め、より低コストでユーザーフレンドリーなものとなりました。

データレイクは元々、未加工の非構造化データをスキーマ（フォーマット）を強制せずに収集し、幅広いデータからより多くのインサイトを研究者に提供するために設計されたものでした。しかし、データレイクには、古い情報、不正確な情報、無駄な情報の解析に問題があるため、あまり効果的ではない「データ・スワンプ（データの沼）」になることがあります。

一般的なデータレイクのアーキテクチャーでは、AWSのAmazon S3のようなオブジェクト・ストレージにデータを保管し、Sparkのようなツールを併用してデータを処理します。

データレイクハウス

データレイクハウスとは、データレイクの柔軟性、コスト効率、スケーリング能力と、データ・ウェアハウスのACID（原子性、一貫性、独立性、永続性）トランザクションおよびデータ管理機能を統合したものです（ACIDとは、トランザクションを定義する一連の重要な特性であるAtomicy（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）の頭文字をとった略語です）。

データレイクハウスはBIと機械学習をサポートしますが、データレイクハウスの主な強みはメタデータのレイヤーを使用するという点にあります。データレイクハウスは、高性能SQL検索用に設計された新しいクエリ・エンジンも使用します。

データ・メッシュ

データ・メッシュはデータ・ウェアハウスやデータレイク、データ・レイクハウスとは異なり、データの所有権を分散化できます。このアーキテクチャー・モデルでは、特定のドメイン（ビジネス・パートナーや部門など）がデータを所有せず、他のドメインと自由にデータを共有します。つまり、データ・メッシュ・システム内にあるすべてのデータは同じ形式を維持する必要があります。

データ・メッシュ・システムは、複数のデータ・ドメインをサポートするビジネスには有効です。データ・メッシュの設計の内には、データ・ガバナンスのレイヤーと可観測性のレイヤーがあります。また、普遍的な相互運用が可能なレイヤーもあります。

データ・メッシュは、急速に拡大し、データの保管に拡張性を必要とする組織には有効です。

将来の使用を見据えてデータをストレージ・システムに格納するプロセスのことをデータ取り込みいい、モダン・データ・プラットフォームにおける第2のレイヤーになります。

簡単に言うと、データ取り込みとは、さまざまなソースから中央の場所にデータを移動させることを意味します。データは、移動させたその中央の場所から記録保持や、さらなる処理・分析を行うために使用できますが、記録保持にしても処理・分析にしても、アクセス可能で一貫性のある正確なデータに依存します。

組織は、アナリティクス・インフラストラクチャーからのデータを用いてビジネス上の意思決定を行います。このデータが持つ価値は、データの取り込みと連携の精度によって左右されます。取り込みプロセス中に問題（データ・セットの欠落や旧式化など）が発生すると、分析プロセスのすべてのステップで問題が発生します。特に、ビッグデータではこうした状況が発生する傾向が強いです。

データ処理モデル

データの取り込みはさまざまな方法で行うことができ、特定のデータ取り込みレイヤーの設計方法はさまざまな処理モデルに基づいています。データは、SaaSプラットフォーム、モノのインターネット（IoT）デバイス、モバイル・デバイスなど、さまざまなソースから取得できます。優れたデータ処理モデルは効率的なデータ戦略の基盤として機能するため、組織はどのモデルが自社の状況に最適であるかを判断する必要があります。

• バッチ処理はデータ取り込みで最も一般的な形式ですが、リアルタイムでの処理に対応するようには設計されていません。代わりに、ソース・データを収集してバッチにグループ化し、送信先に送信します。バッチ処理は、単純なスケジュールを使用して開始することも、ある特定の条件が存在する場合にアクティブ化することもできます。バッチ処理はリアルタイムデータが不要な場合に使われることが多いですが、これはリアルタイム処理よりも作業量が少なく、コストもかからないからです。
  
• リアルタイム処理（ストリーミングまたはストリーム処理ともいいます）は、データをグループ化せず、データを認識するとすぐにそのデータの取得、変換、読み込みを行います。リアルタイム処理は、データ・ソースを常に監視し、新しい情報を自動的に受け入れる必要があるためコストが高くなります。

次のレイヤーはデータ変換です。データ変換ではデータの値、構造、形式の変更を扱います。データ分析を行うプロジェクトでは、このレイヤーが必要になることが多いです。データ・パイプラインを使用する場合、データは保存先に到着する前でも後でも変換できます。

これまで最新のデータ取り込みモデルでは、ETL（抽出、変換、読み込み）手順を用いてソースからデータを取得し、再フォーマットして保存先に転送していました。企業がコストのかかる社内分析システムを使用しなければならなかった時代では、このモデルが通用していました。納品前に変換などの準備作業を行うことで、コストを抑えることができていました。現在もオンプレミスのデータ・ウェアハウスを使用している組織では、通常ETLプロセスを使用します。

現在、多くの組織では、クラウドベースのデータ・ウェアハウス（IBM、Snowflake、Google BigQuery、Microsoft Azureなど）を積極的に利用していますが、これはコンピューティングとストレージのリソースを必要に応じて拡張できるからです。クラウドの拡張性によってプリロード変換をバイパスできるため、未加工データをより迅速にデータ・ウェアハウスに送ることができます。データは到着後、ELT（抽出、読み込み、変換）モデルによって変換されます。これは通常、クエリに応答する際に行われます。

この時点でデータはSQL形式に変換され、調査中にデータ・ウェアハウス内で実行することが可能になります。

データ変換にはいくつかの利点があります。

• ユーザビリティ：データを標準化して適切な構造下に置くことで、データ・エンジニアリング・チームは、通常であれば使い物にならず、分析もしないデータからビジネス価値を生み出すことができます。

• データ品質：未加工データを変換することで、データのエラー、不一致、欠損値を特定して修正できるため、よりクリーンで正確なデータが得られます。
  
  
• 組織力の向上：変換したデータは、人もコンピューターも処理しやすくなります。

モダン・データ・プラットフォームにおける第4のレイヤーは、ビジネス・インテリジェンス（BI）と分析ツールになります。

1865年、Richard Millar Devensは、『Cyclopædia of Commercial and Business Anecdotes』の中で「Business Intelligence（ビジネス・インテリジェンス）」という言葉を発表しました。彼はこの用語を、銀行家だったHenry Furnese卿が競争前に情報を収集し、それを利用して利益を得たことを説明するのに使いました。

現在、データ分析だけでなくビジネス分析からも大量のビジネス情報が収集されています。BIおよび分析ツールを使用すると、データにアクセスして分析を行い、理解しやすいインサイトを提供するビジュアライゼーションに変換できます。研究者やデータサイエンティストに詳細なインテリジェンスを提供することで、戦術的・戦略的なビジネス上の意思決定に役立てることができます。

モダン・データ・プラットフォームにおける第5の基盤レイヤーは、データ可観測性です。

データ可観測性とは、データとその健全性の状態を監視・観察する能力のことをいい、ユーザーがほぼリアルタイムでデータの問題を特定して解決できるようにする多くのアクティビティとテクノロジーをカバーしています。

可観測性により、データ・エンジニアリング・チームは、極度に分散されたシステムの裏側で起こっていることに関する具体的な疑問に答えることができます。データの動きが遅いところや破損個所を示すことができます。

管理者やデータ・チーム、その他さまざまな利害関係者に潜在的な問題に関するアラートが送信されるため、アラートを受け取った人物は問題を積極的に解決できるようになります。予測機能は有効ですが、すべての問題を検出できるという保証はありません。

データ可観測性を有効なものにするには、以下の機能を含める必要があります。

• SLAトラッキング：パイプラインのメタデータとデータ品質を、事前に定義した基準に照らして測定。
  
• モニタリング：システムまたはパイプラインの運用指標を示す詳細なダッシュボード。
  
• ロギング：新たに検出された異常と比較するためにイベントの履歴記録（追跡、比較、分析）を保存。
  
• アラート：異常と予想されるイベントの両方に対して警告を発信。
  
• 分析：システムに適応した自動検出プロセス。
  
• 追跡：特定のメトリクスとイベントを追跡する機能を提供。
  
• 比較：履歴の背景と異常アラートを提供。

多くの組織では可観測性がサイロ化されています。つまり、データにアクセスできるのは特定の部門のみという状態です。哲学的に言うと、データ・メッシュ・システムはデータの共有を要求することでこの問題を解決しますが、従来のストレージ・システムや処理システムでは推奨されていないことが多いです。