Cloudera in the Cloud #CWT2017

1© Cloudera, Inc. All rights reserved.

Cloudera in the CloudTsuyoshi Miyake | Sr. Systems Engineer | Cloudera


⾃⼰紹介

三宅剛史（みやけつよし / Tsuyoshi Miyake）Sr. Systems Engineer & SE Specialization - CloudCareer: Sun, GS, Pivotal, AWS etc.@tsuyokb | [email protected] | 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

特に⼀時的・⻑期的なクラスターの使い分けは必須


商⽤利⽤可能な環境

OPERA

TIONS

DATA

+MAN

AGEM

ENT

UNIFIED+SERVICES

PROCESS,+ANALYZE,+SERVE

STORE

INTEGRATE

Impala

NavigatorNavigator 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


クラスターのライフサイクル管理

ClouderaDirector

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 statebootstrap

SPI

CM-1CDH5

CDH5

bootstrap-remoteterminate-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 [email protected]