HadoopTimes

ストリーミングアーキテクチャ Apache Kafka とMapR Streams による新しい設計手法
技術情報

エンタープライズデータハブの構築: 基盤ソフトウェアの選択

データウェアハウスの用途ではないタスクを、データウェアハウスで処理するのは避けましょう。データウェアハウスは、構造化されたデータ、構造化されていないデータ、および半構造化されたデータのすべての用途の処理装置ではありません。増え続けるさまざまな端末やプラットフォームから四六時中投下されるデータの処理は、本来のデータウェアハウスの用途ではありません。データウェアハウスの本来の用途は高度な数値分析、そしてETL (抽出、加工、書き出し) 処理です。しかしビッグデータによりデータウェアハウスでのタスクの処理が難しくなっています。

では、分刻みで増えるビッグデータの蓄積およびそのすべて情報から利益を生み出す要求を処理するにはどうすればよいのでしょうか。有効な解決策は、エンタープライズデータハブ (EDH) です。EDHは複数のソースからあらゆるデータを収集し、それを瞬時に処理して企業全体で利用できるようにするセントラルプラットフォームとして機能します。つまり、データウェアハウスの補完として複数のワークロードを処理できるのがEDHです。高速な着信ストリームデータを読み込み、それを処理・加工することができます。また生成された出力を既存のデータウェアハウスで読み込むことも可能です。EDHは、データウェアハウスで現在実行されている、複雑で過度にリソースを消費するELTワークロードの一部を処理するための、外部加工エンジンとして使用することもできます。あまり頻繁に使用されないロングテールデータの大掛かりな履歴分析を実行することもできます。そうすることによって、本来リソースを集結させるべきジョブにデータウェアハウスの処理を集中できます。多くの企業が、EDHを起点としたこのような「データウェアハウス最適化」戦略を追求しています。

この記事ではハブの処理を向上する基盤ソフトウェアについて説明します。システムを効率的かつ高い拡張性で実行できる基盤ハードウェアの詳細については、EDH構築についてのCiscoのブログを参照してください。すべてのデータソースをEDHに集約するには、データ統合についてのInfomaticaのブログを参照してください。

基盤の構築

EDHに読み込む可能性のあるデータ型は多岐に及ぶため、幅広いデータを保存できる基盤プラットフォームが必要です。それだけではなく、既存システムがデータ量の急増ですぐに圧迫されてしまうおそれがあるため、データ量に合わせてサーバーを追加して拡張展開できた方が良いでしょう。EDHの用途は、厳格なサービスレベルアグリーメントを満たすために役立つ高可用性、障害復旧、およびセキュリティなどエンタープライズレベルの機能に求められる業務上重要なデータウェアハウスおよびその他のエンタープライズアーキテクチャを補完することです。上記はEDHを走らせるソフトウェアの選択に影響する要因の一部にすぎません。

基盤ソフトウェアとしてのApache™ Hadoop®

ビッグデータの処理およびEDHの利用のための費用対効果が高く、強力なソリューションを探すときによく利用されるテクノロジーの選択肢はますます増えています。Apache Hadoop固有機能として、企業は全体を横断して大量の構造化されたデータ、構造化されていないデータ、および半構造化されたデータを保存して効率的に利用することができます。このようなデータをすべて1つにまとめることにより、データの深堀やより正確な分析が可能になります。

大規模なHadoopエコシステムの一部として利用できるあらゆるデータ処理および分析ツールにより、EDHにHadoopを使って展開するテクノロジーの選択肢はあまたとあります。データのストリーミング、機械学習、リアルタイムクエリ、更にはSQL-on-Hadoopまで、複数のテクノロジーを選択できます。歴史の長いソフトウェア企業でさえ、実績のある自社製品にHadoopを適用して正常に機能しています。Hadoopに対応できる開発者およびIT担当者はますます増えており、Hadoopは将来的に、今日のエンタープライズアーキテクチャでいうところのデータウェアハウスやリレーショナルデータベースと同じようにありふれたフレーズになる可能性があります。

ただし、Hadoopソリューションに向けて社内体制を整えることも忘れないようにしましょう。EDHの展開への最適化が完了していないと、業務上重要なデータウェアハウスの補完は期待できないので、エンタープライズレベルの要件に準拠する必要があります。まず明らかに重要なのは、高い稼働率、事業継続戦略、セキュリティ対策、および恒常的な高パフォーマンスです。これらほど明確ではないものの、同じくらい重要な要件は何でしょうか。

EDHの重要なコンセプトがマルチテナントという概念です。EDHでは異なるユーザーグループ、データセット、ジョブ、およびアプリケーションが1つのクラスターに共存します。ただしそれぞれの独立性は維持されています。EDHではさまざまなソースのデータが蓄積されるため、必然的に異なるユーザーグループやデータセットのハブになります。マルチテナントの代替えは、ユーザーグループごとに独立した個別のクラスターを構築することですが、実際にやってみると、これは極めて高度なメンテナンス操作となることに気づきます。

EDHのためのApache Hadoopを含むMapRディストリビューション

MapRは、複数のソースの構造化されたデータやマルチ構造化されたデータを処理して分析可能な形式に統合する機能だけでなく、フルデータプロテクション、事業継続性および高可用性といった機能を備え企業用途に最適化されたHadoopディストリビューションを提供しています。同様に重要なのが、MapRでは、論理ボリューム、統合型セキュリティ、データ割り当て制御、およびジョブ割り当て制御のサポートを含め複数の機能が組み込まれたマルチテナントがサポートされていることです。多くのMapRユーザーがEDHを展開して大きな成功を収めています。またMapR固有の機能により、以前は圧迫されていたエンタープライズアーキテクチャへの価値ある補完機能の展開を可能にしています。

まだMapRの展開がお済みでない方は、このガ―トナーの最新動画を見て、エンタープライズデータハブの構築成功のための重要な懸案事項をご覧ください。

こちらの記事もおすすめです