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プロダクト本部立山重幸 ([email protected])

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/big-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/big-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が破損した時のリバランス処理は問題にならないか？

“マジな”Hadoop導入の勘所②

ノード間の結線は10GbE以上が望ましい多少コスト高になったとしても、安定的な運用を求められる



③番外編

17


Master とSlaveは、別構成にすべき理屈はわかるが、本番、開発、テスト、DRそれぞれにMasterだけの役割のノードを持たせるのは無駄が多い

“マジな”Hadoop導入の勘所③

最近はNNとDNは同居する事も可能メモリが128GB以上あればNNの管理領域が不足するケースは少ない


バックアップ

18



④バックアップ

19


ログ等非クリティカルなデータである（従来捨てていた）ため、バックアップは必須ではない

データは３重化されているため、メタデータだけバックアップしておけば十分

エンドユーザは裏がHadoopだろうがRDBだろうが気にしない ⇒弊社のポリシーに準拠して提案してください

“マジな”Hadoop導入の勘所④

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認証

“マジな”Hadoop導入の勘所⑤

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 [email protected] Password for [email protected]: [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に保存

「テスト」というファイルを暗号化、非暗号化に配置

mailto:[email protected]



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導入の勘所⑥

お客様のデータはHadoopでもしっかり守れます！ •ディスク交換を頻繁に行うシステムだからこそ、しっかり暗号化が必要


HDFS暗号化のパフォーマンス劣化が心配なんだけど。。。

35

出典： Intel® Xeon® Processor E5-2600 v3 Accelerates Hadoop HDFS Encryption http://www.intel.com/newsroom/kits/xeon/e7v3/pdfs/Xeon_E7v3_Cloudera-aes-ni.pdf

暗号化による劣化はReadで5% Writeはほぼなしベンチマークterasortの結果は1%

“マジな”Hadoop導入の勘所⑦

HDFS暗号化のデメリットは少ない •処理能力が大幅に劣化するというのは都市伝説。


パフォーマンス

36


Hadoopに出し入れする処の話

37

＋

ストアドプロシジャ

File -> Hadoop

MapReduce

Hadoop -> DB

ここの話

•MapReduceやSparkが早いのは当たり前（数台 VS 数百台） •ただし、ロードの部分を何とかしないと全体のスループットとして効果が薄い


Hadoop連携技術はたくさんあるけど、何を選べば良い？

38

Stream loading Batch 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.txt ServerName


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導入の勘所⑧

データロードは、複数ファイルあれば並列化して高速ロードできる・クライアントインストール可能な場合は Hadoop Client(操作が楽）・インストール不可な場合はWebHDFSを利用

“マジな”Hadoop導入の勘所⑨

Edgeサーバは必ず導入しましょう・セキュリティ・DNのローカルから実行すると、当該ノードにブロックが作成されるので偏りが起きる

Hadoop Cluster HDFS nodes

Edge Server

Client


まとめ

46


エンタープライズユーザにHadoopを導入するための勘所

• スケールアウトするのは便利だけど。。。 – > IAサーバは故障するから、大規模構成にしすぎずにある程度の高集約サーバ

• セキュリティやバックアップの運用が心配 – > 機能は充足してきており充分に対応可能

•パフォーマンス – >処理だけではなく、ロードの部分なども考慮して、より効果を高めよう

47


“マジな”Hadoop導入の勘所⑩

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


ご清聴ありがとうございました

その他、Hadoop関連Oracle製品↓ www.slideshare.net/oracle4engineer/

oraclehadoop

49

http://www.slideshare.net/oracle4engineer/oraclehadoop

http://www.slideshare.net/oracle4engineer/oraclehadoop


ご質問・ご相談等ございましたら、終了後もお受けしております

0120-155-096 （平日9:00-12:00 / 13:00-18:00）

http://www.oracle.com/jp/direct/index.html

各種無償支援サービスもございます。

Oracle Direct 検索

Oracle Direct あなたにいちばん近いオラクル

http://www.oracle.com/jp/direct/index.html

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 51

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 52

Software

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

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