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 Athena で実現する データ分析の広がり

2017/9-5-7 に開催された db tech showcase の発表スライドです.
http://www.db-tech-showcase.com/dbts/tokyo

  • Be the first to comment

Amazon Athena で実現する データ分析の広がり

  1. 1. Amazon Athena で実現する データ分析の広がり Makoto Shimura, Data Science Solution Architect Amazon Web Services K.K. 2017.09.06 © 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.
  2. 2. 自己紹介 2 所属: アマゾンウェブサービスジャパン株式会社 業務: ソリューションアーキテクト (データサイエンス領域) 経歴: Hadoopログ解析基盤の開発 データ分析 データマネジメントや組織のデータ活用 志村 誠 (Makoto Shimura)
  3. 3. Agenda • Amazon Athena 概要 • クイックスタート • Amazon Athena の構成 • Update • パフォーマンスガイド & Tips • Athena & Glue によるデータ分析の広がり
  4. 4. Amazon Athena の概要 4
  5. 5. Amazon Athena とは S3上のデータに対して,標準 SQL による インタラクティブなクエリを投げて データの分析を行うことができるサービス 5
  6. 6. Amazon Athena とは • re:Invent 2016 のキーノートにて発表された新サービス • バージニア北部,オレゴン,オハイオ,アイルランド,シンガポール,東京の 計 6 リージョンで展開 • クエリエンジン Presto と,Hive メタストア互換のデータカタログを使用 6 https://aws.amazon.com/jp/blogs/news/amazon-athena-interactive-sql-queries-for-data-in-amazon-s3/
  7. 7. データ分析基盤の進化の流れ Data warehouse appliances 1985 2006 Hadoop clusters 2009 Decoupled EMR clusters 2012 Cloud DWH Redshift Today Clusterless Athena Glue
  8. 8. Athena の特徴 8 サーバレスでインフラ管理の必要なし 大規模データに対しても高速なクエリ 事前のデータロードなしにS3に直接クエリ スキャンしたデータに対しての従量課金 JDBC経由でBIツールから直接クエリ
  9. 9. マネジメントコンソールから簡単にアクセス • 利用開始から数分でクエリを投げられる • クエリごとのスキャンデータ量を確認可能 • Glue データカタログでテーブルスキーマやパーティションを確認
  10. 10. Athena の想定ユースケース 10 ユースケース データ ユーザ 新しく取得したデータに対して, DWに入れる価値があるか探索的に検証 新しく取得したデータ アナリスト 利用頻度の低い過去のデータに対する, BIツール経由のアドホックな分析 コールドデータ アナリスト Webサーバで障害が発生したときに, ログを検索して原因追求 アクセスログ サーバ運用 大規模でないデータに対しての, 低頻度で実施するETL処理 生データ 開発者
  11. 11. Amazon Athena の構成 11
  12. 12. Presto : 高速な分散クエリエンジン • Athenaで使用しているクエリエンジン • データをディスクに書き出さず,すべてメモリ上で処理 • ノード故障やメモリ溢れの場合にはクエリ自体が失敗 • バッチ処理ではなく,インタラクティブクエリ向け 12 https://prestodb.io/overview.html 参考: Presto のアーキテクチャ
  13. 13. データカタログ: Hive メタストア • Athena のデータカタログと互換性がある • Hive は SQL ライクな記法で,Hadoop上のバッチ処理を記述可能 • データソースに対してスキーマを定義し,テーブルのように扱える • HDFS上のデータをベースとしており,標準 SQL とは異なる DDL を持つ 13 https://prestodb.io/overview.html 参考: Presto のアーキテクチャ
  14. 14. Glue データカタログへのアップグレード • バージニア北部リージョンのみ,8/14 に GA になった AWS Glue のデー タカタログを使用 • Athena 以外に Glue,EMR,および Redshift Spectrum で共通して参照 可能 • バージニア北部リージョンで新規に利用する場合は,自動で Glue にデー タカタログが統合される • Glue GA 以前から Athena を使っている方は,公式ドキュメントの手順に 従ってアップグレードをおこなってください 14 http://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html
  15. 15. Athena のデータ型 種類 値 プリミティブ型 tinyint, smallint, int, bigint, boolean, float, double, string, binary, timestamp, decimal, date, varchar, char 配列型 array<data_type> map型 map<primitive_type, data_type> struct型* struct<col_name: data_type> union型 UNIONTYPE<data_type, data_type…> 15 * https://aws.amazon.com/jp/blogs/big-data/create-tables-in-amazon-athena-from-nested-json-and-mappings-using-jsonserde/
  16. 16. Athena のデータ形式 / 圧縮形式 16 項目 値 注意点 データ形式 CSV, TSV, Parquet, ORC, JSON, Regex, Avro, Cloudtrail, Grok • JSONについては Hive-JsonSerDe と Openx-JsonSerDe の2つが利用可能 • CroudtrailSerDe* が利用可能 • 2017/8/14 に Grok をサポート** 圧縮形式 Snappy, Zlib, GZIP, LZO • 2017/4/6 に LZO をサポート * https://aws.amazon.com/jp/blogs/big-data/aws-cloudtrail-and-amazon-athena-dive-deep-to-analyze-security-compliance-and-operational-activity/ ** https://aws.amazon.com/about-aws/whats-new/2017/08/amazon-athena-adds-support-for-querying-data-using-logstash-grok-filters/
  17. 17. データ設計に影響する Athena の特性 • OLTP* ではなく OLAP** 向け – そもそもトランザクションは未サポート • ETL ではなく 分析向け – データをフルスキャン & 変換するのは高コストな設計 – リトライ機構がないため,安定的なバッチ処理には向かない • いかにして読み込むデータ量を減らすかが重要 – パーティション – 列指向フォーマット – 圧縮 17 * Online Transactional Processing ** Online Analytical Processing
  18. 18. パーティション • S3のオブジェクトキーの構成をテーブルに反映し て,読み込むファイル数を減らす • WHERE で読み込み範囲を絞るときに頻繁に使われ るカラムを,キーに指定する • 絞り込みの効果が高いものが向いている • ログデータの場合,日付が定番 • “year/month/day” と階層で指定する 18 SELECT month , action_category , action_detail , COUNT(user_id) FROM action_log WHERE year = 2016 AND month >= 4 AND month < 7 GROUP BY month , action_category , action_detail 以下のS3パスだけが読み込まれる s3://athena-examples/action-log/year=2016/month=04/day=01/ ... s3://athena-examples/action-log/year=2016/month=07/day=31/
  19. 19. パーティションの分け方 19 タイプ 形式 特徴 カラム名あり (Hive 標準) col1=val1/col2=val2/ • CREATE TABLE をしてから,MSCK REPAIR TABLE を実行すればOK • パーティションが増えた際も,MSCK REPAIR TABLE を1回実行すればOK • この形式にするために前処理が必要 カラム名なし val1/val2/ • MSCK REPAIR TABLE が使えないため,ALTER TABLE ADD PARTITION を,パーティション の数だけ実行する必要がある • 後からパーティションが増えた際も,増えたぶ んだけ ALTER TABLE ADD PARTITION* * あらかじめ先の期間までパーティションを作成しておけば,ファイルを置いた瞬間クエリ可能になる
  20. 20. 列指向フォーマット 指向 特徴 列指向 • カラムごとにデータをまとめて保存 • 特定の列だけを扱う処理では,ファ イル全体を読む必要がない • OLAP向き • ORC, Parquet など 行指向 • レコード単位でデータを保存 • 1カラムのみ必要でも,レコード全 体を読み込む必要がある • OLTP向き • TEXTFILE(CSV, TSV) など 20 ORCのデータ構造 https://orc.apache.org/docs/spec-intro.html
  21. 21. 1 2 3 4 5 6 列指向フォーマット & 圧縮 OLAP 系の分析クエリを効率的に実行できる • たいていの分析クエリは,一度のクエリで一部 のカラムしか使用しない • 単純な統計データなら,メタデータで完結する 21 1 2 3 4 5 6 1 2 3 4 5 6 列指向行指向 I/O の効率があがる • 圧縮と同時に使うことで I/O 効率がさらに向上 • カラムごとに分けられてデータが並んでいる • 同じカラムは,似たような中身のデータが続く ため,圧縮効率がよくなる 1 2 3 4 5 61 2 3 4 5 6 列指向行指向
  22. 22. 列指向フォーマット & 圧縮の使い方 • CREATE 文で指定するだけ • データは事前にフォーマット変換 & 圧縮の必要あり • 分析クエリを投げる際に,使用するカラムだけを読み こむようになる 22 SELECT month , action_category , COUNT(action_category) FROM action_log WHERE year = 2016 AND month >= 4 AND month < 7 GROUP BY month , action_category CREATE EXTERNAL TABLE IF NOT EXISTS action_log ( user_id string, action_category string, action_detail string year int, month int, day int ) PARTITIONED BY (year int, month int, day int) STORED AS PARQUET LOCATION 's3://athena-examples/action-log/’ TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY');
  23. 23. リソースに関するポイント • 1アカウントあたりの最大クエリ同時実行数は5個 • クエリは30分でタイムアウト • 1アカウントあたりの最大データベース数は100個 • 1データベースあたりの最大テーブル数は100個 • 1テーブルあたりの最大パーティション数は20000個 23 Athena のリソース上限は以下のとおり* * 上限緩和申請によって増やすことが可能 http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
  24. 24. 入出力に関するポイント 入力 • どのリージョンの S3 からでもデータの読み込みが可能 • ただしリージョンをまたぐ場合,データ転送時間と,転送料金がかかる • 暗号化データ読み込みに対応 (SSE-S3, SSE-KMS, CSE-KMS) – 出力と独立して指定可能 24 出力 • Athena 実行リージョンの S3 にヘッダ付き csv で出力のみ • 結果ファイルは SSE-S3, SSE-KMS, CSE-KMS の3方式で暗号化して出力可能 • INSERT SELECTには未対応
  25. 25. 料金体系 • クエリ単位の従量課金 • S3 のデータスキャンに対して,$5 / 1TB の料金 • バイト数はメガバイト単位で切り上げられ,10MB 未満のク エリは 10MB と計算される • スキャンデータ量は,圧縮状態のデータサイズで計算される • 別リージョンからデータを読み込む場合には,別途S3 のデータ転送料金がかかる • DDL のクエリや,実行に失敗したクエリの料金は無料 • パーティション,列指向フォーマット,圧縮を活用する ことで,スキャンするデータ量を減らして,コスト削減 が可能
  26. 26. パフォーマンスガイド & Tips 26
  27. 27. Amazon Athena の パフォーマンスチューニング Tips トップ 10 ストレージのベストプラクティス 1. データをパーティションに分 ける 2. ファイルを圧縮・分割する 3. ファイルサイズを最適化する 4. 列指向データの作成を最適化 する クエリのベストプラクティス 5. ORDER BY を最適化する 6. JOIN を最適化する 7. GROUP BY を最適化する 8. LIKE 演算子を最適化する 9. 近似関数を使う 10. 必要なカラムだけを読み込む 27 https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/
  28. 28. データをパーティションに分ける • WHERE 句で頻繁に使われるカラムをパーティションキーに選ぶ • ログ等の場合は,日付が第一候補 • テーブル内のパーティション数が増えすぎると,メタデータ取得・処理の オーバーヘッドが増える • データが特定パーティションに偏っている場合は,パフォーマンス状の恩 恵を受けづらい クエリ パーティション分け されていないテーブル パーティション分け されたテーブル 実行時間 スキャン量 実行時間 スキャン量 SELECT COUNT(*) FROM lineitem WHERE l_shipdate = ‘1996-’09-01’; 9.71s 74.1GB 2.16s 29.06MB
  29. 29. データをパーティションに分ける • WHERE 句で頻繁に使われるカラムをパーティションキーに選ぶ • ログ等の場合は,日付が第一候補 • テーブル内のパーティション数が増えすぎると,メタデータ取得・処理の オーバーヘッドが増える • データが特定パーティションに偏っている場合は,パフォーマンス状の恩 恵を受けづらい クエリ パーティション分け されていないテーブル パーティション分け されたテーブル 実行時間 スキャン量 実行時間 スキャン量 SELECT COUNT(*) FROM lineitem WHERE l_shipdate = ‘1996-’09-01’; 9.71s 74.1GB 2.16s 29.06MB SELECT count(*) FROM lineitem; 8.4s 74.1GB 10.65s 74.1GB
  30. 30. ファイルサイズを最適化する • パフォーマンスを最適化する際には,CSV のような分割できないフォー マットを避ける • Parquet / ORC のような分割可能なファイルフォーマットを用いることで, ファイルの大きさに関わらず並列処理が行われる • 読み込みにまつわるオーバヘッドが増大しないように,ファイルサイズは 128MB 以上にまとめるのを推奨 • 以下は 7GB のデータを単一ファイルにした場合と,5000 個に分割(1個 あたり 1.4MB)した場合の比較 30 クエリ ファイル数 実行時間 SELECT count(*) FROM lineitem; 5000 8.40s 1 2.31s
  31. 31. JOIN を最適化する 31 JOIN は大きなテーブルを左側に持ってくるほうがよい 右側のテーブルを各ノードに Broadcast して JOIN するため Presto には Cost-based optimizer がないため,自動で最適化されない 以下の例では,lineitem テーブル=7GB, part テーブル=67GB クエリ 実行時間 SELECT count(*) FROM lineitem, part WHERE lineitem.l_partkey = part.p_partkey 22.81s SELECT count(*) FROM part, lineitem WHERE lineitem.l_partkey = part.p_partkey 10.71s
  32. 32. ORDER BY を最適化する 32 集計クエリで ORDER BY を行う場合,実際にはトップ100件くらいまでしか確認し ないようなケースが多い ORDER BY を行う際には,データを単一ノードに集約してソートするため,基本的に 計算を並列化できない そのため,LIMIT 100 をつけてあげることで,ソート処理を高速に行うことができる SELECT * FROM lineitem ORDER BY l_shipdate SELECT * FROM lineitem ORDER BY l_shipdate LIMIT 100
  33. 33. GROUP BY を最適化する 33 GROUP BY に複数のカラムを指定する場合には,カーディナリティが高 い順番に並べるほうがよい 前に並んだカラムの値に応じて,各ノードにデータを割り振るため, カーディナリティが低いデータだと,処理が十分に並列化されない FROM action_log GROUP BY low_card_col , high_card_col FROM action_log GROUP BY high_card_col , low_card_col
  34. 34. LIKE 演算子を最適化する 34 LIKE 演算子で多数の比較を行う場合には,RegEx で一括処理をしたほ うが効率がよい それぞれの LIKE 演算子について捜査が走るため,数が増えるほど,ま た文字列が長くなるほど,処理が重くなる WHERE comment LIKE ‘%wake%’ , comment LIKE ‘%regular%’ , comment LIKE ‘%expres%’ , comment LIKE ‘%sleep%’ , comment LIKE ‘%hello%’ WHERE regexp_like(comment, 'wake|regular|express|sleep|hello')
  35. 35. 近似関数を使う 35 COUNT DISTINCT でユニーク数を求める際に,正確性より計算速度の ほうが大事なときは,approx_distinct() で求めた近似値を使うとよい approx_distinct() は HyperLogLog で近似値を求めているため,実際の ユニーク数が多い場合でも高速に動作する SELECT COUNT(DISTINCT user_id) SELECT approx_distinct(user_id) https://github.com/prestodb/presto/blob/master/presto-main/src/main/java/com/facebook/presto/operator/aggregation/ApproximateCountDistinctAggregations.java https://github.com/airlift/airlift/blob/master/stats/src/main/java/io/airlift/stats/cardinality/HyperLogLog.java https://github.com/airlift/airlift/blob/master/stats/docs/hll.md
  36. 36. Tips • クエリ結果のデータが含まれるオブジェクト キー名を取得 • 別ユーザの S3 バケットに対して Athena でク エリを実行 • CTAS (CREATE TABLE AS SELECT) 的な運用 を擬似的に実現 36
  37. 37. クエリ結果のデータが含まれるオブジェクトキー名を取得 • SELECT の際に “$PATH” を指定することで,オブジェクト キー名を得ることができる • 問題のあるオブジェクトを Athena クエリで特定して,実際 にオブジェクトファイルにアクセスしたい場合に有用 37 https://github.com/prestodb/presto/issues/5486 > SELECT "$PATH" FROM mytable LIMIT 1; s3://example-backet/mytable/2015/01/04/part-r-00023-ce65fca5-d6c6.txt
  38. 38. 別ユーザの S3 バケットに対し Athena でクエリを実行 ケース 1: 別のユーザの Athena を利用 • アカウント A が,自身の Athena / S3 に関する権限を IAM ポリシーに設定して,適当なロールに設定 • アカウント B に対して,作成したロールへのアクセス を許可 ケース 2: 別のユーザの S3 バケットに対してクエリ • アカウント A の S3 バケットに対して,アカウント B からのアクセスを許可するアクセスポリシーを設定する 38
  39. 39. CTAS を擬似的に実現 • Athena は現在 CTAS をサポートしていない • クエリの出力結果は,s3_staging_dir で指定したディレクトリに 出力される • 出力ディレクトリを指定したテーブルを作成しておき,それに対し てクエリを投げることで,擬似的に CTAS を実現 39 CREATE EXTERNAL TABLE IF NOT EXISTS yourTableName ( col_name data_type ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 's3://path/to/results/' https://aws.amazon.com/jp/premiumsupport/knowledge-center/athena-query-results/
  40. 40. Athena & Glue によるデータ分析の広がり 40
  41. 41. Amazon S3 Data Lake Amazon Kinesis Streams & Firehose Hadoop / Spark Amazon Redshift Data Warehouse Amazon DynamoDB & ElastiCache NoSQL DB & Redis Relational Database Amazon EMR Amazon Aurora Amazon Machine Learning Machine Learning Any Open Source Tool of Choice on EC2 DataSources Amazon S3 を中心としたデータレイク Clusterless SQL Query Amazon Athena TransactionalData
  42. 42. Amazon S3 Data Lake Amazon Kinesis Streams & Firehose Hadoop / Spark Amazon Redshift Data Warehouse Amazon DynamoDB & ElastiCache NoSQL DB & Redis Relational Database Amazon EMR Amazon Aurora Amazon Machine Learning Machine Learning Any Open Source Tool of Choice on EC2 DataSources Amazon S3を中心としたデータレイク Clusterless SQL Query Amazon Athena TransactionalData すべてのデータを1ヶ所に集めて保存 データストアとデータ処理の分離 用途に応じた適切な処理方法の選択
  43. 43. AWS の分析サービス 43 Amazon EMR, AWS GlueETL Amazon Redshiftデータウェアハウス アドホッククエリ Amazon QuickSightBI / 可視化 Amazon EMR, Amazon EC2, AWS Batch機械学習
  44. 44. AWS の分析サービス 44 Amazon EMR, AWS GlueETL Amazon Redshiftデータウェアハウス Amazon Athenaアドホッククエリ Amazon QuickSightBI / 可視化 Amazon EMR, Amazon EC2, AWS Batch機械学習
  45. 45. AWS の分析サービス 45 Amazon EMR, AWS GlueETL Amazon Redshiftデータウェアハウス Amazon Athenaアドホッククエリ Amazon QuickSightBI / 可視化 Amazon EMR, Amazon EC2, AWS Batch機械学習
  46. 46. 2017/8/14 に GA になった AWS上の ETL サービス 巨大データへのETL処理を スケールアウトで対応 サーバレスで提供 AWS Glue https://aws.amazon.com/jp/glue/
  47. 47. Glue の全体像 • データソースをクロールし,メタデータを取得し,データカタログで管理 • メタデータをもとに PySpark のジョブを作成し,サーバレスな環境で実行 47
  48. 48. Glue ベースの S3 データレイク • 各種データソースに対して Glue ジョブで ETL を実施 • 結果を Redshift に格納して分析 48
  49. 49. Glue ベースの S3 データレイク • S3 上のデータを Glue クローラー経由でデータカタログに登録しておく • 用途に応じて Athena, EMR, Redshift Spectrum から分析 49
  50. 50. Glue で低レイテンシの Parquet 変換 ETL を実施 • CSV/TSV/JSON 等のログファイルを Parquet に変換するた めに,従来は EMR などを用いる必要があった • Glue なら GUI 操作のみでも Parquet 変換ジョブを作成可 能 • S3 ファイル追加キックで Lambda を起動して Glue ジョブ を実行すれば,低レイテンシの変換処理が可能に 50 S3Data Source Lambda Glue S3 Athena
  51. 51. Glue でパーティションの自動アップデート • 従来は,新しく追加された Athena テーブルのパーティションを認 識するために,MSCK REPAIR TABLE / ALTER TABLE ADD PARTITION コマンドを実行する必要があった • Glue クローラーをスケジュール or Lambda 経由で実行すること で,常に最新のパーティション状態を認識させることが可能に – 5 分間隔でスケジュール実行可能 51
  52. 52. Kinesis Firehose 経由で取得したログに対して ニアリアルタイムでクエリ • Kinesis Firehose が 2017/8/24 に東京リージョンで利用可能に • Kinesis Firehose はデフォルトで year/month/day/hour と いう S3 キーの形で保存され,Glue クローラーなら自動で JSON フォーマットおよびパーティションを認識してくれる • ログが置かれたら,すぐに分析クエリを投げることができる 52
  53. 53. Athena が向いていない処理 • リトライ機構がなく,データを絞って高速にスキャンする アーキテクチャのため,バッチ処理には向かない • 分析処理でも,大量データを長時間処理するのには向かない 53 ユースケース 適したサービス 大規模なデータに対して,フルスキャンを定期的に行う処理 EMR テンポラリテーブルを活用した多段のETL処理 EMR, Glue サブクエリやJOINを駆使した複雑な集計処理 Redshift 高頻度なレポーティングのための大量の分析処理 Redshift
  54. 54. Amazon Athena では対応できないこと • ピークタイミングのノード数追加 • Presto のパラメタ設定 • 実行する Presto のバージョンを正確に指定 • 利用料金の固定 54 Athena はサーバーレスのクエリサービスであり 利用者側で制御できない部分が存在する
  55. 55. Presto on EMR という選択肢 • EMR クラスタを立てて,その上で Presto を動かす • クラスタの構築・運用コストを下げながら,詳細な チューニングを行うことが可能 • インスタンスフリートやスポットブロックを活用す ることで,利用時のコストを削減することも可能 55 + https://aws.amazon.com/jp/blogs/news/new-amazon-emr-instance-fleets/ https://aws.amazon.com/jp/about-aws/whats-new/2017/03/amazon-emr-announces-instance-fleets-for-amazon-ec2-spot-instances-and-spot-blocks/
  56. 56. Redshift + Spectrum という選択肢 • ホットデータに対する高頻 度の重たいワークロードが 主体の場合には,Redshift を使う方が適切 • その上で Spectrum を使っ て,大量のコールドデータ に対するアクセシビリティ を確保 • Spectrum は,Redshift か ら S3 上のデータを直接読 みこむ機能を持つ 56 Amazon Redshift JDBC/ODBC ... 1 2 3 4 N Amazon S3 Exabyte-scale object storage Spectrum Layer
  57. 57. JDBC ドライバーによる BI ツールからのアクセス • JDBC 対応のさまざまな BI ツールから接続することが可能 • Tableau は 2017/6/5 リリースの 10.3 で Athena コネクタをサポート • Redash もデータソースとして Athena をサポート • もちろん,Amazon QuickSight も Athena をデータソースに指定可能 57 https://www.tableau.com/about/blog/2017/5/connect-your-s3-data-amazon-athena-connector-tableau-103-71105 https://redash.io/help/data-sources/amazon-athena.html
  58. 58. API 経由での既存アプリケーションとの連携 • クエリ実行とネームドクエリの 2 つのカテゴリ • AWS SDK 経由で Python / PHP / Ruby /Java などから接続でき, 内製アプリケーションと連携可能 • テーブル情報の取得やテーブル操 作は,Glue API 経由でも実行す ることができる • AWS CLI からもアクセス 58 Category API Query Execution BatchGetQueryExecution GetQueryExecution GetQueryResults ListQueryExecutions StartQueryExecution StopQueryExecution Named Query BatchGetNamedQuery CreateNamedQuery DeleteNamedQuery GetListNamedQuery ListNamedQueries http://docs.aws.amazon.com/athena/latest/APIReference/Welcome.html
  59. 59. まとめ 59
  60. 60. まとめ • Athena は S3 上のデータに対する,Presto ベースのインタ ラクティブなクエリサービス • ベストプラクティスに沿った使い方をすることで,非常に高 いパフォーマンスを得ることができる • 昨年末のリリース以降,さまざまな機能追加や性能改善を行 なっている • Athena と他のサービスを組み合わせることで,さまざまな 形で分析を行うことができる 60
  61. 61. 61

    Be the first to comment

    Login to see the comments

  • yoheiazekatsu

    Sep. 10, 2017
  • mazgi

    Sep. 20, 2017
  • ssuser14ba1a

    Dec. 9, 2017
  • akuwano

    Dec. 12, 2017
  • sintan23

    Dec. 21, 2017
  • chinmored

    Dec. 26, 2017
  • maogawa

    Jan. 9, 2018
  • takehikokuribayashi

    Mar. 19, 2018
  • hkude

    Mar. 22, 2018
  • sakurait

    Mar. 22, 2018
  • torukimurat

    Apr. 3, 2018
  • noazyunynaka

    May. 18, 2018
  • yoheishinozaki35

    May. 30, 2018
  • TakaoSuzuki1

    Aug. 28, 2018
  • ShogoTasai

    Sep. 23, 2018
  • ShuHungLiu

    Mar. 28, 2019
  • bcjn

    Feb. 25, 2020
  • zuccini

    Sep. 9, 2020
  • garafu

    Nov. 8, 2020
  • ookanekenzo

    Feb. 7, 2021

2017/9-5-7 に開催された db tech showcase の発表スライドです. http://www.db-tech-showcase.com/dbts/tokyo

Views

Total views

11,040

On Slideshare

0

From embeds

0

Number of embeds

721

Actions

Downloads

0

Shares

0

Comments

0

Likes

21

×