![自己紹介
山河 征紀
ウルシステムズ株式会社
マネージングコンサルタント
{
“分野”：”金融系”
“得技”：[“分散処理”,
“インメモリー処理”]
“趣味”：”マラソン”
}](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (10)
Similar to 20171118 jjug snappydata
Similar to 20171118 jjug snappydata (20)
More from Masaki Yamakawa
More from Masaki Yamakawa (9)
Recently uploaded
Recently uploaded (11)
20171118 jjug snappydata
- 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増大 分析までに時 間がかかる 非効率 データ一貫性 保持に苦労
- 11. Apache Spark＋分散インメモリーDB＋独自機能 • Apache Sparkとインメモリーデータベースを統合し、独自機能を付加している • ベースとなる製品はインメモリー処理が得意なので相性が良い 11 分散インメモリー データベース 独自付加機能 カラム型データベース 予測分析処理 ロー型データベース トランザクション 分散処理 フレームワーク バッチ処理 分析処理 ストリーム処理
- 12. SnappyData主要コンポーネント • Sparkとインメモリーデータベースの機能の良いところをシームレスに統合 12 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
- 15. Spark 特徴①：インメモリーデータベースにデータを保持している • 処理対象のデータはすでにメモリー上に保持している • ディスクへの読み書きが発生しない分、通常のSparkよりも処理時間が短い 15 Sparkプログラム Sparkプログラム メモリー メモリー Spark＋HDFSの場合 SnappyDataの場合 ディスク Spark インメモリーDBHDFS
- 16. 特徴①：データアクセスのコード例 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＋HDFSの場合 SnappyDataの場合
- 18. 特徴③：SparkとインメモリーDBのクラスターを統合できる • Spark処理を行うクラスターとインメモリーDBのクラスターを1つのJVMに統合できる • データの移動・コピーなしにインメモリーでデータ処理ができるため速い 18 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
- 19. 特徴③：もう一つのクラスターモード（参考） • SparkクラスターとインメモリーDBクラスターを別にして個別にスケールアウトすることも可能 19 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 クラスター
- 25. SnappyDataはSQLを使ってストリームデータ処理を書く • ストリームデータをテーブル形式で保存するので、SQLを書くだけで処理を実装できる 25 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 CreditCardTx WINDOW (DURATION 10 SECONDS, SLIDE 10 SECONDS) WHERE MerchantCode=‘AA'; 処理内容（Continuous Query）
- 26. ストリームデータソース情報をテーブル定義で指定するだけ 26 ストリーミングデータソース ストレージレベル（Spark設定） CREATE STREAM TABLE CreditCardTx (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変換クラス ストリーミングデータソース毎の設定
- 27. StreamToRowsConverterを実装してテーブル形式に変換する 27 class KafkaToRowsConverter extends StreamToRowsConverter with Serializable { override def toRows(message: Any): Seq[Row] = { val ccTx: CreditCardTx = message.asInstanceOf[CreditCardTx] Seq(Row.fromSeq(Seq(ccTx.getTxId, ccTx.getPos, ccTx.getCardNumber, ccTx.getTxAmount, ccTx.getMerchantCode, ccTx.getTimestamp))) } } ストリームテーブル 1行分のデータ
- 28. SQLでストリームデータの処理を記述できる • 処理の記述に使用するContinuous Queryは通常のSQLとほぼ同じ • WINDOW関数で指定した間隔のデータを取得できる 28 SELECT * FROM CreditCardTx WINDOW (DURATION 15 MINUTES, SLIDE 10 SECONDS) WHERE MerchantCode=‘AA'; MerchantCodeが「AA」のデータを 10秒のスライドウィンドウで取得する DURATION 15分 SLIDE 10秒
- 29. ContinuousQueryではWINDOWに含まれるデータのみ取得される 29 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:20 3 111 197654532 ¥5,130 BB 2017/11/05 10:10:21 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:21 4 333 666666666 ¥323,456 AA 2017/11/05 10:11:05 TxId POS Card Number Tx Amount Merchant Code Timestamp 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
- 30. ストリームデータ処理のコード例 30 // ストリーム処理用のSnappyStreamingContextを作成 val snappy = new SnappyStreamingContext(sc, 10) // Continuous Queryを登録 val creditCardTxStream : SchemaDStream = snappy.registerCQ(s""" SELECT TxId, POS, CardNumber, TxAmount, MerchantCode, Timestamp FROM CreditCardTx WINDOW (DURATION 1 SECONDS, SLIDE 1 SECONDS) WEHERE MerchantCode='AA' """) // ストリームデータを処理 creditCardTxStream.foreachDataFrame(df => { … df.write.insertInto("CreditCardTxHistory") … })
- 32. データの追加、更新、削除が可能 • 新しいデータセットを作成する際に全データを再作成する必要がない 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で追加、更新、 削除することも可能
- 33. データの特性によってテーブル形式を使い分けることも可能 • マスターデータ・トランザクションデータではローテーブル、分析データではカラムテーブルを使用 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
- 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 'EMPNO', COLOCATE_WITH 'DEPT', 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 'EMPNO', COLOCATE_WITH 'DEPT', REDUNDANCY '1', EVICTION_BY 'LRUMEMSIZE 10240', OVERFLOW 'true', DISKSTORE 'LOCALSTORE', PERSISTENCE 'ASYNC'); RDBと大差ないDDLでテーブルを作成できる • 分散インメモリーデータベースであるため、データ分散や永続化の設定が追加で必要 34 データベースエンジン データベースエンジン データ分散設定 データ分散設定 永続化設定 永続化設定 Expireオプション ローテーブル カラムテーブル
- 35. レプリケーション/パーティションを使い分ける • ブロードキャスト変数の代わりにレプリケーション、RDDの代わりにパーティションの使用が可能 35 レプリケーション（マスターデータ向き） パーティション（トランザクションデータ向き） ノード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 複数ノードで データを分散保持 全ノードで 同一データを保持 主 主 主 主
- 36. トランザクション処理もRDBと同様に使用可能 • ローテーブルでは、RDBと同等レベルの分散トランザクションが利用可能 • ただし、従来のRDBとは挙動が異なる部分もある 36 READ UNCOMMITTED × READ COMMITTED ○ REPEATABLE READ ○ SERIALIZABLE × サポートされるトランザクショ ン分離レベル SELECT FOR UPDATE トランザクション中にデータが更新された場合、COMMIT時にコンフリクト例外が発生 する COMMIT/ROLLBACK トランザクション中にクラスタメンバーがダウンした場合、COMMITが失敗したという例 外が発生する LOCK TABLE サポートされない Cascade DELETE サポートされない
- 37. P2P型アーキテクチャー • マスターレスのため、データの参照だけでなく、更新処理もスケールアウトが可能 37 スレーブ マスター クライアント スレーブ スレーブ ノード ノード クライアント ノード ノード マスター・スレーブ型 P2P型
- 38. ③アナリティクス処理 38 APP SnappyData メッセージング ミドルウェア インメモリーDB アナリティクス処理 SQL • SparkSQLの内部に手を加えて高速化している • 近似クエリ、TOP Kテーブルが使える Spark単体利用 との相違点
- 40. よりリアルタイムな分析を可能にする独自機能を実装 • リアルタイムアナリティクスでは、1回のクエリーに何十秒も待っていられない • 精度を抑える代わりに、高速なクエリ処理を可能にする「Synopsis Data Engine」を実装 40 近似クエリ TOP Kテーブル サンプリングしたデータに対してクエリを実行する Min/Maxなど外れ値の検出に必要なデータを取得する
- 41. サンプリング技法を活用することでクエリー時間をさらに短縮 • データの平均や割合を出すのであれば、サンプリングが有効 • サンプリングしたデータを分析することで、通常のクエリーに比べて100分の1～10分の1にクエ リー時間を短縮可能 41 ¥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秒
- 42. サンプリングの精度とクエリーのパフォーマンスを比較すると･･･ 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
- 43. サンプルテーブルを作る方法と直接クエリーする方法がある • 一般的なDDL、SQLにサンプリングのための情報を指定する 43 CREATE SAMPLE TABLE CreditCardTxHistorySample ON CreditCardTxHistory OPTIONS( qcs 'POS, Year, Month', fraction '0.03') AS (SELECT * FROM CreditCardHistory) SELECT POS, AVG(TxAmount) FROM CreditCardTxHistory GROUP BY POS ORDER BY POS WITH ERROR 0.10 CONFIDENCE 0.95 サンプルテーブル Approximate Query
- 44. TOP Kテーブル • Max/Minのデータ検索ではTOPKテーブルを使用する • 外れ値検出等で有効活用できる 44 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テーブル
- 46. アプリケーションからのSnappyDataアクセス • SnappyDataへ接続する場合は、一般的なJDBC/ODBC/ADO.NETプログラミングスタイルで アクセスすることが可能 46 // SnappyData接続 val conn = DriverManager.getConnection("jdbc:snappydata://localhost:1527/") // データ登録（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()