クラウドドラマ、データウェアハウスの悲劇？

何十年にもわたって組織を運営してきた企業にとって、データ ウェアハウスは業務の報告や理解に役立つ効果的な手段となります。

データ ウェアハウスが登場する前は、異なるシステムからデータをレポートして収集することは、コストがかかり、時間がかかり、多くの場合無駄な作業でしたが、単一のリポジトリからクリーンで統合されたデータを確実に取得できました。

複数のレポート ツールを単一のデータ モデルに接続できるようになったことで、現在データとして知られている業界、つまりビジネス インテリジェンス (BI) が誕生しました。しかし、従来のデータ ウェアハウス アーキテクチャと方法論の本来の概念とアプリケーションは、複雑な方法論と設計、不適切なツール、高い開発、保守、インフラストラクチャ コストなどの負担により、今日では受け入れられなくなっています。

[[256232]]

つい最近まで、コンピューティングは依然として非常に高価なリソースであり、データ ウェアハウスは依然として「希少性からの管理」という概念によって制限されていたと言えます。それどころか、さまざまなスキームのデータ設計では、データの集約、複雑なサブデータベース設計の作成、リソースの使用状況の綿密な監視などによって、データベースのサイズを縮小しようとしています。

データ ウェアハウスは死んだのか?

ビッグデータ、特に Hadoop の台頭により、ベンダー、アナリスト、評論家がデータ ウェアハウスは死んだと言っているのをよく耳にします。結局のところ、それらは高価で、堅固で、遅いのです。それはまさに、イーグルスのリードシンガー、グレン・フライが歌った「シンプルな資源の魅力、それは強い引力を持っている」という言葉の通りだ。

ビッグデータはゲームチェンジャーであり、データ ウェアハウスの後継者であるとよく言われます。しかし、そうではありません。むしろ、ビッグ データは、データ ウェアハウスが、有用で実用的な分析データのソースになるという目標を達成する (または少なくとも本来の目的に近いものにまで拡張する) 機会を提供します。

しかし、データ ウェアハウスの考え方では、これを実現するためには物理的な構造への執着を捨てなければなりません。代わりに、将来のデータ ウェアハウスは、さまざまなデータ ソースを処理する必要があります。これは仮想ファブリックとして機能し、「静かな」履歴データ ウェアハウス、リアルタイムの更新とリアルタイムの応答を提供するための自由な分析データベースを実行し、また Hadoop などの他の非リレーショナル ビッグ データ クラスターのエンクロージャー戦略も実行します。このように、ビッグ データは、組織に、入力の量と種類の両面で分析業務の規模を拡大することを強いるとともに、同様に重要なこととして、組織内外でテクノロジーの使用を拡大および強化する方法に関するビジョンを拡大することを強います。

オンプレミスですか?雲？ハイブリッド？

以下は、現在のデータ ウェアハウス プラットフォームの部分的な (完全なものではありません) リストです。

従来型データ ウェアハウスの「生き残り」は、もともとオンプレミスで展開され、現在はハイブリッド モデルになっています。

• IBM
• マイクロソフト
• テラデータ
• ピボタル/グリーンプラム
• オラクル

ピュアクラウド:

• 赤方偏移
• スノーフレーク
• インコルタ
• グーグル

一般に、リレーショナル データベース (RDB) データ ウェアハウスは、上記のモデル、特にトランザクション処理用に設計された RDB のすべての長所と短所を継承しますが、後者は元々データ ウェアハウスと分析をサポートするための特別な処理要件用に設計されています。

これは、Microsoft、IBM、Oracle にも当てはまります。データ ウェアハウスの初期の頃、これら 3 つの製品のパフォーマンスは非常に低かったため、顧客は Teradata、Red Brick、Pivo​​tal/Greemplum、Vertica、Paracel など、データ ウェアハウス操作専用に設計された製品を求めるようになりました。これらの製品のソース コードは Amazon によってライセンス供与され、Redshift に名前が変更されました。

ベンダーはデータ ウェアハウス製品の改善において一定の進歩を遂げています。たとえば、Microsoft は Sybase に SQL Server のコードを提供する権限を与え、IBM と Oracle も継続的に製品の改善と強化を行ってきました。

現時点では、5 つの「生き残り」すべてが、完全なクラウド、オンプレミス、ハイブリッド クラウド ソリューションを備えています。問題は、「純粋なクラウド コンピューティング」製品と「生き残った」クラウド製品の間に本当に違いがあるかどうかです。

各製品には重複する機能がいくつかありますが、中心となる質問は次のとおりです。

• クラウドベースのデータ ウェアハウスの利点は何ですか?
• 生き残った企業は、純粋なクラウド製品に比べて十分な利点を提供しているでしょうか?

ビッグデータサービス企業であるAloomaは次のように指摘した。

• 「各クラウド ウェアハウスは、特定の構造に従うのではなく、独自の構造を持っています。たとえば、Amazon Redshift は従来のデータ ウェアハウスの構造を模倣していますが、Google BigQuery はサーバーをまったく使用しないため、ユーザーはストレージをセットアップして料金を支払うことなく、データを照会して共有できます。」

では、クラウド データ ウェアハウスは何をもたらすのでしょうか?

スケール/スケーラビリティ:通常、コンピューティング リソースは、データ ストレージよりもデータ ウェアハウスの高価なコンポーネントです。コンピューティング リソースをストレージから分離することにより、データ ウェアハウスは大量のデータを保存し、オンデマンドで情報を処理できます。オンプレミス ソリューションでは、このすべてのデータをはるかに高いコストでローカルに保存する必要があります。

柔軟性:データを計算プロセスから分離することで、ユーザーは必要な数の仮想データ ウェアハウスを作成できます。

パフォーマンス:これは、データ ウェアハウス/分析クエリでは、サーバーを数台多く実行するだけではパフォーマンスが向上するわけではないため、依然として当然のことです。 Teradata のような専門ベンダーがこれほど成功している理由は、何十年にも及ぶエンジニアリング、超並列処理の最適化、ワークロード管理テクノロジ、そしておそらく最も重要なのは、Teradata のソフトウェア エンジンとユーザーが実行する独自のハードウェアとの連携であり、そのパフォーマンスは絶えず向上しています。

コスト:クラウドによって価格モデルが変わると誰もが言いますが、実装にどれくらいのコストがかかるかは誰にもわかりません。安価なストレージの誘惑は、比較的安価であっても無料ではないため、事態が手に負えなくなる原因となる可能性があります。従来のベンダーはすべてサブスクリプション価格プランに移行していますが、各契約は非常に複雑です。ここでの推奨事項は、契約と価格設定の詳細についての専門家を雇うことです (ERP 分野ではこれがよく見られます)。

セキュリティ:特にハイブリッド ソリューションではアクセス ポイントが非常に多いため、これは難しい問題です。ほとんどのデータベース製品は内部の脅威に対するセキュリティを実装していますが、近年、外部からの脅威が急増しています。

データ ウェアハウスにはどのような機能が必要ですか?

• あらゆるデータのローカリティ (ローカル ディスク、Hadoop、プライベート クラウド データ、パブリック クラウド データ) をサポートします。
• データベース内の高度な分析。
• 空間、時系列、テキストなどのネイティブ データ タイプを処理する機能。
• 機械学習、地理空間、グラフ、テキスト分析などの新しい分析ワークロードを実行する機能。
• オンプレミス、プライベート、パブリック クラウドを含む柔軟な展開。
• ビッグデータクエリの最適化。
• 複雑なクエリフォーム。
• シャーディングだけでなく、モデルベースの超並列処理。
• ワークロード管理。
• 負荷分散。
• 数千の同時クエリに拡張可能。
• 完全な ANSI SQL など。

最後に

ネイティブ クラウド データ ウェアハウス データベースは、以前の「残存」データベースにはない機能と利点を提供する可能性がありますが、それらはどの程度堅牢なのでしょうか。現時点ではコメントできませんが、純粋なクラウド製品の中には、ユーザーの多くのニーズを満たすのが比較的不十分なものもあります。これらはデータ ウェアハウス製品ですか、それとも PowerPoint スライド上でまとめられた既存のモジュールのコレクションですか?たとえば、Cloudera のデータ ウェアハウスには、データ ウェアハウスと呼ばれるようになる前に存在しなかったものは何もありません。それは、異なる種の異なる細胞株をペトリ皿に放り込んで、それを生物と呼ぶようなものです。

ここでは、古い格言がまだ当てはまるかもしれません。「猫が黒か白かは問題ではありません。ネズミを捕まえる限り、それは良い猫です。」ビッグデータの愛好家は、組織にとっての価値に注意を払わずに、実装と技術的な問題だけを強調して、従来のデータ ウェアハウスを放棄しようとします。いわゆる「データレイク」は良い解決策ではないかもしれません。