データドリブン企業における、hadoop基盤とETL #hcj2016

10,428 views

Published on Feb 8, 2016

Hadoop Conference Japan 2016 で発表した資料です。
http://www.eventbrite.com/e/hadoop-spark-conference-japan-2016-tickets-20809016328

この資料は前半部分です。ドワンゴ志村様による後半部分はこちら: http://www.slideshare.net/smrmkt/hadoopetl-niconico

----
(アブストラクト)
ETL(Extract, Transform, Load) は、外部のソースからデータを抽出し、業務上必要な形に加工し、データ基盤にロードするための一連の技術です。Hadoopの登場により、スケーラブルかつ柔軟なスキーマ構造を持つデータレイヤーであるHDFSに代表される、ETLにおける多くの物理アーキテクチャに変化がもたらされました。しかし一方で、ETLそのものの論理的な必要性は変わっておらず、実際の現場では様々な課題が山積みとなっています。このセッションでは、Flume / Kafka / Sqoop / Hive / Pig / Spark などの HadoopエコシステムによるETLの変革を紹介するとともに、実システムにおけるETLの現実と様々な課題について紹介していきます。

データドリブン企業における、hadoop基盤とETL #hcj2016

2. 2© Cloudera, Inc. All rights reserved.⾃自⼰己紹介•  嶋内　翔(しまうち　しょう)•  テクニカルエバンジェリスト•  2011年年4⽉月にClouderaの最初の⽇日本⼈人社員として⼊入社•  お客様がCloudera製品を活⽤用できるように⼀一緒に議論論するのがメインの仕事•  email: sho@cloudera.com•  twitter: @shiumachi
3. 3© Cloudera, Inc. All rights reserved.エンタープライズセールス⼤大規模システムに関わる営業ができる⼈人歓迎セールスエンジニア技術の価値を伝えることに興味がある⼈人歓迎We are hiring!http://www.cloudera.co.jp/company/careers.htmlcareer-‐‑‒jp@cloudera.comまたは、Cloudera社員に直接話しかけよう！
5. 5© Cloudera, Inc. All rights reserved.•  Extract -‐‑‒ 単⼀一あるいは複数のデータソースからのデータの抽出•  Transform -‐‑‒ ビジネスニーズに応じてデータを変換•  Load -‐‑‒ 最終ターゲットにデータをロード•  データの前処理理•  クレンジング•  正規化•  特にHadoopで「バッチ処理理」と呼ばれている処理理の⼤大多数• ⽇日次集計バッチなどこれらは全てETLですETLとは？
6. 6© Cloudera, Inc. All rights reserved.データウェアハウスETLシステム•  抽出•  変換•  共通化プレゼンテーション層•  共通ディメンション•  ファクトテーブルBIアプリケーション•  業務レポート•  分析アプリケーション•  ダッシュボードデータソース•  RDBMS•  フラットファイル•  XML / JSON•  メッセージキュー•  プロプライエタリなデータフォーマットDWH バックルーム DWH フロントルーム
7. 7© Cloudera, Inc. All rights reserved.データウェアハウス + HadoopETLシステム•  抽出•  変換•  共通化プレゼンテーション層•  共通ディメンション•  ファクトテーブルBIアプリケーション•  業務レポート•  分析アプリケーション•  ダッシュボード•  ⼀一般的な⽤用途のプログラムデータソース•  RDBMS•  フラットファイル•  XML / JSON•  メッセージキュー•  プロプライエタリなデータフォーマット•  複雑構造のデータ•  ⾮非構造化テキスト•  画像、ビデオ•  キーバリューペアDWH バックルーム DWH フロントルーム
8. 8© Cloudera, Inc. All rights reserved.Hadoopを基盤とした、新しいデータプラットフォーム•  安価にスケール可能•  あらゆるワークロードを単⼀一のプラットフォームで実現•  無制限のデータHadoopとエンタープライズデータハブ(EDH)STRUCTURED SqoopUNSTRUCTURED Kafka, FlumePROCESS, ANALYZE, SERVEUNIFIED SERVICESRESOURCE MANAGEMENT YARNSECURITY Sentry, RecordServiceFILESYSTEMHDFSRELATIONALKuduNoSQLHBaseSTOREINTEGRATEBATCHSpark, Hive, Pig MapReduceSTREAMSparkSQLImpalaSEARCHSolrSDKKite
11. 12© Cloudera, Inc. All rights reserved.HadoopとETL(1): データ取込みレイヤSTRUCTURED SqoopUNSTRUCTURED Kafka, FlumePROCESS, ANALYZE, SERVEUNIFIED SERVICESRESOURCE MANAGEMENT YARNSECURITY Sentry, RecordServiceFILESYSTEMHDFSRELATIONALKuduNoSQLHBaseSTOREINTEGRATEBATCHSpark, Hive, Pig MapReduceSTREAMSparkSQLImpalaSEARCHSolrSDKKiteApache Sqoop: SQL to Hadoop•  効率率率的な双⽅方向のデータバルクロード•  RDBMS / EDW / NoSQL ⽤用の無償のカスタムコネクタを利利⽤用可能Apache Flume: Hadoop⽤用ログ収集ソフト•  ⼤大量量のストリーミング/ログデータを移動可能•  信頼性、スケーラビリティ、管理理性、拡張性が⾼高い•  複数のシステムからデータを収集しやすいApache Kafka: Hadoop⽤用Pub-‐‑‒Subメッセージング•  多数の「プロデューサ」から多数の「コンシューマ」へデータを移動可能•  幅広い⽤用途に対し最も柔軟にサポート•  Flume / HBase / Spark などと統合
12. 13© Cloudera, Inc. All rights reserved.HadoopとETL(2): HDFSとHiveメタストアSTRUCTURED SqoopUNSTRUCTURED Kafka, FlumePROCESS, ANALYZE, SERVEUNIFIED SERVICESRESOURCE MANAGEMENT YARNSECURITY Sentry, RecordServiceFILESYSTEMHDFSRELATIONALKuduNoSQLHBaseSTOREINTEGRATEBATCHSpark, Hive, Pig MapReduceSTREAMSparkSQLImpalaSEARCHSolrSDKKiteETLにおけるHDFSとHiveメタストア•  HDFS -‐‑‒ データフォーマットを選ばない、すなわちリレーショナルテーブルである必要がない•  Hiveメタストア / HCatalog -‐‑‒ オープンで拡張性が⾼高い、ベンダ固有のテーブルではないスキーマオンリード•  クエリ実⾏行行側にどうやってデータを活⽤用するのかを決めさせることができる•  性能を得るために、ビューのマテリアライズを遅延させることができる•  例例) Parquet File の作成
13. 14© Cloudera, Inc. All rights reserved.HadoopとETL(3): データ変換処理理STRUCTURED SqoopUNSTRUCTURED Kafka, FlumePROCESS, ANALYZE, SERVEUNIFIED SERVICESRESOURCE MANAGEMENT YARNSECURITY Sentry, RecordServiceFILESYSTEMHDFSRELATIONALKuduNoSQLHBaseSTOREINTEGRATEBATCHSpark, Hive, Pig MapReduceSTREAMSparkSQLImpalaSEARCHSolrSDKKiteSpark / MapReduce•  分散処理理による⾼高速なバッチ処理理Hive / Pig / Crunch•  バッチ処理理を記述しやすくするための上位⾔言語
14. 15© Cloudera, Inc. All rights reserved.従来のバックルーム Hadoopによるバックルームデータソースからの転送が遅い投⼊入前に物理理的なデータ変換が必要投⼊入前にクレンジングや正規化が必要RDBMSテーブルターゲットが必須メタデータはシステムテーブルに制限プレゼンテーション層はベンダー固有でRDBMS SQLにしか対応不不可バックルームの変化: システム⾯面
15. 16© Cloudera, Inc. All rights reserved.従来のバックルーム Hadoopによるバックルームデータソースからの転送が遅いデータソースからの転送が速い投⼊入前に物理理的なデータ変換が必要物理理的なデータ変換はオプション投⼊入前にクレンジングや正規化が必要投⼊入前のクレンジングや正規化は⾮非推奨RDBMSテーブルターゲットが必須 RDBMSテーブルターゲットはオプションメタデータはシステムテーブルに制限 HCatalogによる拡張性のあるメタデータプレゼンテーション層はベンダー固有でRDBMS SQLにしか対応不不可プレゼンテーション層は制限がない•  データ変換前に適⽤用してもいい•  分析アプリケーション毎に固有•  複数の特徴を同時に持つことが可能バックルームの変化: システム⾯面
16. 17© Cloudera, Inc. All rights reserved.従来のバックルームETLスタッフのよくある発⾔言•  「データはまだ準備中」•  「データはクレンジングが必要」•  「データガバナンス優先」•  「エンドユーザは信⽤用できない」Hadoopによるバックルーム誰もが⾃自由にデータを使える•  ⾼高いスキルの分析ユーザ•  データサイエンティスト•  ⾃自動化プロセス•  機械学習アプリケーション•  実験的なモデル作成•  SQL以外のクライアント•  全⽂文検索索エンジンバックルームの変化: チーム⾯面
17. 18© Cloudera, Inc. All rights reserved.HDFS•  ⽣生データ領領域•  ソースデータの完全な複製•  情報ドメイン毎に整理理•  変換処理理は⼀一切切⾏行行わない•  精製済データ領領域•  ユースケース毎に整理理•  変換済・準備済データセット•  ユーザ定義領領域•  IT部⾨門の準備を待ちたくないユーザは多い•  サンドボックスとしてデータの活⽤用を実験したいユーザも多い•  マスターデータ、メタデータ、外部からの参照データなどは専⽤用領領域に格納•  システム全体をセキュアに•  認証、ロールベースアクセス制御、暗号化「次の数年年間で、社内のデータマートをかなりの数減らすことができるだろう」「意思決定のための全ての社内アプリケーションにとっての単⼀一のデータソースとなることが⽬目標」Kaiser Permanente の事例例⽣生データ領領域ユーザ定義領領域精製済データ領領域データレジストリ(タグ&カタログ)マスターデータメタデータ使⽤用量量データ内部参照データ業界参照データデータロード置換抽出-‐‑‒ロードコピーデータ抽出データソースDWH/DMデータ・セレクションHive ImpalaPig Java Python図は以下の参考資料料を元に作成http://www.cloudera.com/resources/recordedwebinar/the-‐‑‒future-‐‑‒of-‐‑‒data-‐‑‒warehousing-‐‑‒-‐‑‒etl-‐‑‒will-‐‑‒never-‐‑‒be-‐‑‒the-‐‑‒same.html