Cloudera in the Cloud #CWT2017

1© Cloudera, Inc. All rights reserved.
Cloudera in the Cloud
Tsuyoshi Miyake | Sr. Systems Engineer | Cloudera

⾃⼰紹介
三宅剛史（みやけつよし / Tsuyoshi Miyake）
Sr. Systems Engineer & SE Specialization - Cloud
Career: Sun, GS, Pivotal, AWS etc.
@tsuyokb | tsuyo@cloudera.com | github.com/tsuyo

アジェンダ
• なぜデータ分析をクラウドでやるのか？
• Why Cloudera in the Cloud?
• デプロイパターンとストレージオプション
• Cloudera Director
• Cloudera Altus
• Workload Analytics
• まとめ

なぜデータ分析をクラウドでやるのか？

⼤規模データが⽣
成・保存されアプ
リケーションがデ
プロイされる場所
である

いつでも使えて
「伸縮可能」
「従量課⾦」

データがどこからで
もアクセスできる

Why Cloudera in the Cloud?

ハイブリッド・マルチクラウドに対応
アプリケーションがどんな環境でも透過的に動くことが必須

様々なユースケースに対応
Modern data processing
(ETL) at scale
Data
Engineering
Explore, analyze, and
understand all your data
Analytic DB
Data-driven applications to
deliver real-time insights
Operational
DB
Multi-Storage,
Multi-Environment
Exploratory data science
and machine learning
Data Science
特に⼀時的・⻑期的なクラスターの使い分けは必須

商⽤利⽤可能な環境
OPERATIONS
DATA+MANAGEMENT
UNIFIED+SERVICES
PROCESS,+ANALYZE,+SERVE
STORE
INTEGRATE
Impala
Navigator
Navigator
Optimizer
Hive-on-
Spark
Hue BI Partners

デプロイパターンと
ストレージオプション

⼀時的なクラスター
(Cloud-native)
デプロイモデルの選択
Object Store
⻑時間稼働のクラスター
(Lift and Shift)

Pets vs. Cattle

⻑時間クラスター (Lift-and-shift) ユースケース
⻑時間クラスターへの要求
• ⾼可⽤性とディザスタリカバリ
• 運⽤管理（リソース管理・パッチ・ローリングアップグレード）
• セキュリティ
• クラスターの動的な伸縮
ユースケース
• HBase/Kudu/Kafka clusters
• Persistent Batch/BI (>50-60% Usage)
• Large, multi-user clusters

Cloud-native アプリケーションパターン
クラスタの短期利⽤、
コスト削減
リソース競合を回避、
ワークロードの最適化
Object Store
ストレージと計算の分離
ストレージ
計算

⼀時的なクラスター (Cloud-native) ユースケース
⼀時的なクラスターへの要求
• Cloud-native アプリケーション（前掲）
ユースケース
• ⾮定期的な Batch/BI (<50% Usage)
• 突発的な ETL に対応
• 開発・テスト環境の複製（稼働率によって⻑
期的なクラスターへの移⾏も）

アーキテクチャー・パターン (1)
HDFS S3
Persistent Transient
#2 Persistent
Batch
（最もコントロー
ルしやすい）
Cloud デプロイ・パターン
ストレージオプション
クラスターライフサイクル
デフォルト
#3 Persistent
Batch on HDFS
（最も速い）
#1 Transient Batch
（最も柔軟）

アーキテクチャー・パターン (2)
Native Support

ハイブリッド・ストレージオプション (HDFS + S3)
• S3 をバックアップとして都度 HDFS にコピーする Hybrid 型（下図）
• 中間データは HDFS に書き、最終結果を S3 に格納する Hybrid 型
S3
Run jobStart Cluster Stop Cluster
Copy to HDFSStart Cluster Run Job Copy to S3 Stop Cluster
HDFS
Time
S3 Only
Hybrid

Cloudera Director

Overview (1)
オンデマンドのクラスター
起動・拡張・縮⼩・終了
● Cloudera Manager との連携
● 既存クラスターへ新規ノードの
追加や削除が可能
● 外部の DB や RDS をサポート
● Transient クラスター⽤の従量
課⾦モデル

Overview (2)
マルチクラウドのサポート
● AWS, Azure, GCP
● ハイブリッド
● OSS SPI で独⾃のプラグイン

Overview (3)
プログラム化・反復可能
● クラスターを反復可能な設定
ファイルベースで定義
● 様々なベストプラクティスが存
在 (director-scripts)
● クラスターの⽴ち上げ時や
シャットダウン時にカスタムの
スクリプトを流すことが可能

Overview (4)
Long-Running クラスター
● CDH & CM のアップグレード
● クラスターのトポロジー変更や
再構成
● != 24 hrs クラスター

Overview (5)
セキュリティー
● Cloudera Director DB の⾃動暗
号化
● CM & CDH の Kerberos 認証サ
ポート
● Cloudera Navigator のデプロイ
サポート（監査・リネージ）

Overview (6)
強⼒な Web UI
● マルチクラウドにまたがったク
ラスターと CM の⼀元管理
● クラスターのオペレーション全
般（作成・拡張・縮⼩・終了）

Overview (7)
安定したライフサイクル
● ワーカーノードの Auto-Repair
● クラスターのライフサイクル全
般においてインスタンスロス
(Spot, Preemptible) に対する安
定した対応
● S3Guard

クラスターのライフサイクル管理
Cloudera
Director
AWS
Azure
GCP
Plugins
CM
CM
CM
CM
BU1 – VPC1
BU2 – VPC2
BU3
BU4
CDH Cluster 1
CDH Cluster 2
CDH Cluster
CDH Cluster
CDH Cluster

Azure
Director Architecture with Java SPI (plugins)
Web UI
API console
SDKs
Director ServerAPI SPI CM-2CDH5
CDH5
AWS
GCP
Director Client.conf file
local state
bootstrap
SPI
CM-1CDH5
CDH5
bootstrap-remote
terminate-remote
import

Let’s get started with cloudera-boot
まずはサクッと試してみたい⽅に
● https://github.com/tsuyo/cloudera-boot/

Cloudera Altus

ユーザーがフォーカスしたいのは
クラスター管理ではなくジョブ
ログを失うとクラスター起動の失
敗や実⾏時のパフォーマンス問題
への対処が不可能
独⾃のストレージ・ファイル構造
がインフラのロックインを引き起
こす
運⽤の負荷アプリのトラブルシューティングサイロなサービス・ロックイン
クラウドでビッグデータを扱う際の課題

● Cloudera PaaS のブラン
ド名
● サービスを構築するため
のフレームワークの基礎
要素（右図）
● サービスの第⼀弾が
Altus for Data Engineering
Analytic
DBMS
Operational
DBMS
Data
Engineering
Altus Platform Services
Altus PaaS Foundation
= 現在 = 計画中
Cloudera Altus はビッグデータ分析⽤の PaaS

Data Engineering のための Cloudera Altus
AWS 上での ETL・機械学習・
データ処理⽤の PaaS
● MR2, Hive, Spark, Hive-on-Spark
のサポート
● Job ファースト
● 迅速かつ容易なワークロードト
ラブルシューティング・分析
● Cloudera プラットフォーム・
パートナーテクノロジーとの運
⽤互換性

Altus でユーザーが解放されること
ソフトウェアのインストール
ハードウェアのインストール
クラスターの構成
クラスターのアップグレード・再構成
OS のアップグレード・パッチ適⽤
リソース管理

ジョブを中⼼にエンドユーザーに焦点を
ワークロードトラブルシュー
ティング・分析
● クラスター終了後のログ・構成
を⽤いたジョブのトラブル
シューティング
● ジョブ失敗の直接的原因の表⽰
● 遅いジョブの特定及び根本原因
の分析

Altus サービスアーキテクチャー

ジョブのリアルタイム監視
via Cloudera Manager

Altus UI から終了したジョブの確認
過去に実⾏された
ジョブの⼀覧を表⽰
特定のクラスタで
実⾏されたジョブ
の⼀覧を表⽰

Workload Analytics

What is ‘Workload Analytics’ (WA) ?
• パブリッククラウドサービス上の Cloudera 管理のマネージドサービス
• オプトイン形式（デフォルトではオフ）、利⽤に際してコストは発⽣しない
• Altus クラスターから分析に必要な情報を収集
• 失敗・遅いワークロードに対してのトラブルシューティング及びパフォーマン
ス管理を提供
• ⼀時的なクラスターをシャットダウンした後にも利⽤可能
• 特に繰り返し実⾏されるワークロードに関して最適化されている

WA がない場合

ジョブ終了時、Telemetry Publisher が最新のワークロード情報を Altus に送信
• YARN アプリケーションログ（AM、task/executor logs）
• メトリック
• MR-based: .jhist files
• Spark : event logs
• Oozie workflow (XML)
• Job 構成情報など
• Hive post-execution hook info（クエリレベルの情報を取得可能）
収集されるデータ

ヘルスチェック（致命的エラー）

• パフォーマンスの問題を特定
• ステージレベルでボトルネックを特定
ヘルスチェック（データの偏り）
２シグマ (σ) 外であれば
Outlier（外れ値）として表⽰

• Hadoop history server (SHS/JHS) 同等機能
• クラスター停⽌後もデータを利⽤可能
• Spark と MR で統⼀のインタフェース
ログ・メトリック・構成

• 同じ名前のジョブをトラック
• 異常値（± 2σ）の検知
ジョブのトレンドと異常検知

まとめ

まとめ: Why Cloudera in the Cloud?
- アプリケーションのポータビ
リティを保持
- 単に複数の環境を使うことで
はない
- ベンダーロックインを避ける
- 特に⼀時的・⻑期的なユース
ケース両⽅に対応していること
が重要（詳細は後述）
- 統合的な管理性
- 可⽤性
- セキュリティ
- データガバナンス
など商⽤環境に求められる要件
を保持したままリスクを低減
ハイブリッド・マルチクラウド様々なユースケース商⽤利⽤可能

まとめ: Altus
低コスト
• ノードごとの時間課⾦
• Spot インスタンスとセルフヒーリング対応
エンドユーザーに焦点
• クラスター管理をユーザーから解放
• エンドユーザーがセルフサービスで利⽤可能
• Workload
統合プラットフォーム
• オンプレ・クラウドで同⼀の Cloudera プラット
フォーム
セキュア
• AWS セキュリティとの統合
• Cloudera は顧客データに⼀切アクセス不可能
• 複数 AWS アカウントのサポート

最後に: Pets “&” Cattle
Cloudera はお客様のワークロー
ドが最も価値のある場所で実⾏
されることを信じています

Thank you!
tsuyo@cloudera.com

Cloudera in the Cloud #CWT2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cloudera in the Cloud #CWT2017

Similar to Cloudera in the Cloud #CWT2017 (20)

More from Cloudera Japan

More from Cloudera Japan (8)

Cloudera in the Cloud #CWT2017