Cisco様主催「実際動いているIoT & Hadoopシステムから学ぶ会」での2つ目の講演のスライドです。 http://www.cisco.com/web/JP/event/es/161/iot_hadoop/index.html ビッグデータのPoCで成果を出すことができれば、それでそのまま本番投入できるのか？ 本スライドでは、構築、運用にあたってどのような問題があるかを紹介します。

1. 1© Cloudera, Inc. All rights reserved.
エンタープライズデータハブ
活⽤用の落落とし⽳穴
Cloudera テクニカルエバンジェリスト
嶋内 翔

2. 3© Cloudera, Inc. All rights reserved.
エンタープライズデータハブ
バッチ、インタラクティブ、
リアルタイム
1つのプラットフォームで最⾼高の
パフォーマンスとユーザビリティ
を実現
• きめ細かい分析ワークフロー
• より多くのデータにアクセス
• 新たな⽅方法でデータを処理理
• これまでとは異異なるユーザーの
取り込み
セキュリティと運⽤用管理理
プロセス
取込み
Sqoop, Flume
変換
MapReduce, Hive,
Pig, Spark
ディスカバー
分析データベース
Impala
検索索
Solr
モデル
機械学習
SAS, R, Spark,
Mahout
サーブ
NoSQL データベー
ス
HBase
ストリーミング
Spark Streaming
無制限のストレージ HDFS, HBase
YARN, Cloudera Manager,
Cloudera Navigator

3. 4© Cloudera, Inc. All rights reserved.
エンタープライズデータハブを試すのは簡単
cloudera.com/live
CDH

4. 6© Cloudera, Inc. All rights reserved.
しかし……
• 本番環境を構築・運⽤用するには多くの課題がある
• そもそもどれだけの性能を出せばいいのか？
• データ量量の増加予測は本当に間違いないのか？
• バージョンアップ時にセンサーデータからのデータ収集を⽌止めるの
か？
• IoTプロジェクトの責任者が辞めてしまったら？

5. 7© Cloudera, Inc. All rights reserved.
SLAを定める
• 「週次」「⽉月次」のみの分析はもう過去の話
• 特にIoTの世界であれば時間単位、分単位の処理理は当たり前
• しかし、流流⼊入し続ける⼤大量量のデータを低レイテンシ、あるいはスト
リームで処理理し続ける基盤を作るのは多⼤大な困難を伴う
• SLAをどう定めるかは慎重に決定する必要がある

6. 8© Cloudera, Inc. All rights reserved.
アーキテクチャ設計の重要性
パフォーマンスは発揮できているか？
100台のクラスタにおいて5%性能向上はサーバ5台分の経費削減
ストレージ層は正しく設計できているか？
ファイルフォーマット、HBase / Hive スキーマなど
フォーマットの選択により、読み書きの性能、データの圧縮率率率が決まる
データ量量が膨⼤大になると、データフォーマットの変更更には時間もコストもかかる
オンプレかクラウドか、正しく選択できているか？
初期投資、ランニングコスト
データ転送にかかる時間、費⽤用
パフォーマンス、セキュリティ
間違ったアーキテクチャ設計は、無駄なハードウェアコスト、性能の低下、安定性の
低下など多くの問題を引き起こす

7. 9© Cloudera, Inc. All rights reserved.
• 計画当初のデータ増加量量予測は
⼤大抵⼤大きい⽅方に外れる
• ビジネスの拡⼤大
• 新サービスの追加
• 新たなユースケース
• 1.5億個のセンサーの収集データ
を毎分10バイト追加すると年年間
721TB、Hadoop上なら2.1PB
の増加となる
• ⽇日本の携帯電話は1.5億個
データ量量の増加
運⽤用年年数
データ量量
計画当初の予測
実際のデータ量量は
もっと⼤大きくなる！

8. 10© Cloudera, Inc. All rights reserved.
• バージョン塩漬けの問題
• サポート期限
• セキュリティ脆弱性の対応
• 新しい機能の導⼊入ができない
• エンタープライズデータハブは⻑⾧長期間
の運⽤用が前提となるため、アップグ
レード必須
• バージョンアップには様々な課題があ
る
• 動作検証の⽅方法
• 移⾏行行費⽤用
• メンテナンス時間
• 特に流流⼊入し続けるデータをどう保
持するかが課題
バージョンアップ・サービスの追加
Cloudera 4.7
Impala 追加
Spark 追加
Kafka 追加
Cloudera 5.1
Cloudera 5.4

9. 11© Cloudera, Inc. All rights reserved.
• 分散メッセージキューKafkaを使
えば、Hadoopがダウンしても
Kafka上にデータを保持すること
が可能
• Hadoopの前段に設置すれば、
アップグレード時もデータの流流
⼊入を停⽌止する必要がない
• バッチ読み込みができるので後
追いで処理理の実施が可能
Kafkaを活⽤用したデータストリームの保持
Hadoopクラスタ
Kafkaクラスタ
センサーデータ
Hadoopがダウンしても
データは流流⼊入し続ける

10. 14© Cloudera, Inc. All rights reserved.
• Hadoopクラスタは社内のエース
エンジニアが構築することが多
い
• エースがずっと同じ業務に携わ
ることはできない
• 異異動、あるいは昇進
• 転職
• チームとして運⽤用する体制が重
要！
• 後進の育成も必須
事業継続性
Hadoopのことならな
んでも任せてくれ！
お世話になり
ました…
頼もしい！
これからどう
しよう…
数年年後

11. 15© Cloudera, Inc. All rights reserved.
まとめ

12. 16© Cloudera, Inc. All rights reserved.
IoTのための基盤を作るには
適切切に要件を定義する
バッチ処理理だけでは競争⼒力力を得られない
複雑なストリーム処理理は構築・運⽤用に困難を伴う
正しい知識識で構築・運⽤用する
低レイテンシの環境を維持するのは容易易ではない
短期間の修得が必要なら Cloudera のトレーニングを活⽤用すること

13. 17© Cloudera, Inc. All rights reserved.
Questions?
sho@cloudera.com