Hadoop Conference Japan_2016 セッション「顧客事例から学んだ、エンタープライズでの "マジな"Hadoop導入の勘所」

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |
顧客事例から学んだ、
エンタープライズでの
"マジな"Hadoop導入の勘所
日本オラクル株式会社
クラウド・テクノロジー事業統括
Cloud/Big Data/DISプロダクト本部
立山重幸 (Shigeyuki.Tateyama@oracle.com)
Hadoop Conference Japan 2016

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. |
• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明する
ものです。また、情報提供を唯一の目的とするものであり、いかなる契約
にも組み込むことはできません。以下の事項は、マテリアルやコード、機
能を提供することをコミットメント（確約）するものではないため、購買決定
を行う際の判断材料になさらないで下さい。オラクル製品に関して記載さ
れている機能の開発、リリースおよび時期については、弊社の裁量により
決定されます。
2
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。

本日のお話
3
Hadoop
エキスパート
Hadoopを導入する人
Hadoop入門した人
Hadoop知らない人
HDFSやMapReduceの概要は理
解したが、実際のHadoop導入と
なると壁の高さを感じてしまう人
のためのワダチ的な内容です。

Hadoopの現在地と
エンタープライズのお客様に提案する際の
論点
4

50万社データベースユーザ
5
As of 2016
3000社ビッグデータユーザ
出典：ビッグデータが「みんなのもの」に?
オラクルが予測する2016年の見通し
http://www.oracle.com/jp/corporate/features/pr/b
ig-data-for-all-oracles-2016-predictions/index.html

Copyright © 2016 Oracle and/or its affiliates. All rights reserved. | 6
As of 2016
数万社ビッグデータユーザ
出典：ビッグデータが「みんなのもの」に?
オラクルが予測する2016年の見通し
http://www.oracle.com/jp/corporate/features/pr/b
ig-data-for-all-oracles-2016-predictions/index.html
RDBユーザが、ど真ん中で
Hadoopも利用

Hadoopの現在地
• 2016年Big Data市場における
Hadoopの普及率は約22%
• キャズムを超えて、アーリーマジョ
リティへの導入が進んでいる
7
出典：Hortonworks Inc. Big Data & Hadoop Market
2.5% 13.5% 34% 34% 16%
イノベーターアーリー
アダプター
アーリー
マジョリティ
レイト
マジョリティ
ラガード
キャズム
16%
22%

2016/10/29 日本オラクルプレスリリース
セブン＆アイ・ホールディングス様
8
• 「いつでも、どこでも、スムーズに、お客様が求める商
品を購入でき、人に紹介したくなるサービス」をコンセ
プトに、国内1万9,000以上の店舗とインターネット販
売を融合させるオムニチャネルの構築を推進
• 2016年11月1日グループ横断型の新通販サイト
「omni7（オムニセブン）」を開設
• ネットとリアルの融合と複数事業体のシームレスな連
携を可能にするオムニチャネルを実現するため、IT基
盤を新たに構築
• ネットや実店舗から発生する膨大なデータを
セキュアに蓄積、管理、分析
• オラクルのエンジニアド・システムやクラウドなど最先
端の技術を駆使したオラクル製品の包括的な導入
（Oracle Big Data Appliance含）
2016/10/29 日本オラクルプレスリリースより抜粋

構造データ
9
MES
機器ログ
ERP
ソース収集蓄積
DWH
Data
Visualization
Analytics
Platform
分析
• これまでの取り組み
– ERPをグローバルシングルインスタンス化
• Oracle Applicationsを活用
• 業務プロセス標準化、ITコスト削減（$7.7M）
– グローバルKPIシステム（DWH）を構築
• Exadata、Exalyticsを活用
• 世界中の各生産ラインの生産状況や歩留情報、
在庫情報、販売情報のKPIを可視化
• 影響分析等、効率的な工場管理が可能に
• 新たな課題
– 長期間データの蓄積、分析が不可
• 毎24時間毎にデータ収集が必要
– サマリデータのみが分析対象のため、
詳細かつ正確な分析ができない、工数増大
バッチデータフロー
インテラクティブなデータフロー
お客様事例① 製造業
機器データ活用により、詳細な生産状況の分析を実現
某グローバル製造業様

非構造
データ
構造データ
10
MES
機器ログ
ERP
音声
ビデオ
テキスト
ソーシャル
ソース収集蓄積
DWH
データ
貯蔵庫
Data
Visualization
Analytics
Platform
分析
• 新たな取り組み
– 既存DWHの隣に、データ貯蔵庫を構築
• Oracle Big Data Applianceを活用
• MES、装置の詳細かつ長期間データを
リアルタイムに取得
• 効果
– 生産工程における新たなデータ分析を実現
• 長期間でのデータ分析の実現
• 生産条件最適化のための分析
• 操業率低下の原因分析
• 複数のセル-モジュールをまたいだ原因分析
• 品質の可視化
– データ分析の効率化
• データ分析作業の期間短縮
• 対象データのカバレッジ（種類、量、期間）
バッチデータフロー
インテラクティブなデータフロー
マスター、
サマリー、
詳細データ
サマリー
分析結果
アーカイブ
お客様事例① 製造業
機器データ活用により、詳細な生産状況の分析を実現
某グローバル製造業様

• メインフレーム・ダウンサイジング
– MIPS：30％削減
– バッチ処理時間：50%削減
• Exadata＋Big Data Appliance（Hadoop 基
盤）のハイブリッド構成
– 既存データマートの集約
– OPEX：約40% 削減
• データ配布モデルの近代化
– 「データありき」
vs 「スキーマ／モデルありき」
– 顧客360°ビューの実現
お客様事例② 金融業
ITコスト削減と、情報の一元化によるビジネス変革実現
La Caixa様メインフレームテープサブシステム・DWHバッチ処理レポート
Data Reservoir
(Hadoop)
ソーシャルデータ
顧客情報
決済情報
バッチ処理の削減による
コスト削減メインフレーム
およびテープ上の
ストレステスト
データの移行
レポート
顧客360°
DWH
(RDBMS)

弊社が提案するビッグデータの特徴
• ビッグデータ＝ RDB ＋ Hadoop
⇒RDBと同等のSLAが求められる事が多い
12
提案構成例

SLAを満たすためのHadoop基盤検討ポイント（非機能）
• サーバ構成
– 従来通りのベストプラクティスで良いのか？
• バックアップ
– どこにどうやって取るべきか？
• セキュリティ
– 認証、暗号化
• パフォーマンス
– ロード
13

サーバ構成
14

Hadoopを提案する側の考え方 ⇔ RDBお客様の要望
①サーバ構成の考え方
15
Hadoopベストプラクティス提案時におけるお客様からの指摘
安いIAサーバを、たくさん積んでください
PXEやPuppetを組み合わせれば運用も楽です
会社の方針でサーバ統合している中で数百台の
サーバ導入は説明がつかない
故障率1%として、300台クラスタの場合、ほとんど毎
日故障が発生する事になるため許容されない
初期サイジングより増えた場合にデータセンターに
場所がなくなってしまう
“マジな”Hadoop
導入の勘所①
パフォーマンスと運用を鑑みた、ある程度の集約を意識した分散構成を組む
例）10PBクラスタの場合
4TB HDD × 8本 ⇒ 313台（ラック18台分）
8TB HDD × 12本 ⇒ 105台(ラック6台分)

②ネットワークの考え方
16
DN内で処理をして、DN間はほとんどデータ転送が
発生しないのでノード間は細い線でも大丈夫
バックアップデータをクラスタに復旧させる際にボト
ルネックになるのでは？
DNが破損した時のリバランス処理は問題にならな
いか？
導入の勘所②
ノード間の結線は10GbE以上が望ましい
多少コスト高になったとしても、安定的な運用を求められる

③番外編
17
Master とSlaveは、別構成にすべき理屈はわかるが、本番、開発、テスト、DRそれぞれ
にMasterだけの役割のノードを持たせるのは無駄
が多い
導入の勘所③
最近はNNとDNは同居する事も可能
メモリが128GB以上あればNNの管理領域が不足するケースは少ない

バックアップ
18

④バックアップ
19
ログ等非クリティカルなデータである（従来捨ててい
た）ため、バックアップは必須ではない
データは３重化されているため、メタデータだけバッ
クアップしておけば十分
エンドユーザは裏がHadoopだろうがRDBだろうが気
にしない
⇒弊社のポリシーに準拠して提案してください
導入の勘所④
HadoopのバックアップはHadoopで！
バックアップのために、NASやTapeを提案するとHadoopのコストメ
リットが薄らいでしまう
（StorageServerに仕事をさせるのが、Hadoopの売りなのに）

クラスター分割はエンドユーザからのBigクエリ対策にも有効
20
•Hadoop to Hadoopであればコピー先を参照用として利用するなど、運用の幅が広がる
（リソース制御やセキュリティ制御などにも有用）
ソース Hadoop #1 バッチ利用
ターゲット Hadoop #2 バックアップ、データ参照
Hadoop Cluster #1
バッチ処理
Hadoop Cluster #2
データ参照
(Sandbox)
バック
アップ

基本的なバックアップ要件は、Hadoopだけでも対応可能
21
バックアップ要件例 Hadoopにおける対応
バックアップの断面が取得可能であること
Snapshot
・対象ディレクトリのブロックをReadOnlyで参照する仕組み
・複数バージョン取得可
・バージョン間の比較も可
クラスタ停止時間以内にバックアップが完了すること
DistCp
・複数mapperが並列で他Hadoopに並列コピーする
・差分更新も可能
Hiveメタ情報とHDFSの同期が取れていること
作り込み
⇒Cloudera BDR (Backup & Disaster Recovery)などで対応
リアルタイムに同期が取れていること
Hadoop to Hadoop
かなり大変 ⇒ Wandiscoなどで対応
DB to Hadoop
かなり大変 ⇒Oracle GoldenGateなどで対応

使い方も簡単
22
①snapshot作成の許可
-bash-4.1$ hdfs dfsadmin -allowSnapshot /tmp/26860-tera-in
Allowing snaphot on /tmp/26860-tera-in succeeded
100GBのデータ
②snapshotの作成
-bash-4.1$ hdfs dfs -createSnapshot /tmp/26860-tera-in
Created snapshot /tmp/26860-tera-in/.snapshot/s20160125-174328.432
.snapshotディレクトリに
ReadOnlyとして作成される
③DistCPによる他クラスタへのレプリケーション
--bash-4.1$ hadoop distcp -atomic /tmp/26860-tera-in/.snapshot/s20160125-174328.4
32 webhdfs://benkei01/tmp/26860-tera-in/
・・・
16/01/27 15:38:34 INFO mapreduce.Job: map 0% reduce 0%
16/01/27 15:38:45 INFO mapreduce.Job: map 2% reduce 0%
・・・
16/01/27 15:48:04 INFO mapreduce.Job: Job job_1452235540015_0003 completed successfully
Mapperが並列にコピー

セキュリティ
23

無防備なHadoopクラスタ (Security Level 0)
検証環境では、ありがちな構成
• Hadoopクライアント
– 認証なし
– どの端末からもアクセス可能
• Beeline , JDBCクライアント
– HiveServer2になりすまし認証
24
Hadoop Cluster
HDFS
YARN
HIVE
管理画面
Hadoop Client
OSユーザ
JDBC
JDBCユーザ
ブラウザ

Hadoopのセキュリティ機能概要
25
セキュアなHadoop環境を実現可能
分類機能対応ツール例
認証ユーザーの認証 Apache Hadoopのベース機能(Kerberos認証)
認可 Hive, ImpalaでのRole単位での認可 Sentry
暗号化
通信路の暗号化 Apache Hadoopのベース機能
保存データの暗号化・マスキング HDFSの暗号化
監査監査の取得・レポーティング 3rd Party Tool

Hadoopの認証機能
• Hadoopの認証では以下の2つの設定がある
–認証なし: クライアント側のOSユーザーをHadoopユーザーとして認識
–Kerberos認証
導入の勘所⑤
Edgeサーバ＋Kerberos認証の設定はHadoopのセキュリティ設定のスタート地点
•悪意のあるユーザーがクライアントにhdfs OSユーザーを作成し、hdfsユーザーで
HDFSユーザーでHadoopにアクセスすると全データを操作できてしまう
⇒不特定多数の端末からアクセスさせない

Security Level 1：エッジサーバを介したアクセス
• 不特定多数からHadoopクラスタ
にアクセスさせない
– 利用者は、エッジサーバにログイン
した上で、Hadoopを操作する
27
Hadoop Cluster
HDFS
YARN
HIVE
管理画面
Edge Server
Hadoop
Client
FireWall

Security Level 2：Kerberos認証
• Kerberos,LDAPによるユーザ認証
– 利用者は、認証サーバに許可を取
得した上で利用する
• 余談
– SqoopでRDB連携する時は、
Oracle walletで鍵アクセス可能
28
Hadoop Cluster
HDFS
YARN
HIVE
管理画面
Edge Server
Hadoop
Client
FireWall
KRB5
LDAP
認証

Security Level 3：認可、暗号化
• Hadoopそのものも守る
– RBAC
• HDFSのアクセス権設定
• SentryによるHive表等のアクセス制御
– データ暗号化
• HDFS Data at Rest Encryption
– 監査
• HDFS監査ログ
• Cloudera Navigator
• Oracle Audit Vault & Database Firewall
• etc
29
Hadoop Cluster
HDFS
YARN
HIVE
管理画面
Edge Server
Hadoop
Client
FireWall
KRB5
LDAP
認証
Sentry
HDFS
Encryption
Audit

HDFS Encryptionのアーキテクチャ
• HDFSクライアントが扱うファイルの暗号化・復号を担当
• Encryption Zoneごとに鍵が存在
Encryption Zone Key = EZK
EZKは鍵管理を行うコンポーネントであるKMSが管理。
ただし、EZKを使って個々のファイルを暗号化するわけではない
• Encryption Zone 内のファイルごとに鍵をKMSが生成
Data Encryption Key = DEK
• ただしDEKをそのまま保管するのは危険なため、DEKをEZKで暗
号化したencrypted DEK = EDEKをNameNodeにメタデータの一部
として保持
• NameNodeの管理権限のある(OS上のファイルとしてEDEKを不
正に取得することもできる)HDFS管理ユーザーにKMSに対する
権限を与えないように設定をしておく(ブラックリスト)
30

HDFS Encryptionのアーキテクチャ
• Keystore
– keystoreは、 Key Management
Server (KMS)の鍵保管を行う
– 通常はファイルベースの
keystore(Java KeyStore)
– Clouderaの場合Cloudera Navigator
Key Trustee Server(PostgreSQL)
31

HDFS暗号化は本当にOSから参照できなくなる？ 1/3
32
①HDFSの暗号化ゾーンを作成
[oracle@server01 ~]# kinit hdfs@EXA.JP.ORACLE.COM
Password for hdfs@EXA.JP.ORACLE.COM:
[oracle@server01 ~]# hdfs dfs -mkdir /cipher
[oracle@server01 ~]# hdfs dfs -mkdir /plain
[oracle@server01 ~]# hadoop key create nokk
[oracle@server01 ~]# hdfs crypto -createZone -keyName nokk -path /cipher
Added encryption zone /cipher
[oracle@server01 ~]# hdfs crypto -listZones
/cipher nokk
Kerberos認証
暗号化ゾーン作成
[oracle@server01 ~]# echo テストデータ > /oracle/テスト
[oracle@server01 ~]# hdfs dfs -put /oracle/テスト /cipher/
[oracle@server01 ~]# hdfs dfs -put /oracle/テスト /plain/
②テストデータをHDFSに保存
「テスト」というファイルを暗号化、非暗号化に配置

33
③HDFSのブロック番号を検索
[oracle@server01 ~]# hdfs fsck /cipher/テスト -files -blocks
Connecting to namenode via http://server02.exa.jp.oracle.com:50070
FSCK started by test (auth:KERBEROS_SSL) from /xxx.xxx.xx.xx for path /cipher/テスト at Thu Dec 10 11:34:06 JST 2016
/cipher/テスト 19 bytes, 1 block(s): OK
0. BP-529482047-192.168.21.81-1448469031064:blk_1073773664_32840 len=19 repl=3
以下略
暗号化ファイルのブロック
[oracle@server01 ~]# find /u[0-1][0-9] -name blk_1073773664
/u07/hadoop/dfs/current/BP-529482047-192.168.21.81-
1448469031064/current/finalized/subdir0/subdir124/blk_1073773664
④ブロックの場所を検索
当該ブロックの絶対パス
/cipher/テスト blk_1073773664
/plain/テスト blk_1073773668
IPadress
IPadress

34
⑤ファイルの中身の確認
[oracle@server01 ~]# cat /u07/hadoop/dfs/current/BP-529482047-192.168.21.81-1448469031064/
current/finalized/subdir0/subdir124/blk_1073773664
▒▒▒qqa>▒▒▒▒▒▒Λ`▒
[oracle@server01 ~]# cat /u03/hadoop/dfs/current/BP-529482047-192.168.21.81-1448469031064/
current/finalized/subdir0/subdir124/blk_1073773668
テストデータ
暗号化ファイルされたファイル
IPadress
IPadress
暗号化されていないファイル
導入の勘所⑥
お客様のデータはHadoopでもしっかり守れます！
•ディスク交換を頻繁に行うシステムだからこそ、しっかり暗号化が必要

HDFS暗号化のパフォーマンス劣化が心配なんだけど。。。
35
出典： Intel® Xeon® Processor E5-2600 v3 Accelerates
Hadoop HDFS Encryption
http://www.intel.com/newsroom/kits/xeon/e7v3/pdfs/Xeo
n_E7v3_Cloudera-aes-ni.pdf
暗号化による劣化はReadで5%
Writeはほぼなし
ベンチマークterasortの結果は1%
導入の勘所⑦
HDFS暗号化のデメリットは少ない
•処理能力が大幅に劣化するというのは都市伝説。

パフォーマンス
36

Hadoopに出し入れする処の話
37
＋
ストアド
プロシジャ
File ->
Hadoop
MapReduce
Hadoop
-> DB
ここの話
•MapReduceやSparkが早いのは当たり前（数台 VS 数百台）
•ただし、ロードの部分を何とかしないと全体のスループットとして効果が薄い

Hadoop連携技術はたくさんあるけど、何を選べば良い？
38
Stream loadingBatch loading
Kafka
Flume
GoldenGate
HDFS Put
Kite CLI
distcp
sqoop
WebHDFS
HttpFS
•エコシステムはたくさんあって便利ですが、セキュリティやリソース制御とか監視な
どを考えると、可能な限り万能選手を厳選して利用したい

バッチロードツールの比較
Hadoop Client Httpfs WebHDFS
Edgeサーバへ
のインストール
必要不要不要
Hadoop側の
GateWay有無
無必要(SPoF) 無(動的)
使いやすさ
◎
コマンドライン
○
HTTP REST API
○
HTTP REST API
パフォーマンス思っていたより遅い（１ファイル１スレッド処理）
39
Hadoop Cluster
HDFS nodes
Edge Server
Client

hadoop fs -put test hdfs://scaj43bda02:8020/tmp/test31;
curl -i -X PUT -L -H 'Content-Type:application/octet-stream'
"http://scaj43bda03:14000/webhdfs/v1/tmp/test11?op=CREATE&user.name=root" -T test.txt;
ロードパフォーマンスの違いを比較してみた
40
コマンドは以下の通り:
1) HttpFS
2) WebHDFS
curl -i -X PUT -L
"http://scaj43bda02:50070/webhdfs/v1/tmp/test21?op=CREATE&user.name=root" -T test.txt
3) Hadoop Client
ServerName
ServerName
curl -i -X PUT -L
"http://scaj43bda02:50070/webhdfs/v1/tmp/test21?op=CREATE&user.name=root" -T test.txtServerName

DISK
CPU
HttpFS WebHDFS Hadoop
client
•どれも同じような動き
•HttpFS、WebHDFSはGateway
が動作しているノードだけ若干
CPUを利用している
リソースを使い切れていない
DBのように並列ロードする仕
組みを考えてみる

• 前提として、分割されたファイルを用意する
# ls /stage/files/|wc -l
50
• ファイルサイズは51GB
# du -sh /stage/files
51G /stage/files
• まずは普通にHDFSに書き込んで見る（シングルスレッド）:
# time hadoop fs –put /stage/files/*hdfs://scaj43bda03:8020/tmp/load_test3
real 3m36.966s
• クライアントを複数起動して、同時にHDFSに書き込む
# for i in `ls /stage/files/`; do time hadoop fs -put /stage/files/$i
hdfs://scaj43bda03:8020/tmp/load_test3 2>&1 & done;
real 1m13.156s
Hadoop Clientから並列ロードをやってみよう
３分半かかる
約３倍の速さに
42

DISK
CPU
パラレル
ロード
シングル
ロード
•リソースは使い切れていない
ものの、シングルよりは大幅に
改善

1) パラレル WebHDFSロード
for i in `ls /stage/files/`; do time curl -i -X PUT -L
"http://scaj43bda02:50070/webhdfs/v1/tmp/load_test3/$i?op=CREATE&user.name=root" -T /stage/files/$i
2>&1 & done;
WebHDFS やHttpFSでも同様の効果があるか？
2) パラレルHttpFS ロード
for i in `ls /stage/files/`; do time curl -i -X PUT -L -H 'Content-Type:application/octet-stream'
"http://scaj43bda03:14000/webhdfs/v1/tmp/load_test3/$i?op=CREATE&user.name=root" -T /stage/files/$i;
2>&1 & done;
結果
•WebHDFSは、Hadoopクライアントと同等性能が測定された
•しかし、HttpFSには、ほとんど効果なし（Gatewayだけがんばる)
44

データロードに関する勘所
45
導入の勘所⑧
データロードは、複数ファイルあれば並列化して高速ロードできる
・クライアントインストール可能な場合は Hadoop Client(操作が楽）
・インストール不可な場合はWebHDFSを利用
導入の勘所⑨
Edgeサーバは必ず導入しましょう
・セキュリティ
・DNのローカルから実行すると、当該ノードにブロックが作成されるので偏りが起きる
Hadoop Cluster
HDFS nodes
Edge Server
Client

まとめ
46

エンタープライズユーザにHadoopを導入するための勘所
• スケールアウトするのは便利だけど。。。
– > IAサーバは故障するから、大規模構成にしすぎずにある程度の高集約サーバ
• セキュリティやバックアップの運用が心配
– > 機能は充足してきており充分に対応可能
• パフォーマンス
– >処理だけではなく、ロードの部分なども考慮して、より効果を高めよう
47

導入の勘所⑩
RDBユーザのど真ん中を開拓する事で、Hadoopはもっと広がる！
・SPoFもなくなり、国内事例も増えてきており、Hadoopを静観する時期は過ぎた

ご清聴ありがとうございました
その他、Hadoop関連Oracle製品↓
www.slideshare.net/oracle4engineer/
oraclehadoop
49

ご質問・ご相談等ございましたら、終了後もお受けしております
0120-155-096
（平日9:00-12:00 / 13:00-18:00）
http://www.oracle.com/jp/direct/index.html
各種無償支援サービスもございます。
Oracle Direct 検索
Oracle Direct
あなたにいちばん近いオラクル

Hadoop Conference Japan_2016 セッション「顧客事例から学んだ、エンタープライズでの "マジな"Hadoop導入の勘所」

Hadoop Conference Japan_2016 セッション「顧客事例から学んだ、エンタープライズでの "マジな"Hadoop導入の勘所」

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Hadoop Conference Japan_2016 セッション「顧客事例から学んだ、エンタープライズでの "マジな"Hadoop導入の勘所」

Similar a Hadoop Conference Japan_2016 セッション「顧客事例から学んだ、エンタープライズでの "マジな"Hadoop導入の勘所」 (20)

Más de オラクルエンジニア通信

Más de オラクルエンジニア通信 (20)