[ ICYMI パート 1 スケーラブルでないデータ プラットフォームを読む]

今日のデータ プラットフォームの多くはボトムアップで構築されており、「後で役に立つかもしれない」データの収集から始めて、必要に応じて徐々にソリューションをつなぎ合わせていきます。このアプローチでは、必然的に実装が断片化され、コストと技術的負債が増大します。データ システムの設計には、データ モデリング、分散システム、セキュリティ、コンプライアンスにわたる専門知識が必要です。ほとんどの企業は、初期段階では専任のデータ インフラストラクチャ チームを雇う余裕がなく、成長に合わせてデータ システムを構築し、適応させる必要があります。

ただし、既存のシステムを進化させる道筋は非常に困難です。チームは、複数の重複システムを維持しながら長期間の移行を行うか、コストのかかるシステム全体の切り替えを行うかの選択を迫られることがよくあります。Netscape は 1997 年にブラウザ エンジンを書き直すことを決定しましたが、Internet Explorer の急速な機能リリースに対抗できず、ブラウザ ビジネスと市場支配を Internet Explorer に奪われ、最終的に市場シェアの低下につながりました。多くの企業は、カスタム ソリューションから始めて、成長するにつれてベンダー プラットフォームに移行します。ただし、企業がベンダー プラットフォームを利用できる規模であっても、ユース ケースに適合しない可能性があり、社内ユーザーは新しいワークフローに適応する必要があります。多くの企業は、規模が拡大するにつれて、ベンダー プラットフォーム上にカスタム ソリューションを構築することになります。社内のインフラストラクチャ チームは、元のシステムを維持し、ベンダー プラットフォームを運用し、それらのプラットフォーム上でカスタム実装をサポートする必要があります。また、さまざまなツールにわたってユーザーをトレーニングし、複数のシステムにわたるセキュリティと統合を処理する必要があります。計画の欠如とビジネスの規模が大きくなるにつれて有機的な進歩により、最初は安価なソリューションだったものが、運用コストが大幅に増加し、運用が複雑になります。

ビジネスの成長に合わせて拡張できるデータ プラットフォームの設計は、以前よりも実現しやすくなりました。過去 10 年間で、多くの組織が明確なデータ使用パターンを確立しました。製品チームはユーザー行動データを必要とし、マーケティング チームはキャンペーンのパフォーマンスを追跡し、財務チームは収益指標を監視し、セキュリティ チームは脅威パターンを分析します。これらの一般的なユース ケースは、必要なデータとその速さの点で十分に確立されています。コストのかかる移行やベンダー ソリューションの改造を通じて要件を発見するのではなく、コストと運用効率の点で持続的に拡張できるデータ プラットフォームを構築できます。

データプラットフォームの設計

本質的に、データ プラットフォームは、必要なデータ (データ モデル) と、そのデータが必要になるまでの時間 (レイテンシ要件) という 2 つの基本コンポーネントによって定義できます。ユース ケースの定義があいまいであっても、これら 2 つのコンポーネントを理解することで、データ収集メカニズムとインフラストラクチャのニーズを体系的に導き出すことができます。

不正リスク検出を例に挙げてみましょう。通常、不正リスクには、ID、トランザクション、ケース管理という 3 つのデータ コンポーネントが必要です。

各データ コンポーネントは、レイテンシのニーズに基づいてインフラストラクチャにマッピングできます。ID とトランザクションの検証には、リアルタイムの不正検出のためのストリーム処理、継続的な監視とアラートを処理するデータベース処理、パターン分析やモデル トレーニングなどの長時間実行されるタスクをサポートするデータ レイクが必要です。

データモデル

データ モデルは、データをどのように整理し、標準化するかを定義します。一連のフィールドとその特性 (各フィールドの形式、タイプ、ルール) を指定します。スキーマによってデータの検出が可能になり、個々のフィールドの定義によってガバナンス ポリシーとコンプライアンス要件が決まります。

明確に定義されたデータ モデルにより、組織全体で標準化されたデータ収集と処理が可能になります。ユーザー データを例に挙げると、マーケティング部門はキャンペーンの追跡に、カスタマー サービスはケース管理に、製品チームは行動分析に、リスク チームは不正検出にデータを必要とします。共有ユーザー データ モデルがなければ、各チームが独自のユーザー プロファイルと追跡ロジックを構築します。チームは、システム間でユーザー データを解決および調整するために、複雑な統合を作成することになります。共有データ モデルは、信頼できる唯一の情報源として機能するため、データ収集と実装が簡素化され、一貫した標準により、セキュリティとコンプライアンスの管理がはるかに容易になります。

包括的なデータ モデルを定義することは、通常、各チームが当面のニーズに重点を置くため、難しいことがよくあります。マーケティング チームはキャンペーン関連の分野に重点を置き、リスク チームは ID 検証属性に重点を置きます。同じデータがどのようにさまざまな機能を果たすかを全体的に把握していないと、チームは不完全なデータ モデルや焦点が絞られたデータ モデルを作成することが多く、システム間のさらなる処理や統合が必要になります。

時間要件

時間要件は、データを処理して利用可能にする必要がある速度を定義します。処理ウィンドウは、即時の決定のためのリアルタイム (数秒) から、監視のための準リアルタイム (数分)、分析および AI/ML アプリケーションのためのバッチ処理 (数時間) までの範囲です。これらの時間要件は、リアルタイムの場合はストリーミング、準リアルタイムの場合はデータベース、バッチ処理の場合はデータ レイクなど、特定のインフラストラクチャの選択にマッピングされます。

フレームワークがないと、製品チームは同様のニーズに対して冗長なインフラストラクチャを構築することがよくあります。たとえば、あるチームがストリーミングに Kafka を使用し、別のチームが MSK を使用したり、あるチームがデータベースに DynamoDB を選択し、別のチームが Cassandra を使用したりすることがあります。これにより、チームがセキュリティ制御と統合が重複した複数のシステムを維持することになり、不必要な複雑さが生じます。

インフラストラクチャ コンポーネントを標準化することで、製品チームは独自のインフラストラクチャを展開する必要がなくなり、プラットフォーム チームは保守するシステムが少なくなり、運用上のオーバーヘッドを削減できます。また、この標準化により、セキュリティ制御の向上、統合の合理化、監視の簡素化、コストの最適化も実現します。

汎用データプラットフォーム

データ プラットフォーム アーキテクチャ フレームワークを使用すると、データ収集仕様、インフラストラクチャ要件、セキュリティ制御、統合機能を体系的に導き出すことができます。これにより、多くの組織が現在直面している複雑さとコストのスパイラルに直接対処できます。プラットフォーム チームがサポートに苦労する個別のシステムをチームが構築するのではなく、一貫したフレームワークによって、組織全体のセキュリティ、コンプライアンス、統合、コスト管理が簡素化されます。

一貫した実装がなければ、プラットフォーム チームは常に、既存システムの維持、コストのかかる移行の実行、新機能の構築のいずれかを選択するよう求められます。プラットフォーム チームは、ビジネスに不可欠な機能を提供するのではなく、ほとんどの時間をさまざまなシステムの維持と移行の処理に費やしてしまうことになります。フレームワーク主導のアプローチにより、組織は移行を中断することなくデータ プラットフォームを拡張できます。小規模な組織は必要なコンポーネントから始めて成長に合わせて拡張でき、大規模な組織は既存のシステムを一度標準化すれば、継続的な書き換えは不要になります。

次回の予定

「One Off to One Data Platform」シリーズの第 3 部では、このフレームワークを実際のレベルで実装する方法について説明します。ストリーミング、データベース、データ ウェアハウス、データ レイクなどの一般的なデータ プラットフォーム コンポーネントを組み立てて、一貫したセキュリティとコンプライアンスの制御を備えたさまざまなビジネス ユース ケースをサポートする方法について説明します。組織が成長しても、このモジュール アプローチにより、チームは標準化されたインターフェイスと制御を維持しながら個々のコンポーネントを個別に拡張できるため、継続的な移行が不要になります。明確なデータ プラットフォーム アーキテクチャ フレームワークがあれば、組織はビジネスを制限するのではなく、ビジネスとともに成長するデータ アプリケーションを構築できます。