データ活用をもっともっと円滑に！～データ処理・分析基盤編を少しだけ～

Copyright © 2016 NTT DATA Corporation
NTTデータ技術革新統括本部
OSSプロフェッショナルサービス
土橋昌
データ活用をもっともっと円滑に！
～データ処理・分析基盤編を少しだけ～
Spark Summit2016報告会＆データ分析勉強会

2Copyright © 2016 NTT DATA Corporation
自己紹介
土橋昌 - Masaru Dobashi
OSSを徹底活用したシステム開発やR&Dに従事。エンジニア。
7、8年前にHadoopに出会い、1000台超えのHadoopのシステ
ムの開発・運用などを担う。当時の課題感からStorm、Sparkの
取り組みをはじめ現在に至る。
技術コンサルから現場開発、インフラからデータ処理、ゲテモノ
から定番まで、捻じ伏せてどうにかするのがお仕事です。
等々
Spark Summit Strata Hadoop World

 分析に関わるエンジニアと分析者が円滑に仕事するために、
データ処理基盤が押さえるべきポイントは？の話
なぜ分析に関して基盤のことを考えなくてはならないか？
=> 要であるデータはそこを通ってやってから。
プロダクト固有の話は省略
ポイントは色々ある中からピックアップして紹介
今日のお話

Copyright © 2015 NTT DATA Corporation 4
背景

 データ活用の様々な現場で見てきた辛いやり取りの一例
背景

背景
急だけど○○のデータ使いたいのだけ
ど、すぐ出せない？
やってみるよ。…あー、元データない
かも？どうするかな
HadoopとかSparkとか××とかで
一発で出せるよね？
いや、HadoopやSparkや××も
万能じゃないし。
むしろ遅いときあるよね
いつもの日次のバッチなんだけど、1
時間ごとにできないか？って聞かれれ
たんだけど、どう？
処理は行けるかもしれないけど、そ
もそも入力データって、たしか連携
先で自作した日次バッチで置いても
らっているんじゃなかったかなぁ

 他にも、処理基盤側でできることをグループ内でちゃんと共
有できていなかったために、機会損失しているとか。
 組織構造的に難しいケースもあるのも事実ですが…。
 ある程度の作業分担が進んだ組織で、責任分界点がある
状態だと、「仕組み」が入り組んだ状態では、前述の
課題を解決するのはなかなか難しい。
背景

 せめて、データ処理基盤＝仕組みの部分でもっとう
まく取り回しできて、生産的な連携に力を注ぐことができたら
…。
 そこで今後のために、企業におけるデータ処理基盤のキホン
を改めて押さえよう！
今回紹介すること

分析のための処理基盤のキホン

 お手元のシステムで本観点で十分に機能していますか？
 ちなみに、Hadoop界隈でよく見られるキーワードを付記して
みると…
結論：キホンは蓄積、処理、パイプラインを制すること
処理
蓄積パイプライン
Hadoop HDFS
HBase
Hive
Hadoop MapReduce
Spark
Fluentd
Embulk
Kafka
データの原石を加工して
価値のある情報をスムーズに
抽出するために最低限必要な要素は？
注：ここではデータを連携する仕
組み自体とします
（やや狭義のパイプライン）

 これを突き詰めていくと最終的に、「データの基本セットを機
械的に生成」、「オンデマンドで必要なデータを生成」するため
の環境が整う
 さらにデータマネジメント注の考え方と合わせて用いれば、管
理されたデータから必要なデータを取り出したり、生成するの
が円滑になる。
 …でも現実では、これを手堅く実現するのが意外とおざなり
になるから大変だったりするわけですね
注：ここでは単純に「データを価値のあるリソースとして管理するための規約」のこととします

 これを突き詰めていくと最終的に、「データの基本セットを機
械的に生成」、「オンデマンドで必要なデータを生成」するため
の環境が整う
 さらにデータマネジメント注の考え方と合わせて用いれば、管
理されたデータから必要なデータを取り出したり、生成するの
が円滑になる。
 …でも現実では、これを手堅く実現するのが意外とおざなり
になるから大変だったりするわけですね
注：ここでは単純に「データを価値のあるリソースとして管理するための規約」のこととします
このあたりの基本をおさえて調整
できるエンジニアと分析者が
組めるととても強力

各観点のポイントをいくつか紹介
ポンポンポンと
紹介していきます。
別の場所でちゃんと
体系立てて説明したい。

 ログなどを扱う場合には、生データを溜めていざというときに
取り出せるようにしたい。
分析していると、ロジックの問題なのか元データの特徴なのか振り返
ることがある。「元データに原因があるか？」という検証をすることも
多々ある。また異なる分析処理に入れるために元があったほうが良
いことも多い。（異なる分析処理ではそれぞれ異なる解釈がある）
ただし、ある程度活用先のスコープが絞れるならばスキーマ付データ
ストアは当然強力。型を後でバリデートするのは大変…。
 入力データだけでなく、中間データ、結果データも保存対象
になることが多い。したがって、必要な容量は意外と多いと
覚悟して検討をスタートするが良い。
蓄積のポイントの例（その１）
蓄積処理
パイプ
ライン

 一方で、生成はもとより、削除、アーカイブ化にも注意
データストアは必ず容量が不足 or コストが問題化する。
容量見積もりが甘いから、という話もあるが、
現実的な問題として後から要件が追加されることは多い。
（分析業務においては）
しばらく運用していると、もしかしたら「ごみの山」でいっぱいかも？
でも、「ごみと認定するルール」は？オンデマンドの処理を許されたク
ラスタでは利用度合いの可視化 & 強制対処も必要。
- データストアのユーザディレクトリの使用量可視化、計算リソースの使用量可視
化など
アーカイブ化にも馬力が必要なことに注意。データ処理を前提として
データストア（HDFSなど）に入れておかないと将来困る可能性がある。
蓄積のポイントの例（その２）
蓄積処理
パイプ
ライン

 自分のワークロードで意図通り動くことを確認するのは大事
 既存資料を参考にするにせよ、妄信するのは火傷の元…。
「コツ」と割り切って、本当に正しいかは手元で確認必要。
 分散処理関連のOSSは、開発元の目的に特化したものが多い。
ハマれば非常に強いが、外したときの扱いづらさもなかなか大きい。
- 根本的に思ったような効果が得られないときは「もしかしたら使い方があっていな
いのかも？」と考える思考も大事。
 ログなどを扱う場合には、生データを加工、集計するための柔軟
な仕組みが欲しい。例えば前処理って大事。
 複数の処理フレームワークで実現する方法は適材適所の利点
 単一のフレームワークで実現する方法は取り回しのよさの利点
 スケーラビリティが本当に必要かどうか？は重要な岐路。
 結果としてPostgreSQL、Pythonなどのツールなどを採用するケースもある
処理のポイントの例（その１）
蓄積処理
パイプ
ライン

 計画性は大事なのは前提だが、「試行錯誤」は残ると覚悟
試行錯誤するのに適した処理環境があると便利。
後発の分散処理（Sparkなど）はそれを意識したつくりになっている
ただしリソース消費を読みづらい点から、リソース分離が鬼門になり
がちなことに注意。最悪別環境で…とかも考える。そうすると後述の
データパイプラインがキモになる。
 「性能」、「汎用性」の間には直接の関係性はないが、トレード
オフになることもあるから注意
 蓄積する技術と比べて、処理するための技術は様々な趣向
が凝らされたプロダクトが生まれる傾向がある。様々な処理
系を実行できる環境があればベター。
処理のポイントの例（その２）
蓄積処理
パイプ
ライン

 様々な場所からデータを届けるための仕掛けはとても重要
 パイプライン前後のインターフェースや機能は、勝手に決めら
れないことも多いうえに様々な種類があって大変。柔軟性に
富んだ仕組みにはコスト注
がかかる認識が必要。
外接部分はとにかく条件が複雑になりがちで心労も大きい…。
パイプラインのポイントの例（その１）
注：ここでいうコストは、稼働、金額などを含む広義のコスト
蓄積処理
パイプ
ライン

 本当に柔軟性が必要ならメッセージングシステムなどを挟ん
でリード・ライトのライフサイクルを分離する必要あり。
パイプラインにデータを流す頻度、速度に分析のサイクルが束縛され
ることもあるから気が抜けない。
要求されるサイクルはビジネス要求によっても変化することに注意
データの利用者が複数になると、同じデータを異なるサイクルで消費
することもある。その目的でもメッセージングシステムを挟むのは有用
 「高速に届ける。かつ、絶対に落とさないし、重複もしない」
という条件は、安易に合意するものではない。
結局のところ費用対効果の話に落ち着く。異常系発生時の影響を
考慮したうえで、やりすぎないように注意。「サービス（ビジネス）上は
どんなインパクトがあるのか？」
パイプラインのポイントの例（その２）
蓄積処理
パイプ
ライン

背景（再掲）
急だけど○○のデータ使いたいのだけ
ど、すぐ出せない？
やってみるよ。…あー、元データない
かも？どうするかな
HadoopとかSparkとか××とかで
一発で出せるよね？
いや、HadoopやSparkや××も
万能じゃないし。
むしろ遅いときあるよね
いつもの日次のバッチなんだけど、1
時間ごとにできないか？って聞かれれ
たんだけど、どう？
処理は行けるかもしれないけど、そ
もそも入力データって、たしか連携
先で自作した日次バッチで置いても
らっているんじゃなかったかなぁ
蓄積
処理
パイプライン

まとめ
多数のエンジニアや分析者が絡み、責任分界点があ
る組織では複雑な仕組みが問題に拍車をかけること
がある
仕組みを作るうえでのポイントを関係者間で認識し、
意図せずに問題を難しくしないように心がけたい
基本は、蓄積、処理、パイプライン。
注意点に気を付けて「データの基本セットを機械的に
生成」、「オンデマンドで必要なデータを生成」する環
境を手にしよう
そのあとは色々と希望に合わせて応用

お問い合わせ先：
株式会社ＮＴＴデータ技術革新統括本部
OSSプロフェッショナルサービス
URL: http://oss.nttdata.co.jp/hadoop
メール： hadoop@kits.nttdata.co.jp TEL： 050-5546-9000

データ活用をもっともっと円滑に！～データ処理・分析基盤編を少しだけ～

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie データ活用をもっともっと円滑に！～データ処理・分析基盤編を少しだけ～

Ähnlich wie データ活用をもっともっと円滑に！～データ処理・分析基盤編を少しだけ～ (20)

Mehr von NTT DATA OSS Professional Services

Mehr von NTT DATA OSS Professional Services (20)