Comments
Description
Transcript
講演資料ダウンロード - Cloudera World Tokyo 2016
HBaseで実現する 大量の特許文書データを扱うための アーキテクチャとベストプラクティス アスタミューゼ株式会社 開発・インフラ部 福田 信顕 自己紹介 • 福田 信顕 (ふくだ のぶあき) • アスタミューゼ株式会社 開発・インフラ部 • ソフトウェアエンジニア • Hadoop歴5年、現在はSparkを愛用 • ミドルウェアの導入と運用、大規模データ処理の設計と実装 2 弊社とCDHと私 CDH 3 Powered by 6 特許公報とastamuse.com • 特許公報とは特許に関する正式な文書です • 1,100万文書 • 1,700億文字 • 図面画像1.6億枚 7 8 課題 大量の特許公報データを処理する仕組みを構築する 13 取り扱うデータのスペック • 数千個のtar.gzファイル • １ファイルあたり数GB • フォーマット • テキスト（XML、SGML） • 画像（TIFF） 14 アーキテクチャ システム構成 Spark Hive S3 PostgreSQL YARN HBase WebApp elasticsearch HDFS mongoDB データの流れ S3 render ¦ put PNG HDFS XML, TIFF load HBase XML, TIFF analyze ¦ put mongoDB JSON 17 ４つのプラクティス ４つのプラクティス 1. 『生データは不可変に』 2. 『疎な結合は蜜の味』 3. 『HBaseは褒めて使え』 4. 『ディストリビューションを活用する』 19 Practice 1 『生データは不可変に』 20 1-1 ケース「生ハムはどこへ消えた？」 • 生ハムメロンに関する特許があるとします。 • ウェブページで、生ハムなしのメロン画像が表示される不具合が報告されました。 • HBaseの該当行を調べると、生ハムありのメロン画像を確認できました。 HDFS HBase S3 21 1-1 ケース「生ハムはどこへ消えた？」 • HDFS上の生データ(tar.gz)を調査したところ、生ハムありのメロン画像が確認できました。 • さらなる調査の結果、原因は転送プログラムのバグであることが判明しました。 HDFS HBase S3 22 1-2 ケース「テーブルデータの喪失」 • HBaseのテーブルを誤って削除するという事案が発生しました。 テーブルA HBase 23 1-2 ケース「テーブルデータの喪失」 • HDFS上の生データからデータを再生成し、復旧しました。 生データ HDFS テーブルA HBase 24 Practice 1 『生データは不可変に』 • データのトレーサビリティの確保 • HDFS保管の生データからの再生成を可能に • 巨大な永続化キャッシュとしてのHBase 25 Practice 2 『疎な結合は蜜の味』 26 ケース「影響の局所化」 • データの調達先の変更に伴い、生データ(tar.gz)のレイアウトに変更が生じました。 • この変更の影響を受けるのはどこでしょうか。 OLD /foo/1/a /foo/2/b NEW /bar/1/a /bar/2/b HDFS Job B 画像処理 S3 Job C テキスト処 理 mongoDB HBase Job A StoreFile生 成 27 ケース「影響の局所化」 • 影響を受けるのはJob Aのみ。 • 実際に変更の必要性が生じたのは、カスタムのRecordReaderクラスのみでした。 OLD /foo/1/a /foo/2/b NEW /bar/1/a /bar/2/b HDFS Job B 画像処理 S3 Job C テキスト処 理 mongoDB HBase Job A StoreFile生 成 28 Practice 2 『疎な結合は蜜の味』 • 原則１つの仕事は１つのジョブとして実装する • 変更の影響範囲を局所化する設計 29 Practice 3 『HBaseは褒めて使え』 30 3-1 カラムファミリの活用 • 画像とテキストは、データの形式とアクセスパターンが異なります。 • それぞれのデータを最適な形で格納する方法はあるでしょうか。 Job B 画像処理 S3 HBase Job C テキスト処 理 mongoDB 31 3-1 カラムファミリの活用 • 画像とテキストを、それぞれ別のカラムファミリに割り当てました。 • カラムファミリ毎に格納領域が集約され、圧縮も利用でき、I/Oの最適化が図れます。 row-key1 row-key2 meta: raw: aux: name: foo date: 20161108 hash: xxxxxxxx foo.xml: <xml>くぁwせdrftgyふじこlp</xml> foo_1.tif: xxxxxxxxxx xxxxx name: bar date: 20161027 hash: yyyyyyyy bar.xml: <xml>くぁwせdrftgyふじこlp</xml> bar2.xml: <xml>くぁwせdrftgyふじこlp</xml> baz_1.tif: xxxxx baz_2.tif: xxxxxxxxx 32 3-2 バルクロードの活用 • 大量のデータをテーブルに書き込む際に、１件ずつPutをすると時間がかかりすぎます。 このままではリリースに間に合いそうもありません。 • スループットを上げる方法はあるでしょうか。 HBase Putするジョブ HDFS 33 3-2 バルクロードの活用 • HBaseのバルクロードの仕組みを使うことにしました。 • 高速かつ効率的にデータをテーブルにロードできます。 • 全体のリードタイムを短縮でき、スケジュールに間に合わせることができました。 HBase StoreFile生成ジョブ completebulkloadコマンド HDFS StroreFile 34 3-3 テーブル管理 Table メジャーコンパクション Region Region Region Region • デフォルトで7日間隔で走る • StoreFileは１つの大きなファイルに統合される Store Store Store MemStore MemStore MemStore StoreFile StoreFile StoreFile StoreFile StoreFile StoreFile StoreFile 3-3 テーブル管理 Table リージョンの分割 • StoreFileはサイズが一定の閾値を超えると 2つに分割される Region Region Region • 分割の度にリージョンの数が増える Table Region Region Region Region マニュアルでの制御 • 自動メジャーコンパクション機能の無効化 • hbase.hregion.majorcompaction デフォルト７日 → 0 • 分割の抑制 • hbase.hregion.max.filesize デフォルト10g → 大きな値 この２つの設定により、一定のリージョン数で運用 37 新しいデータの追加 運用でカバー • 定期的にリージョンの状況をチェック • 偏りが大きくなっている場合は手動で分割 • バッド・ノウハウ疑惑 39 期待のルーキー Region Normalizer (v1.2.0) 3-4 トラブルシューティング • リージョンサーバのダウン（OOMKillerやYouAreDeadException） • 自動再起動は使用しない • リージョンサーバの再起動 • メタデータ不整合が生じた場合はhbckコマンドを使用して調査・修復 • ドキュメント重要 41 Practice 3 『HBaseは褒めて使え』 • カラムファミリはデータの形式とアクセスパターン毎に • バルクロード爆速 • テーブル管理のバッド・ノウハウ • hbckコマンド重要 42 Practice 4 『ディストリビューションを活用する』 43 Practice 4 『ディストリビューションを活用する』 • 大事なのは品質と時間 • バージョンアップの恩恵 44 ４つのプラクティス 1. 『生データは不可変に』 2. 『疎な結合は蜜の味』 3. 『HBaseは褒めて使え』 4. 『ディストリビューションを活用する』 45 今後の課題 • クラウド環境への適応と最適化 • アーキテクチャの見直し 46 アスタミューゼの舞台袖 @astamuseLab アスタミューゼでは、開発・デザイン の情報を発信しています。 47 ご清聴ありがとうございました。