Microsoft Word - htsst-axies2013_backup.doc

Transcription

1 Extreme Big Data 時代に向けた TSUBAME スーパーコンピュータでの取り組み 佐藤仁, 松岡聡 東京工業大学学術国際情報センター 概要 :2010 年 11 月より 東京工業大学学術国際情報センターでは スーパーコンピュータ TSUBAME2 の運用を行ってきた 近年 様々な分野で 大規模なデータ処理の需要が高まってきており TSUBAME2 上でも 例外ではなく 実験器や観測器 あるいは スーパーコンピュータ上のシミュレーションから生成された大量のデータに対する分析処理への対応の要求が非常に大きくなってきている 本稿では TSUBAME2 上での大規模データ処理に関する活動の一部を紹介し 将来のスーパーコンピュータ上での大規模データ処理にむけた活動について述べる 1 はじめに近年 情報技術の発達により 人類の取り扱う データ量が爆発的に増加している 例えば Google 社では 1 日に 20 PB 以上のデータに対してクラ スタ計算機を用いた並列分散処理を行っていると 報告されている 科学技術計算の分野においても この傾向は当てはまり 高エネルギー物理学 生 物学 天文学などの分野においても大規模なデー タに対して並列分散処理を行う試みが広く行われ ている 東京工業大学 ( 東工大 ) 学術国際情報セン ター (GSIC) では 2010 年 11 月よりスーパーコン ピュータ TSUBAME2 の運用を行ってきた この TSUBAME2 も 例外ではなく 実験器や観 測器 あるいは スーパーコンピュータ上のシミ ュレーションから生成された大量のデータに対す る分析処理への対応の要求が非常に大きい 本稿では TSUBAME2 上での大規模データ処 理に関する活動の一部を紹介する まず TSUBAME2 の大規模データ処理を支えるアーキ テクチャの構成の現状を示し ひとつの事例とし て どのようにストレージ構成が変遷してきたか を示めす また TSUBAME2 上で動作する大規 模データ処理関連のソフトウェアについて紹介し 最後に 将来のスーパーコンピュータ上での大規 模データ処理にむけた活動について述べる た さらに 2013 年 9 月 これまで TSUBAME2.0 に搭載されていた NVIDIA M2050 GPU アクセラレータを NVIDIA Tesla K20X へと置き換え 既存の TSUBAME2.0 をアップグレードし 理論ピーク性能 5.76PFlops( 倍精度 ) 17.1PFlops( 単精度 ) の TSUBAME2.5 の運用を開始した 図 1 に 現在の TSUBAME2 の全体の構成について示す 2013 年 9 月現在 TSUBAME2 は 1422 台の計算ノードからなり 総メインメモリ容量は 80TB を超える また 各計算ノードには SSD が搭載され 総容量は 190TB 以上となっている これらの計算ノードは フルバイセクション構成の QDR Infiniband ネットワークにより相互に接続され さらに 7PB 超の HDD によるストレージ領域や 4PB のテープライブラリ領域とも接続されており 大規模データ処理にも適した構成となっている この章では まず 2013 年 9 月現在の TSUBAME2 (version 2.5) の構成に触れ その後 TSUBAME2 上での大規模データ処理を支えるストレージの構成の詳細について述べる 2 TSUBAME2 の構成 2010 年 11 月 東工大 GSIC では スーパーコ ンピュータ TSUBAME2.0 [1] の運用を開始し

2 x5 2.1 計算ノード PCI E gen2 x16 x2slot/node GSIC:NVIDIA Tesla S1070GPU 図 1 TSUBAME2 の全体構成 TSUBAME2 の計算ノードは 1408 台の Thin ノード 24 台の Medium ノード 10 台の Fat ノ ードと呼ばれる計算ノード群からなる これらの 計算ノードの違いは主には搭載されるメモリ容量 の違いからなる これらの全ての計算ノード上で OS として 標準的な Linux である 64bit 対応の x86 ベースの SuSE Linux Enterprise Server 11 が動作している 従って 標準的なデスクトップ PC やサーバで動作する多くのオープンソースソ フトウェアは特別な改変をすることなく動作させ ることが可能である Thin ノードは HP ProLiant SL390s G7 からな り CPU として Intel Xeon X GHz (6 core) を 2 socket GPU アクセラレータとして NVIDIA Tesla K20X を 3 つ搭載する メインメ モリとして計 54GB ( 一部 96GB) の DDR3 メモリ を搭載し また 60GB ( 一部 120GB) の SSD 2 台 を RAID0 によりローカルストレージを構成する また 40Gbps の QDR Inifniband の HCA (Host Channel Adaptor) を 2 つ持ち 各計算ノードやス トレージへ接続されている 一方 Medium ノードと Fat ノードはともに HP ProLiant DL580 DL からなり CPU として Intel Xeon X GHz (8 core) を 4 socket GPU アクセラレータとして NVIDIA Tesla S1070 (Medium ノードでは一部 NextIO vcore Express 2070 を搭載 ) を備える Medium ノード では計 128GB Fat ノードでは DDR3 メモリを計 512GB( 一部 256GB) 搭載するが ローカルストレ ージは Medium ノード Fat ノードとも 128GB の SSD4 台を RAID0 として構成する この他に 40 Gbps の QDR Infiniband の HCA を 1 つ持ち 他の計算ノードやストレージへ接続されている 2.2 ネットワーク各計算ノードとストレージとの間は QDR Infiniband のインターコネクトにより接続される このインターコネクトは 2 段のスイッチからなるファットツリー フルバイセクション構成で Dual rail により各 rail がファットツリーを構成する エッジスイッチとして 36 ポートの Voltaire GridDirector 4036 を 185 台 ( うち 6 台は Voltaire GridDirector 4036e) を持ち 各エッジスイッチのポートのうち 18 ポートは上流のコアスイッチに接続され 残りの 18 ポートは下流のノードに接続される コアスイッチは 324 ポートの GridDirector 4700 で 各 rail につき 6 台 計 12 台存在する 各ノードは 2 本の 40Gbps QDR InfiniBand によりエッジスイッチに接続され 2 本は Dual rail のそれぞれに接続される 各ストレージは 5 台の Voltaire GridDirector 4036 からなるエッジスイッチに接続され これらのエッジスイッチは Dual rail の片方の各コアスイッチと 2 本の QDR InfiniBand によりファットツリーで接続される 2.2 ストレージ TSUBAME2.5 のストレージは 1.2 PB のホーム領域と 6PB の並列ファイルシステム領域から構成される ホーム領域は 1 台の DDN SFA ストレージシステムを FC8 ネットワークを介して 4 台の HP ProLiant DL 380 G6 サーバと 2 台の BlueArc Mercury 100 サーバに接続した構成となっている ホーム領域は QDR Infiniband や 10Gbps Ethernet 経由で NFS, CIFS, iscsi などでアクセスされ TSUBAME2.5 上の /home 領域の提供や 教育 事務などの学内向けの様々なストレージサービスの用途に使用している 並列ファイルシステム領域は TSUBAME1.0 の運用経験を基に I/O のスケーラビリティと信頼性を実現するために分割された複数の Lustre[2] 及び GPFS[3] からなる並列ファイルシステムで構成される 総計で 30 台の HP ProLiant DL 360 G6 サーバに DDN SFA をバックエンドのストレージシステムと

3 して それぞれを QDR Infiniband を介してネ ットワークに接続した構成となっている 並列 ファイルシステム領域の構成は TSUBAME2 の運用が進むにつれ 利用状況に応じて再構成 を行い変遷しているため この点の詳細につい ては 次章で詳しく述べる これらのホーム領域 及び 並列ファイルシ ステム領域のストレージは 計 4 PB の Sun SL8500 のテープライブラリに接続され 適時 バックアップされる また テープライブラリ は 階層型ファイルシステムの基盤レイヤとし ての利用もされている これらのストレージ構成に加えて TSUBAME2.5 では 各計算ノードが GB の SSD をローカルストレージとし て持ち アプリケーションの一時ファイル生成 やチェックポイントなどのような細粒度な I/O のために使用される また 東工大 GSIC では 2012 年 9 月末より TSUBAME2 の 革新的ハイパフォーマンス コンピューティング インフラ (HPCI) の共用 運用を開始した HPCI では 現在 広域での データ共有環境の整備が進められており 理化 学研究所計算科学研究機構 及び 東京大学情 報基盤センターに設置されたストレージシステ ムを広域分散ファイルシステム Gfarm [4] で 連携し HPCI 共用ストレージ を構築してい る 東工大 GSIC においても この HPCI 共用 ストレージの資源の一部として利用するために 600TB のストレージ (DDN SFA 12000) の導入 を進めており 広域分散環境での大規模データ の高度な利用の推進や 次世代のスーパーコン ピュータのための大規模データ共有手法の検討 を進めている 3 TSUABME2 のストレージ構成の変遷前節でも述べたとおり TSUBAME2 のストレ ージの構成は これまで利用状況により変遷して きた この章では TSUBAME2 のストレージの 構成が どのような理由によりどのように変更し てきたか について具体的に述べる 3.1 TSUBAME2 稼働直後のストレージ構成 2010 年 11 月 TSUBAME2 の稼働直後の並列 ファイルシステム領域のストレージ構成 (2010 年 11 月 2011 年 3 月 ) を図 2 に示す Global$Work$Space $#1 Thin$Nodes Global$Work$ Space $#2 Infiniband$QDR$Network$for$MPI Global$Work$ Space $#3 Medium/Fat$Nodes Infiniband$QDR$Network$for$LNET$and$Other$Services Scratch $$ MDS$x10 cnfs/clusterd$samba$ w/$gpfs $$ OSS$x20 NFS/CIFS/iSCSI$ by$bluearc $$ 図 2 TSUBAME2 のストレージ構成 (2010 年 11 月 年 3 月 ) この地点では 全ての並列ファイルシステム領 域は /work0, /work1, /work9, /gscr の 4 つの Lustre ファイルシステムとして構成されていた これは TSUBAME1 の運用経験から 分割して 複数のファイルシステムを構成したほうが I/O のスケーラビリティと信頼性を実現しやすいと判 断したためである このうち /wor0 は TSUBAME2 のユーザへの MPI-IO などの並列 I/O を伴うアプリケーション用のデータ領域 /gscr は Gaussian など 大量の中間ファイルの 生成やスクラッチ I/O を伴うアプリケーション用 の領域としての使用を意図した また /work1 は TSUBAME1 からの移行用のデータの保存領域と して利用し /work9 は未使用とした 図 3 に 各 /work0 /work1, /gscr と同一の Lustre ファイル システムの構成とその上での I/O スループット性 能の結果について示す Lustre ファイルシステム は プロセスからの並列 I/O に高い性能を示すこ とが伺える Client'#1 Client'#5 Client'#2 Client'#6 Client'#3 Client'#7 Client'#4 Client'#8 IB'QDR'Network SFA 10k 600 Slots Data 560x 2TB SATA 7200 rpm 図 3 Lustre の構成と I/O スループット性能 3.2 階層型ファイルシステムの導入 TSUBAME1 の運用において 運用の末期であ る 2009 年 2010 年は ストレージの利用率が常

4 に 80% 90%となり 容量不足に陥り 運用に深 刻な支障をきたしていた このような背景により 2010 年 3 月 Sun SL8500 のテープドライブを導 GPFS%#0% TB% Inode 1%Bil. GPFS%#1% TB% Inode 1%Bil. System%Pool TSM%Pool 入し この慢性的なストレージ容量不足状態を劇 的に改善して 効率的なストレージ利用の促進を 図った 一方 このテープライブラリの導入は 主に GPFS%HSM%Client% TSM%Client GPFS%HSM%Client% TSM%Client TSM%Server TSM%Server バックアップ用途を意図しており TSUBAME2 のユーザからは利用しづらいものであった しか し 数十 数百テラバイト ないし ペタバイト 図 4 階層型ファイルシステムの構成 規模の大容量のストレージを必要とするアプリケ 図 5 に GPFS ファイルシステムの構成とその上 ーションユーザの要求が年々増加しており ユー での I/O スループット性能を示す Lustre と比較 ザ自身によるストレージ領域の不要データのテー して 若干性能が低いものの 複数プロセスから プライブラリ領域へバックアップや 必要データ の大量の逐次アクセス性能では Lustre よりも良 のテープライブラリからストレージ領域へリスト 好 な 結 果 を 得 て い る こ と が 伺 え る ア などの要望が高まり 既存のインフラでは対 応できないことが問題となった そこで 上記のような問題を解消するために テープライブラリと連携して階層的なデータ管理 機能を持つストレージシステムの導入を進め HSM(Hierarchical Storage Management)機能を 持つ GPFS 並列ファイルシステムの配備を行った 図 4 がその構成図である 4 台の HP ProLiant DL 380 G6 と 4 台の HP ProLiant DL 360 G6 が NSD サーバとして動作し 2 台の DDN SFA ス トレージシステムと QDR Infiniband を介して接 続され ストレージ機能を提供する DDN SFA 内は System Pool と TSM (Tivoli Storage Manager) Pool と２つのパーティッションに分割 して構成される System Pool は GPFS による実 際のファイルの格納のための領域として機能し GPFS の機能である ILM(Information Lifecycle 図 5 GPFS の構成と I/O スループット性能 図 6 に GPFS 直後の TSUBAME2 のストレージ の全体構成を示す Lustre 領域はこれまでと同様 /work0 /work1, /gscr との 3 つの Lustre ファイ ル シ ス テ ム と し て 構 成 さ れ た Lustre 領 域 と GPFS 領域の使い分けは Lustre が従来の並列 I/O を伴うもの GPFS はテープライブラリと連動し て動作するため 大量のデータを伴うビッグデー タ向けのアプリケーションのものを意図した Management)機能により定期的にアクセス頻度 MDS$x10 OSS$x20 Infiniband$QDR$Network$for$LNET$and$Other$Services の少ないファイルを TSM Pool へファイルを転送 する TSM Pool は TSM によりテープライブラ リへファイルをバックアップ ないし リストア するためのバッファ領域として機能する これら Global$Work$Space $#1 Global$Work$ Space $#2 Global$Work$ Space $#3 Scratch $$ cnfs/clusterd$samba$ w/$gpfs $$ NFS/CIFS/iSCSI$ by$bluearc $$ の機能が協調動作することにより ユーザからは 透過的に利用できる階層的なファイルシステムを 構 成 す る 図 6 TSUBAME2 のストレージ構成 (2011 年 4 月 2012 年 3 月) 3.1 大 規 模 ス ト レ ー ジ の 耐 故 障 性 2011 年度末から TSUBAME2 の利用が進み ストレージへのアクセス集中による I/O スループ

5 ットの低下や ストレージの故障などが頻発する ようになった ハードウェアの故障としては HDD 故障やスト レージコントローラの故障が圧倒的に多かった しかし これらの故障は 大抵の場合 コンポー ネントの交換により対応可能であり 交換も運用 中に可能であるため ユーザへの影響はほとんど 見られなかった 一方 ソフトウェアの故障に関しては Lustre や GPFS など フェイルオーバなど耐故障機能を サポートしているものの ユーザへ多大な影響を 与えた 例えば Lustre においては ソフトウェ アのバグによる OSS や MDS のハングアップ 対象としているストレージ領域が invisible になる などの事象が発生し ストレージサーバが過負荷 状態になり I/O スループットが著しく低下した GPFS では ネットワーク故障の影響により GPFS のメタデータに不整合が発生した 前者の 事象は ストレージアクセスに対して サーバ数 が少なすぎることが問題であり 後者に関しては ストレージのネットワークを共用しているがため に問題が発生したため サーバ増加と分離された ストレージネットワークの構築を行った 図 7 が 全体構成である TSUBAME1 の経験よりこれま で少数のファイルシステムを複数構築し運用を行 ってきたが 近年 Lustre のソフトウェアの性能 や安定性の向上により大規模環境での運用でも問 題ないと判断したため このような構成変更を行 った これらの改良以降 TSUBAME2 のストレ ージは安定的に稼働している QDR IB (4x) 4 SFA12k #1 /hpci0 Gfarm for HPCI GPFS with HSM 600TB Infiniband QDR Network for LNET and Other Services QDR IB (4x) 16 QDR IB (4x) 20 QDR IB (4x) 20 SFA10k #1 /data0 SFA10k #2 /data1 2.4 PB HDD + 4PB Tape Lustre SFA10k #3 SFA10k #4 /work0 /work1 /gscr0 Lustre 3.6 PB SFA10k #5 QDR IB (4x) 16 GPFS#1 GPFS#2 GPFS#3 GPFS#4 HOME System application FC cnfs/clusterd Samba w/ GPFS SFA10k #6 図 7 TSUBAME2 のストレージ構成 (2013 年 9 月現在 ) 10GbE 2 HOME iscsi NFS/CIFS/ iscsi by BlueARC 3 データインテンシブミドルウェアの 整備状況 TSUBAME2 では 大規模データ処理向けのソ フトウェアに関しても整備を進めている ここで は それらのいくつかの事例について紹介する 3.1 並列ワークフロー一般的なスーパーコンピュータでは 他のジョブの影響を受けることなく計算資源を効率良く利用するために バッチジョブスケジューラを介してジョブ実行を行っている TSUBAME2 でも PBS Pro を用いている 一方 科学技術計算では 同種のジョブを パラメータを変えて大量に実行するパラメータサーベイ型のアレイジョブや 依存関係のあるジョブを多数実行するようなワークフロー型のジョブなど 複雑なジョブの実行を要求するものが非常に多い このようなジョブに対応するために TSUBAME2 では GXP make などワークフローツールの整備を進めている GXP make[5] は 東京大学を中心に開発が進められている並列ワークフローシステムである make は プログラムのコンパイル リンクの際にソースファイル間の依存関係を自動的に解決し 目的のファイルを生成することを支援するユーティリティである make と並列分散シェルである GXP[6] の組み合わせにより 依存関係のあるジョブのワークフローとしての実行を可能にしている もともと GXP はグリッド環境のような広域並列環境での利用を指向していたが バッチジョブスケジューラでの利用にも対応し TSUBAME 上の PBS Pro への利用も可能になっている また TSUBAME では 一部 PBS Pro をカスタマイズしたコマンドを使用しているが これらへの対応も行っている また TSUBAME2 では GXP をワークフロー型のジョブだけでなく パラメータサーベイ型のジョブへも対応を進めている 元来 バッチジョブスケジューラである PBS Pro でもパラメータサーベイ型のアレイジョブの実行が可能であるが TSUBAME2 では 大量のアレイジョブを大規模に実行した場合 スケジュールのための時間 オーバーヘッドが著しく増大するという問題が発生した GXP make ではこのようなオーバーヘッドが少ないため これらの事象に対応するために

6 GXP make を基盤に PBS Pro のアレイジョブ実行の際のコマンド群と類似したコマンドを提供している 3.2 MapReduce MapReduce は 近年注目されている 大規模データに対する並列分散処理を行うためのプログラミングモデルであり 分散した key-value のペアデータに対して統一的な操作を並列で適用し, データへのアクセスの局所性を考慮したスケーラブルなデータ処理を実現する データ処理のプロセスを Map,Shuffle,Reduce の 3 つのフェーズに分解し Map フェーズで入力データとなる key-value ペアから中間データとなる key-value ペアを生成し Suffle フェーズで同じ key に対して value のリストを生成し Reduce で中間データを Shuffle することにより得られた key と value のリストから最終出力となる key-value のペアデータを生成するというものである 典型的な例では ウェブのデータ解析などの処理に適用され 数千台規模の大規模なクラスタ計算機において ノード数に応じたスケーラビリティを得ている また 様々な機械学習アルゴリズムへ MapReduce を適用して有効を示した事例をはじめ 機械学習ライブラリである Aache Mahout やグラフマイニングシステムの PEGASUS などの MapReduce アプリケーションのエコシステムも構築されつつある TSUBAME2 においても ユーザからの大規模データ処理への要望は高く MapReduce 処理の代表的なオープンソース実装である Hadoop[7] を実行したいというものも挙がっている そこで 我々は Hadoop を TSUBAME2 での実行に適するように改良した Tsudoop[8] と呼ばれるツールを開発している TSUBAME2 は バッチジョブスケジューラである PBS Pro が動作しているため Hadoop との連携動作が必要であったり ストレージも Lustre, GPFS 計算ノードのローカルストレージの SSD など 典型的な Hadoop の実行環境とは若干異なる部分があったりし また GPU ア クセラレータの Hadoop からの活用法も明らかで ない Tsudoop は TSUBAME2.0 上のジョブスケジ ューラである PBS Pro や Lustre などの並列フ ァイルシステム ノード上の複数の SSD からなる ローカルストレージなどの既存のシステムと協調 動作して オンデマンドで TSUBAME2.0 に Hadoop 環境を構築し ユーザの MapReduce ア プリケーションを実行する 実行の終了後は 自 動的に Hadoop 環境の破棄を行う 図 8 は Tsudoop の概要図である また GPU アクセラレ ータの活用に関しても GPU アクセラレータ上で Map タスクを動作させ 自動的に CPU と GPU アクセラレータ間で Map タスクのハイブリッド スケジューリングを行う手法の開発などを進めて いる PBS%Pro% 2+acquire+compu:ng+nodes by+using+pbs+pro+ Job+ Tracker node 3+invoke+JobTracker+and+TaskTrackers (op:onally++namenode+and+datanode)+ 4+submit++a+MapReduce+job+to+the+JobTracker++ client+ 1+run+tsudoop4sub+by+user+ 図 8 5+run+MapReduce+tasks+on+the+TaskTracker+nodes+++ Task+ Tracker Job Job Job Job node node node node File%Systems%(HDFS,%Lustre,%etc.) file Task+ Tracker 7kill+JobTracker+and+TaskTrackers, (op:onally+namenode+and+datanode).+ TSUDOOP の構成 4 おわりに 将来に向けて Task+ Tracker 6I/O+to+FSs+(HDFS,+Lustre,+etc.)+++ Task+ Tracker file file file file file 現状の ビッグデータ は データ量が高々 数百ギガバイト ~ ペタバイト級であり その用 途は 顧客の全体的な購買動向を調査 その為 時系列的に伝票のデータマイニングを行う 等 で 数台 ~ 数百台の安価なクラスタやクラウド 上の HDD にファイルとして分散し 処理はリ ニアスキャンや RDB からのインデクシング アルゴリズムの拡張で済む場合が多い その理 由は (1) データが企業内に閉じている サイロ 化 のため データ量 種別とも少ない (2) ビ ッグデータの黎明期で そのようなデータの

7 制限 によりアプリのバラエティが少なく機能要求が低い (3) ビッグデータに供されるハードウェアやシステムソフトウェアの性能が低く (1)-(2) の自己抑制が働く という悪循環が考えられる 実際 Google は 2008 年に ペタバイトソート ( 実際は高々 10 テラ要素 ) をサーバ 4800 台 HDD4 万 8 千器で 6 時間にて達成し 2011 年にはサーバ 8000 台で 33 分に短縮した その資源量は世界のトップ 10 スパコンに匹敵するが ソート速度は高々 55 億要素 / 秒であり ペタバイト級のメモリを持つトップスパコンなら 100 倍 ~500 倍の速度が得られることを予測できる 非定型ビッグデータ処理の下地のグラフ処理も 処理速度の世界ランキングの Graph500 ( は全てスパコンが占め IDC クラウドの影はない この理由は本質的で 真の ビッグデータ処理は 本質的にハード的にメモリ ネットワーク I/O バンド幅を要求し かつそれらを生かすシステムソフトウェアを要求するが Google, Amazon, MS Azure 等の現状のビッグデータに供されるハードウェアやシステムソフトウェアは IDC クラウドの web やビジネスホスティングからの転用であり 超高性能 I/O 性能を達成するのが困難だからである 例えば IDC の典型的なネットワークは各ノードの 1GbE がラック単位 (20-40 ノード ) で縮退した 10GbE に集約され 上位層はさらに縮退される それ故 ( 近年は多少改善されつつも )IDC の 10 万ノード級ネットワークのバイセクションバンド幅は高々数テラビット / 秒 end-to-end のレーテンシはサブミリセカンドが典型である 一方スパコン東工大 TSUBAME2.0 は 1400 ノードにもかかわらず 220 テラビット / 秒のバイセクションバンド幅を持ち レーテンシは僅か 2 マイクロ秒で 高性能システムソフトウェアでその性能が維持されている I/O も IDC クラウドでは仮想化等 の多大なオーバーヘッドで低性能化しており GFS(Google File System) 等のクラウドのファイルシステムでは 容量は数十万台で数百ペタバイト級だが I/O 性能は低い このような IDC クラウドの処理環境でも 現状の小規模レベルの ビッグデータ ならば当面問題ない しかし ビッグデータは先の量的 質的進化とともに急速に変容する事が予測され Intel 等も同様の指摘をしている 特にオープンアクセスの一般化によるデータの公共化と 同時に センサ及びユビキタスネットワークの進化で IoT(Internet of Things) が本格化により ビッグデータは 一見相関がない エクサ~ゼータ~ヨッタバイト / 年にも及ぶ 一見無関係な様々な超大量の継続的な多次元 マルチ解像度のデータストリームから意味のある情報を抽出し 単なる解析だけでなくシミュレーションとリアルタイムでマッチングする 処理に変貌する また 処理形態も MapReduce などを用いたリニアなスキャンやインデキシングでの高速化では不十分で 莫大なデータの O(n log n), O(m n), の 計算やデータ転送コストが高い複雑なアルゴリズムでの処理が必須となる このような変貌は オープンデータが主流になってきた科学研究の世界では先駆けて起こっており 総称的に データ科学 あるいは Data Intensive Computing 等と呼ばれるが それを実現するための現状のビッグデータインフラの不備が多く指摘されている 我々は このような状態を Extreme Big Data(EBD) と呼び 上述のような問題を解決するような研究活動 例えば フラッシュなどをはじめとする不揮発性メモリの活用手法 大規模データ処理へのアクセラレータの活用 などを現在積極的に進めている 成果の一部は 次世代のスーパーコンピュータの設計 構築に活用されることを目指している

8 参考文献 [1] Satoshi Matsuoka, Takayuki Aoki, Toshio Endo, Hitoshi Sato, Shin ichiro Takizawa, Akihiko Nomura, and Kento Sato, TSUBAME2.0: The First Petascale Supercomputer in Japan and the Greatest Production in the World, Comtemporary High Performance Computing From Petascale toward Exascale Chapter 20, pp , [2] Lustre, [3] Frank Schmuck and Roger Haskin, GPFS: A Shared-Disck File System for Large Computing Cluster, Proceedings of the FAST 02 Conference on File and Storage Technologies. [4] Gfarm, [5] Kenjiro Taura, Takuya Matsuzaki, Makoto Miwa, Yoshikazu Kamoshida, Daisaku Yokoyama, Nun Dun, Takeshi Shibata, Choi Sung Jun, Jun Ichi Tsuji, Design and implementation of GXP make A workflow system based on make, Future Generation Computer Systems, Volume 29 Issue 2, [6] GXP, [7] Hadoop, [8] 佐藤仁, 松岡聡, TSUBAME2.0 上での Hadoop の性能評価, 情報処理学会研究報告 2011-HPC-129(16), pp. 1-8, 2011.