Hadoopデータプラットフォーム #cwt2013
•
10 recomendaciones•4,061 vistas
#cwt2013 Clouderaの嶋内 @shiumachi によるビッグデータプラットフォームの構築・運用についてのスライドを公開しました。Hiveをどう扱うかという話から、チームサイズ別の運用方法まで紹介しています
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (12)
Similar a Hadoopデータプラットフォーム #cwt2013
Similar a Hadoopデータプラットフォーム #cwt2013 (20)
Más de Cloudera Japan
Más de Cloudera Japan (20)
Hadoopデータプラットフォーム #cwt2013
- 2. 自己紹介 嶋内 翔(しまうち しょう) • 2011年4月にClouderaの最初の日本人社員として入 社 • テクニカルサポート業務をメインに、日本における技 術に関係する業務全般を担当 • email: sho@cloudera.com • twi?er: @shiumachi • 2
- 3. Hadoop オペレーションの日本語訳が発売予定です • • • • • • 3 11月下旬発売 通称「パカ」本 (?) Cloudera の Eric Sammer 著 翻訳は安心の玉川竜司さん レビューを手伝ってました 日本語版のみの付録も執筆！
- 4. Cloudera Impala の⽇日本語フリーブック • • • オライリーの「インパラ本」、日本語PDF版が無償公開される予定です！ Cloudera の John Russell 著 Hadoop、HBase、Hadoopオペレーション、 プログラミングHiveなどを翻訳された 玉川竜司さんが翻訳！ 「これまでClouderaの皆 さんにご尽力いただいた 翻訳レビューへの感謝の 気持ちとして、Cloudera World Tokyo開催のお祝 いに翻訳寄贈します！」 4
- 5. 今日のアジェンダ Hadoopシステムの全体構成 • データの取り込み • Hive / Impala を使ったデータの活用 • Cloudera Searchとの統合 • データ基盤におけるクラスタ管理 • 5
- 7. Hadoopシステムの全体構成 APIアクセス 外部システム 外部システム APIアクセス BIツール + JDBC/ODBC Webサーバ等の ログを生成するサーバ SQL Hadoop 検索 ログ収集 ユーザ 携帯端末の 通信ログ 分散バッチ処理 RDBMS 7 テーブルごと インポート 機械学習 テーブルごと エクスポート DWH
- 8. Hadoopのシステム全体構成 APIアクセス 外部システム 外部システム APIアクセス データの取り込み Webサーバ等の ログを生成するサーバ データの 保存 Hadoop データの活用 BIツール + JDBC/ODBC 分析 SQL 探索 提供 検索 ログ収集 ユーザ 携帯端末の 通信ログ 分散バッチ処理 RDBMS 8 テーブルごと インポート データの処理 機械学習 テーブルごと エクスポート DWH
- 9. Hadoopのシステム全体構成 APIアクセス 外部システム 外部システム APIアクセス データの取り込み Webサーバ等の ログを生成するサーバ データの 保存 Hadoop データの活用 BIツール + JDBC/ODBC 分析 SQL 探索 提供 検索 ログ収集 ETLツール BI・DWH 携帯端末の 通信ログ ユーザ 分散バッチ処理 RDBMS 9 テーブルごと インポート データの処理 機械学習 テーブルごと エクスポート DWH
- 10. Hadoopシステムの全体構成 APIアクセス 外部システム 外部システム APIアクセス BIツール + JDBC/ODBC Webサーバ等の ログを生成するサーバ SQL Hadoop 検索 ログ収集 ユーザ 携帯端末の 通信ログ 分散バッチ処理 RDBMS 10 テーブルごと インポート 機械学習 テーブルごと エクスポート DWH
- 11. データの取り込み 11
- 12. データの取り込み 外部システム データの 取り込み APIアクセス 外部システム APIアクセス BIツール + JDBC/ODBC Webサーバ等の ログを生成するサーバ SQL Hadoop 検索 ログ収集 ユーザ 携帯端末の 通信ログ 分散バッチ処理 RDBMS 12 テーブルごと インポート 機械学習 テーブルごと エクスポート DWH
- 13. Flume • ⽣生成される⼤大量量のデータを効率率率的に移動させるための分散システム • • ⾼高い信頼性と可⽤用性、そして拡張性を備える Flumeは各種サーバのログファイルをHDFSに取り込むために使う • • • ウェブサーバ ファイアーウォール メールサーバ HDFS Flume エージェント ネットワーク Application Application Application Server Server Server Network Switch Network Switch Network Router 13 Network Switch Network Router Network Router
- 14. Flumeによるイベント収集の一例 Webサーバ メールサーバ Flumeエージェント Flumeエージェント Flumeエージェント Flumeエージェント syslog 圧縮 暗号化 14 Hadoop DWH
- 15. Sqoop • • RDBMS/DWHとのデータインポート・エクスポートライ ブラリ MapReduceを使うので高速にデータをロード可能 DWH DWH Hadoop RDBMS 16 テーブルごと インポート テーブルごと エクスポート RDBMS
- 16. HBaseを使ったデータの取り込み • • • REST API を使って外部システムからデータを収集 Flume から直接流し込むことも可能 CSVファイルなどからバルクアップロードも可能 CSVファイル Flumeエージェント 外部システム 17 APIアクセス バルクロード
- 17. HDFS • 単なるファイルも、HDFSにアップロード可能 • • • • FTPサーバのような put/get が可能 他のシステムでzipに固めたデータをアップロードすると きなどに使う CDH4からはREST APIでアクセス可能に CDH5からはNFSマウントも可能に ファイル Hadoop 18
- 19. Hive / Impala を使ったデータの活用 20
- 20. Hive と Cloudera Impala Hive SQLライクなクエリ言語 クエリ言語はMapReduce アプリケーションにコンパイルされる Cloudera Impala オープンソースの低レイテンシクエリ言語 MapReduceを使わない。非常に高速 SELECT customer.id, customer.name, sum(order.cost) FROM customer INNER JOIN order ON (customer.id = order.customer_id) WHERE customer.zipcode = '63105’ GROUP BY customer.id, customer.name; 21
- 21. 生データをHive/Impalaで活用する json BIアナリスト 生データA テーブルa テーブルd テーブルa’ 中間テーブルc sequencefile 生データB 22 テーブルb テーブルe アドホックな クエリの結果
- 22. 生データをHive/Impalaで活用する json 生データA sequencefile 生データB 23 BIアナリスト データは完全に生のままHadoopに入 れるより、最低限の加工処理をほど テーブルa こしておいた方がいい • 圧縮 テーブルd テーブルa’ • ファイルの結合 • etc… 中間テーブルc テーブルe テーブルb アドホックな クエリの結果
- 23. 生データをHive/Impalaで活用する json BIアナリスト 生データA テーブルa’ 中間テーブルc sequencefile 生データB 24 どんなデータでもSerDe テーブルa を使うことでテーブル構 造としてパース可能 テーブルd (Hiveのみ) テーブルb テーブルe アドホックな クエリの結果
- 24. スキーマ・オン・リード • • • Hiveの最も強力な「概念」の一つ データを読むときにスキーマを使う 自由にデータが投入可能になる テーブルA Hadoop CSV 25 ログ テキスト テーブルB
- 25. Hiveのスキーマ作成クエリの例 CREATE EXTERNAL TABLE tweets ( id BIGINT, created_at STRING, favorited BOOLEAN, retweet_count INT, retweeted_status STRUCT< text:STRING, user:STRUCT<screen_name:STRING,name:STRING>> ) PARTITIONED BY (datehour INT) ROW FORMAT SERDE 'com.cloudera.hive.serde.JSONSerDe' LOCATION '/user/flume/tweets' 26
- 26. Hiveのスキーマ作成クエリの例 CREATE EXTERNAL TABLE tweets ( id BIGINT, created_at STRING, favorited BOOLEAN, 外部テーブル retweet_count INT, retweeted_status STRUCT< text:STRING, user:STRUCT<screen_name:STRING,name:STRING>> ) データのパス PARTITIONED BY (datehour INT) ROW FORMAT SERDE 'com.cloudera.hive.serde.JSONSerDe' LOCATION '/user/flume/tweets' 27
- 27. 外部テーブル • • ファイルシステム上にあるデータをそのままテーブルとして扱 える 他のツールとデータを共有することも簡単にできる Hive テーブルA MapReduce Impala CSV CSV CSV /user/sho/super_cool_web_service/access_log 28
- 28. 外部テーブル • テーブルを削除しても、データは消えない Hive テーブルA MapReduce Impala 影響なし！ CSV CSV CSV /user/sho/super_cool_web_service/access_log 29
- 29. Hiveのスキーマ作成クエリの例 CREATE EXTERNAL TABLE tweets ( id BIGINT, created_at STRING, favorited BOOLEAN, retweet_count INT, retweeted_status STRUCT< text:STRING, SerDe user:STRUCT<screen_name:STRING,name:STRING>> ) PARTITIONED BY (datehour INT) ROW FORMAT SERDE 'com.cloudera.hive.serde.JSONSerDe' LOCATION '/user/flume/tweets' 30
- 30. SerDe • • • Serializer / Deserializer の略。「さーでぃー」と読む あらゆるデータをHiveレコードに変換するためのイン タフェースを提供する 組み込みSerDeもいくつかある • • テキスト以外のバイナリデータなども、カスタム SerDeを実装することで読み込むことは可能 • 31 RegexSerDeなど ただしJavaのクラスを実装する必要がある
- 31. 生データを少し加工しておく • とはいえ、純粋に生データのまま保存するといくつか 問題がある • • • ファイル数が多くなる→NNのヒープ圧迫などの問題 無圧縮→ストレージを圧迫 再利用しやすい形に加工しておくと便利 • ファイルの結合 • • • 圧縮 • • 32 SequenceFile など Hive / Impala からしか使わないのであれば RCFile / Parquet も可 gzip snappy
- 32. 追記: データの加工について あくまで生データを管理しやすいようにパッキングす るという意味です • 情報を削ったり、別のものに変換するという意味では ないです • • • • 33 この辺もケースバイケース 明らかに不要な情報なら削ってもいいかもしれない(でもそ れが明らかに不要って誰が証明できる？) 自分達のシステムに一番合った形に保存して起きま しょう
- 33. 加工例: SequenceFile(BLOCK) + gzip テーブル作成 CREATE TABLE seq_table (id INT, name STRING, … ) STORED AS SEQUENCEFILE; set mapred.output.compression.type = BLOCK; set hive.exec.compress.output = true; set mapred.output.compression.codec = org.apache.hadoop.io.compress.GzipCodec; INSERT INTO seq_table SELECT * FROM raw_table; 34
- 34. 加工例: SequenceFile(BLOCK) + gzip テーブル作成 外部テーブル + S (id INT, name STRING, … ) CREATE TABLE seq_table erDe を組み合わせて、生 STORED AS データに対するスキーマを作る SEQUENCEFILE; set mapred.output.compression.type = BLOCK; SequenceFile形式の テーブルに変換する set hive.exec.compress.output = true; set mapred.output.compression.codec = org.apache.hadoop.io.compress.GzipCodec; INSERT INTO seq_table SELECT * FROM raw_table; 35
- 35. 生データをHive/Impalaで活用する json BIアナリスト 生データA テーブルa テーブルd テーブルa’ 中間テーブルc sequencefile 生データB 36 テーブルb テーブルe アドホックな クエリの結果
- 36. Hadoop活用のポイント(1) 富豪的プログラミング • Hadoopを使うときはリソースをケチらない！ • • • Hiveの場合、サブクエリのネストに注意 • • ネストが深い = MapReduce の実行数が多い 特に再利用することが多い場合は中間テーブルを作 りましょう • 38 特にストレージリソースの活用は見落としがち 他のシステムに比べてHadoopのストレージリソースは安 い 使い終わった中間テーブルはきちんと消すこと
- 37. Hadoop活用のポイント(1) 富豪的プログラミング こうするより…… この方が断然速い(トータルは遅い) SELECT … FROM (SELECT … FROM (SELECT … FROM … SELECT … FROM tmp_table 中間テーブルA’ テーブルA テーブルA
- 38. 生データをHive/Impalaで活用する json BIアナリスト 無理に全部Hadoop上で処理し 生データA ようとせず、ローカルPCで処理 できるぐらいのデータ量になっ テーブルa’ たらエクスポートする 40 テーブルd 中間テーブルc sequencefile 生データB テーブルa テーブルb テーブルe アドホックな クエリの結果
- 39. Hadoop活用のポイント(2) なるべくHadoopを使わない • 基本は「ローカルでできることはなるべくローカルでやる」 • • その処理、本当にHive/Impalaでやる必要があります か？ • • • フィルタ・集計した結果が1GB以下になったらローカルPCに落と してRやPythonなど好きなスクリプト言語を使いましょう もちろんExcelが使えるなら使いましょう もちろん、クラスタで処理した方が速いものはクラスタで 行う • • 41 Hadoopが必要な処理はそんなに多くない バランスが大事 このあたりはもう経験を積むしかない
- 40. Oozieによるワークフローの管理 多段処理はOozieでひとまとめに スケジューリングによる定期実 行も可能 json BIアナリスト 生データA テーブルa テーブルd テーブルa’ 中間テーブルc sequencefile 生データB 42 テーブルb テーブルe アドホックな クエリの結果
- 41. Hue の Oozie ワークフロー管理 スケジューリング実行な どはOozieに任せてしまう のが便利 (日次集計など) 43
- 43. Cloudera Search と統合する json BIアナリスト 生データA テーブルa テーブルd テーブルa’ 中間テーブルc sequencefile 生データB 45 テーブルb テーブルe アドホックな クエリの結果
- 44. Cloudera Search と統合する 検索 インデックス 検索UI json BIアナリスト 生データA テーブルa テーブルd テーブルa’ 中間テーブルc sequencefile 生データB 46 テーブルb テーブルe アドホックな クエリの結果
- 45. Cloudera Search Hadoop上のデータに対してインデックスを貼り、Solrで検 索できる • 利点は色々 • • • 47 検索エンジンのように利用できる 検索結果でまず当たりをつけてから分析に入れる
- 47. クラスタの管理 Cloudera Managerがどんなに素晴らしくても、クラス タを使うのも管理するのも人の役目 • ここでは「人」に視点をおいたクラスタ管理の方法に ついて説明します • ※ Cloudera Manager: Cloudera の運用管理ツール。後のセッションで説明し ます 49
- 48. リソース管理 • Hadoopのリソース • • • リソースはみんなのもの • 50 計算リソース(CPU + メモリ、あるいはタスクスロット) ストレージリソース 譲りあって仲良く使いましょう
- 49. 計算リソースの管理 • 誰がリソース管理をするのか？ • 小規模なチーム: 全員 • • 中規模なチーム: クラスタ管理者 • • • 「お前のジョブ長すぎ。(ジョブを)殺すから」 ジョブ監視の仕組みが必要 大規模なチームは？ • • • • 51 「ちょっとクラスタ使うよ」と声かければ済む スケジューラ cgroup YARN チーム単位でリソース配分が出来る Cloudera Manager 5 を使い ましょう！
- 50. ストレージリソースの管理 • 富豪も無限にお金持ちではない • いくらリソースをケチらないといっても限度がある 必ず出てくる、やたらとストレージ圧迫するユーザ • 対処法 • • 小規模なチーム • • 中規模なチーム • • 管理者が容量をチェックしつつ、メールで指摘しましょう 大規模なチーム • 52 声かけましょう Cloudera Manager のレポート機能を使いましょう
- 51. そもそも誰に使わせるのか？ • 少数精鋭型 • • • • 全員に使わせる • • 53 大半の企業はこのタイプになるはず 管理が楽なのがメリット 反面、チームは他の部署からの問合せ対応に追われるし、 他の部署はほしいデータがすぐに手に入らないのが不満 になる 管理は大変だが、誰もがデータにアクセスできるので、 データを活用する文化が根づいていれば強力 Kerberos認証などのセキュリティ機構をフル活用する必要 がある
- 52. セキュリティ • オペレーションミス防止のためにも最低限のセキュリ ティは必要 • • マルチテナント環境では必須 • • • 54 HDFSのパーミッション、Hiveの権限など Kerberos認証 Apache Sentryによるアクセス制御 Cloudera Navigator によるアクセス監査
- 53. Cloudera Navigator によるアクセス監査 55
- 54. 管理者はどこまで管理するのか？ 容量・種類ともに増大していくデータを、中身まで全 て面倒を見るのか？ • 自分のチームのデータのみ • • • 他部署との連携によるデータの送受信 • • 56 管理可能 中規模の企業でも管理が困難 大規模な企業だとまず不可能
- 55. イントラネット イントラネット トップページ 事業部門B 社長メッセージ 事業部門A 製品a エコキャンペーン 57 製品b 事業部門Bの 部門ブログ
- 56. イントラネット イントラネット管理者は、 新規に作られたページ全てを把握・管理す イントラネット トップページ るわけではない このコンテンツだけの管理者が別にいる 事業部門B 社長メッセージ 事業部門A 製品a 製品b エコキャンペーン しかし社員は検索結果に表れればこ のコンテンツを使うことができる 58 事業部門Bの 部門ブログ
- 57. データプラットフォームの理想型 データベース 顧客情報 シンクタンクからの情報 製品情報 製品a 政府情報 59 製品b 新規顧客A社 の情報
- 58. データプラットフォームの理想型 データプラットフォームの管理者はデータ全てを把握する データベース 必要はない 個別のデータ管理者が管理する 顧客情報 シンクタンクからの情報 製品情報 製品a 製品b 政府情報 しかし社員は検索結果に表れればこ のデータを使うことができる 60 新規顧客A社 の情報
- 59. まとめ 61
- 60. Hadoopシステムの全体構成 APIアクセス 外部システム 外部システム APIアクセス BIツール + JDBC/ODBC Webサーバ等の ログを生成するサーバ SQL Hadoop 検索 ログ収集 ユーザ 携帯端末の 通信ログ 分散バッチ処理 RDBMS 62 テーブルごと インポート 機械学習 テーブルごと エクスポート DWH
- 61. We are Hiring! • Clouderaは貴方を求めています！！ • ソリューションアーキテクト • • カスタマーオペレーションエンジニア（サポート） • • • • Hadoopを使ったコンサルティングやモデリング 世界中のお客様のHadoopを守る！ インストラクター システムエンジニア(技術営業) セールス 興味のある方は info-‐jp@cloudera.com まで ご連絡下さい！ 63
- 62. We are Hiring! 64
- 63. 65