Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Amazon S3を中心とするデータ分析のベストプラクティス

7,175 views

Published on

DB tech showcase
Amazon S3を中心とするデータ分析のベストプラクティス

Published in: Technology
  • Be the first to comment

Amazon S3を中心とするデータ分析のベストプラクティス

  1. 1. 1 Amazon S3を中心とする データ分析のベストプラクティス Ryosuke Iwanaga Amazon Web Services Japan Solutions Architect 2016.10
  2. 2. 2 Agenda • データレイクとAmazon S3 • データ分析のためのAmazon EMR • 【事例】データ分析で作る新しい価値
  3. 3. 3 データウェアハウス
  4. 4. 4 データウェアハウスを中心としたデータ分析 Databases Logs Data Warehouse BI Report
  5. 5. 5 データウェアハウスを利用する利点 • スキーマが定義されている • データの型も強制できる • どんなデータもあって、共通のセキュリティモデルで利用 • アクセスするツールが簡単、エコシステムが安定 • トランザクション
  6. 6. 6 課題1: 入ってくるデータの量と質の変化 Databases Logs Data Warehouse BI Report Events Media
  7. 7. 7 課題2: データを利用する側の量と質の変化 Databases Logs Data Warehouse BI Report Lab Realtime Machine Learning
  8. 8. 8 データのサイロ化
  9. 9. 9 データのサイロ化の課題 • スケーラビリティの課題は解消しない – 要求が10倍になったら、サイロ数が10倍になる?? • どこにどのデータがあるか分からない – 途中で場所が変わったら更にカオスに • サイロをまたいだ分析が困難 – 同じデータを複数サイロに重複して持つと、無駄や同期が課題に
  10. 10. 10 データレイク
  11. 11. 11 データレイクを中心としたデータ分析 Data Lake … … …
  12. 12. 12 データレイクのメリット • ストレージと計算処理の分離 – それぞれ独立してスケールできるので最適化しやすい • Single Source of Truth – データレイクにあるものを正とすれば良い • 様々なinput/output手法に対応 – in/outが独立、ETLも独立できるので、後からの拡張がスムーズ
  13. 13. 13 データレイク – Hadoop (HDFS)をストレージとして Search Access QueryProcess Archive
  14. 14. 14 Transaction s データレイク – Amazon S3をストレージとして Search Access QueryProcess Archive Amazon RDS Amazon DynamoD B Amazon Elasticsearch Service Amazon Glacier Amazon S3 Amazon Redshift Amazon Elastic MapReduce Amazon Machine Learning Amazon ElastiCach e
  15. 15. 15  何でも保存できる (オブジェクトストレージ)  スケール可能 / 弾力的  99.999999999% の耐久性 (イレブン・ナイン)  実質的に無限のインバウンド帯域  とても低いコスト: $0.03/GB-月; $30.72/TB-月  全てのAWSサービスにとって仮想的なデータレイヤ Amazon S3
  16. 16. 16 クロスリージョン レプリケーション Amazon CloudWatch メトリクス AWS CloudTrail サポート VPCエンドポイント for Amazon S3 Amazon S3 バケット数 上限引き上げ イベント通知 全リージョンで 新規作成後の読み取り一貫性 Amazon S3の進化
  17. 17. 17 S3のストレージクラスの選択肢 標準 アクティブデータ アーカイブデータ低頻度アクセスデータ 標準 - 低頻度アクセス Amazon Glacier
  18. 18. 18 どうやってアクセスする? • ETL等を経て、他のDB/DWHへ取り込む – Pros: DB/DWHの強力な機能が利用できる – Cons: ETL処理が必要になる、スケールに限界がある • 直接S3にアクセスする – Pros: S3に置いた瞬間にアクセスできる、スケールは無限 – Cons: レイテンシに多少ペナルティがある
  19. 19. 19 S3上のペタバイト級のデータ群を、Hiveテーブルとして利用する hive> CREATE EXTERNAL TABLE airdelays ( yr INT, quarter INT, month INT, flightdate STRING, uniquecarrier STRING, airlineid INT, . . . div5tailnum STRING ) PARTITIONED BY (year STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LINES TERMINATED BY 'n' LOCATION 's3://flightdelays-kls/csv’; データがあるS3のバケット: S3上のデータ をテーブルと して見えるよ うにHiveに指 示する hive> describe airdelays; OK yr int quarter int month int flightdate string . . . div5wheelsoff string div5tailnum string year string # Partition Information # col_name data_type comment year string Time taken: 0.169 seconds, Fetched: 115 row(s) Hiveはテーブルを知ることができる:
  20. 20. 20 s3://bucket/logs /file001 /file002 /file003 /file004 /file005 /file006 /file007 /file008 R R R M M M M 1,aaa,... 2,bbb,... ... SQLを使ってS3に直接アクセスする CREATE TABLE logs ... Metastore SELECT … FROM logs ...
  21. 21. 21 S3のパフォーマンス: レンジGET vs データ局在性? GET Range 128-192MB GET Range 0-64MB GET Range 64-128MB GET Range (n-64)-nMB ワーカーノード S3オブジェクト(大きめのファイル)
  22. 22. 22 ID Age State 123 20 CA 345 25 WA 678 40 FL 999 21 WA 行指向 vs 列指向フォーマット 123 20 CA 345 25 WA 678 40 FL 999 21 WA 123 345 678 999 20 25 40 21 CA WA FL WA ROW FORMAT COLUMN FORMAT
  23. 23. 23 ストレージのパフォーマンス: S3 vs HDFS at Netflix http://techblog.netflix.com/2014/10/using-presto-in-our-big-data-platform.html
  24. 24. 24 ユースケース 我々はクラウドベースのデータウェアハウスの"source of truth"としてS3を利用しています。取っておく価値のある データは全てS3に保存されています。この中には、我々の ログデータパイプライン(Ursula)によって、(Netflixが組 み込まれた)テレビやパソコン、そしてモバイルデバイス から毎時間取得される数十億ものイベントストリームに加 えて、AegisthusパイプラインのCassandraから産まれる ディメンションデータも含まれています。 “ ” Source: http://techblog.netflix.com/2013/01/hadoop-platform-as-service-in-cloud.html Eva Tse Director, Big Data Platform
  25. 25. 25 我々のBig Dataの規模感 トータル ~25PB のデータウェアがAmazon S3に 読み出し ~10% (データ/日) 書き込み ~10% (読み出しデータ/日) ~ 5500億イベント/日 ~ 350のアクティブなプラットフォームユーザ
  26. 26. 26 クラウド アプリ Kafka Ursula Cassandra Aegisthus ディメンションデータ イベントデータ 15分 日次 Amazon S3 SSテーブル データパイプライン
  27. 27. 27 データ分析のためのAmazon EMR
  28. 28. 28 データ処理を単純化してみる 収集 保存 処理/分析 利用 データ 答え 答えを出すまでの時間(レイテンシ)は? スループットは? 費用は?
  29. 29. 29 データ処理/分析に必要なこと • 常に新しくなる分散処理エコシステムへの対応 – バージョンアップ、新プロダクト、カスタマイズ • 簡単にスケールできること – データに応じて、利用者数に応じて • データレイクとの連携 – データレイクのデータをネイティブに扱える
  30. 30. 30  スケール可能なHadoopクラスタをサービスとして  Hadoop, Hive, Spark, Presto, Hbase, etc.  簡単に利用でき、完全にマネージド  オンデマンド、予約、スポットの価格  HDFS, S3, Amazon EBSのファイルシステム  エンドツーエンドのセキュリティ Amazon EMR
  31. 31. 31 EMRノード Master instance group EMR cluster Task instance groupCore instance group HDFS HDFS
  32. 32. 32 なぜEMR? • 豊富なアプリケーションが簡単に利用可能 – 高速なアップデートで業界最新に追従 • クラスタ作成から終了まで全てを自動化 • 低コストで運用可能
  33. 33. 33 Storage S3 (EMRFS), HDFS YARN Cluster Resource Management Batch MapReduce Interactive Tez In Memory Spark Applications Hive, Pig, Spark SQL/Streaming/ML, Mahout, Sqoop HBase/ Phoenix Presto Hue (SQL Interface/Metastore Management) Zeppelin (Interactive Notebook) Ganglia (Monitoring) HiveServer2/Spark Thriftserver (JDBC/ODBC) Amazon EMR サービス
  34. 34. 34 Amazon EMR Release (2015/07以降) • Release 4.0.0 – 2015/07 • Release 4.1.0 – 2015/09 • Release 4.2.0 – 2015/11 • Release 4.3.0 – 2016/01 • Release 4.4.0 – 2016/03 • Release 4.5.0 – 2016/04 • Release 4.6.0 – 2016/04 • Release 4.7.1 – 2016/06 • Release 4.7.2 – 2016/07 • Release 5.0.0 – 2016/08 • 約12ヶ月間で10回のリ リース • 進化の早いHadoopエ コシステムに追従して いくため
  35. 35. 35 アプリケーションの変更履歴 (〜5.0.0)
  36. 36. 36 EMR 5.0 - Applications
  37. 37. 37 カスタムアプリケーションもBigtopで https://blogs.aws.amazon.com/bigdata/post/TxNJ6YS4X6S59U/Building-and-Deploying-Custom-Applications-with-Apache-Bigtop-and-Amazon-EMR
  38. 38. 38 なぜEMR?: 自動化 EC2 Provisioning Cluster Setup Hadoop Configuration Installing Applications Job submissionMonitoring and Failure Handling
  39. 39. 39 Amazon EMRならではの使い方 • 必要な時だけクラスタ起動 – 消せばお金はかからない – 処理が終わったら自動で消え る設定も可能 • データは全てAmazon S3 – クラスタを消してもデータは 消えない – データを貯める段階ではクラ スタ不要 t
  40. 40. 40 $0.27 $0.29$0.50 1b 1c1a 8XL $0.30 $0.16$0.214XL $0.07 $0.08$0.082XL $0.05 $0.04$0.04XL $0.01 $0.04$0.01L C3 $1.76 On Demand $0.88 $0.44 $0.22 $0.11 各インスタンスファミリー 各インスタンスサイズ 各アベイラビリティゾーン 各リージョン 全てが別々のSpot Market Spot Market
  41. 41. 41 なぜEMR?: ストレージとコンピュートの分離 Amazon Kinesis (Streams, Firehose) Hadoop Jobs Persistent Cluster – Interactive Queries (Spark-SQL | Presto | Impala) Transient Cluster - Batch Jobs (X hours nightly) – Add/Remove Nodes ETL Jobs Hive External Metastore i.e Amazon RDS Workload specific clusters (Different sizes, Different Versions) Amazon S3 for Storage create external table t_name(..)... location s3://bucketname/path-to-file/
  42. 42. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Scott Donaldson, Senior Director Clayton Kovar, Principal Architect EMR と 対話的な分析
  43. 43. 最大で 750億件の イベントが 毎日 5 PBを超える ストレージ 投資家を 保護する マーケットを 清廉に保つ アメリカの 99%の株取引と 70%のオプション を監視している マーケットの 再構築は 10兆もの ノードとエッジが 含まれる 大きく 考える
  44. 44. EMRは我々のアーキテクチャ上でユビキタス データマート (Amazon Redshift) クエリクラスタ (EMR) クエリクラスタ (EMR) Auto Scaled EC2 分析 アプリ 正規化ETL クラスタ (EMR) バッチ分析 クラスタ (EMR) アドホック クエリクラスタ (EMR) Auto Scaled EC2 分析 アプリ ユーザ データ 提供者 Auto Scaled EC2 データ 投入 サービス 最適化ETL クラスタ (EMR) 共有Metastore (RDS) クエリ最適化 (S3) Auto Scaled EC2 データ カタログ &派生 サービス 参照データ (RDS) 共有データサービス Auto Scaled EC2 クラスタ管理 &ワークフロー サービス 生データ (S3)
  45. 45. Hive on EMR/S3で十分戦える
  46. 46. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Abhishek Sinha, Amazon Web Services Gaurav Agrawal, AOL Inc October 2015 BDT208 A Technical Introduction to Amazon EMR
  47. 47. AOLデータプラットフォームアーキテクチャ 2014
  48. 48. データの統計と洞察 クラスタサイズ 2 PB 自前のクラスタ 100ノード 行データ/日 2-3 TB データ保持期間 13-24ヶ月
  49. 49. AOLデータプラットフォームアーキテクチャ2015 1 2 2 3 4 56
  50. 50. 50 EMR+S3のベストプラクティス • データをまずはS3に着地させる – 生データ • ETLを回して、必要なデータを生成 – 集計済データ、クエリ最適化データ等 • 計算処理は必要に応じてEMRクラスタを複数利用 – コンピュートとストレージの分離 – いつでもエンジン切替、バージョンアップ等が可能
  51. 51. 51 リアルタイム分析
  52. 52. 52 Lambda Architecture Amazon Kinesis Amazon EMR + Amazon S3 http://lambda-architecture.net/
  53. 53. 53 【事例】データ分析で作る新しい価値
  54. 54. The Life of a ClickHow Hearst Publishing Manages Clickstream Analytics Rick McFarland April 2016
  55. 55. The Evolution of “Chasing the Customer” Past Near Past Now! Survey Websites Every Electronic Device 100–1000 Responses 1 MM–1 BN Trillions 1 Week Daily Seconds Survey Data Clickstream Data “Lifestream” Data Collection Volume Speed Description “Thoughtstream” Data? When will it stop? Nanobots? Won’t matter! Future?
  56. 56. HearstDataServicesinAction Product initiative led by all editors at Hearst Buzzing@Hearst
  57. 57. バズりによるビジネス価値 • 我々の読者からの記事に対する素早いフィードバック • メディアを超えて、人気の記事を定期的に再配信する (例えばトレンドになっている新聞記事は雑誌にも取り 上げられる) • 記事を書く編集者に、我々の読者により関係のある情 報や、どのチャネルがより我々の読者に記事を読んで もらえるかという情報を与える • 究極的には、定期的な価値を生み出す • ページビューが25%上がれば、定期的な価値につなが る訪問者が15%増加する
  58. 58. • スループット目標: 250以上の世界中のHearst所有メディア からデータを送る • レイテンシ目標: クリックからツールへの反映が5分以下 • 変更速度: クリックストリームへ簡単に新しいデータフィー ルドを追加できる • データサイエンスチームが定義する特有のメトリクス(例え ば標準偏差や回帰)の要求 • データレポートは1時間分から1週間分までの期間が選べる • フロントエンドはゼロから開発されるので、APIを通して開 発チームの特有の要求に応じてデータが提供される そして最も大事なことは、既存サイトの運用に影響があっては いけない! バズりのためのエンジニアリングの必要条件は…
  59. 59. 初期に作ったもの Hearst全体の静的なClickstream Hearst所有サイト のユーザ 会社の データセンタ Netezza データウェアハウス Clickstream 1日1回 約30 GB/日の 基本的なweb logデータ (例: リファラ, URL, ユーザエージェント, クッキー, 等) アドホックな SQLベースの レポーティングと 分析
  60. 60. Clickstreamデータの取り込み Amazon Kinesis Node.JS App- Proxy Kinesis S3 App – KCL Libraries Users to Hearst Properties Clickstream “Raw JSON” Raw Data Tip 全サイトにJavaScriptをデプロイするために Tag managerを利用する Phase 1
  61. 61. Phase 2a データ処理 1.0 ETL on Amazon EMR Clean Aggregate DataRaw Data “Raw JSON” 母国語 内部的にHadoopが処理基盤と して選ばれたが、その理由は Amazon EMRでの作成が簡単 だったのと、Pigの書き方を 知っていたから。 50以上のUDFがPythonで書か れているが、それは我々が Pythonを知っていたから。
  62. 62. Phase 2b データ処理 2.0: Spark Streaming Amazon Kinesis Node.JS App- Proxy Users to Hearst Properties Clickstream ETL on EMR Clean Aggregate Data コスト削減のために Spotインスタンスを利用 Reminders 達成 Apache Sparkで実 装することでHearst のデータチームが Scalaを学べた
  63. 63. Phase 3a データサイエンスを本物に Data Science on EC2 Amazon Kinesis ETL on EMR Clean Aggregate Data API-Ready Data SAS on Amazon EC2を選択 データ編集と、回帰の様な 複雑なデータサイエンス テクニックの両方を使える様に この方式でデータサイエンス を行うと、完了までに3-5分 かかる
  64. 64. Phase 3b データサイエンス: 開発と本番 Amazon Kinesis Data Science “Production” Amazon Redshift ETL on EMR Data Science “Development” on EC2 Run Once per Day Models Agg Data Clean Aggregate Data API-Ready Data Statistical Models Tip データサイエンスモ デルをS3に保存し、 それらをAmazon Redshiftに適応 データサイエンス分割 モデリングと本番を分割し 本番はAmazon Redshiftへ データサイエンスの 処理時間は 100秒に短縮!
  65. 65. Buzzing API API Ready Data Amazon Kinesis Streams Node.JS App- Proxy Clickstream Data Science Application Amazon Redshift ETL on EMR Users to Hearst Properties 最終的なHearst Data Pipeline LATENCY THROUGHPUT Milliseconds 30 Seconds 100 Seconds 5 Seconds 100 GB/Day 5 GB/Day 1 GB/Day 1 GB/Day Agg Data Models Firehose S3
  66. 66. 我々の学びのまとめ Yesterday Today Tomorrow Amazon Kinesis Amazon Kinesis Amazon Kinesis S3 EMR-Pig Spark- Scala PySpark + SparkR Amazon Redshift EC2-SASS3 S3 S3 EMR to Amazon ES Amazon ES Amazon ES 1 hr < 5 min < 2 min Transport Storage ETL Storage Analysis Storage Exposure Latency
  67. 67. Clickstreamsはビジネスにおける 新しい"データの通貨" 少ない力で より多くのことが 本当にできる 大きなチームは 不要: 2-3人のフルタイム エンジニアのチーム で達成できる …もしくは めったにみつからない 貴重な人材1人で
  68. 68. 68 参考情報
  69. 69. 69 AWS Big Data Blog • https://blogs.aws.amazon.com/bigdata/ – 最新の事例、アーキテクチャ、サービス、ソリューションが毎週投稿される • 最新投稿例 – Real-time Stream Processing Using Apache Spark Streaming and Apache Kafka on AWS – Amazon EMR-DynamoDB Connector Repository on AWSLabs GitHub – Encrypt Data At-Rest and In-Flight on Amazon EMR with Security Configurations – Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics – Writing SQL on Streaming Data with Amazon Kinesis Analytics – Part 2 – Integrating IoT Events into Your Analytic Platform – Processing VPC Flow Logs with Amazon EMR
  70. 70. 70 日本からの投稿例: SmartNews https://blogs.aws.amazon.com/bigdata/post /Tx2V1BSKGITCMTU/How-SmartNews- Built-a-Lambda-Architecture-on-AWS-to- Analyze-Customer-Behavior-an
  71. 71. 71 まとめ
  72. 72. 72 Summary • Amazon S3でデータレイク • Amazon EMRでコンピュートとストレージ分離 • 新たなビジネス価値の創出を加速可能
  73. 73. 73

×