Submit Search
Upload
20171125 springfest snappydata
•
5 likes
•
6,823 views
M
Masaki Yamakawa
Follow
2017/11/25 Spring FestでのSnappyData発表資料
Read less
Read more
Technology
Report
Share
Report
Share
1 of 51
Download now
Download to read offline
Recommended
20171118 jjug snappydata
20171118 jjug snappydata
Masaki Yamakawa
20220331_DSSA_MigrationToYugabyteDB
20220331_DSSA_MigrationToYugabyteDB
Masaki Yamakawa
20181031 springfest spring data geode
20181031 springfest spring data geode
Masaki Yamakawa
トレジャーデータ 導入体験記 リブセンス編
トレジャーデータ 導入体験記 リブセンス編
Kentaro Yoshida
MongoDB概要:金融業界でのMongoDB
MongoDB概要:金融業界でのMongoDB
ippei_suzuki
データウェアハウスモデリング入門(ダイジェスト版)(事前公開版)
データウェアハウスモデリング入門(ダイジェスト版)(事前公開版)
Satoshi Nagayasu
MongoDBご紹介:事例紹介もあり
MongoDBご紹介:事例紹介もあり
ippei_suzuki
データ可視化勉強会
データ可視化勉強会
Daichi Morifuji
Recommended
20171118 jjug snappydata
20171118 jjug snappydata
Masaki Yamakawa
20220331_DSSA_MigrationToYugabyteDB
20220331_DSSA_MigrationToYugabyteDB
Masaki Yamakawa
20181031 springfest spring data geode
20181031 springfest spring data geode
Masaki Yamakawa
トレジャーデータ 導入体験記 リブセンス編
トレジャーデータ 導入体験記 リブセンス編
Kentaro Yoshida
MongoDB概要:金融業界でのMongoDB
MongoDB概要:金融業界でのMongoDB
ippei_suzuki
データウェアハウスモデリング入門(ダイジェスト版)(事前公開版)
データウェアハウスモデリング入門(ダイジェスト版)(事前公開版)
Satoshi Nagayasu
MongoDBご紹介:事例紹介もあり
MongoDBご紹介:事例紹介もあり
ippei_suzuki
データ可視化勉強会
データ可視化勉強会
Daichi Morifuji
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
トレジャーデータとtableau実現する自動レポーティング
トレジャーデータとtableau実現する自動レポーティング
Takahiro Inoue
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
データウェアハウス入門 (マーケティングデータ分析基盤技術勉強会)
データウェアハウス入門 (マーケティングデータ分析基盤技術勉強会)
Takeshi Mikami
Nosqlの基礎知識(2013年7月講義資料)
Nosqlの基礎知識(2013年7月講義資料)
CLOUDIAN KK
About NoSQL
About NoSQL
hideaki honda
Html5j data visualization_and_d3
Html5j data visualization_and_d3
Daichi Morifuji
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
Hideo Takagi
qpstudy 2013.07 NoSQL
qpstudy 2013.07 NoSQL
Akihiro Okuno
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
[db tech showcase Tokyo 2017] D35: 何を基準に選定すべきなのか!? ~ビッグデータ×IoT×AI時代のデータベースのアー...
[db tech showcase Tokyo 2017] D35: 何を基準に選定すべきなのか!? ~ビッグデータ×IoT×AI時代のデータベースのアー...
Insight Technology, Inc.
オンラインゲームソリューション@トレジャーデータ
オンラインゲームソリューション@トレジャーデータ
Takahiro Inoue
データ分析を支える技術 データ分析基盤再入門
データ分析を支える技術 データ分析基盤再入門
Satoru Ishikawa
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
Shohei Kobayashi
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ~Apache Cassandra編~
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ~Apache Cassandra編~
kishimotosc
Azure Datalake 大全
Azure Datalake 大全
Daiyu Hatakeyama
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
Daiyu Hatakeyama
ビジネス活用事例で学ぶデータサイエンス入門 #6
ビジネス活用事例で学ぶデータサイエンス入門 #6
you shimajiro
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
griddb
データ分析概略
データ分析概略
Daiyu Hatakeyama
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
griddb
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ IoT時代のデータベースとは??
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ IoT時代のデータベースとは??
griddb
More Related Content
What's hot
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
トレジャーデータとtableau実現する自動レポーティング
トレジャーデータとtableau実現する自動レポーティング
Takahiro Inoue
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
データウェアハウス入門 (マーケティングデータ分析基盤技術勉強会)
データウェアハウス入門 (マーケティングデータ分析基盤技術勉強会)
Takeshi Mikami
Nosqlの基礎知識(2013年7月講義資料)
Nosqlの基礎知識(2013年7月講義資料)
CLOUDIAN KK
About NoSQL
About NoSQL
hideaki honda
Html5j data visualization_and_d3
Html5j data visualization_and_d3
Daichi Morifuji
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
Hideo Takagi
qpstudy 2013.07 NoSQL
qpstudy 2013.07 NoSQL
Akihiro Okuno
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
[db tech showcase Tokyo 2017] D35: 何を基準に選定すべきなのか!? ~ビッグデータ×IoT×AI時代のデータベースのアー...
[db tech showcase Tokyo 2017] D35: 何を基準に選定すべきなのか!? ~ビッグデータ×IoT×AI時代のデータベースのアー...
Insight Technology, Inc.
オンラインゲームソリューション@トレジャーデータ
オンラインゲームソリューション@トレジャーデータ
Takahiro Inoue
データ分析を支える技術 データ分析基盤再入門
データ分析を支える技術 データ分析基盤再入門
Satoru Ishikawa
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
Shohei Kobayashi
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ~Apache Cassandra編~
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ~Apache Cassandra編~
kishimotosc
Azure Datalake 大全
Azure Datalake 大全
Daiyu Hatakeyama
What's hot
(16)
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
トレジャーデータとtableau実現する自動レポーティング
トレジャーデータとtableau実現する自動レポーティング
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
データウェアハウス入門 (マーケティングデータ分析基盤技術勉強会)
データウェアハウス入門 (マーケティングデータ分析基盤技術勉強会)
Nosqlの基礎知識(2013年7月講義資料)
Nosqlの基礎知識(2013年7月講義資料)
About NoSQL
About NoSQL
Html5j data visualization_and_d3
Html5j data visualization_and_d3
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
【ウェブ セミナー】AI 時代のクラウド データ ウェアハウス Azure SQL Data Warehouse [実践編]
qpstudy 2013.07 NoSQL
qpstudy 2013.07 NoSQL
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
[db tech showcase Tokyo 2017] D35: 何を基準に選定すべきなのか!? ~ビッグデータ×IoT×AI時代のデータベースのアー...
[db tech showcase Tokyo 2017] D35: 何を基準に選定すべきなのか!? ~ビッグデータ×IoT×AI時代のデータベースのアー...
オンラインゲームソリューション@トレジャーデータ
オンラインゲームソリューション@トレジャーデータ
データ分析を支える技術 データ分析基盤再入門
データ分析を支える技術 データ分析基盤再入門
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ~Apache Cassandra編~
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ~Apache Cassandra編~
Azure Datalake 大全
Azure Datalake 大全
Similar to 20171125 springfest snappydata
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
Daiyu Hatakeyama
ビジネス活用事例で学ぶデータサイエンス入門 #6
ビジネス活用事例で学ぶデータサイエンス入門 #6
you shimajiro
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
griddb
データ分析概略
データ分析概略
Daiyu Hatakeyama
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
griddb
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ IoT時代のデータベースとは??
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ IoT時代のデータベースとは??
griddb
20191115-PGconf.Japan
20191115-PGconf.Japan
Kohei KaiGai
佐賀大学 - データ分析と向き合う
佐賀大学 - データ分析と向き合う
Daiyu Hatakeyama
Big data解析ビジネス
Big data解析ビジネス
Mie Mori
Apuri she ji_gaido_d_bmentenansushe_ji__v1.0
Apuri she ji_gaido_d_bmentenansushe_ji__v1.0
Kaito Tonooka
Database Security for PCI DSS
Database Security for PCI DSS
Ohyama Masanori
世界分散配信システムとレポーティングシステム刷新のお話
世界分散配信システムとレポーティングシステム刷新のお話
Geniee, Inc. / 株式会社ジーニー
QConTokyo2015「Sparkを用いたビッグデータ解析 〜後編〜」
QConTokyo2015「Sparkを用いたビッグデータ解析 〜後編〜」
Kazuki Taniguchi
04 citynet awsセミナー_クラウドでビックデータのスモールスタート
04 citynet awsセミナー_クラウドでビックデータのスモールスタート
充博 大崎
クラウドでビックデータのスモールスタート
クラウドでビックデータのスモールスタート
Yukihito Kataoka
Treasure Data Intro for Data Enthusiast!!
Treasure Data Intro for Data Enthusiast!!
Takahiro Inoue
[C23] 「今」を分析するストリームデータ処理技術とその可能性 by Takahiro Yokoyama
[C23] 「今」を分析するストリームデータ処理技術とその可能性 by Takahiro Yokoyama
Insight Technology, Inc.
#TokyoR 39 高速に前処理するNYSOL
#TokyoR 39 高速に前処理するNYSOL
Satoshi Kitajima
E-commerce企業におけるビッグデータへの挑戦と課題‐機械学習への期待について‐
E-commerce企業におけるビッグデータへの挑戦と課題‐機械学習への期待について‐
Rakuten Group, Inc.
World wide ssp delivery system
World wide ssp delivery system
英伸 篠塚
Similar to 20171125 springfest snappydata
(20)
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
郡山 Connect 2022 ハッカソン 基調講演 - Hackathon からサービスインになったらデータを扱いましょう
ビジネス活用事例で学ぶデータサイエンス入門 #6
ビジネス活用事例で学ぶデータサイエンス入門 #6
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
データ分析概略
データ分析概略
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
何を基準に選定すべきなのか!? 〜ビッグデータ×IoT×AI時代のデータベースのアーキテクチャとメカニズムの比較〜
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ IoT時代のデータベースとは??
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ IoT時代のデータベースとは??
20191115-PGconf.Japan
20191115-PGconf.Japan
佐賀大学 - データ分析と向き合う
佐賀大学 - データ分析と向き合う
Big data解析ビジネス
Big data解析ビジネス
Apuri she ji_gaido_d_bmentenansushe_ji__v1.0
Apuri she ji_gaido_d_bmentenansushe_ji__v1.0
Database Security for PCI DSS
Database Security for PCI DSS
世界分散配信システムとレポーティングシステム刷新のお話
世界分散配信システムとレポーティングシステム刷新のお話
QConTokyo2015「Sparkを用いたビッグデータ解析 〜後編〜」
QConTokyo2015「Sparkを用いたビッグデータ解析 〜後編〜」
04 citynet awsセミナー_クラウドでビックデータのスモールスタート
04 citynet awsセミナー_クラウドでビックデータのスモールスタート
クラウドでビックデータのスモールスタート
クラウドでビックデータのスモールスタート
Treasure Data Intro for Data Enthusiast!!
Treasure Data Intro for Data Enthusiast!!
[C23] 「今」を分析するストリームデータ処理技術とその可能性 by Takahiro Yokoyama
[C23] 「今」を分析するストリームデータ処理技術とその可能性 by Takahiro Yokoyama
#TokyoR 39 高速に前処理するNYSOL
#TokyoR 39 高速に前処理するNYSOL
E-commerce企業におけるビッグデータへの挑戦と課題‐機械学習への期待について‐
E-commerce企業におけるビッグデータへの挑戦と課題‐機械学習への期待について‐
World wide ssp delivery system
World wide ssp delivery system
More from Masaki Yamakawa
20231111_YugabyteDB-on-k8s.pdf
20231111_YugabyteDB-on-k8s.pdf
Masaki Yamakawa
20221117_クラウドネイティブ向けYugabyteDB活用シナリオ
20221117_クラウドネイティブ向けYugabyteDB活用シナリオ
Masaki Yamakawa
20211118 dbts2021 マイクロサービスにおけるApache Geodeの効果的な使い方
20211118 dbts2021 マイクロサービスにおけるApache Geodeの効果的な使い方
Masaki Yamakawa
20190523 IMC meetup-IMDG&DS
20190523 IMC meetup-IMDG&DS
Masaki Yamakawa
Apache geode at-s1p
Apache geode at-s1p
Masaki Yamakawa
20180217 hackertackle geode
20180217 hackertackle geode
Masaki Yamakawa
Geode hands-on
Geode hands-on
Masaki Yamakawa
インメモリーデータグリッドの選択肢
インメモリーデータグリッドの選択肢
Masaki Yamakawa
インメモリーで超高速処理を実現する場合のカギ
インメモリーで超高速処理を実現する場合のカギ
Masaki Yamakawa
超高速処理とスケーラビリティを両立するApache GEODE
超高速処理とスケーラビリティを両立するApache GEODE
Masaki Yamakawa
More from Masaki Yamakawa
(10)
20231111_YugabyteDB-on-k8s.pdf
20231111_YugabyteDB-on-k8s.pdf
20221117_クラウドネイティブ向けYugabyteDB活用シナリオ
20221117_クラウドネイティブ向けYugabyteDB活用シナリオ
20211118 dbts2021 マイクロサービスにおけるApache Geodeの効果的な使い方
20211118 dbts2021 マイクロサービスにおけるApache Geodeの効果的な使い方
20190523 IMC meetup-IMDG&DS
20190523 IMC meetup-IMDG&DS
Apache geode at-s1p
Apache geode at-s1p
20180217 hackertackle geode
20180217 hackertackle geode
Geode hands-on
Geode hands-on
インメモリーデータグリッドの選択肢
インメモリーデータグリッドの選択肢
インメモリーで超高速処理を実現する場合のカギ
インメモリーで超高速処理を実現する場合のカギ
超高速処理とスケーラビリティを両立するApache GEODE
超高速処理とスケーラビリティを両立するApache GEODE
Recently uploaded
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
sugiuralab
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
iPride Co., Ltd.
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Yuma Ohgami
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
Toru Tamaki
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
taisei2219
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
Toru Tamaki
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
Hiroki Ichikura
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
Toru Tamaki
Recently uploaded
(9)
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
20171125 springfest snappydata
1.
ついにきたリアルタイムSpark ビッグデータ処理の新定番「SnappyData」とは 2017.11.24 Fri. SPRING FEST
2017 #jsug #sf_35
2.
自己紹介 山河 征紀 ウルシステムズ株式会社 マネージングコンサルタント { “分野”:”金融系” “得技”:[“分散処理”, “インメモリー処理”] “趣味”:”マラソン” } 2
3.
現在のビッグデータ基盤の課題 Part 1
4.
ビッグデータの処理基盤に満足していますか? 複数プロダクトを組み合わせており複雑 データ連携に意外にも時間がかかる インタラクティブな分析を行うにはパフォーマンスが悪い キャッシュだと速いが、メモリーへの読み込みが必要 データの更新は苦手なものが多い 4
5.
ビッグデータ処理のよくある要求 トランザクション アナリティクス 従来からの データ処理 RDBMS DWH 5 ビッグデータ 処理 NoSQL
SQL on Hadoop ストリーミング ストリームデータ処理
6.
技術を積み上げるとツギハギのシステムになりがち 業務データの記録 業務システム RDBMS 6 データの集約 データの可視化、分析 DWH
BI/データ分析 大量データの記録、処理 Web/B2Cサービスなど データの集約 データの可視化、分析 リアルタイムデータの処理 履歴データの保管 IoT/センサー/ リアルタイムデータなど ストリームデータ処理 リアルタイム AP 通知、アラート
7.
技術を積み上げるとツギハギのシステムになりがち 業務データの記録 業務システム RDBMS 7 データの集約 データの可視化、分析 DWH
BI/データ分析 大量データの記録、処理 Web/B2Cサービスなど データの集約 データの可視化、分析 リアルタイムデータの処理 履歴データの保管 IoT/センサー/ リアルタイムデータなど ストリームデータ処理 リアルタイム AP 通知、アラート TCO増大 分析までに時 間がかかる 非効率 データ一貫性 保持に苦労
8.
Spark登場後はかなりシンプルにはなったものの・・・? 業務システム BI/データ分析 Web/B2Cサービスなど IoT/センサー/ リアルタイムデータなど 8 リアルタイム AP 業務データの記録 大量データの記録、処理 リアルタイムデータの処理 データの可視化、分析 通知、アラート
9.
SnappyDataならもっとシンプルなビッグデータ基盤を構築できる 業務システム BI/データ分析 Web/B2Cサービスなど IoT/センサー/ リアルタイムデータなど 9 リアルタイム AP SnappyData業務データの記録 大量データの記録、処理 リアルタイムデータの処理 データの可視化、分析 通知、アラート
10.
SnappyData=データベース機能を備えたSpark 10
11.
Apache Spark+分散インメモリーDB+独自機能 • Apache
Sparkとインメモリーデータベースを統合し、独自機能を付加している • ベースとなる製品はインメモリー処理が得意なので相性が良い 分散インメモリー データベース 独自付加機能 カラム型データベース 予測分析処理 ロー型データベース トランザクション 分散処理 フレームワーク バッチ処理 分析処理 ストリーム処理 11
12.
SnappyData主要コンポーネント • Sparkとインメモリーデータベースの機能の良いところをシームレスに統合 Micro-batch Streaming
Spark Core Transaction Spark SQL Catalyst OLTP Query OLAP Query SynopsisData Engine P2P Cluster Management Replication/Partition In-Memory Database Sample/TopK TableIndex Row Table Column Table HDFS HDFS HDFS HDFS Spark 独自実装 分散 インメモリーDB 分散 ファイルシステム Stream Table Continuous Query 12
13.
SnappyDataの特徴 Part 2
14.
Sparkプログラムを高速化する4つのキーワード インメモリーデータベース データ保持形式 クラスター統合 SparkSQLチューニング 1 2 3 4 14
15.
Spark 特徴①:インメモリーデータベースにデータを保持している • 処理対象のデータはすでにメモリー上に保持している • ディスクへの読み書きが発生しない分、通常のSparkよりも処理時間が短い Sparkプログラム
Sparkプログラム メモリー メモリー Sparkの場合 SnappyDataの場合 ディスク Spark インメモリーDBHDFS 15
16.
特徴①:データアクセスのコード例 // SparkContextをラップしたSnappySessionを作成 val snappy
= new org.apache.spark.sql. SnappySession(spark.sparkContext) // SQL、DataFrameを使用して新しいデータを作成 val filteredDf = snappy.sql("SELECT * FROM SnappyTable WHERE …") val newDf = filteredDf. .... // 作成したデータを保存 newDf.write.insertInto("NewSnappyTable") // データ読み込み val df = spark.sqlContext.read. format("com.databricks.spark.csv"). option("header", "true").load("hdfs://...") df.createOrReplaceTempView("SparkTable") // SparkSQL、DataFrameを使用して新しいデータを作成 val filteredDf = spark.sql("SELECT * FROM SparkTable WHERE ...") val newDf = filteredDf. .... // 作成したデータを保存 newDf.write. format("com.databricks.spark.csv"). option("header", "false").save("hdfs://...") データ読み込み処理は不要 Sparkの場合 SnappyDataの場合 16
17.
• データはインメモリーDB上にSparkと同じ形式で保持する • データの取得・保存時にシリアライズや型変換が発生しないので速い 特徴②:Sparkと同一のデータ形式で保持している DataFrame Spark データ取得/保存 HDFS/データストア CSVファイル Sparkの場合 Spark DataFrame インメモリーDB データ取得/保存 型変換、シリアライズ/ デシリアライズは不要 SnappyDataの場合 型変換 シリアライズ/ デシリアライズ 17
18.
特徴③:SparkとインメモリーDBのクラスターを統合できる • Spark処理を行うクラスターとインメモリーDBのクラスターを1つのJVMに統合できる • データの移動・コピーなしにインメモリーでデータ処理ができるため速い SnappyData Locator Spark+インメモリーDB クラスター SnappyData Leader (Spark
Driver)Spark Context Unifiedクラスターモード SnappyData DataServer Spark Executor DataFrame DataFrame インメモリーDB JVM SnappyData DataServer Spark Executor DataFrame DataFrame インメモリーDB JVM SnappyData DataServer Spark Executor DataFrame DataFrame インメモリーDB JVM 18
19.
特徴③:もう一つのクラスターモード(参考) • SparkクラスターとインメモリーDBクラスターを別にして個別にスケールアウトすることも可能 SnappyData Locator Sparkクラスター SnappyData Leader (Spark Driver)Spark
Context Splitクラスターモード SnappyData DataServer Spark Executor DataFrame DataFrame インメモリーDB JVM SnappyData DataServer Spark Executor DataFrame DataFrame インメモリーDB JVM SnappyData DataServer Spark Executor DataFrame DataFrame インメモリーDB JVM JVM JVM JVM インメモリーDB クラスター 19
20.
特徴④:SparkSQLを高速化している • SnappyDataはSparkとは異なるDAGを生成する Sparkの場合 SnappyDataの場合 独自のDAGが生成 され、シャッフルが少 なくなり高速となるScan HashJoin Aggregate 20 さらにSparkSQLの一部のワー クロードに手を加えることで処 理の高速化をはかっている SELECT A.CardNumber, SUM(A.TxAmount) FROM CreditCardTx1
A, CreditCardComm B WHERE A.CardNumber=B.CardNumber AND A.TxAmount+B.Comm < 1000 GROUP BY A.CardNumber ORDER BY A.CardNumber Sort SortJoin Aggregate Aggregate
21.
Snappy Dataの使い方 Part 3
22.
例:クレジットカード不正使用検知システム • クレジットカード取引情報をストリームデータとしてリアルタイムに収集し、不正な利用に対して アラートをあげる • SnappyDataで高速処理と大量データの蓄積を実現 APP SnappyData メッセージング ミドルウェア …etc クレジットカード 使用履歴 リアルタイム通知等 カード取引情報 クレジットカード使用情報 ブラックリスト情報 ブラックリスト 情報 リジェクト 情報 ブラックリスト情報 カード取引情報 カード取引情報 ・・・ インメモリーDB 22
23.
• ストリームデータ、トランザクション、アナリティクスを全てSnappyDataで処理する • データベースを内包している点、SQLで処理を記述できる点がポイント SnappyDataを使った場合のアーキテクチャ APP SnappyData メッセージング ミドルウェア インメモリーDB トランザクション 処理 アナリティクス処理 ストリーム データ処理 SQL SQL SQL 23
24.
①ストリームデータ処理 APP SnappyData メッセージング ミドルウェア インメモリーDB ストリーム データ処理 SQL • ストリームデータはテーブルへ書き込まれる • SQLでストリームデータ処理を記述できる Spark単体利用 との相違点 24
25.
SnappyDataはSQLを使ってストリームデータ処理を書く • ストリームデータをテーブル形式で保存するので、SQLを書くだけで処理を実装できる TxId POS Card Number Tx Amount Merchant Code Timestamp 1
111 123456789 ¥10,000 AA 2017/11/05 10:10:01 2 222 777777777 ¥3,980 AA 2017/11/05 10:10:20 3 111 197654532 ¥5,130 BB 2017/11/05 10:10:21 4 333 666666666 ¥323,456 AA 2017/11/05 10:11:05 5 111 888888888 ¥1,980 BB 2017/11/05 10:11:15 6 111 123456789 ¥23,456 AA 2017/11/05 10:11:16 ストリームテーブル SELECT * FROM CreditCardStream WINDOW (DURATION 10 SECONDS, SLIDE 10 SECONDS) WHERE MerchantCode=‘AA'; 処理内容(Continuous Query) 25
26.
ストリームデータソース情報をテーブル定義で指定するだけ ストリーミングデータソース ストレージレベル(Spark設定) CREATE STREAM TABLE
CreditCardStream (TxId long, POS long, CardNumber string, TxAmount long MerchantCode int, Timestamp timestamp) USING KAFKA_STREAM OPTIONS (storagelevel 'MEMORY_AND_DISK_SER_2', rowConverter 'uls.snappy.KafkaToRowsConverter', kafkaParams 'zookeeper.connect->localhost:2181;xx', topics 'CreditCardTxStream'); KAFKA以外のストリーミングデータソース TWITTER_STREAM DIRECTKAFKA_STREAM RABBITMQ_STREAM SOCKET_STREAM FILE_STREAM ストリームデータRow変換クラス ストリーミングデータソース毎の設定 26
27.
StreamToRowsConverterを実装してテーブル形式に変換する class KafkaToRowsConverter extends
StreamToRowsConverter with Serializable { override def toRows(message: Any): Seq[Row] = { val ccTx: CreditCardStream = message.asInstanceOf[CreditCardStream] Seq(Row.fromSeq(Seq(ccTx.getTxId, ccTx.getPos, ccTx.getCardNumber, ccTx.getTxAmount, ccTx.getMerchantCode, ccTx.getTimestamp))) } } ストリームテーブル 1行分のデータ 27
28.
SQLでストリームデータの処理を記述できる • 処理の記述に使用するContinuous Queryは通常のSQLとほぼ同じ •
WINDOW関数で指定した間隔のデータを取得できる SELECT * FROM CreditCardStream WINDOW (DURATION 10 SECONDS, SLIDE 2 SECONDS) WHERE MerchantCode=‘AA'; MerchantCodeが「AA」のデータを 2秒のスライドウィンドウで取得する DURATION 10秒 SLIDE 2秒 28
29.
ContinuousQueryではWINDOWに含まれるデータのみ取得される 2 61 43 TxId
POS Card Number Tx Amount Merchant Code Timestamp 1 111 123456789 ¥10,000 AA 2017/11/05 10:10:01 2 222 777777777 ¥3,980 AA 2017/11/05 10:10:02 3 111 197654532 ¥5,130 BB 2017/11/05 10:10:08 2 61 43 2 61 43 5 5 5 TxId POS Card Number Tx Amount Merchant Code Timestamp 3 111 197654532 ¥5,130 BB 2017/11/05 10:10:08 4 333 666666666 ¥323,456 AA 2017/11/05 10:10:15 TxId POS Card Number Tx Amount Merchant Code Timestamp 4 333 666666666 ¥323,456 AA 2017/11/05 10:10:15 5 111 888888888 ¥1,980 BB 2017/11/05 10:10:13 6 111 123456789 ¥23,456 AA 2017/11/05 10:10:14 29
30.
ストリームデータ処理のコード例 // ストリーム処理用のSnappyStreamingContextを作成 val snappy
= new SnappyStreamingContext(sc, 10) // Continuous Queryを登録 val creditCardTxStream : SchemaDStream = snappy.registerCQ(s""" SELECT TxId, POS, CardNumber, TxAmount, MerchantCode, Timestamp FROM CreditCardStream WINDOW (DURATION 10 SECONDS, SLIDE 2 SECONDS) WEHERE MerchantCode='AA' """) // ストリームデータを処理 creditCardTxStream.foreachDataFrame(df => { … df.write.insertInto("CreditCardTxHistory") … }) 30
31.
②トランザクション処理 APP SnappyData メッセージング ミドルウェア インメモリーDB トランザクション 処理 SQL • DataFrameに対して追加、変更、削除はインメモリーDBへ反映される • RDBと同等の機能を実現している Spark単体利用 との相違点 31
32.
データの追加、更新、削除が可能 • 新しいデータセットを作成する際に全データを再作成する必要がない ccBlackListStream.foreachRDD(rdd =>
{ val streamDS = rdd.toDS() // CreditCardBlacklistより削除 streamDS.where("ACTION = 'DELETE'").write.deleteFrom("CreditCardBlacklist") // CreditCardBlacklistへ追加・更新 streamDS.where("ACTION = 'INSERT'").write.putInto("CreditCardBlacklist") }) creditCardTxStream.foreachRDD(rdd => { val streamDS = rdd.toDS() // blacklist tableのDataFrame作成 val ccBlackList = snappy.table("CreditCardBlacklist") // JOINしたものをリジェクトトランザクションテーブルへ登録 val blackListedTxns = streamDS.join(ccBlackList, $"CardNumber" === $"CardNumber", "leftsemi") val failedTx = blackListedTxns.select("TxId", "POS", "CardNumber", "MerchantCode", "Timestamp") failedTx.write.insertInto("RejectedCardTx") }) SnappySessionを使用し 通常のSQLで追加、更新、 削除することも可能 32
33.
データの特性によってテーブル形式を使い分けることも可能 • マスターデータ・トランザクションデータではローテーブル、分析データではカラムテーブルを使用 頻繁に追加、更新を行うデータ 特定条件で検索するデータ 特定のカラムで集計やグループ化を行うデータ ローテーブル(マスターデータ/トランザクションデータ向き) カラムテーブル(集計・分析データ向き) TxId
POS Card Number Tx Amount Merchant Code … 1 111 123456789 ¥10,000 AA 2 222 777777777 ¥3,980 AA 3 111 197654532 ¥5,130 BB 4 333 666666666 ¥323,456 AA … 6 111 123456789 ¥23,456 AA Card Number Card Type Expiration Date … 999999999 1 2020/12 876543210 1 2019/04 213757211 2 2020/02 555444777 1 2018/08 … 987654321 2 2022/09 33
34.
CREATE TABLE CreditCardBlacklist (CardNumber
CHAR(16) NOT NULL PRIMARY KEY, CardType CHAR(1) NOT NULL, ExpirationDate DATE NOT NULL, … CHAR(3) , … CHAR(1) , … DATE , … DECIMAL(9,2)) USING ROW OPTIONS (PARTITION_BY 'CardNumber', COLOCATE_WITH 'CardAccount', REDUNDANCY '1', EVICTION_BY 'LRUMEMSIZE 10240', OVERFLOW 'true', DISKSTORE 'LOCALSTORE', PERSISTENCE 'ASYNC', EXPIRE '86400'); CREATE TABLE CreditCardTxHistory (TxId BIGINT , POS CHAR(2) , CardNumber CHAR(16) , TxAmount DECIMAL(15,2) , MerchantCode CHAR(2) , … DATE , … DECIMAL(9,2)) USING COLUMN OPTIONS (PARTITION_BY 'TxID', COLOCATE_WITH 'CardAccount', REDUNDANCY '1', EVICTION_BY 'LRUMEMSIZE 10240', OVERFLOW 'true', DISKSTORE 'LOCALSTORE', PERSISTENCE 'ASYNC'); RDBと大差ないDDLでテーブルを作成できる • 分散インメモリーデータベースであるため、データ分散や永続化の設定が追加で必要 データベースエンジン データベースエンジン データ分散設定 データ分散設定 永続化設定 永続化設定 Expireオプション ローテーブル カラムテーブル 34
35.
レプリケーション/パーティションを使い分ける • ブロードキャスト変数の代わりにレプリケーション、RDDの代わりにパーティションの使用が可能 レプリケーション(マスターデータ向き) パーティション(トランザクションデータ向き) ノードA ノードC ノードB ノードD データ
A データ B データ C データ D データ A データ B データ C データ D データ A データ B データ C データ D データ A データ B データ C データ D ノードA ノードC ノードB ノードD データ A データ D データ B データ C データ A データ B データ C データ D 複数ノードで データを分散保持 全ノードで 同一データを保持 主 主 主 主 35
36.
トランザクション処理もRDBと同様に使用可能 • ローテーブルでは、RDBと同等レベルの分散トランザクションが利用可能 • ただし、従来のRDBとは挙動が異なる部分もある READ
UNCOMMITTED × READ COMMITTED ○ REPEATABLE READ ○ SERIALIZABLE × サポートされるトランザクショ ン分離レベル SELECT FOR UPDATE トランザクション中にデータが更新された場合、COMMIT時にコンフリクト例外が発生 する COMMIT/ROLLBACK トランザクション中にクラスタメンバーがダウンした場合、COMMITが失敗したという例 外が発生する LOCK TABLE サポートされない Cascade DELETE サポートされない 36
37.
P2P型アーキテクチャー • マスターレスのため、データの参照だけでなく、更新処理もスケールアウトが可能 スレーブ マスター クライアント スレーブ スレーブ
ノード ノード クライアント ノード ノード マスター・スレーブ型 P2P型 37
38.
③アナリティクス処理 APP SnappyData メッセージング ミドルウェア インメモリーDB アナリティクス処理 SQL • SparkSQLの内部に手を加えて高速化している • 近似クエリ、TOP
Kテーブルが使える Spark単体利用 との相違点 38
39.
SnappyDataはSparkSQLより10~20倍速い • カラムテーブルならSparkSQLの約10~20倍高速に分析可能 39
40.
よりリアルタイムな分析を可能にする独自機能を実装 • リアルタイムアナリティクスでは、1回のクエリーに何十秒も待っていられない • 精度を抑える代わりに、高速なクエリ処理を可能にする「Synopsis
Data Engine」を実装 近似クエリ TOP Kテーブル サンプリングしたデータに対してクエリを実行する Min/Maxなど外れ値の検出に必要なデータを取得する 40
41.
サンプリング技法を活用することでクエリー時間をさらに短縮 • データの平均や割合を出すのであれば、サンプリングが有効 • サンプリングしたデータを分析することで、通常のクエリーに比べて100分の1~10分の1にクエ リー時間を短縮可能 ¥182,531 ¥132,712 ¥79,521 ¥12,903 ¥0 ¥20,000 ¥40,000 ¥60,000 ¥80,000 ¥100,000 ¥120,000 ¥140,000 ¥160,000 ¥180,000 ¥200,000 111
222 333 444 POS 平均利用額 ¥182,294 ¥132,801 ¥79,582 ¥12,912 ¥0 ¥20,000 ¥40,000 ¥60,000 ¥80,000 ¥100,000 ¥120,000 ¥140,000 ¥160,000 ¥180,000 ¥200,000 111 222 333 444 POS 平均利用額(サンプリング) サンプリング 処理時間 10秒 処理時間 1.2秒 41
42.
サンプリングの精度とクエリーのパフォーマンスを比較すると・・・ 項目 標準SQL ケース1
ケース2 ケース3 ケース4 ケース5 誤差 - 0.20 0.05 0.20 0.30 0.20 信頼度 - 0.70 0.95 0.80 0.80 0.90 クエリー処理時間 10.0秒 1.2秒 1.4秒 1.3秒 1.2秒 1.1秒 0 2 4 6 8 10 12 クエリー処理時間 標準SQL ケース1 誤差:0.2 信頼度:0.7 ケース2 誤差:0.05 信頼度:0.95 ケース3 誤差:0.2 信頼度:0.8 ケース4 誤差:0.3 信頼度:0.8 ケース5 誤差:0.2 信頼度:0.9 42
43.
特定カラムのデータ分布を踏まえてサンプリングできる • 一般的なDDLにサンプリングのための情報を指定する CREATE SAMPLE
TABLE CreditCardTxHistorySample ON CreditCardTxHistory OPTIONS( qcs 'POS, Year, Month', fraction '0.03') AS (SELECT * FROM CreditCardTxHistory) サンプルテーブル 43 ベーステーブル CreditCardTxHistory サンプルテーブル CreditCardTxHistorySample サンプル テーブル作成 Tx Id POS Year Mont h Tx Amount … 1 111 2017 11 ¥10,000 … 2 222 2017 11 ¥3,980 … 3 111 2017 11 ¥5,130 … 4 222 2017 11 ¥323,456 … 5 111 2017 11 ¥1,980 … 6 111 2017 11 ¥23,456 … Tx Id POS Year Mon th Tx Amount … 1 111 2017 11 ¥10,000 … 2 222 2017 11 ¥3,980 … 5 111 2017 11 ¥1,980 … 指定したカラムのデータ分布を 踏まえてサンプルリングされる
44.
ランダムなデータのサンプリングは直接クエリーできる • SQLにサンプリングのための情報を指定する SELECT POS, AVG(TxAmount) FROM CreditCardTxHistory GROUP BY POS ORDER
BY POS WITH ERROR 0.10 CONFIDENCE 0.95 44 ベーステーブル CreditCardTxHistory Tx Id POS Year Mont h Tx Amount … 1 111 2017 11 ¥10,000 … 2 222 2017 11 ¥3,980 … 3 111 2017 11 ¥5,130 … 4 222 2017 11 ¥323,456 … 5 111 2017 11 ¥1,980 … 6 111 2017 11 ¥23,456 … ランダムに サンプリングされる SQL結果SQL Approximate Query
45.
TOP Kテーブル • Max/Minのデータ検索ではTOPKテーブルを使用する •
外れ値検出等で有効活用できる CREATE TOPK TABLE MostUsedCreditCard on CreditCardTxStream OPTIONS ( key 'CardNumber', timeInterval '60000ms’, size '50’ frequencyCol 'TxAmount', timeSeriesColumn 'Timestamp‘ ) 1分間隔で利用金額の多い上位50件を収集する場合 CardNumber TxAmount … 666666666 ¥1,2345,678 … 197654532 ¥10,000,000 … 197654532 ¥5,048,600 … ・・・ ・・・ … TOP Kテーブル 45
46.
BIツールからのSnappyDataアクセス • TableauやApache Zeppelinからも接続が可能 46
47.
アプリケーションからのSnappyDataアクセス • SnappyDataへ接続する場合は、一般的なJDBC/ODBC/ADO.NETプログラミングスタイルで アクセスすることが可能 // SnappyData接続 val
conn = DriverManager.getConnection("jdbc:snappydata://localhost:1527/APP") // データ登録(Insert) val psInsert = conn. prepareStatement("INSERT INTO CreditCardBlacklist VALUES(?, ?, ?, ?, …)") psInsert.setString(1, "1000200030004000") psInsert.setBigDecimal(2, java.math.BigDecimal.valueOf(100.2)) … psInsert.execute() // データ取得(Select) val psSelect = conn.prepareStatement(“SELECT * FROM CreditCardBlacklist WHERE CardNumber=?") psSelect.setString(1, "1000200030004000") ResultSet rs = psSelect.query() // 切断 conn.close() 47
48.
Springからも繋がります! @Autowired @Qualifier("snappyJdbc") private JdbcTemplate snappyData; @Component public
class SnappyDataConfiguration { @Bean(name="snappyData") public DataSource createDataSource() { return DataSourceBuilder.create() .driverClassName("io.snappydata.jdbc.ClientDriver") .url("jdbc:snappydata://localhost:1527/APP") .username("XXXXX").password("ZZZZZ") .build(); } @Bean(name="snappyJdbc") public JdbcTemplate createJdbcTemplate( @Qualifier("snappyData") DataSource dataSource) { return new JdbcTemplate(dataSource); } … } 48
49.
Snappy Dataサマリー Part 4
50.
SnappyDataサマリー Spark100%コンパチブル SparkとインメモリーDBが統合されシンプル テーブルとSQLを中心として統一された処理 高速化のための工夫がたくさん 50
51.
お問合せ先 mailto: info@ulsystems.co.jp http://www.ulsystems.co.jp 51
Download now