本当に必要なビッグデータ活用インフラはこれだ!! PivotalHD + Isilon が作り出すデータレイク構想 東京エレクトロンデバイス株式会社 CN 事業統括本部 2014 年 8 月 本掲載内容に関するお問合せはこちらにお願いします 東京エレクトロンデバイス株式会社 CN 事業統括本部 TE

Transcription

1 本当に必要なビッグデータ活用インフラはこれだ!! PivotalHD + Isilon が作り出すデータレイク構想 東京エレクトロンデバイス株式会社 CN 事業統括本部 2014 年 8 月 本掲載内容に関するお問合せはこちらにお願いします 東京エレクトロンデバイス株式会社 CN 事業統括本部 TEL:

2 昨今 ビッグデータ活用に関する話題は テレビ 新聞 各種メディアなどでも取り上げられ 大きな期待とともに注目されています その一方で ビッグデータ活用を実現するために 人 データ システムの 3 つの観点で実現しなければならない要素に対する取り組みが必要となってきているのも事実です 本資料では その中でもシステムにフォーカスを当て データレイク と呼ばれるアプローチにより実現するビッグデータインフラについて解説します < ビッグデータとは?> ビッグデータというと 単に大規模なデータを 扱う という意味に捉えられがちです ですが 本当の意味でのビッグデータとは これまでデータ活 の対象としなかったデータをも活 対象とし そのデータの蓄積 処理 分析を可能にするシステムとそれを使いこなす人材 これらの要素全てを包括したものを指します これらの要素が揃って初めて本来の意味を成し それを実現した企業がビジネスチャンスを 出したことから ビッグデータという 葉が注 され始めたといわれています つまり 様々なデータを 活 していくことこそが ビッグデータの本当の意味となります 人材 組織データサイエンティストなど データ処理 蓄積 分析技術 Hadoop NoSQL 機械学習 東経解析など 非構造化データテキスト 動画 音声 センサー GPS など 構造化データ顧客データ 売上データなど 図 1: ビッグデータの構成要素 ビッグデータの 活用 という観点では 従来から基幹システム等で管理 利 される顧客データや売上データなどの構造化データに加えて 今まで活用対象として られていなかったログデータやセンサーなどの非構造化データも活用対象データとなります 加えて そのデータを使いこなすためのシステムと人材 計 4 つの要素がビッグデータには含まれます ( 図 1) が このシステムの部分には 多くの技術が登場しており どの技術が最適なシステムを実現してくれるのか判断が難しくなってきているという課題があります では 多くの企業ではどういったデータ活 が われているのかを考えてみます < データ活用現場における よく聞く声 > データ活 そのものは 規模の や深さを問わず多くの企業で少なからず われています 全社レベルのデータ活用を実現するまでには 小規模なワーキンググループでデータ活用方法と KPI を設定し PDCA サイクルを繰り返し 他の部 へと範囲 規模を拡 しながら全社展開していくというアプローチが 般的な流れとなっています しかし この流れの中でシステムを構築していくため 現場レベルではそれぞれが担当する業務に則した使い勝 の良い部 専 のシステムを構築したり 新しいプロジェクトのための専 システムが構築されたりすることも事実です 例えば マーケティング部 商品管理 経営分析 といった部 や 途に合わせて個別にデータウェアハウスが ち上がっている状態が典型です まさにデータウェアハウスのサイロ化です さらに そのサイロ化されたシステムからデータを抽出し 加工された情報が 個人 PC にだけ保存されており 有益な情報であるにもかかわらず共有されていないという事もあります 現在 データ活 への注 が まる中で新しい気づきが得られるようなデータ分析を う取り組みを開始している企業では このサイロ化したシステムが実は大きな問題となっています データ活 の現場では きく経営層 パワーユーザー 管理職 般社員の 3 つのプレイヤーに分けられます データ活 への意識が まれば まるほど 各プレイヤーにより活 法のバリエーションは増えますが ( 図 2) サイロ化によりデータが点在するため 各 が必要なデータが えない 活 できないという状況が まれ 結果としてビックデータ活用の大きな課題となっています ( 図 3) モニタリングツール モニタリングツール ( ダッシュボード ) にて計画に対する達成度の検証戦略修正 針の決定 経営層 パワーユーザー 分析ツール データを使い分析やシュミレーションを い KPI/ 計画値の 案 経営層 一面的なデータだけでなく 社外や過去履歴を含めた多面的なデータを使った傾向分析結果が欲しい 新しい気づきが得られるような分析データが欲しい オンデマンドで たい観点の分析結果が欲しい パワーユーザー 様々な分析手法を試したいが 分析対象データが乏しい 分析対象データを 元管理できていないため 理想的な分析が えない レポーティングツール レポーティングツールで KPI/ 計画値を確認しながら日常業務を実施 管理職一般社員 管理職 般社員 閲覧可能なデータが限られている環境しかない 個々人で好きな観点でデータを使った傾向把握をしたいが 元になるデータが散在しているため実現ができない 図 2: データ活用者の課題

3 この点在されたデータの一元管理を実現させ さらなる拡張を実現するのが データレイク 構想です データレイクとは 文字通りデータの湖を作るイメージでデータの 元管理を実現する構想です サイロ化しているデータウェアハスの統合とデータ活用における最適なシステムを実現するという観点で 今回 Pivotal 社が提供する Hadoop 製品の PivotalHD と EMC 社が提供するスケールアウト NAS の Isilon 製品が提唱するデータレイク構想を組み合わせたアプローチをご紹介します 顧客情報 経営分析 DWH <Pivotal のデータレイクの考え方 > Pivotal 社は EMC 社 VMware 社と GE 社 (GeneralElectric 社 ) から共同出資され設 された EMC グループ会社の 1 社です EMC VMware 社が開発提供を っていたミドルウエア製品群を集約し EMC グループの第三の柱としてビジネス展開が われています その Pivotal 社が手掛ける製品群の中に エンタープライズ向け Hadoop 製品の PivotalHD がデータレイクを実現するソリューションとして提供されています ( 図 4) PivotalHD は ApacheHadoop をベースにした Hadoop 製品ではありますが そのファイルシステムの が持つ高い拡張性に加えて 内に格納されたデータを活用の要件に応じてデータ処理エンジンを使い分けることを可能にし データレイクを実現しています DWH のサイロ化により横断的なデータ分析ができない DWH 外のデータとの連携活用ができない 過去履歴を含めた 規模データ蓄積環境がない マーケティング部門 DHW 役員 マネージャー経営戦略経理 財務営業マーケティング 外部向け DWH 売上情報 分析対象データ 図 3: データ活 がうまく えないシステム典型例 そのデータ処理エンジンには ApacheHadoop で提供される MapReduce Hive Pig などはさることながら ストリーミングやインメモリ処理も可能とする機構を備えています 中でもビッグデータの活 において SQL インターフェースが提供されることは 多くの企業に Hadoop を使ったデータ活用の実現ハードルを下げる要素の一つとなりますが PivotalHD はまさにそのハードルを下げる製品で 業界標準 SQL をサポートした HAWQ と呼ばれる SQL エンジン活 ができるという特 を持っています 他のエンタープライズ Hadoop 製品の中にも SQL インターフェースを持った製品はありますが この HAWQ は Pivotal 社が 年 GreenplumDB という DWH 用 DB 製品の開発で培った DB エンジンを実装しており 性能はもちろん利用可能な SQL 関数も豊富であるため BI/BA ツールや既存の SQL 資産の有効活用を実現します ( 図 5) 部門用 DWH 商品管理 DWH ストリームインジェスチョン ストリーミングサービス 在庫情報 アナリティックワークロード SQL サービス サマリーデータしか扱えない 個人 PC に蓄積されているデータが多い 分析資産の共有ができない ファイルサーバー A ファイルサーバー B ファイルサーバー C ファイルサーバー D メール Web コンテンツアクセスログ M2M SNS 音声 画像 映像 DataLake: データ処理基盤の基盤要素となる にデータを蓄積 あらゆるデータ 要件に応じて処理エンジンを使い分ける Pivotal データプラットフォーム DataLake New Data-fabrics Software-DefinedDatacenter 図 4:PivotalDataLake オペレーショナルインテリジェンスインメモリサービス GemFireXD... ETC ランタイムアプリケーションインメモリオブジェクトサービス GemFireXD HAWQ アドバンスドデータベースサービス PivotalHD Enterprise リソース管理 & ワークフロー Yarn Zookeeper Oozie HBase HVE Sqoop Xtension フレームワーク ANSISQL+ アナリティクス カタログサービス ダイナミック パイプライニング クエリオプティマイザ Pig,Hive, Mahout MapReduce Flume Command Center コンフィグデプロイモニター管理 Apache PivotalHD 追加機能 図 5:PivotalHD+HAWQ

4 <EMCIsilon( アイシロン ) のデータレイクの考え方 > EMCIsilon( 以下 Isilon) は スモールスタートからリニアに拡張が可能なスケールアウト型 NAS 製品です 昨今 テクノロジーの進化に伴い様々なプロトコルでデータの取り扱いが可能となる中で Isilon は CIFS/NFS/FTP/HTTP/REST/ など多種多様なプロトコルをサポートし あらゆるプロトコルからのファイルアクセスを可能にするデータレイクを提供しています ビッグデータ活用という観点では 多種多様なデータを取り込み活用することが求められますが Isilon が備える幅広いインターフェースによりデータの収集とHadoop を利 したデータ分析処理をも可能にします ( 図 6) 加えて このHadoop の利 を可能にするインターフェースはデータ活用のみならず Hadoop システムのシステム効率と可 性を めることを可能にします 具体的には Hadoop システムを構築する場合 きくファイルシステムと並列処理機構の2つの観点からサイジングを いますが このファイルシステム領域をIsilon 側で構築することが可能となるため サイジングが容易になります 加えてIsilon が持つ拡張性と可用性により が持つ拡張メリットを維持しながら可用性図 6:IsilonDataLake の高い の構築を実現します ( 図 7) 高い拡張性 全ノード Active で動作するコントローラー 複数ノード構成での 1 ボリューム NAS に 最小ノード数 : 3 台 最大 20PB まで拡張可能 20PB 1)Isilon が持つ高い拡張性最小構成は 3 ノードからスタートでき 最大で 144 ノード 物理容量 20PB( 実効容量は約 15PB) を 1 つのボリュームとして使うことができます 全てのノードには HDD 以外にコントローラとネットワークインターフェースが搭載されており 全てのコントローラ ( 全てのノード ) が Active で稼働できるため ノード増設とともに全体パフォーマンスが向上していきます 必要な時に必要な容量を増設できるスケールアウト型ストレージです 2)Isilon が持つ高い可用性書き込まれるデータは ファイル分割され あらかじめ設定された保護レベルに従った数量のパリティデータとともに各ノードに分散書き込みされます Hadoop では 1 つのデータに対して 3 つのレプリカを作成し冗 構成を 実現していますが Isilon の場合はパリティデータとともに並列分散書き込みをする事で データ利 効率を めながら高い可用性を実現します また 最大 4 ノード同時障害でも耐えうる保護レベル (N+4) や 一般的な NAS でサポートされているようなその他の機能 (SnapShot Replication 他 ) が使えるメリットがあります <Pivotal と Isilon のデータレイクを融合 > これら 2 つのデータレイクの共通項は にあります PivotalHD は 上のデータへのアクセスエンジン の利便性を めることで Isilon は 上のデータのイン / アウトおよび 元管理と拡張を可能にすることで データレイクを実現します すなわち 汎用ハードウェアで構築する Hadoop システムでは実現が難しかった点を克服するだけではなく さらに使いやすい Hadoop システムを実現するビッグデータプラットフォームを構築できることになります ( 図 8) 高い可用性 ファイル分割による分散配置 選択可能な保護レベル最大 4ノード同時障害まで対応 図 7:Isilon の高い拡張性と可用性 分散ファイルシステム 1 3 つレプリカを作成することにより 1 ノードにおけるデータ搭載効率が悪くなる 2 容量要件 性能要件を満たすためのサイジングが難しいことがある 容量 vs 性能の観点で必要ノード数がマッチしない 分散アーキテクチャメリットを残しつつ データ搭載効率を め 更に可用性も担保するシステム EMCISILON + MapReduce 規模分散処理フレームワーク 1 データ処理 語 (MapReduce) が 専用言語であるため 分析ツールからのアクセスが難しい MapReduce エンジニアが少ない 2 枯れたデータ処理 語の つである SQL ライクな処理言語 (Hive Pig 等 ) も存在するが 汎用 SQL と同等レベルでない 性能を含めた処理安定性に不安あり 分散アーキテクチャメリットを使いこなし 業界標準 SQL に準拠した SQL インターフェース 図 8: より使いやすいビッグデータプラットフォーム

5 <PivotalHD/HAWQ+Isilon 利 イメージ > Pivotal と Isilon のデータレイクを使ったビッグデータプラットフォームの利 イメージを 2 つご紹介します 1 つ目は Isilon が持つ豊富なインターフェースを利 した柔軟なデータ取り込みと活 を実現するプラットフォームです ( 図 9) 活用対象のデータの取り込みには CIFS/NFS などのプロトコルを利 し ファイルサーバー感覚で Isilon にデータを取り込みます 取り込まれたデータを Isilon の ゲートウェイを利 し PivotalHD+HAWQ からアクセスすることにより 既存の SQL 資産や BI/BA ツールを用いたデータ活用が可能となります Hadoop 活 において きな課題であるデータの取り込みと活 を解決し データの 元管理と柔軟な分析活 を可能にするプラットフォームを実現します 各種システム SQL アクセス アクセスログ顧客情報購買情報アクセスログ顧客情報購買情報 CIFS/NFS/. OneFS 図 9:PivotalHD/HAWQ+Isilon 利 イメージ 1 2 つ の利 イメージは 低スペックマシンにて構築をしてきた Hadoop 環境のシステム効率化を図るイメージです Hadoop のサイジングにおいては 性能 (Compute ノード ) とデータ容量 (Data ノード ) の 2 つの軸で検討を います データ量の増加や くなる性能要件 分析要件の多様化などに対しても サーバー増設により対応ができることが Hadoop のメリットではありますが 例えば 性能観点では 50 台のサーバーで構成可能であるものの 容量の観点では 1 0 台のサーバーが必要となるケースもあり 結局サーバー 100 台で構成をする事も珍しくはありません 1 0 台のサーバーで Hadoop システムを稼働させた場合 運 管理の観点での負荷は くなりがちです そこで Compute ノード Data ノードを担保するシステムを分け Isilon に容量管理の役割を担わせることで 効率的なシステムの実現が可能となります 加えて Isilon が持つ高い保護機能および高い拡張性により 通常の Hadoop システムが持つ拡張性を担保しながらより い可 性でデータの運 管理が可能となります ( 図 10) さらに Compute ノード側に PivotalHD+HAWQ を活用することにより 既存の MapReduce/Hive 等の資産を有効活用しつつ汎用性の高い SQL を利 した新しいデータ活 が可能となります Before 低 Spec マシンで SmalStart した Hadoop 環境の大規模化 - 分析データの 容量化に伴い 性能要件以上のサーバ台数に - システム効率化の観点で オーバーヘッドが多数存在 -MapReduce Hive が使えるエンジニアが必ず必要 After PivotalHD/HAWQ + Isilon にて 効率化の図られた利便性の高い Hadoop 環境を実現 -Compute とデータ領域の役割分担で システム効率化を実現 - 要件に合わせた拡張が可能 - 汎用 SQL の活用が可能なため BI/BA ツールにてアクセスも可能 性能増設 容量増設 図 10:PivotalHD/HAWQ+Isilon 利 イメージ 2 EMC ISILON Data

6 < もっと使える Hadoop を!> まとめになりますが これまでご紹介した通り ビッグデータ活用において重要な要素は データレイク というアプローチとそれを実現する Hadoop であるということがご理解頂けたかと思います その Hadoop を使いこなすにはいくつかの越えなければならないハードルがありますが PivotalHD+HAWQ xisilon がそれを実現します この 2 つが実現する Hadoop こそが ビッグデータの活用につなげるシステムであり まさに もっと使える Hadoop となります (HadoopDistributedFileSystem) 分散ファイルシステム MapReduce 規模分散処理フレームワーク Hadoop 1) 最小 3 つのレプリカを作成することにより 1 ノードにおけるデータ搭載効率が悪くなる 2) 容量 性能要件を満たすためのサイジングが難しい - 容量 vs 性能の観点で必要ノード数がマッチしない 1) データ処理 語 (MapReduce) が 専用言語であるため - 分析ツールからのアクセスが難しい - MapReduce エンジニアが少ない 2) 枯れたデータ処理 語の つである SQL ライクな処理減 (Hive Pig 等 ) も存在するが - 汎用 SQL と同等レベルでない - 性能を含めた処理安定性に不安あり PivotalHD+HAWQ xisilon Isilon の インターフェースを活用することにより Isilon が持つスケールアウト NAS としての特 を活 が可能となり データ搭載効率の向上とさらに い可 性の担保を実現 PivotalHD+HAWQ が持つ分散処理 DB 用 SQL エンジンを機能を使うことにより 分散アーキテクチャーである Hadoop システム上で 業界標準 SQL に準拠した SQL にて 内データへのアクセスを可能に 図 11: スモールスタート可能なビッグデータプラットフォーム 弊社東京エレクトロンデバイスでは 10 年以上と 6 年以上に渡る Isilon 製品の販売 サポートと Pivotal 製品の販売 サポートの経験をもとに 今後の皆様のビッグデータ活用基盤のご提案 構築サポートを提供して参ります

7 もっと使える Hadoop を!