The truth about SQL and Data Warehousing on Hadoop

1. How to build a successful Data Warehouse on Hadoop
Simon Harris, Senior Performance Architect, Big Data. IBM.
貝嶋創, Technical Sales, BigData, IBM

2. 2
 どのHadoop上のSQLソリューションを使うべきか ???
• ベンダーロックインの有無
 既存DB、DWHからのポーティング
• データの移動
• ワークロードの移動 (SQL)
 Hadoop上のWareHouseを実運用環境へ
• パフォーマンス、拡張性、ワークロードマネージャー
• セルフチューニング
• エンタープライズレベルセキュリティ
 DWHからHadoopへのコネクティビティ
• Federation
• Spark exploitation
 さらなる価値の創造
Agenda

3. 3
お客様からのコメント …
Hiveで十分間に合ってます！！
もしくは
Hiveでも良いのですが、BI・レポーティングが簡単にできるものはないで
すか？
Hive/MapReduceへの同時接続数が増えワークロードが増加すると問題が
置きます.この状況でクエリの遅延がないようにできませんか？
増え続けるワークロードに対して現在持っているHadoopを増強し続ける
つもりです．ただし、無制限な増強を回避する方法はないでしょうか？
変えたいことは色々ありますが，どこから始めればよいでしょうか？

4. 4
Hadoop上のSQLエンジンの多数の選択肢 – 何を選択するか
??
 SQLエンジンは多数発表されており、信じられないペースで成熟してい
ます!
 SQL on Hadoop はローコストで，簡単にスケールアウトできます.
 ただし、すべてのエンジンは長所・短所があります，
何を選択すればよいでしょうか？
IBM Big SQL
SQL

5. 5
Hive Execution Engine
(open source)
そもそもHiveとは…
3つの構成要素
Hive
(Open Source)
Hive Storage Model (open source)
Hive
metastore
(open
source)
MapReduce
CSV
Tab
Delim
.
Parquet ORC Others
1
23

6. 6
Hive Execution Engine
(open source)
実行エンジンは変換が可能
Hive Metastoreとファイル（フォーマット）を活用
Big SQL
(IBM)
Hive
(Open Source)
Hive Storage Model (open source)
Hive
metastore
(open
source)
C/C++
MPP
Engine
Spark SQL
(Open Source)
Impala
(Open Source)
CSV
Tab
Delim
.
Parquet ORC Others
• Big SQL は他のオープンソースエンジンと同様の構成
• ロックインしません. データはHadoopが管理します. いつでもHive環境に戻
ることが可能.

7. 7
ODPi Interoperable Solutions
ODPi is a nonprofit organization committed to simplification & standardization of the
big data ecosystem.
As a shared industry effort , ODPi is focused on promoting and advancing the state of Apache Hadoop® and big data
technologies for the enterprise. See https://www.odpi.org/ for more details.
7
 Open Data Platform initiative
(ODPi) は
ディストリビューションの標準化と，
Hadoop エコシステムの発展を促進
 Big SQL v4.2 はODPi での運用が可
能であり，
IBM と HortonWorks
のHadoop ディストリビューション
で動作.
ODPi: ディストリビューション間での相互運用性
ODPi Runtime Compliant Platforms
ODPi Runtime Specification
HDFS YARN MapReduce
Hive HCFS
Big SQL
(IBM)

8. 8
 どのHadoop上のSQLソリューションを使うべきか ???
• ベンダーロックインの有無
 既存DB、DWHからのポーティング
• データの移動
• ワークロードの移動 (SQL)
 Hadoop上のWareHouseを実運用環境へ
• パフォーマンス、拡張性、ワークロードマネージャー
• セルフチューニング
• エンタープライズレベルセキュリティ
 DWHからHadoopへのコネクティビティ
• Federation
• Spark exploitation
 さらなる価値の創造
Agenda

9. 9
既存のDWHからHadoop WareHouseへどのように移動するの
か？
 データ移動はシンプル – 問題は時間だけ!
 データ移動に関するツールやテクニックはすでに広く知られている
$$$ $
EXPORT -> COPY TO HDFS
Sqoop
Federation: INSERT..SELECT..
 Storage format ?
 Partitioning Columns ?

10. 10
問題はSQLアプリケーションの移動！
 DWHは複雑なSQLを実行，移植ができるのか？
 RDBMSのベンダーはそれぞれ独自の構文や関数を持っている – ANSI
SQL準拠に加えて
 SQL over Hadoop ベンダーによるSQLスタンダード対応は途上
 急速に改善されては来ていますが…
Query re-writes ?
Porting is made simpler if the SQL
over Hadoop solution is ANSI
Compliant, and can understand the
SQL dialect of the original
Warehouse.

11. 11
Big SQL は様々なベンダーのSQLを実行可能.
Porting effort to Hadoop will be reduced.
Big SQL は ANSI SQL
対応だけではなく、
DB2,
Oracle,
Netezza
のSQLを実行可能です
SQL コンパチビリティは
100%ではありませんが, Big
SQL は複数のベンダーで実装さ
れているSQLのポーティングを
容易にします
Big SQL
Common Query
Compiler/Optimizer
Read & Scan
Optimized
IBM IOP
Hadoop
Hortonworks
HDP Hadoop
ANSI SQL 2003/2011+
Hive
Storage
Hive
metastore

12. 12
SQL on Hadoop ソリューションのチャレンジ
ポーティングにも以下の考慮点がある:
 スケジュール
 チューニング（SQLリライト）
 アーキテクチャの違い（データ構造）
Hadoopのアーキテクチャは従来のデータウェアハウスの機
能との間にはチャレンジあり
 すべてはトレードオフ!
 HadoopによりDWHで直面してきた問題の解決も可能
 リレーショナルデータだけではないデータ処理

13. 13
 どのHadoop上のSQLソリューションを使うべきか ???
• ベンダーロックインの有無
 既存DB、DWHからのポーティング
• データの移動
• ワークロードの移動 (SQL)
 Hadoop上のWareHouseを実運用環境へ
• パフォーマンス、拡張性、ワークロードマネージャー
• セルフチューニング
• エンタープライズレベルセキュリティ
 DWHからHadoopへのコネクティビティ
• Federation
• Spark exploitation
 さらなる価値の創造
Agenda

14. 14
パフォーマンスとスケーラビリティ
Why do they matter so much in SQL over Hadoop !
 HadoopのSQLソリューションは既存のRDBMSより遅い
 2x – 10x slower
 重要な機能の欠如 – キャッシュ/インデックス/データ配置 etc….
 未成熟 - オプティマイザやワークロードマネージャ
 これらはRDBMsが長年取り組んできた分野
 RDBMsの特徴的な機能:
 カラムナストレージ
 インメモリDB
 データ圧縮
 このギャップを埋めるには時間が必要

15. 15
北米のテレコム会社のProof of Concept実施結果
以下のチャートはお客様によりBig SQLを評価した際の結果です.
Teradataのデータ増加に対して対応が必要な状況:
Option 1: Teradataの容量をアップして対応 ($$$)
Option 2: Hadoopへのオフロードを実施
7つの複雑なSQLを選択して評価を実施

16. 16
12.0
154.0
345.0
43.0
140.0
3.0
59.0
29.7
154.9
39.2
7.9
26.7
7.1
21.8
0
60
120
180
240
300
360
420
1 2 3 4 5 6 7
Time(sec)
Query Number
Teradata vs. Big SQL Baseline Query Comparison
Elapsed time (secs). Smaller is better
Teradata
Big SQL
Big SQL Query Performance:
at Major North American Telecom

17. 17
Big SQL Concurrency Testing
at Major North American Telecom
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7
Seconds
Query
User 1
User 2
User 3
User 4
User 5
Query User 1 User 2 User 3 User 4 User 5
1 62.9 39.3 36.2 49.8 48.3
2 379.9 395.4 253.6 372 378.4
3 776.2 768 587.4 773.2 778.3
4 10.8 12 10.7 26.8 10
5 30.7 35.8 29.8 47.5 57.2
6 8.3 8.9 8.8 10 9.5
7 30.1 35.7 27.6 39.1 40.7
Consistent response
times as number of
users grows

18. 18
0
50
100
150
200
250
0 20 40 60 80 100 120
Throughput(Queries/Hour)
Number of Users
Number of Users vs. Throughput
0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
0 50 100 150
TestTime(sec)
Number of Users
Number of Users vs. Test
Time
o Workload throughput peaks at about 10
concurrent users and is consistent for even 100
concurrent users
o Big SQL default workload management (WLM)
ensures memory is not used up, so throughput
does not decrease
o Test time gets proportionally longer after 10
users, as expected
o The test time does not get exponentially
longer with 100 users
Big SQL Workload Throughput for Concurrent Users
at Major North American Telecom

19. 19
チューニング !
Readers
Sorting
Filesystem
Database
Hadoopのチューニングは熟練者であっても大変
Hadoop上のジョブを考慮した数百にのぼるパラメータの最適
値を決定
 さらに個々のクエリについてのチューニングも必要
Big SQLはSelf Tuning Memory Manager (STMM) による自
動チューニング
 メモリ割り当てをモニターして自動でメモリ割り当て
 BigSQL Consumerへのメモリの自動再割り当て

20. 20
Role Based Access
Control
Row Level Security
Colum Level
Security
Separation of Duties
/ Audit
 Apache Rangerは中央集約型のア
クセスコントロールやログ取得を行
うセキュリティフレームワーク.
 Big SQLは現状Rangerとは連携し
ていない. ただし, Hiveではでき
ないセキュリティ機能を提供
 Big SQLの提供するセキュリティ
 GRANT / REVOKE
 列・行レベルマスク
 SQLによる設定
セキュリティ
Security models vary across the vendors
BRANCH
_A
BRANCH
_B
FINANCE
See it in action on YouTube:
https://www.youtube.com/watch?v=N2F
N5h25-_s

21. 21
 どのHadoop上のSQLソリューションを使うべきか ???
• ベンダーロックインの有無
 既存DB、DWHからのポーティング
• データの移動
• ワークロードの移動 (SQL)
 Hadoop上のWareHouseを実運用環境へ
• パフォーマンス、拡張性、ワークロードマネージャー
• セルフチューニング
• エンタープライズレベルセキュリティ
 DWHからHadoopへのコネクティビティ
• Federation
• Spark exploitation
 さらなる価値の創造
Agenda

22. 22
データベースフェデレーション
 データウェアハウスは1つのDBに限らない
 様々なデータソースに分散しているデータにアクセス
• 他システムのデータへのアクセスし
• ソースデータを持っているシステムからデータを取得
Big SQL
Common Query
Compiler/Optimizer
Read & Scan
Optimized
Federation
Oracle
SQL
Server
Teradata
DB2
IBM IOP
Hadoop
Hortonworks
HDP Hadoop
ANSI SQL 2003/2011+
Hive
Storage
Hive
metastore

23. 23
BigSQLとSparkのインテグレーション
Integration is Technology Preview (Big SQL v4.2)
Big SQL
Common Query
Compiler/Optimizer
Spark
Read & Scan
Optimized
Read and
In-Memory Analytics
Optimized
Federation
Oracle
SQL
Server
Teradata
DB2
IBM IOP
Hadoop
Hortonworks
HDP Hadoop
ANSI SQL 2003/2011+
Hive
Storage
Hive
metastore
 Sparkはデータアナリストやデータサイエンティストが利用するインメモリアー
キテクチャ
 SparkとHadoopのDWHとの相互利用は重要

24. 24 HDFS
Big SQL Head Node
Spark Exec.
Big SQL
Worker
Spark Exec.
Big SQL
Worker
Spark Exec.
Big SQL
Worker
Spark Exec.
Big SQL
Worker
= Fast data transfer over
shared memory
Big SQL は Spark インメモリ実行エンジン:
Integration is Technology Preview (Big SQL v4.2)
 Big SQLのHead NodeがSparkを起動
 Spark executors が Big SQL workersと協調動作
 それぞれの実行プロセスが共有メモリを通じて協調動作

25. 25
 どのHadoop上のSQLソリューションを使うべきか ???
• ベンダーロックインの有無
 既存DB、DWHからのポーティング
• データの移動
• ワークロードの移動 (SQL)
 Hadoop上のWareHouseを実運用環境へ
• パフォーマンス、拡張性、ワークロードマネージャー
• セルフチューニング
• エンタープライズレベルセキュリティ
 DWHからHadoopへのコネクティビティ
• Federation
• Spark exploitation
 さらなる価値の創造
Agenda

26. 26
SQL
分析のための
アドホックな
データ整形
フェデレー
ション
キーバリュー
の高速なデー
タストア
少数ユーザー
によるアド
ホックなクエ
リ
ELT や単純で,
巨大なデータ
を処理するク
エリ
多数のユー
ザーが接続す
る環境での複
雑なSQL
オペレーショ
ナルデータス
トア
Big SQL
Hive Spark SQL
Big SQL
HBase
Big SQL
Phoenix
Spark SQL
Hive
Big SQL
HBase
Big SQL
Phoenix
SQL over Hadoop ユースケース

27. 27
 Operational Data Stores はAnalyticsの組織において重要
 Hadoop上でUpdateやDeleteを実行するのは難しい
 HBaseはHadoopのベースコンポーネントの一つであり、キ
ーバリュー型
 ODSとしての利用は可能だがSQLの実行はできない
 Apache Phoenix はSQLインターフェースを提供
 Non-ANSI SQL
 セキュリティモデルとユーザー認証
 HiveとＨＢａｓｅには別のConnectionが必要
 HiveとHBaseのテーブルのjoinは現在開発中．No ETA.
OLTP
Warehouse
ODS
Operational Data Store (ODS) on Hadoop

28. 28
Building an Operational Data Store on Hadoop with Big SQL
 Big SQLならHBaseでもANSI SQLを利用可能
 1接続でHiveとHBaseにアクセス
 1つのJDBC/ODBCドライバ
 統合されたセキュリティ機能
 Hive,HBase間のJoin
 BigSQLのテーブルを
ODSとして利用可能
Big SQL
Common Query
Compiler/Optimizer
Spark
Read & Scan
Optimized
Insert/Update/Delete
Lookup
Optimized
Read and
In-Memory Analytics
Optimized
Federation
Oracle
SQL
Server
Teradata
DB2
IBM IOP
Hadoop
Hortonworks
HDP Hadoop
Native
tables (row &
column)
ANSI SQL 2003/2011+
HBaseHive
Storage
Hive
metastore
Regular RDBMs tables.

29. 29
Building an OLTP system on Hadoop using Big SQL
 HBaseは小範囲のルックアップや更新処理には優れるため、OLTP的な利用
も可能
 OLTPワークロードにはBigSQL・ローカルテーブルの利用も可能
Big SQL
Common Query
Compiler/Optimizer
Spark
Read & Scan
Optimized
Insert/Update/Delete
Lookup
Optimized
Read and
In-Memory Analytics
Optimized
Federation
Oracle
SQL
Server
Teradata
DB2
IBM IOP
Hadoop
Hortonworks
HDP Hadoop
Native
tables (row &
column)
ANSI SQL 2003/2011+
HBaseHive
Storage
Hive
metastore
Regular RDBMs tables.

30. 30
サマリ: HadoopのData Warehouse
 ベンダーロックインは避ける
– Hive metastoreとストレージモデルを共用
 ワークロードの移動・移行はできるだけシンプルに
 RDBMSで利用していた機能に関しても考慮 （Grantなど）
 他のデータソースへの接続を考慮
 Sparkとの利用を考慮
SQL on Hadoop を積極的に使いましょう
– 単なるDWHよりも多くの処理が可能です

31. 31
Big SQL エコシステム
Big SQL
Common Query
Compiler/Optimizer
Spark
Read & Scan
Optimized
Insert/Update/Delete
Lookup
Optimized
Read and
In-Memory Analytics
Optimized
Federation
Oracle
SQL
Server
Teradata
DB2
IBM IOP
Hadoop
Hortonworks
HDP Hadoop
Native
tables (row &
column)
ANSI SQL 2003/2011+
HBaseHive
Storage
Hive
metastore
Regular RDBMs tables.