クラウドコンピューティングの世界におけるデータアーキテクチャの再考

今日、データ分析ソリューションが登場しています。データ チームは、アクセス、データの整合性、セキュリティ、適切なガバナンスに対するすべての要求のバランスを取る必要があり、関連するポリシーと規制への準拠が求められるため、嵐の中心にいます。データ チームがサービスを提供する企業は、できるだけ早く情報を必要としており、不均衡な行動に対抗するために、データ チームは迅速かつインテリジェントに行動する必要があります。

また、現在のシステムだけでなく、将来のためのプラットフォームも構築する必要があるため、分析と予測も必要です。データ チームが最初に考慮しなければならない重要な点の 1 つは、オープン データ アーキテクチャかクローズド データ アーキテクチャかということです。

[[409817]]

オープンデータアーキテクチャとクローズドデータアーキテクチャ

まず、「データ アーキテクチャ」という用語から始めましょう。過去何年にもわたってエンタープライズ アーキテクチャ ダイアグラムを表示した場合、そのデータ ラベルは実際にはデータベースのラベルである可能性が高くなります。つまり、データ自体ではなく、データを処理するエンジンのラベルです。 Oracle、DB2、SQL Server、Teradata、Exadata、Snowflake などの名前は、皆さんもよくご存知でしょう。これらは、運用または分析の目的でデータセットをロードするように設計されたデータベースであり、「データ アーキテクチャ」の基礎となります。

定義上、これらのデータベースは「クローズド データ アーキテクチャ」と呼ばれるものです。つまり、データ自体は他のアプリケーションから分離されており、データベース エンジンを介してアクセスする必要があります。これは、ETL ジョブを使用してデータを移動する場合にも当てはまります。なぜなら、ある時点でエクスポートまたはインポートを行うには、それが目的を達成するための最善の方法であるかどうかに関係なく、データベースを調べる必要があるからです。この重要な意味で、データはアーキテクチャの残りの部分から「閉じられている」ことになります。

要約すると、クローズド データ アーキテクチャではデータがデータベース エンジンに渡され、オープン データ アーキテクチャではデータベース エンジンがデータに渡されます。

企業がオープン アーキテクチャを扱っているかどうかをテストする簡単な方法は、将来的に新しいエンジンを導入することがどの程度難しいかを検討することです。新しいエンジンは既存のエンジンと並行して（同じデータ上で）実行できますか、それとも大規模な（そして非現実的な）移行が必要になりますか？

この時点で、「オープン」の重要な側面がオープンソースとはまったく関係ないことに触れられていることに注意することが重要です。最初のステップは、データを公開し、それを利用したいあらゆるサービスに利用可能にすることを決定することです。これは、クラウド コンピューティングの世界で実現します。

オープンなサービス指向のデータアーキテクチャ

アプリケーションがクライアント サーバーから Web に移行すると、基本的なアーキテクチャが変更されました。 1 つのプロセスで実行されるモノリシック アプリケーションから、より小さく、より専門的なソフトウェア サービスに分割されるサービス指向アプリケーションに移行します。これらは最終的に「マイクロサービス」として知られるようになり、Web およびモバイル アプリケーションの主要な設計として残っています。クラウド コンピューティング インフラストラクチャの性質上、マイクロサービス アプローチには多くの利点があります。オンデマンド リソース モデルと機能ブロックで作業する多数のチームを備えたスケールアウト システムでは、アプリケーションは数十または数百のマイクロサービスのファサードにすぎません。

多くの人は、このアプローチにはモジュール式でスケーラブルなアプリケーションを構築する上で多くの利点があると考えています。何らかの理由で、このパラダイムはデータではうまく機能しないと考えられています。専門家は、アプリケーションと同じようにオープンでサービス指向の方法でデータを表示するというロジックは明白であり、望ましいと指摘しています。オープンでサービス指向のデータ アーキテクチャは、実用レベルと戦略レベルの両方で意味を持ちます。

これが、オープンソース ソフトウェアの問題が二次的なものである理由です。最も重要な「オープン」は、オープン データ アーキテクチャがクローズド データ アーキテクチャよりも優れていると判断する最初のステップです。それが起これば、重大な転機が訪れるでしょう。オープン ファイルおよびテーブル形式 (Apache Parquet、Apache Iceberg など) は、業界全体のイノベーションを可能にするため重要です。その革新は、独立系開発者向けのサービスという形で提供されます。乱雑で、コストがかかり、脆弱で、コンプライアンスに違反するデータが大幅に削減または排除されます。データ チームは、10 年以上にわたってアプリケーション サービスで行われてきたのと同じように、最適なサービスを選択してそのデータを処理し、アーキテクチャに適合させることができます。データ アーキテクチャが追いつくべき時が来ました。

オープンデータアーキテクチャの価値に異議を唱える人々は、それが複雑すぎると主張します。あらゆる大きな技術的変化は複雑さを伴います。ミッドレンジ マシンは、当初は既存のメインフレームよりも管理が困難でした。当時、Intel ベースのサーバーは、既存のミッドレンジ システムよりも管理が困難でした。当初、パーソナル コンピュータの管理は、既存のダム端末の管理よりも複雑でした。そして、テクノロジーの変化が起こるたびに、それは通常の採用曲線を経て主流へと移行します。管理の観点から見ると、初期段階は常に複雑ですが、時間の経過とともに新しいツールとアプローチによって複雑さが軽減され、初期の複雑さのコストをはるかに上回るメリットが得られます。だからこそ技術革新が起こっているのです。

Dremio は、オープンでサービス指向のデータ アーキテクチャをより簡単に、より強力にするために作成された DaaS プラットフォームです。 Dremio を使用すると、すべての部分が適合するため、レイクハウスに対して SQL を実行するのは簡単です。その過程で、Nessie、Apache Arrow、ArrowFlight など、業界を変えるオープンソース プロジェクトが作成されました。これらはオープンソース プロジェクトです。オープンソース テクノロジは、エンタープライズ データ アーキテクチャのサービス統合層にとって重要な採用と相互運用性を促進するためです。顧客は、革新的な主要テクノロジーを採用してより良いサービスを提供できるため、メリットが得られます。オープンソース愛好家は、コードにアクセスして理解を深め、さらには改善することもできるため、メリットがあります。業界ベンダーは、これらのイノベーションを利用してレイクハウス上で SQL を迅速かつ簡単に作成できるため、メリットが得られます。

この議論で指摘しておくべき重要な点は、現実的には、ベンダーがどれだけ「オープン」であると主張しても、オープン フォーマットやオープン スタンダードのサポートについてどれだけ語っても、そのベンダーの中核がオープン ソースであっても、データ アーキテクチャがクローズであれば、それはクローズであるということです。

Snowflake が最近の記事で指摘した重要な点は、ビジネス ニーズを満たすために、データ形式やストレージ所有権などの領域で閉鎖性が必要であるということです。これは数年前には必要だったかもしれませんが、クラウド ストレージやトランザクション テーブル形式などの最近の進歩により、オープン アーキテクチャでこれらの要件を満たすことができるようになりました。オープン アーキテクチャとそれに伴うすべての利点によって要件を満たすことができるのに、企業がクローズド アーキテクチャを選択するのはなぜでしょうか。

データが第一級市民になる

業界の専門家は、データ自体がアーキテクチャの第一級の対象になる世界を提唱しています。業界のベンダーは、企業がオープンアーキテクチャのメリットを享受しやすくしています。たとえば、(1) さまざまなジョブに最適な最善のエンジンを使用できる柔軟性を持つことなどです。 （２）独自のエンジンを通じてデータにアクセスしなければならない状況を回避すること（３）将来のイノベーションを活用する準備があること（4）データウェアハウスへのデータのコピーや移動を際限なく行う複雑さを排除する。

業界のベンダーは、オープン スタンダードとオープン ソースが重要であるだけでなく、何よりもまずオープン データ アーキテクチャに重点を置いています。実装と使用が容易になるにつれて、クローズド データ アーキテクチャに対する利点が圧倒的になります。