DB管理も兼務する羽目に

クラウドによるビッグデータ活用でワリを食う管理者のため息

クラウドのおかげで、ビッグデータの管理や大規模化するデータウェアハウスの運用を行う選択肢が増えている。これらの選択肢は、クラウド管理者の役割に直接影響を与えている。

公開 2014年05月12日 08時05分

著者

Dan Sullivan

[TechTarget]

印刷する Googleで優先するソースとして追加

　IaaS（Infrastructure as a Service）を主にコンピュートおよびストレージインフラとして使おうとする企業では、データベース管理者は、データウェアハウスコンポーネントのインストール、構成、監視の管理を続けることになる。一方、オーバーヘッドを最小限に抑えようとする企業や、既存のクラウド管理者を有効に活用しようとする企業にとっては、米Amazon Web Servicesの「Amazon Redshift」のようなホステッド型データウェアハウスサービスが適切な選択肢かもしれない。しかし、こうしたホステッド型データウェアハウスを利用する場合、クラウド管理者の役割と責任に一般的なデータベース管理者の仕事が加わってくる。

　クラウド管理者が担うさまざまな責任を理解するため、クラウドで使用する大規模データウェアハウスの3つの選択肢を考えてみよう。すなわち、（1）Redshiftで提供されるホステッドデータウェアハウスサービス、（2）「Amazon Elastic MapReduce」（EMR）とともに使う「Hive」、（3）AmazonのIaaSで自前で管理するクラスタ上で使う「Apache Spark」――だ。データストアと運用モデルの組み合わせはこれら以外にも可能だが、この3つの選択肢には、代表的な幾つかの重要な考慮点が含まれている。

Amazon Redshift：ホステッドデータウェアハウスサービス

　Redshiftでは、完全なデータウェアハウスサービスが提供され、オーバーヘッドが軽減されている。このサービスは「PostgreSQL」をベースにモニタリングや基本的な管理機能（バックアップなど）が用意されている。このデータウェアハウスサービスでは、スケールアップ（より大規模なサーバを使う）やスケールアウト（サーバを追加する）によって規模を拡大できる分散データベースが実装されている。

　Redshiftを利用する場合、クラウド管理者の役割はデータベース管理者に似たものになる。一部の設計作業（物理モデルの選択など）は免れるが、他の多くの作業がクラウド管理者に降り掛かる。例えば、クラウド管理者はデータベース上のロードに応じて、データウェアハウスのノードの数やタイプを変更しなければならない。また、データベースサービスがマネージド型でも、クラウド管理者は一般的なクラウド管理作業、例えば、ID管理やアクセス制御情報のメンテナンスや、コンプライアンス上の報告要件への対応などを行う必要がある。

　Redshiftには他にも難点がある。データウェアハウスのソースのサイズ、スコープ、数が大きくなると、ETL（データの抽出、変換、ロード）が厄介になることだ。AmazonはRedshiftで、「Amazon Simple Storage Service」（S3）、「Amazon DynamoDB」および外部ホストとの統合をサポートしている。

　ETLアプリケーションの開発には多額の投資が必要になることがある。多くのソースやターゲットの間でデータを移動する必要がある場合や、使用するデータストアのタイプを変更する可能性がある場合は、米TalendなどのビッグデータETLツールの利用を検討するとよい。このツールを使えば、ターゲットデータベースを変更または追加する場合にコードの書き換えを最小限に抑えられる。

Amazon EMR上のHive：Hadoopを使ったデータウェアハウジング

　EMRでHiveを実行することで、マネージドサービスのメリットの一部が得られるが、管理者には多くの作業が要求される。クラウド管理者はHiveの論理データモデルを設計するだけでなく、データロードの管理、クラスタ構成の設計、ワークロードのモニタリングを行わなければならない。これらの作業は通常、データベース管理者が担当している。

　Hiveは、Hadoop上に構築されたデータウェアハウスシステムであり、EMRでサポートされている。Hadoopは「Hadoop Distributed File System」（HDFS）を使うように設計されているため、管理者は、データウェアハウスがどのようにHDFSとS3を使ってデータを保存するかを決める必要がある。「DistCp」ツールを使ってHadoop内外のデータをコピーでき、データがS3にある場合は「S3DistCp」ツールを使ってコピーできる。HDFSデータは、クラスタがシャットダウンされた後は存在しないため、管理者は、クラスタを終了する前にデータをS3などの永続データストアにコピーするワークフローを計画する必要がある。

　また、EMRを使用するクラウド管理者は、Hadoopクラスタの構成を指定する必要がある。指定する内容には、使用するインスタンスタイプに加え、ソースプログラム、ログファイル、データソース、SSH（Secure Shell）キーの場所が含まれる。さらに重要なことは、管理者は、データロードや長時間のバッチ処理といったワークフローのモニタリングとデバッグも行う必要があることだ。

　同じデータセットに対して複数のワークフローが実行されるときは、管理者はワークフローのスケジューリングを最適化して、ETLのオーバーヘッドを最小限に抑え、Hadoopクラスタの不要な起動とシャットダウンをなくすとよい。

Apache Spark：DIYモデル

　クラウドを主にコンピュートおよびストレージリソースとして使う場合、クラウド管理者に要求されるデータベース管理スキルのレベルが最も高くなる。だが、Apache Sparkのような新しいプラットフォームを最も柔軟に利用できる。

　対話型クエリをサポートしなければならないデータウェアハウスは、Hadoopの書き込み集約型処理モデルのMapReduceの先を行かなければならない。Apache Sparkは、ビッグデータアナリティクスのためのインメモリアナリティクスエンジン。機械学習、グラフ処理、ストリーミング、対話型クエリをサポートしている。Apacheのトップレベルプロジェクトに昇格したことが2014年2月末に発表されている。

　Sparkの開発者は、「Amazon Elastic Compute Cloud」（EC2）上のクラスタでSparkを実行するためのスクリプトを提供している。Amazonは、EMR上でのSparkと「Shark」（Spark上のHive）の実行に関するチュートリアルを公開している。クラウド管理者は管理作業全体に責任を持ち、その中にはクラスタの構成、Sparkのパラメータ設定、データロードの管理、アクセス制御の設定、ジョブのモニタリング、トラブルシューティングなどが含まれる。

印刷する

この記事の著者

Dan Sullivan

クラウドによるビッグデータ活用でワリを食う管理者のため息

関連記事

Amazon Redshift：ホステッドデータウェアハウスサービス

関連記事

Amazon EMR上のHive：Hadoopを使ったデータウェアハウジング

Apache Spark：DIYモデル

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

クラウドによるビッグデータ活用でワリを食う管理者のため息

関連記事

Amazon Redshift：ホステッドデータウェアハウスサービス

関連記事

Amazon EMR上のHive：Hadoopを使ったデータウェアハウジング

Apache Spark：DIYモデル

この記事の著者

関連記事

Amazon、Google、NTTドコモの事例が示すビッグデータの可能性

【事例】じゃらん、ゼクシィにも活用、リクルートはなぜ「Hadoop」を使う？

医療分野のビッグデータ事例 「Hadoop」を採用した徳島大学病院

先行事例で見えてきたビッグデータ活用の課題

【事例】「意思決定に貢献する」データ活用法とビッグデータ活用に必要なスキル

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

医療分野のビッグデータ事例　「Hadoop」を採用した徳島大学病院