【勉強会】dbtech_showcase2016day3
2016-07-15 dbtech_showcase2016day3
これに行ってきた。
EXADATAからPureStorageへの移行
- ピュアストレージジャパン 岩本知博さん
- NTTぷらら 長谷部勇さん
[db tech showcase Tokyo 2016] D32: SPARCサーバ + Pure Storage DB仮想化のすべらない話 〜 Exadata リプレース話付き 〜 by ピュア・ストレージ・ジャパン株式会社 岩本 知博 & 株式会社NTTぷらら 長谷部 勇 from Insight Technology, Inc.
www.slideshare.net
旧基盤
- NetAppとSPARCでDataGuard構成
- SharedNothing型にしたかった
良かった点
- NetAppは瞬時バックアップ、瞬時クローンが簡単
- 待機系のクローンをとって検証環境として使う
課題
- DataGuardはF/O時にクライアント接続が追従できない
- I/Oボトルネック（NFSの限界）でCPU過負荷、バッチが終わらない
- システム更改にコスト削減が課題になった
- DataGuard→RAC
- NASStrage(NAS)→SANStrage（FC）
PureStorage
- IOPSだけじゃない、スループットもいい
- 固定長ブロックじゃない、512byteから32Kで可変
- ディスク効率がいい
- あえてAct-Actでは使わせない、シンプル構成
- 入れ替えが楽、ホットスワップ的に使える
新基盤
- ExadataX2(quarter rack）
demo
- Swingbench
BigData基盤のカテゴリ分類
- リクルートテクノロジーズ 渡部鐵太郎さん
www.slideshare.net
- いっぱいあるけど、こう分類できるよ
- 代表的なプロダクト、こんなのあるよ
- リクルートではこう使い分けしてるよ
という話。
分類は2軸4象限に分類できる
- 重視する性能
- レスポンス重視（主にオンライン）
- スループット重視（主に分析やバッチ）
- ここをわけて考えないと話が通らない
- 性能拡張方式
- スケールアップして集約するのか
- スケールアウトして分散するのか
ざっくりこう。
| オンライン | 分析 | |
|---|---|---|
| 集約 | KVS/DocumentDB | Hadoop |
| 分散 | RDB(OLTP) | RDB(DWH) |
集約・分析型＝RDB（DWH)
プロダクト
- オンプレ:EXADATA
- サービス:Redshift
特徴
- データをパーティショニング、複数ディスクから同時に読む
- DBnodeとStragenodeが４GBbpsSAN
- SSDでキャッシュしてDiskIO削減
- 列指向で圧縮してデータ格納
- 行指向はランダムアクセスは早いけど集計はディスクIO多くて遅い
- 列指向はランダムは遅いけど集計が早い
- 数秒から数分レスポンス、直近１３カ月データ、SQLベース
- 自由検索、レポート、BI
- 更新（Insert/Update/Delete）が遅い、できるけど
Hadoop
- 分散したファイルに、さまざまな分散処理をできるソフトウェア群
- 分散処理エンジンと、分散ファイルシステム
- オンプレ：hadoop、cloudera、Hortonworks HDFSベース
- オンプレ：MapR MapR-FSベース
- サービス：EMR＋S3、CloudDataproc+GCS、TreasureData+？？？
- レスポンスは数時間、ペタバイトクラス、SQLに限らずプログラムレベル・機械学習
- HDFSは基本ローカルのデータに対して処理、ノード増やすとデータコピーが必要
- クラウドなら、EMRならデータはS3なので、ノード増やせばすぐ使える
KVS
- 分散してシンプルなオペレーションができる
- オンプレ：redis、riak KeyValue ワイドカラム
- クラウド：ElastiCache KeyValue
- 整合性を緩めることでスケールアウト可能にする
- データ間の参照関係を定義させないことで分散しやすいデータモデル
- 一つのデータでクエリが完結する
- 大規模Webのバックエンド、セッション格納、事前計算データのキャッシュ
- メッセージングシステム
- トランザクションや集計はできない
ドキュメントDB
- オンプレ：mongoDB、couchbase
- KVSよりクエリが豊富
- データモデルにJSONを使う
- 集計“も”できる、本職ではない
- 分散処理を活かしたユースケース
- 大規模Webのバックエンド
- オンラインゲーム
- JSON使いたいだけのユースケース
- ドキュメントDBの集計機能はおまけ、本気で分析するなら向かない
- ACIDトランザクションを提供する、といったら分散処理を犠牲にしている可能性がある
- 非構造向きではない、半構造向き
その他
Spark
マイクロバッチ
- ストリームデータに対して、短い時間で集計をする
- kafka＋Spark、KinesisStream＋KinesisAnalytics
- PUB（出版）、分散キュー、SUB（購読）
- データを永続化しないからデータベースではない
- 初回訪問ユーザの属性
インメモリデータグリッド
- GemFire、ApacheGEODE
- アプリのローカルに置かれるキャッシュ
- KVSライク
- メモリ上処理が前提
- ミリ秒単位の応答
Elasticsearch
グラフDB
- Neo4j
- グラフ演算に特化したDB
- JOINの入れ子のような処理が超早い
ブロックチェーン
- 分散KVSの応用
分散OLTP
- １０万TPS
- HWをいっぱい乗せる
OLAP options on Hadoop
- HDFS+YARNが狭義のHadoop
- ApacheKylin、ApacheDruid
- Hive0.x（MapReduce）
- Hive1.2（Tez、Vectorize、ORC、CBO）
- Hive2.0（LLAP）
- MPP（Impara、Drill、SparkSQL、HAWQ、RedShift）
- ACID/MERGE、Hive(WIP)
- OLAP/Cube、Kylin、Druid
Apache Kylin
- eBay上海で開発されたOLAPエンジン
- HiveでのOLAPの速度に満足できなかった
- 数秒でのレスポンスが欲しかった
- Architecture
- RESTAPI/QueryEngine/Router/Hive or HBase
- Hiveの結果はCubeBuilder通してCubeがHBaseに入る
- Cube：集計をあらかじめ定義してマテリアライズしたもの
- KylinのIF
- ANSI SQL準拠、HBase直アクセス禁止、MDXは未対応
Apache Druid
- MetaMarketで開発されたOLAPエンジン
- 列指向分散データストア
- sub−secondでのクエリレスポンス
- 自在なスライシング、ダイシング
- ペタバイトデータ
- 広告配信サービスのリアルタイムダッシュボード
- Architecture
- BatchData→Ingest→HistricalNode←BrokerNode
- StreamData→Kafka→RealtimeNode←BrokerNode
- BrokerNodeがどちらからもデータ取れる
- DruidのIF
- ThetaSkethes KMV：Open source by Yahoo!
- UUをリアルタイムに計算するライブラリ
- Yahoo
- EventData→HourETL/DailyRollup/Aggregate→HDFS→Druid→UI
- Solution Architecture for SQL analysis
- DataSource→Kafka→HDFS→Hive→OLAP（Kylin/Druid）
http://www.slideshare.net/uprush/hivesubsecondsqlonhadooppublic
ビッグデータ関連OSS動向調査とニーズ分析
- OSS推進フォーラム副理事長 吉田行男
- コミッタ数：Spark、Mesos、Drill
- コミット数：Elasticsearch、Spark、Ceph、Cephは分散ストレージ技術
- ML流量：Hive、Storm、Kafka、ストリーミング系
- 脆弱性：JasperReportsは11年で10件
- BigDataはまだまだ普及していない
- 目的がはっきりしないから投資されない
- とりあえず溜めておこう（＝DataLake）は現実的に波及していない
- IoT、AIにおける利用ケースが具体的になったり、キラーアプリが必要
RDB比較
http://www.slideshare.net/ryotawatabe/2016715-jpoug-rdbms-backup-architecture
Delphix
- Delphix 三村泰弘さん・槌屋砂幾さん
背景
- Agile/DevOpsの流れにデータマネジメントは追いついていない
- 課題
- データコピーに時間がかかる
- 数TBのデータを数分で、任意の時間で、DBAなしで
- データの保管場所
- データの重複排除、スナップショット技術により、１複製が1/10
- セキュリティの問題
- 個別のマスクツールは不要
- Delphixエンジン
- 本番環境から非本番環境へデータコピー
- データのバージョン管理ができる
- ブランチング
- 任意の時刻にプロビジョニング
- データが汚れたら一回消して再取り込みも瞬時に可能
demo
- 1:nでのコピーが可能
初回フルバックアップ、同期
プロビジョン
- dSource内はデータをブロック管理
- VDB（VirtualDB）を作成、ブロックをマッピング（実コピーはしない）
- VDBを開発環境ホストにNFSマウント
- VDBが独自に更新したものは、VDB内でブロック管理
- VDB内でもタイムスタンプでリビジョン管理可能
- VDB作成時にフックも書ける
- VDBからブランチ作成可能
- VDBの管理は個別に可能、DBA不要で開発者が操作できる
マスキング
- VDBの定義時にルールを指定する
- 初回作成時、リフレッシュ時に適用される
- Rulesetでテーブルとカラムを指定してマスクを指定できる
- アルゴリズムは事前に定義
- Lookup：指定のカラムとダミーデータのリストをランダムに置換
www.slideshare.net
