The truth about SQL and Data Warehousing on Hadoop
Download as PPTX, PDF2 likes1,672 views
The truth about SQL and Data Warehousing on Hadoop
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
- 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.