Proceedings of the 12th Annual Meeting of Particle Accelerator Society of Japan
August 5-7, 2015, Tsuruga, Japan

PASJ2015 THP108

HBase/Hadoop を利用した J-PARC 運転データアーカイバの改良
IMPROVEMENT OF THE J-PARC OPERATION DATA ARCHIVER USINGHBASE/HADOOP
池田浩#, A, B), 菊澤信宏 A), 吉位明伸 C), 加藤裕子 A)
Hiroshi Ikeda #, A, B), Nobuhiro KikuzawaA), Akinobu YoshiiB), Yuko KatoA)
A)
Japan Atomic Energy AgencyB)
Visible Information Center, Inc.
C)NS Solutions Corporation

Abstract
The Linac and the RCS in J-PARC provide enormous operation data to control their equipment, and we have been
accumulating the data into a PostgreSQL database system, while we are planning to replace the storage withHBase/Hadoop. HBase is so-call NoSQL, specialized for big-data with scalability to the data size at the cost of the highbroad utility of SQL. HBase is constructed on a distributed file system provided by Hadoop, using a cluster withadvantages including automatically covering its composing nodes’ breakdowns and easily adding new nodes to extend
its capacity.
In the previous presentation we reported that we updated the versions of HBase/Hadoop composing our test system,
to conquer a single point of failure by making redundant the master node, and we showed issues to fix our tools in thenew system, while we also mentioned some issues about the construction of our cluster itself.
In this presentation we are reporting that we have re-designed and re-constructed the cluster with resolving the issues,
including enhancing hardware of master nodes, creating scripts to automatically construct nodes, and introducing
monitoring tools for nodes. Having accordingly adjusted the configurations of HBase/Hadoop and measured theperformance of our new system, we are also reporting its results and considerations.

1.

はじめにJ-PARC の Linac 及び RCS では機器から得られるデータを PostgreSQL に蓄積しているが [1] 、これをHBase[2]/Hadoop[3] を用いたシステムに変更するための準備を進めている。前回の発表では、テスト用に作られたシステムを運用段階に移行するに問題点をいくつか指摘した [4]。今回の発表ではこれらを含む問題点を解消するべく、新しいクラスタの再設計・再構築について述べ、新クラスタのパフォーマンスについて述べる。
OS は CentOS 6.6 を用いる。なお、Transparent
Huge Pages はデフラグ機能に不具合があるため無効にする。Hadoop 2.2.0, HBase 0.96.1.1, ZooKeeper 3.4.5を用いる。現在ではこれらは既に古くなってしまっているため、ノード構築の手順が一通り確立してから、これらのバージョンを上げることを検討する予定である。

2.

クラスタの再設計・再構築

2.1

ハードウェアの増強とメモリの割り当て

前回の発表にて、Hadoop のバージョンアップにより、Hadoop の分散ファイルシステム（HDFS）において単一障害点であったマスタノードの冗長化が可能になった。これにより、DRDB や Heartbeat などの他のソフトウェアの手助けなしに、実用レベルのクラスタを構築できるようになった。ただし、我々が冗長化のために用意したハードウェアは著しくスペックが不足しており、また、RAID も組まれていなかった。このため、ハードウェアを増強し、Hadoop 等のプロセスの配備、及び、メモリの配分を見直した。
Hadoop にて マ スタ ノ ード を 冗 長 化す る に使 う
ノードは最低 3 台必要となる。このうち 2 台は、Hadoop が構築するファイルシステムのメタ情報を記録するモジュールであるネームノードのアクティブとバックアップとなり、同等のハードウェアスペックを有するのが望ましい。3 台目が必要なのは、
ZooKeeper 及び Hadoop のモジュールの 1 つであるジャーナルノードが、多数決の原理により決定を行う性質を持つものであるためである。
新しく増強したハードウェアは 2 台でありスペックが高いのでこれをネームノードのアクティブとスタンバイにする。冗長化を行う前に使用していた既存のマスタのハードウェアとあわせて、3 台構成とする。なお、Hadoop の MapReduce 処理を行う基盤となる YARN は冗長化の対象とされていないが、そのマスタは既存のマスタ上で稼動させることとする。
各機器のハードウェアスペック及び具体的なモジュールの配備とメモリの割り当てを、それぞれTable 1 及び Table 2 で示す。

___________________________________________#

ikedahi@post.j-parc.jp- 1312 -Proceedings of the 12th Annual Meeting of Particle Accelerator Society of JapanAugust 5-7, 2015, Tsuruga, Japan

PASJ2015 THP108

Table 1: Hardware Specification
Master
Node 1Master
Node 2,3Slave
Node

DELL PowerEdge R610
CPU: Intel Xeon E5620 (4Core, 2.4GHz)
MEM: 24GB
HDD: 600GB x4 (RAID10)
DELL PowerEdge R320
CPU: Intel Xeon E5-1410v2 (4Core, 2.8GHz)
MEM: 24GB
HDD: 600GB x4 (RAID10)
DELL PowerEdge R410
CPU: Intel Xeon E5620 (4Core, 2.4GHz)
MEM: 24GB
HDD: 2TB x4

Table 2: Memory Allocation (GB)Master Node
ZooKeeper
Name Node
ZKFC
Journal Node
Resource Manager
History Server
HBase Mastertotal

2.21111142,31811415

Slave NodeData Node1Node Manager
YARN container
Region Servertotal

161220RAID とマウントオプション

Hadoop にお け る実 デ ータ の 冗 長 化は ス レー ブ
ノード間で複製を行って実現している。このため、スレーブノードで冗長化のために RAID を組むのは意味をなさない。そもそも、RAID による冗長化はあくまで HDD に対する冗長化であり、ノードそのものを冗長化するわけではなく、代わりにはならない。また、障害発生時のパフォーマンス低下は著し
く正常時の数分の 1 に落ちる。このため、ノードそのものに障害が発生したと判断されてクラスタから切り離されたら本末転倒になる（ただし、その方がクラスタとしてのパフォーマンスを維持することができるかもしれない）。RAID コントローラのホットスワップを利用すれば HDD の障害に対する復旧は比較的容易ではあるが、ノード構築の自動化の確立でそれに代えることができよう。
正常時のパフォーマンスについても RAID 0 を使うよりも Hadoop に個々の物理ディスクにアクセスさせた方が速いと言われている。これは、RAID 0
ではもっとも遅いディスクに速度を合わせる必要があるためと説明されている。このため、Hadoop のスレーブノードは RAID を組まないことが常識とされている。ただし、複数のディスクに並列にアクセスする必要がない低負荷の場合は、RAID 0 を組んだ方がパフォーマンス的に有利になるだろう。
前回の発表時では、スレーブノードが物理ディスク 4 台の RAID 5 で構成されていた。RAID 5 はパリティ計算の負荷のために書込みについてパフォーマンスが落ちるとされているが、RAID コントローラがこの負荷を担当することで、物理ディスクが一台少ない RAID 0 構成と同等の性能を発揮する。何れにせよ、障害発生時や高負荷時を考え、Hadoop の常識に従って非 RAID に変更する。正確には、現在使用している RAID コントローラでは非 RAID を構成できないので、1 台構成の RAID 0 を 4 つ構成することとする。RAID コントローラを経由するため、バッテリバックアップ及び不揮発性のメモリを備えた RAID コントローラのキャッシュが利用できる。
OS のファイルシステムとして、現在 Linux で標準的な ext4 を用いる。マウントオプションについてだが、スレーブノードは冗長化しているが最悪のケースを想定し、データの永続化を保証するものとする。RAID コントローラの不揮発性のキャッシュが 利 用 で き る た め 、 I/O バ リ ア を 無 効 と す る 。
ジャーナルモードは ordered を用い不正なデータが見える可能性を防ぐ（Hadoop ではランダムアクセスをサポートしていないのでこれで十分となる）。
我々の ZooKeeper, Hadoop, HBase では Java 6 をサポートしているが、Java 6 ではディレクトリに対する fsync に相当する命令が用意されていないため、必然的に dirsync が必要となる。
実のところ、Hadoop のスレーブノードでは既定で fsync が実行されず、このままでは上記の設定は意味を成さない。ドキュメントに記述されていないプロパティ dfs.datanode.synconclose を true に設定する必要がある。後述するパフォーマンス測定は、これが判明する前の段階で行ったものであり、旧クラスタ・新クラスタともこのプロパティを設定していない。
2.3

HBase のテーブルの属性とパフォーマンス

HBase のテーブルにおいて、パフォーマンスに影響を与える幾つかの属性について言及しておく。
HBase は、複数のレコードに同じデータが何度も現れることを問題とせず、ファイルに格納する。これは、Data Block Encoding や、Snappy 等の圧縮アルゴリズムを適用することを前提としており、テーブル属性として指定される。Data Block Encoding は
HBase 0.94 から導入され、HBase のレコードの構成に沿った自明な圧縮を行うもので、特に行キーが値に比べてかなり大きい場合に有効である。圧縮アルゴリズムはその後に適用される。我々のテーブル設計では Data Block Encoding のロジックが非常に合致する。実際にどのような組み合わせが有効であるかは、後に記述するパフォーマンス測定にて示している。
データ検索については、ブルームフィルタが利用可能である。HBase の実装上、データの検索には複数のファイルを確認する必要があるが、これに掛かるコストを、ブルームフィルタを使って軽減することができる。これはテーブルの属性として設定され、既定では行キーに対してブルームフィルタの検索が可能な設定になっている。ただし、我々の用途では範囲条件による複数レコードの抽出が主たる閲覧方法であり、これにはブルームフィルタを適用できず、ブルームフィルタに要する多少の記録容量がほぼ完全に無駄になってしまうため、ブルームフィルタを無効にする。

- 1313 -Proceedings of the 12th Annual Meeting of Particle Accelerator Society of Japan
August 5-7, 2015, Tsuruga, JapanPASJ2015 THP108

さらに、HBase にはミリ秒オーダのレイテンシを実現する目的で Block Cache という機能が用意されている。一度ディスクから読み込んだブロックは次からはメモリ上のキャッシュから参照される。
キャッシュ自体はサーバ毎に 1 つ用意されるが、実際に使うかどうかはテーブルの属性で指定する。
我々の用途では、テーブルの閲覧では一度に大量のデータを取得し、このためレイテンシの低さ自体はあまり興味がなく、一度読み込んだデータを再度参照することは少ないだろう。また、Block Cache は既定では最大ヒープの 40%まで使う設定となっており、メモリの大量消費と GC の頻発によるパフォーマンスの劣化の可能性も考えられる。このため、Block Cache は無効にする。
2.4

ノードのモニタリング

まれる jps コマンドを用いてプロセスの存在確認をし、また、ソケット通信にて問い合わせできるものに関してはその応答を確認するプラグインを自作してこれを使う。これは、手動での確認を自動化するということを念頭に置くものである。
Nagios の他には旧クラスタにインストールされてい た Ganglia を イ ン ス ト ー ル し て い る 。 こ れ は
Nagios と異なり数値情報を収集するもので、CPU やリソースの異常消費等、不具合や状態異常のアナログ的判断や、パフォーマンスチューニングに適しているだろう。マルチキャストを使うため、ネットワークの負荷が軽いという特徴がある。
Nagios も Ganglia も JMX 経由で Hadoop や HBaseから内部情報を取得できる。しかし、未ドキュメン
トのパラメータが多いため、それが指し示す意味と妥当な閾値を決めることは、ソースコードを解読するなど熟練が必要だろう。

冗長化しても障害発生時に対応しなかった場合はせいぜい寿命の期待値が 2 倍になるだけであり、障害発生によるサービスの停止やデータの損失は避け 2.5 ノード構築の半自動化られないだろう。特に、マスタスレーブ型のクラスあらかじめ作成されたノードから、どのような設タでは、台数が比較的少ないマスタが弱点となる。 定、チューニングが行われたかを確認するのはほぼ
Hadoop ではマスタが冗長化されたが、アクティブ 不可能である。手動でノードを構築するとしてそのとスタンバイの 2 台までとなっている。
手順が漏れなくドキュメント化されていれば障害発サーバの状態監視には Nagios という定番のツール 生時に元の状態に戻すことはできるが、ドキュメンを使っている。Nagios では状態異常の検知は全てプ トへの記入漏れやノード構築時のヒューマンエラーラグインとして導入され、Nagios 本体は検知のスケ などのリスクは避けられない。また、それらを正しジュールやメールによる異常状態通知を行う。リ く遂行したとしても、手動でのノード構築には時間モートサーバの状態を収集するためには、通常、 が掛かる。特にマスタノードに対する冗長性の損失
NRPE というプラグインを使う。Web ブラウザから は、早急に回復する必要がある。一方、どのようなサーバやサービスの状態の一覧を見ることができる 設定を行ったかを客観性・曖昧さを排除し、再現が、この Web アプリケーションも外部モジュール 性・再評価可能である形で示すことは、意味のあるとして Nagios 本体から切り離されている。
評価を行うのに重要である。
通常、Nagios による監視では異常の通知をメールノードの構築ではその手続きを全て自動化するので受け取るが、我々のクラスタが配置される制御 が望ましいが、SSH の鍵の設定や IPMI 経由で取得
LAN は基本的に外部のネットワークと切り離されて するハードウェア状態に関する設定などは、セキュおり、制御 LAN 内部からメールサーバへの通信が リティ的な観点及び環境依存が強いものは手動で行遮断されている。このため、SSH 経由でログインし、 うこととする。
Nagios が Web アプリケーション用に更新するファノードの構築は OS のキックスタートから始める。
イルを定期的にパースして状態を確認する。あるい OS のインストールディスク（DVD）を用い、キッはそれを自動的に行うスクリプトを走らせるものと クスタートファイルは USB メモリ経由で与える。
する。なお、このスクリプト自身が異常終了した場 インストールディスクから OS をインストールし、合は目で見て判断できるが、将来的にメールでノー OS を稼動させるのに必要とされるソフトウェアのドの異常を通知するようになった場合は、Nagios 本 他、ディスクに含まれるソフトウェアモジュールで体の異常終了に対する対策を考えておく必要がある。 我々のクラスタが必要とするものをインストールすNagios のプラグインは、サーバに対する ping など る。OS やこれらのソフトウェアの設定ファイルも定番のものは予め幾つか用意されているが、それ以 ここで編集する。OS のインストール後の再起動後、外は必要に応じてスクリプトを書いたり、信頼のお SSH 鍵の手動設定を行い、SSH 経由で、残りのソフけるサイトから有用なものを別途ダウンロードした トウェアのインストール及び設定を行うためのセッりする必要がある。我々のクラスタでは、ハード トアップ一式をコピー及び実行を行う。
ウェアの状態監視に対しては、OS のインストール
なお、ここでは、ハードウェア構成をおよそマスディスクに含まれるソフトウェア freeipmi を利用し タノードおよびスレーブノードで単純化しており、て IPMI 経由でハードウェア状態を取得するプラグ 将来的にさまざまなハードウェア構成のノードをク
イン check_ipmi_sensor と、SNMP 経由で各機器にイ ラスタに追加していく場合は、このままのキックス
ンストールされた Dell の OpenManage にアクセスし タートでは対応できずに、新しい対応をする必要がてハードウェア情報を取得する check_openmanage あるだろう。しかし、手始めとしては悪くないだろを使う。ソフトウェア（ZooKeeper, Hadoop, HBase う。の各モジュール）の状態監視については、JDK に含- 1314 -Proceedings of the 12th Annual Meeting of Particle Accelerator Society of Japan
August 5-7, 2015, Tsuruga, JapanPASJ2015 THP108

3.

パフォーマンス測定

汎用的な測定ではなく、J-PARC における実際の使われ方を想定したデータの登録・取得のパフォーマンスを測定する。クラスタを再構築する前の旧クラスタについても測定を行った。
3.1

測定条件

後者は｛none(適用なし), GZ, Snappy, LZ4｝について測定した。
3.2

測定結果測定結果をまとめたものを以下の表に示す。Table3 はデータ登録の所要時間で、1 日毎に得られるデータを 5 日分で平均したものである。Table 4 はこのうち none-none のケースについて、データ登録の所要時間の日推移を示したものである。Table 5 はデータ取得の所要時間で、スレッド毎に得られるデータを平均したものである。Table 6 は Hadoop の分散ファイルシステム（HDFS）上に書き込まれたデータの総量を示す。正確にはこれは新クラスタに対するデータだが、これらのデータはおよそ Data
Block Encoding と圧縮アルゴリズムに依存する。

データ登録の測定では、EPICS レコード 10000 個から 1 秒周期でデータを取得して格納することを想定し、1 日分のデータがどの程度の所要時間でクラスタに登録できるかを、継続して 5 日分測定する。
1 つ 1 つのレコードは非常に粒度が小さいため、実際の運用では、バッファにまとめてから送信するだろう。これに従い、auto-flush は off にし、最後にflush を 行 い 、こ れ が完了 す るま でを 測 定す る。
EPICS のチャネル名として 30 文字を想定し、大文字・小文字のアルファベット計 52 文字から構成さTable 3: Write Test (min)れる文字列をランダムで 30 文字の名前を生成し、none
GZ
Snappy
LZ4
データは 0.0 以上 1.0 未満のランダムな倍精度実数
oldclusterを使う。理想的には、テーブルの作成時に予めリー102.3
59.0
64.3
64.8
none
ジョンを適切に分割しておくのが望ましい。実際の
57.4
54.0
58.9
59.4
diff
運用では、どのように適切に分割するべきかは自明
56.7
55.9
58.5
58.8
fast_diff
でないが、バランサが適時働いて徐々に負荷がスレーブノード間で分散していくことは期待できよう。 new cluster
none
81.9
77.6
74.9
80.8
このツールでは短い時間でパフォーマンスを測定す
67.6
68.6
75.4
87.3
diff
るため、予めリージョンを分けてテーブルを作成し、
69.0
71.7
76.4
71.4
fast_diff
初めから負荷分散をする。具体的には、ランダムに生成した名前が一様分布しているとし、アルファ
Table 4: Write Test Details of the none-none Case (min)ベット 1 文字を使ってできるだけ均等にリージョンを分割して、リージョンサーバ数と同じだけのリー
day
old cluster
new cluster
ジョンを作る。
75.6
73.8
0
データ取得の測定では、先に登録したデータを利
91.5
80.2
1用する。5 個のクライアントが同時に接続している
108.2
83.1
2
ことをエミュレートして 5 個のスレッドを用い、そ
98.6
86.3
3
れぞれ、10 個のランダムなチャネルに対し、ランダ
137.6
86.3
4
ムな日付の 1 日分のデータを取得させ、これが完了するまでの時間を測定する。もともと HBase では、Table 5: Read Test (sec)Hadoop のスループット重視とは対照にレスポンス
noneGZ
SnappyLZ4を重視しており、また、同時アクセスする複数のク
old cluster
ライアントへの対応を複数のリージョンサーバに分
7.3
8.3
8.8
7.1
none
散することで、総合的なパフォーマンスの向上が期
8.9
10.0
11.0
9.4
diff
待できるものである。しかし、実際の我々の使い方
7.5
8.9
8.2
9.4
fast_diff
では、それほど多くのクライアントが同時接続する
newcluster
ことを想定しておらず、また、単体のクライアント
7.2
8.2
8.0
8.5
none
に対する大量のデータ取得のスループットに興味が9.8
8.5
10.0
11.3
diffある。
8.6
8.6
9.0
8.3
fast_diff
HBase のクライアントにおける書込みバッファは既定で 2MB となっておりこれを用いる。また、Table 6: Sum of Stored Files (GB)
HBase におけるデータの取得では 20000 レコードのnone
GZ
SnappyLZ4キャッシュを用いる。これは 1 レコードを 100bytesと換算しておよそ 2MB となる。
286.264.1
80.5
76.7
none
先に述べたように、HBase のテーブルの属性とし53.1
47.3
52.9
53.1
diffて、Data Block Encoding と圧縮アルゴリズムとして
53.8
48.7
53.8
53.9
fast_diff
何を組み合わせればよいかは不明瞭であり、これらの組み合わせについて測定を行った。具体的には、
前者は｛none(適用なし), diff, fast_diff｝について、- 1315 -Proceedings of the 12th Annual Meeting of Particle Accelerator Society of Japan
August 5-7, 2015, Tsuruga, Japan

PASJ2015 THP108思われる。
このようなドキュメント化されていない重要なプ
書き込みに関しては旧クラスタが 20～40％ほど速
ロパティについては、一度、ソースコードを注意深い。ただし、HDFS に書き込むデータ量が極端に多い none-none のケースでは、新クラスタの方が速く、 く解読するか、Hadoop や HBase のバグトラッキン
旧クラスタは急速にパフォーマンスが劣化している。 グに使われている JIRA を注意深く追跡する必要が
こ れ は 、 負 荷 が 低 い 場 合 は 旧 ク ラ ス タ に お け る あるだろう。
3.3

考察

RAID コントローラの支援を受けた RAID 5 の速度 4.2 HBase 等のバージョンの更新が効くが、負荷が高い場合は新クラスタにおけるHBase や Hadoop、ZooKeeper のバージョンを更新ディスクへの並列アクセスの効果が高いためと考えすることを検討する。これまでにこれらのバージョられる。新クラスタの優位性を示すには、テストでン互換性の問題に巻き込まれたことがあったため、使用したデータ量が圧倒的に足りなかったようだ。
先ず運用レベルのクラスタを準備することについて読み込みに関しては、旧クラスタと新クラスタでフォーカスを当ててきた。これを達成したことを受大差がない。ここでは示していないが、テストに用け、HBase 等のバージョンの更新とそれに伴う調いたチャネル数が少ない場合や再読み込みで OS の整・修正等を行う。
キャッシュや HBase の Block Cache を利用する場合は、旧クラスタが速い傾向がある。おそらくこれも、 4.3 スクリプトの汎用化ディスクへのアクセスが少なくなる場合は、相対的現在、ノード構築に使われる OS のキックスターに RAID 5 の効果が高くなるためと考えられる。
トファイルやセットアップファイルでは、簡単のた
Data Block Encoding と圧縮アルゴリズムについて め、IP アドレスなどをハードコーディングしている。
は、我々のテーブル設計では Data Block Encoding と このため、別の環境で利用することが難しい。何らして diff や fast_diff を使うのが圧縮の効果が高く、 かの形でこれに対応しておきたい。
また書込み速度も高い。テストで使用したデータでは常にデータが変化するため diff の圧縮率が僅かに 4.4 ノードの増設手順のドキュメント化高いが、実際の J-PARC での運用では変動の無いノードの交換手順についてはドキュメント化したデータも記録するため、fast_diff の効果が高いだろ が、ノードの増設手順に関してもドキュメント化しう。diff や fast_diff を適用した場合、圧縮アルゴリ ておく必要があるだろう。
ズムとして圧縮率の低い Snappy や LZ4 を適用しても圧縮の効果が現れず、変換に要する時間だけ無駄 4.5 データ収集ツールの冗長化
データストアを冗長化したが、データ収集ツールの よ う だ 。 圧 縮 率 の 高 い GZ は そ の 変 換 速 度 はSnappy や LZ4 の数分の 1 とされているが、目立っ が冗長化していないと、データ収集に関して単一障た速度の低下は見られない。おそらく、ハードウェ 害点となる。ZooKeeper が稼働しているので、これアのスペック上、I/O に比べて CPU の能力が高いた を用いてアクティブ・スタンバイを決定するのが素直だろう。
めと思われる。
まとめると、新クラスタが旧クラスタよりもデー
4.6 EPICS レコードからのデータ収集以外に適用タ量に対するスケーラビリティを持つことが示唆さ
現在、EPICS レコードからのデータ収集にフォーれるが、明らかに示すにはテストに使ったデータ量が圧倒的に足りなかった。Data Block Encoding の カスを当てているが、その他、大量データ収集が必
diff や fast_diff は効果が高く、さらに圧縮アルゴリ 要な状況への適応を検討する。
ズムを適用するなら GZ を使うのが良いことが示された。

参考文献

4.

今後の対応

4.1

設定の修正とその影響の確認

前述の通り、Hadoop のスレーブノードでは既定で fsync が実行されない。OS のファイルシステム
ext4 には遅延アロケーションが導入されており、最大 30 秒のデータ損失の可能性がある。fsync を実行させるには、ドキュメントに記述されていないプロ
パティ dfs.datanode.synconclose を true に設定する必要がある。Hadoop の設定ファイルの修正及びノード構築スクリプトの修正を行い、パフォーマンスへの影響を確認する。ただし、I/O バリアを無効化しているので RAID コントローラのキャッシュへの掃出しまでに留まるため、ほぼ影響を受けないものと[1] S. Fukuta et al., “Development Status of Database for JPARC RCS Control System (1)”, Proceedings of the 4th
Annual Meeting of Particle Accelerator Society of Japan,August 2007.
[2] http://hbase.apache.org/[3] http://hadoop.apache.org/[4] N. Kikuzawa et al., “DEVELOPMENT OF TOOLS FOR
THE J-PARC OPERATION DATA ARCHIVING USINGHBASE/HADOOP”, Proceedings of the 11th Annual
Meeting of Particle Accelerator Society of Japan, August2014- 1316 -