ApacheSparkを中心としたOSSビッグデータ活用と導入時の検討ポイント

© 2016 IBM Corporation

Apache Spark を中心としたOSSビッグデータ活用と導入時の検討ポイント

Tanaka Y.P2016-10-25

© 2016 IBM Corporation2

自己紹介田中裕一（ yuichi tanaka）主にアーキテクチャとサーバーサイドプログラムを担当することが多い。 Hadoop/Spark周りをよく触ります。Node.js、 Python、最近は Spark周りの仕事で Scalaを書くことが多い気がします。

休日は OSS 周りで遊んだり。

詳解 Apache Spark


自己紹介


背景

昨今データ活用の重要性が説かれて久しく、IoT, 機会学習 ,Cognitive,AI,Security,etc,.etc のワードと共に全ての業種で必須と言っていいほど分析基盤の重要性は高まっています。

参考：総務省 H.24 情報通信白書 http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h24/html/nc121410.html


HADOOP が起こしたブレイクスルー


遥か昔

データ活用のための基盤というのは非常に限られた世界の技術でした。当時の考え方1. 非常に高価な HW （最適化された高速な CPU, 多くのメモリ）を用

いて2. 少量のデータに対し複雑な処理を行わせる

- 専用の HW- 専用の知識- 専用の技術- 早い限界

Fat Server


分散システム

ここで登場するのが分散システムの考え方です。 GridComputing や HPC を筆頭に1. 一つのタスク（仕事）を2. 複数のマシンで分散して処理を行う発想が登場しました。中央に配置したデータを実行時に CPU にコピーし複数のマシンで複雑な処理を行わせる3. 複雑なプログラミング4. CPU にコピーするための帯域の上限5. 耐障害性の課題


Hadoop の登場

昨今注目を集めているのが Apache Hadoop での分散システムです。データは配置する際に分散して配置し、処理はデータが配置されたマシン上に割振る1. 安価な (commodity 化された )HW2. データコピーによる単純な耐障害性の担保3. 高レイヤでのアプリ構築4. 最低限のデータ転送5. スケーラビリティ


Hadoop 時代のアーキテクチャまとめ

Hadoop 登場により、一般の企業に大規模データを活用した高度な分析や新しいサービスが登場し活用が広がっていきます。

登場人物のおさらい1. 分散データ（ HDFS ）2. 分散処理（ MapReduce ）

HDFS

MapReduce


Hadoop の Ecosystem 化


Hadoop の複雑化

大規模データの活用が広がる中で、より簡単により専門的な処理を行うための新しいミドルウェアが登場や、新たな要件の取り組み、また Hadoop 自体も洗練されていきます。

Hadoop の洗練- 分散処理のうち、分散処理の為のフレームワークとリ

ソース管理の分離

HDFS

MapReduce

HDFS

MapReduce

YARN


Ecosystem の形成

Hadoop を中心とした Ecosystem の形成- より簡単に SQL 文で分散処理を行う Hive 等、 SQL エンジンの登場- より専門的な機会学習を分散処理する Mahout 等、機会学習エンジンの登場- 大規模なデータを効率よく検索させる Solr 等、全文検索エンジンの移植- Graph 処理を扱う Giraph,Hama 等、 Graph 処理エンジンの登場- データを効率よく Hadoop に収集するための Flume 等、 ETL システムの登

場- 処理した結果を効率よく他システムに連携する為の queue 、 RDB との組み

合わせ- 大量書き込み可能な HBase 等、ストレージエンジンの登場- HadoopEcosystem 全体を管理するための Ambari 等、 Cluster 管理システム

の登場- etc,.etc


Ecosystem の登場人物

活用が広がる中で、各分野が専門化し、それらを組み合わせた一つの世界を作っていきます。

登場人物のおさらい- 分散データ（ HDFS ）- ストレージエンジン（ HBase ）- 全文検索（ Solr,Elasticsearch ）- Queue,RDB(Kafka,RabbitMQ,PostgreSQL,MySQL)- リソース管理 (YARN)- 分散処理 (MapReduce)- SQL エンジン (Hive)- 機会学習 (Mahout)- Graph 処理 (Giraph,Hama)- ETL(Flume,Sqoop)- Cluster 管理 (Ambari)


Hadoop(HDFS/YARN)

基幹データ顧客データ

購買データデータベース

従来型のデータ

ソーシャルデータオープンデータ

新しいデータ

センサーデータ

IoT

batch

Micr

o batch

Stream

ing

SPSS

Cognos

データ活用基盤の技術要素の俯瞰

Data ソース ETL系処理系

操作系表示系

連携系

管理系


多様なデータを表現する為の OSS の利用

RethinkDB

RabbitMQ

Postgres

Elasticsearch

Hadoop

高速 / 高度な分析

検索 I/F の提供

OLTP I/F の提供

リアルタイムな更新情報 I/F の提供

AMQP システム間連携 I/F の提供


データ活用と Ecosystem の問題

Hadoop の登場でデータ活用が広く一般的になってきました。しかし、データ活用の業界が広がるにつれ、

- 新たな要件に fit したミドルウェアが乱立- 大規模データに対するレイテンシの要件の高度化

が求められた結果- 複雑化した Ecosystem で迷子になる- 管理運用難易度が上がり- 複数のミドルウェアに対応するため、技術習得の難易度も上がる

この辺りから HadoopEcosystem 全般を管理運用する為の Hadoop エンジニアの必要性が高まります。


Spark の登場

そこで登場したのが Spark です。- 大規模データに対するレイテンシの要件に対し、 InMemory で分散処理を行う- ミドルウェアの乱立に対し、 Spark内に SQL,Streaming,GraphX,MLlib を内包する


Spark とは❶Spark とはRDD と DAG をコアコンセプトとして設計された分散並列処理フレームワーク

Driver Program

Worker Worker Worker

ProgramProgramProgram

DataDataData


Spark とは❷Spark とはRDD と DAG をコアコンセプトとして設計された分散並列処理フレームワーク

Driver Program


ProgramProgramProgramDataDataData


Spark とは❸Spark とはRDD と DAG をコアコンセプトとして設計された分散並列処理フレームワーク

Driver Program


ProgramProgramProgramDataDataData

output output output


NarrowDependency,ShuffleDependency

ここでは各 Partition の変換操作（ NarrowDependency ）とアクション操作（ ShuffleDependency ）を Transaction.csvを元に reduceByKey 時の job を見ていきます。

WorkerNode

WorkerNode

WorkerNode

Partition0

Partition3

Partition1

Partition2

6,tanaka,532

1,tanaka,1002,tanaka,300

3,tsuchiya,504,kaijima,2000

5,tsuchiya,1320

Partition0

Partition3

(tanaka,100)(tanaka,300)

(tanaka,532)

Partition1(tsuchiya,50)(kaijima,2000)

Partition2(tsuchiya,1320)

Partition0(tanaka,932)

Partition2(kaijima,2000)

Partition1(tsuchiya,1370)

Narrow DependencyShuffle Dependency

Stage0 Stage1

task0

task1

task2

task3

task4

task5

task6


さらなるデータ活用の浸透


Spark の活用と新たな可能性

Spark の登場により従来の分析処理（ BI の為の集計など）に加え、- 機会学習処理をアドホックに行う- 今流れているデータに対して分析を行う- 分析結果を他システムに直接連携し、別システムの Input とする

といった運用が可能になりました。

従来の分析

ストリーミング処理

アドホック処理


断続的な処理を想定したデータ処理　　　　　　　　　 ~ データを”永久”に保持しない ~ 全データに対する一括処理を目的とせず、断続的に流れるデータをインメモリで加工処理しデータ出力をする一連の流れを最も簡単にモデル化したデータ処理モデル .

記録データ

処理要求処理結果データ

インメモリデータ

処理

バッチ、 OLTP 処理ストリーム・コンピューティング

※任意の時間・区間データをメモリ上に保持することができます。

※全てのデータは HDD に永続化されていることが前提。

PULLPUSH

アクション


受信データから特定条件（フィルタリング）データのみを抽出する

区間内の移動平均値や一括り処理をする

フィルタリング入力タプル出力タプル

例 :条件閾値>100（℃）

フィルタリング、タプルの追加・削除、タプルの変換に利用

(1) フィルタリング処理

t(1) t(k)スライディング・ウィ

ンドウ

データをある束に区切って処理する場合に利用

区間内の「タプル数」で集約する場合は、タンブリング・ウィンドウを用います。

(2) スライディング・ウィンドウ処理

参考：オペレータ処理の例


Spark とストリーム処理の組み合わせ例

Incidents

Calls for Service (911, etc)

311

Code Violation

sPermit

s

Buildings Apache Spark

MLlib

HDFS

ヒストリカル・データ

Model2 :どのアク

ションを実行すべき

か？

Model1 :これはフォルス・アラームか？

リアルタイムインプット

データ

リアルタイム予測分析 & コン

テキスト解析

リアルタイム・ダッシュボード

InfoSphere STREAMS


機械学習への取り組みの変化

学習用DataSet

モデル化

モデル

本番 DataSet

適用

学習用DataSet学習用

DataSet学習用DataSet

モデル

モデル

モデル

D

D

D

D

他システム連携

ナレッジ

複合の分析

従来の分析• 単一データセット• 小さなデータ

変化• 複合データセット• 大きなデータ• 即応性• チームでの分析


データサイエンティストの需要の高まりと基盤

今まで一部企業のみにあったデータサイエンティストという職種が広く求められてきます。合わせて、データサイエンティストが必要とす

る環境に合わせて JupyterNotebook,ZeppelingNotebook などのNotebookI/F系が今注目されています。- Web 上でのアドホック分析- データと分析処理のナレッジ化- 分析の共有


ユースケースとアーキテクチャ


分析基盤の３つの用途

ここまで BigData と呼ばれる分野の歴史を駆け足で見てきました。ここからは目的の整理とアーキテクチャを見ていきます。

大きな３つの用途- 大規模バッチ処理を目的とした基盤- リアルタイム処理を目的とした基盤- アドホック分析を目的とした基盤


大規模バッチ処理基盤

この用途の基盤では多くのバッチ処理が継続的に平行で流れます。主に他システムで発生したデータを集約し、結果を BI/CI 、他システムに連携していく事をメインに扱います。

Hadoop(HDFS/YARN)

繰り返し処理


リアルタイム処理基盤

この用途の基盤では他システムで発生したデータを直接受け取り継続的に小規模なバッチや異常値検知などで利用されます。こちらも結果を他システムに連携していく事をメインに扱います

Hadoop(HDFS/YARN)

MQTT


アドホック分析基盤

この用途の基盤では他システムで発生したデータを組み合わせ様々な新しい知見を得る為に利用されます。こちらは結果をアドホックに得る為、いかにインタラクティブに処理を行わせるかがメインとなってきます。

Hadoop(HDFS/YARN)


まとめ

この３つの用途は分離可能ではなく、うまく共存していく事が重要です。 OSS の選定の際にも、

- 主となる用途（バッチがメイン？アドホック分析がメイン？）- 補助的な用途、またはチャレンジ

を意識して BigData 基盤を育てていくと良いでしょう。

ApacheSparkを中心としたOSSビッグデータ活用と導入時の検討ポイント

Technology

Transcript of ApacheSparkを中心としたOSSビッグデータ活用と導入時の検討ポイント