Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模データ分析を支えるインフラ系オープンソースソフトウェアの最新事情
Search
草薙昭彦
June 08, 2016
Technology
0
29
大規模データ分析を支えるインフラ系オープンソースソフトウェアの最新事情
みんなのPython勉強会#13
での発表資料です。
草薙昭彦
June 08, 2016
Tweet
Share
More Decks by 草薙昭彦
See All by 草薙昭彦
現場で役立つAPIデザイン
nagix
35
13k
Postmanを使いこなす!2025年ぜひとも押さえておきたいPostmanの10の機能
nagix
2
150
Postman Vault を使った秘密情報の安全な管理
nagix
0
150
Postman Vaultを使った秘密情報の安全な管理
nagix
3
260
Postman AIエージェントビルダー - AIエージェントの作成をいつものPostmanのインターフェースで!
nagix
0
110
APIデバッグとリバースエンジニアリング
nagix
0
93
AIアシスタントの活用で品質の向上と開発ワークフローのスピードアップ
nagix
0
81
APIデバッグとリバースエンジニアリング
nagix
0
120
Mini Tokyo 3D × PLATEAU - 公共交通デジタルツインにリアルな風景を
nagix
1
340
Other Decks in Technology
See All in Technology
OpenID BizDay#17 KYC WG活動報告(法人) / 20250219-BizDay17-KYC-legalidentity
oidfj
0
290
AndroidXR 開発ツールごとの できることできないこと
donabe3
0
130
全文検索+セマンティックランカー+LLMの自然文検索サ−ビスで得られた知見
segavvy
2
130
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
1
1.5k
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
300
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
57k
CZII - CryoET Object Identification 参加振り返り・解法共有
tattaka
0
420
表現を育てる
kiyou77
1
220
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
150
2024.02.19 W&B AIエージェントLT会 / AIエージェントが業務を代行するための計画と実行 / Algomatic 宮脇
smiyawaki0820
14
4k
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
660
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
250
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
A Philosophy of Restraint
colly
203
16k
Facilitating Awesome Meetings
lara
52
6.2k
How GitHub (no longer) Works
holman
314
140k
For a Future-Friendly Web
brad_frost
176
9.5k
RailsConf 2023
tenderlove
29
1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
How STYLIGHT went responsive
nonsquared
98
5.4k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.2k
Side Projects
sachag
452
42k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Transcript
大規模データ分析を支えるインフラ系 オープンソースソフトウェアの最新事情 草薙 昭彦 (@nagix) MapR Technologies
自己紹介 • 草薙 昭彦 (@nagix) • MapR Technologies データエンジニア NS-SHAFT
無料!
一般的な分析のデータフロー 収集 抽出 変換 加工 格納 集計 加工 生成 モデル
作成 可視化 レポート
一般人 収集 抽出 変換 加工 格納 集計 加工 生成 モデル
作成 可視化 レポート 手入力 Excel Excel Excel Excel
一般人 収集 抽出 変換 加工 格納 集計 加工 生成 モデル
作成 可視化 レポート 手入力 Excel Excel Excel Excel 実は専門家も
企業では 収集 抽出 変換 加工 格納 集計 加工 生成 モデル
作成 可視化 レポート 各部門 のRDB のCSV 出力 マスタと の結合 名寄せ 分析用 RDB SQL R SAS SPSS Excel Oracle DB2 MySQL PostgreSQL …
組織の規模が大きくなると • データボリューム – 大容量ストレージ・効率の良い格納フォーマット • 処理性能 – データ増や複数ユーザの同時アクセスに対応 • 信頼性・可用性 – ハードウェアのHA化・データの複製
• セキュリティ – 認証・アクセス制御・暗号化・監査
大企業では 収集 抽出 変換 加工 格納 集計 加工 モデル 作成
可視化 レポート ETL ツール RDB コネクタ ETL ツール データ ウェア ハウス SQL R SAS SPSS セルフ サービ スBI Teradata IBM Netezza HP VerLca AcLan Matrix InformaLca Data Stage Syncsort Talend QlikView Pentaho
ビッグデータって何でしたっけ • データボリューム – 従来のアーキテクチャでは処理格納できない量 • データの種類 – 非構造化(=スキーマが確定していない)データ • データの流入頻度 – 月次・日時バッチ投入から都度の投入へ
大規模なデータを扱う時に重要なこと • スケールアウト(水平スケーラビリティ) • CPUとストレージの距離(データローカリティ) サーバ ・・・ スケールアウト可能なアルゴリズム・データ格納方式 共有ストレージ (NAS/SAN)
サーバ レイテンシ の問題 スループット の問題 サーバ サーバ サーバ 内蔵 HDD /SSD 内蔵 HDD /SSD 内蔵 HDD /SSD CPU CPU CPU
大規模なデータを扱う時に重要なこと • Data Gravity(データの重力) Web App Data 分析 App Data
会計 App Data マーケ App Data 販売 App Data 販売 App Data 会計 App マーケ App
分析のROI • 最も重要なのはデータを増やしたとしてもそ れに見合うリターンが得られるかどうか – データが増えれば得られる価値は上がりそう・・ – 問題はコストをいかに抑えることができるか • コモディティハードウェアは必須! • スケールアウト分散処理ソフトウェアは必須!
• オープンソースソフトウェアは有力な選択肢
参考 • Google対Yahoo—インターネット戦争でどうしてここ まで差がついたのかを振り返る hZp://jp.techcrunch.com/2016/05/23/20160522why-google-beat-yahoo-in-the-war-for-the-internet/ – “NetAppハードウェアのコストはYahooの規模の拡大と同 じ速さで増大し、Yahooの利益の大きな部分に食い込むこ ととなった” –
“これに対して Googleは、規模を拡大し新サービスを追加 するときに起きるはずの問題を、それが起きる前に予期し、 効率的に対処できるようGoogle File Systemの開発に全力 を挙げた”
Hadoop ベース分析基盤(初期) 収集 抽出 変換 加工 格納 集計 加工 モデル作成
可視化 レポート ログ コレクタ RDB コネクタ Map Reduce Hive Pig HDFS Map Reduce Hive Pig Mahout セルフ サービ スBI
Hadoopって? サーバ サーバ サーバ サーバ サーバ サーバ
Hadoopって? サーバ Hadoop Distributed File System (HDFS) データをブロックに 分割して分散配置、 3つのレプリカ作成
Hadoopって? サーバ Hadoop Distributed File System (HDFS) 分割されたデータ をMap、Reduceと いう単位で並列分
散処理 MapReduce
Hadoopって? Hadoop Distributed File System (HDFS) MapReduce Hadoop コア
Hadoopって? Hadoop Distributed File System (HDFS) MapReduce Hive SQLクエリ エンジン
HBase NoSQL データベース Pig データ加工 フレームワーク Mahout 機械学習 Zoo Keeper 分散レポジトリ ・・・ MapReduce/HDFS を使いやすくする ための無数のプロ ジェクト
Hadoop ベース分析基盤(現在) 収集 抽出 変換 加工 格納 集計 加工 モデル作成
可視化 レポート ログ コレクタ RDB コネクタ Spark Hive Pig HDFS Spark SQL Dashbo ard NoteBo ok Apache Spark Apache Kylin Apache Drill Apache Impala Presto MLLib Oryx Apache Spark Apache Hive Apache Pig Apache Flume Fluentd Jupyter Apache Zeppelin Spark Notebook H2O
Sparkって? • (主に)MapReduce の置き換え – バッチだけでなくインタラクティブな処理も – メモリを最大限利用し、より効率よく Spark Spark SQL SQLクエリ
エンジン Spark Streaming ストリーム処理 MLlib 機械学習 GraphX グラフ処理 Spark R R on Spark HDFS またはその他のファイルシステム
トレンド:リアルタイム処理 • ビジネス側からの要件 – より早い変化の検知、決断、情報の提供 – 業務処理と分析処理は統合へ • データフロー、格納、処理それぞれに新しい アーキテクチャが必要 • 処理の2つのアプローチ
– バッチを極限まで細かくしていく(マイクロバッチ) – メッセージを1つ1つ処理していく
リアルタイム処理基盤 収集 抽出 変換 加工 格納 集計 加工 モデル作成 可視化
ログ コレクタ RDB コネクタ Spark Streami ng Kaka メッセー ジ キュー Spark Streami ng Dashbo ard Spark Streaming Apache Storm Apache Flink Apache APEX Apache Nifi StreamSets Apache Flume Fluentd ElasLcsearch /Kibana Grafana
ラムダアーキテクチャ • バッチ処理(Data at Rest)とリアルタイムストリー ム処理(Streaming Data)は組み合わせることで 価値が出る – 近似的な速報値をリアルタイム処理で得る
– 正確な集計や深い分析は履歴データを利用しバッチ 処理で得る • データを入口で複製し、用途に応じた最適な フォーマットで格納する – 例: 時間レンジの検索ならHBase、履歴集計なら Parquet
ラムダアーキテクチャ hZps://www.mapr.com/developercentral/lambda-architecture
ラムダアーキテクチャ 収集 抽出 変換 加工 格納 集計 加工 モデル作成 可視化
格納 抽出 変換 加工 集計 加工 モデル作成 バッチレイヤー スピードレイヤー Kaka HDFS
分析のタイプ • バッチ分析 – 蓄積された大量データから知見を得る • リアルタイム分析 – 流れてくるデータを対象にとりあえずの解を得る • インタラクティブ分析 – よくわからないものから鍵を見つけ方針を決める
Apache Arrow • カラム型インメモリ分析のデファクト標準を目 指す Apache プロジェクト • 多くのビッグデータ系Apacheプロジェクトで共 通のデータ構造を使うといいよね?
• データ構造、アルゴリズム、クロス言語バイン ディングを定義 • 最新のCPUの機能を活用した高速な分析
これは非効率性だわ・・・ • 各システムは独自の内部メモリ 形式を持つ • 70〜80%のCPUはシリアライズ・ デシリアライズに使われる • 似たような機能が複数のプロジェ クトで実装される
Thrin, Avro, Protobuf,…
• すべてのシステムは共通のメモリ 形式を持つ • システム間のやりとりにオーバー ヘッドがない • プロジェクト間で機能を共有できる (例: Parquet-to-Arrow
リーダー) ならばこうだ
カラム型フォーマット Row-oriented フォーマット (CSV, 従来のRDB, …) Column-oriented フォーマット (Parquet, ORC,
…)
Feather File Format • Apache ArrowをベースにしたRとPythonの Data Frameに適したディスク上のファイル フォーマット •
なんで今までこんな便利なものがなかったん だ!
PyhtonはUI言語から処理言語へ? hZp://www.slideshare.net/wesm/nextgeneraLon-python-big-data-tools-powered-by-apache-arrow
ありがとうございました