Movatterモバイル変換

自己紹介2所属:アマゾンウェブサービスジャパン株式会社業務:ソリューションアーキテクト(データサイエンス領域)経歴:Hadoopログ解析基盤の開発データ分析データマネジメントや組織のデータ活用志村誠 (Makoto Shimura)

Agenda• Amazon Athena 概要• クイックスタート• Amazon Athena の構成• Update• パフォーマンスガイド & Tips• Athena & Glue によるデータ分析の広がり

Amazon Athena とはS3上のデータに対して，標準 SQL によるインタラクティブなクエリを投げてデータの分析を行うことができるサービス5

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/

データ分析基盤の進化の流れData warehouseappliances1985 2006Hadoopclusters2009Decoupled EMRclusters2012Cloud DWHRedshiftTodayClusterlessAthena Glue

Athena の特徴8サーバレスでインフラ管理の必要なし大規模データに対しても高速なクエリ事前のデータロードなしにS3に直接クエリスキャンしたデータに対しての従量課金JDBC経由でBIツールから直接クエリ

マネジメントコンソールから簡単にアクセス• 利用開始から数分でクエリを投げられる• クエリごとのスキャンデータ量を確認可能• Glue データカタログでテーブルスキーマやパーティションを確認

Athena の想定ユースケース10ユースケースデータユーザ新しく取得したデータに対して，DWに入れる価値があるか探索的に検証新しく取得したデータアナリスト利用頻度の低い過去のデータに対する，BIツール経由のアドホックな分析コールドデータアナリストWebサーバで障害が発生したときに，ログを検索して原因追求アクセスログサーバ運用大規模でないデータに対しての，低頻度で実施するETL処理生データ開発者

Presto : 高速な分散クエリエンジン• Athenaで使用しているクエリエンジン• データをディスクに書き出さず，すべてメモリ上で処理• ノード故障やメモリ溢れの場合にはクエリ自体が失敗• バッチ処理ではなく，インタラクティブクエリ向け12 https://prestodb.io/overview.html参考: Presto のアーキテクチャ

データカタログ: Hive メタストア• Athena のデータカタログと互換性がある• Hive は SQL ライクな記法で，Hadoop上のバッチ処理を記述可能• データソースに対してスキーマを定義し，テーブルのように扱える• HDFS上のデータをベースとしており，標準 SQL とは異なる DDL を持つ13 https://prestodb.io/overview.html参考: Presto のアーキテクチャ

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

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/

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/

データ設計に影響する Athena の特性• OLTP* ではなく OLAP** 向け– そもそもトランザクションは未サポート• ETL ではなく分析向け– データをフルスキャン & 変換するのは高コストな設計– リトライ機構がないため，安定的なバッチ処理には向かない• いかにして読み込むデータ量を減らすかが重要– パーティション– 列指向フォーマット– 圧縮17 * Online Transactional Processing ** Online Analytical Processing

パーティション• S3のオブジェクトキーの構成をテーブルに反映して，読み込むファイル数を減らす• WHERE で読み込み範囲を絞るときに頻繁に使われるカラムを，キーに指定する• 絞り込みの効果が高いものが向いている• ログデータの場合，日付が定番• “year/month/day” と階層で指定する18SELECTmonth, action_category, action_detail, COUNT(user_id)FROMaction_logWHEREyear = 2016AND month >= 4AND month < 7GROUP BYmonth, 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タイプ形式特徴カラム名あり(Hive 標準) col1=val1/col2=val2/• CREATE TABLE をしてから，MSCK REPAIRTABLE を実行すればOK• パーティションが増えた際も，MSCK REPAIRTABLE を1回実行すればOK• この形式にするために前処理が必要カラム名なし val1/val2/• MSCK REPAIR TABLE が使えないため，ALTERTABLE ADD PARTITION を，パーティションの数だけ実行する必要がある• 後からパーティションが増えた際も，増えたぶんだけ ALTER TABLE ADD PARTITION** あらかじめ先の期間までパーティションを作成しておけば，ファイルを置いた瞬間クエリ可能になる

列指向フォーマット指向特徴列指向• カラムごとにデータをまとめて保存• 特定の列だけを扱う処理では，ファイル全体を読む必要がない• OLAP向き• ORC, Parquet など行指向• レコード単位でデータを保存• 1カラムのみ必要でも，レコード全体を読み込む必要がある• OLTP向き• TEXTFILE(CSV, TSV) など20ORCのデータ構造https://orc.apache.org/docs/spec-intro.html

1 2 3 4 5 6列指向フォーマット & 圧縮OLAP 系の分析クエリを効率的に実行できる• たいていの分析クエリは，一度のクエリで一部のカラムしか使用しない• 単純な統計データなら，メタデータで完結する211 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列指向行指向

列指向フォーマット & 圧縮の使い方• CREATE 文で指定するだけ• データは事前にフォーマット変換 & 圧縮の必要あり• 分析クエリを投げる際に，使用するカラムだけを読みこむようになる22SELECTmonth, action_category, COUNT(action_category)FROMaction_logWHEREyear = 2016AND month >= 4AND month < 7GROUP BYmonth, action_categoryCREATE EXTERNAL TABLE IF NOT EXISTS action_log (user_id string,action_category string,action_detail stringyear int,month int,day int)PARTITIONED BY (year int, month int, day int)STORED AS PARQUETLOCATION 's3://athena-examples/action-log/’TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY');

リソースに関するポイント• 1アカウントあたりの最大クエリ同時実行数は5個• クエリは30分でタイムアウト• 1アカウントあたりの最大データベース数は100個• 1データベースあたりの最大テーブル数は100個• 1テーブルあたりの最大パーティション数は20000個23Athena のリソース上限は以下のとおり** 上限緩和申請によって増やすことが可能http://docs.aws.amazon.com/athena/latest/ug/service-limits.html

入出力に関するポイント入力• どのリージョンの S3 からでもデータの読み込みが可能• ただしリージョンをまたぐ場合，データ転送時間と，転送料金がかかる• 暗号化データ読み込みに対応 (SSE-S3, SSE-KMS, CSE-KMS)– 出力と独立して指定可能24出力• Athena 実行リージョンの S3 にヘッダ付き csv で出力のみ• 結果ファイルは SSE-S3, SSE-KMS, CSE-KMS の3方式で暗号化して出力可能• INSERT SELECTには未対応

料金体系• クエリ単位の従量課金• S3 のデータスキャンに対して，$5 / 1TB の料金• バイト数はメガバイト単位で切り上げられ，10MB 未満のクエリは 10MB と計算される• スキャンデータ量は，圧縮状態のデータサイズで計算される• 別リージョンからデータを読み込む場合には，別途S3のデータ転送料金がかかる• DDL のクエリや，実行に失敗したクエリの料金は無料• パーティション，列指向フォーマット，圧縮を活用することで，スキャンするデータ量を減らして，コスト削減が可能

パフォーマンスガイド & Tips26

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/

データをパーティションに分ける• WHERE 句で頻繁に使われるカラムをパーティションキーに選ぶ• ログ等の場合は，日付が第一候補• テーブル内のパーティション数が増えすぎると，メタデータ取得・処理のオーバーヘッドが増える• データが特定パーティションに偏っている場合は，パフォーマンス状の恩恵を受けづらいクエリパーティション分けされていないテーブルパーティション分けされたテーブル実行時間スキャン量実行時間スキャン量SELECT COUNT(*) FROM lineitemWHERE l_shipdate = ‘1996-’09-01’; 9.71s 74.1GB 2.16s 29.06MB

データをパーティションに分ける• WHERE 句で頻繁に使われるカラムをパーティションキーに選ぶ• ログ等の場合は，日付が第一候補• テーブル内のパーティション数が増えすぎると，メタデータ取得・処理のオーバーヘッドが増える• データが特定パーティションに偏っている場合は，パフォーマンス状の恩恵を受けづらいクエリパーティション分けされていないテーブルパーティション分けされたテーブル実行時間スキャン量実行時間スキャン量SELECT COUNT(*) FROM lineitemWHERE l_shipdate = ‘1996-’09-01’; 9.71s 74.1GB 2.16s 29.06MBSELECT count(*) FROM lineitem; 8.4s 74.1GB 10.65s 74.1GB

ファイルサイズを最適化する• パフォーマンスを最適化する際には，CSV のような分割できないフォーマットを避ける• Parquet / ORC のような分割可能なファイルフォーマットを用いることで，ファイルの大きさに関わらず並列処理が行われる• 読み込みにまつわるオーバヘッドが増大しないように，ファイルサイズは128MB 以上にまとめるのを推奨• 以下は 7GB のデータを単一ファイルにした場合と，5000 個に分割（1個あたり 1.4MB）した場合の比較30クエリファイル数実行時間SELECT count(*) FROM lineitem;5000 8.40s1 2.31s

JOIN を最適化する31JOIN は大きなテーブルを左側に持ってくるほうがよい右側のテーブルを各ノードに Broadcast して JOIN するためPresto には Cost-based optimizer がないため，自動で最適化されない以下の例では，lineitem テーブル=7GB, part テーブル=67GBクエリ実行時間SELECT count(*) FROM lineitem, partWHERE lineitem.l_partkey = part.p_partkey22.81sSELECT count(*) FROM part, lineitemWHERE lineitem.l_partkey = part.p_partkey10.71s

ORDER BY を最適化する32集計クエリで ORDER BY を行う場合，実際にはトップ100件くらいまでしか確認しないようなケースが多いORDER BY を行う際には，データを単一ノードに集約してソートするため，基本的に計算を並列化できないそのため，LIMIT 100 をつけてあげることで，ソート処理を高速に行うことができるSELECT*FROMlineitemORDER BYl_shipdateSELECT*FROMlineitemORDER BYl_shipdateLIMIT100

GROUP BY を最適化する33GROUP BY に複数のカラムを指定する場合には，カーディナリティが高い順番に並べるほうがよい前に並んだカラムの値に応じて，各ノードにデータを割り振るため，カーディナリティが低いデータだと，処理が十分に並列化されないFROMaction_logGROUP BYlow_card_col, high_card_colFROMaction_logGROUP BYhigh_card_col, low_card_col

LIKE 演算子を最適化する34LIKE 演算子で多数の比較を行う場合には，RegEx で一括処理をしたほうが効率がよいそれぞれの LIKE 演算子について捜査が走るため，数が増えるほど，また文字列が長くなるほど，処理が重くなるWHEREcomment LIKE ‘%wake%’, comment LIKE ‘%regular%’, comment LIKE ‘%expres%’, comment LIKE ‘%sleep%’, comment LIKE ‘%hello%’WHEREregexp_like(comment, 'wake|regular|express|sleep|hello')

近似関数を使う35COUNT DISTINCT でユニーク数を求める際に，正確性より計算速度のほうが大事なときは，approx_distinct() で求めた近似値を使うとよいapprox_distinct() は HyperLogLog で近似値を求めているため，実際のユニーク数が多い場合でも高速に動作するSELECTCOUNT(DISTINCT user_id)SELECTapprox_distinct(user_id)https://github.com/prestodb/presto/blob/master/presto-main/src/main/java/com/facebook/presto/operator/aggregation/ApproximateCountDistinctAggregations.javahttps://github.com/airlift/airlift/blob/master/stats/src/main/java/io/airlift/stats/cardinality/HyperLogLog.javahttps://github.com/airlift/airlift/blob/master/stats/docs/hll.md

Tips• クエリ結果のデータが含まれるオブジェクトキー名を取得• 別ユーザの S3 バケットに対して Athena でクエリを実行• CTAS (CREATE TABLE AS SELECT) 的な運用を擬似的に実現36

クエリ結果のデータが含まれるオブジェクトキー名を取得• 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

別ユーザの S3 バケットに対し Athena でクエリを実行ケース 1: 別のユーザの Athena を利用• アカウント A が，自身の Athena / S3 に関する権限をIAM ポリシーに設定して，適当なロールに設定• アカウント B に対して，作成したロールへのアクセスを許可ケース 2: 別のユーザの S3 バケットに対してクエリ• アカウント A の S3 バケットに対して，アカウント Bからのアクセスを許可するアクセスポリシーを設定する38

CTAS を擬似的に実現• Athena は現在 CTAS をサポートしていない• クエリの出力結果は，s3_staging_dir で指定したディレクトリに出力される• 出力ディレクトリを指定したテーブルを作成しておき，それに対してクエリを投げることで，擬似的に CTAS を実現39CREATE EXTERNAL TABLE IF NOT EXISTS yourTableName (col_name data_type)ROW FORMAT DELIMITEDFIELDS TERMINATED BY ','LOCATION 's3://path/to/results/'https://aws.amazon.com/jp/premiumsupport/knowledge-center/athena-query-results/

Athena & Glue によるデータ分析の広がり40

Amazon S3Data LakeAmazon KinesisStreams & FirehoseHadoop / SparkAmazon RedshiftData WarehouseAmazon DynamoDB & ElastiCacheNoSQL DB & RedisRelational DatabaseAmazon EMRAmazon AuroraAmazon Machine LearningMachine LearningAny Open Source Toolof Choice on EC2DataSourcesAmazon S3 を中心としたデータレイクClusterless SQL QueryAmazon AthenaTransactionalData

Amazon S3Data LakeAmazon KinesisStreams & FirehoseHadoop / SparkAmazon RedshiftData WarehouseAmazon DynamoDB & ElastiCacheNoSQL DB & RedisRelational DatabaseAmazon EMRAmazon AuroraAmazon Machine LearningMachine LearningAny Open Source Toolof Choice on EC2DataSourcesAmazon S3を中心としたデータレイクClusterless SQL QueryAmazon AthenaTransactionalDataすべてのデータを1ヶ所に集めて保存データストアとデータ処理の分離用途に応じた適切な処理方法の選択

AWS の分析サービス43Amazon EMR, AWS GlueETLAmazon RedshiftデータウェアハウスアドホッククエリAmazon QuickSightBI / 可視化Amazon EMR, Amazon EC2, AWS Batch機械学習

AWS の分析サービス44Amazon EMR, AWS GlueETLAmazon RedshiftデータウェアハウスAmazon AthenaアドホッククエリAmazon QuickSightBI / 可視化Amazon EMR, Amazon EC2, AWS Batch機械学習

AWS の分析サービス45Amazon EMR, AWS GlueETLAmazon RedshiftデータウェアハウスAmazon AthenaアドホッククエリAmazon QuickSightBI / 可視化Amazon EMR, Amazon EC2, AWS Batch機械学習

2017/8/14 に GA になった AWS上の ETL サービス巨大データへのETL処理をスケールアウトで対応サーバレスで提供AWS Gluehttps://aws.amazon.com/jp/glue/

Glue の全体像• データソースをクロールし，メタデータを取得し，データカタログで管理• メタデータをもとに PySpark のジョブを作成し，サーバレスな環境で実行47

Glue ベースの S3 データレイク• 各種データソースに対して Glue ジョブで ETL を実施• 結果を Redshift に格納して分析48

Glue ベースの S3 データレイク• S3 上のデータを Glue クローラー経由でデータカタログに登録しておく• 用途に応じて Athena, EMR, Redshift Spectrum から分析49

Glue で低レイテンシの Parquet 変換 ETL を実施• CSV/TSV/JSON 等のログファイルを Parquet に変換するために，従来は EMR などを用いる必要があった• Glue なら GUI 操作のみでも Parquet 変換ジョブを作成可能• S3 ファイル追加キックで Lambda を起動して Glue ジョブを実行すれば，低レイテンシの変換処理が可能に50S3Data Source Lambda Glue S3 Athena

Glue でパーティションの自動アップデート• 従来は，新しく追加された Athena テーブルのパーティションを認識するために，MSCK REPAIR TABLE / ALTER TABLE ADDPARTITION コマンドを実行する必要があった• Glue クローラーをスケジュール or Lambda 経由で実行することで，常に最新のパーティション状態を認識させることが可能に– 5 分間隔でスケジュール実行可能51

Kinesis Firehose 経由で取得したログに対してニアリアルタイムでクエリ• Kinesis Firehose が 2017/8/24 に東京リージョンで利用可能に• Kinesis Firehose はデフォルトで year/month/day/hour という S3 キーの形で保存され，Glue クローラーなら自動で JSONフォーマットおよびパーティションを認識してくれる• ログが置かれたら，すぐに分析クエリを投げることができる52

Athena が向いていない処理• リトライ機構がなく，データを絞って高速にスキャンするアーキテクチャのため，バッチ処理には向かない• 分析処理でも，大量データを長時間処理するのには向かない53ユースケース適したサービス大規模なデータに対して，フルスキャンを定期的に行う処理 EMRテンポラリテーブルを活用した多段のETL処理 EMR, GlueサブクエリやJOINを駆使した複雑な集計処理 Redshift高頻度なレポーティングのための大量の分析処理 Redshift

Amazon Athena では対応できないこと• ピークタイミングのノード数追加• Presto のパラメタ設定• 実行する Presto のバージョンを正確に指定• 利用料金の固定54Athena はサーバーレスのクエリサービスであり利用者側で制御できない部分が存在する

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/

Redshift + Spectrum という選択肢• ホットデータに対する高頻度の重たいワークロードが主体の場合には，Redshiftを使う方が適切• その上で Spectrum を使って，大量のコールドデータに対するアクセシビリティを確保• Spectrum は，Redshift から S3 上のデータを直接読みこむ機能を持つ56AmazonRedshiftJDBC/ODBC...1 2 3 4 NAmazon S3Exabyte-scale object storageSpectrumLayer

JDBC ドライバーによる BI ツールからのアクセス• JDBC 対応のさまざまな BI ツールから接続することが可能• Tableau は 2017/6/5 リリースの 10.3 で Athena コネクタをサポート• Redash もデータソースとして Athena をサポート• もちろん，Amazon QuickSight も Athena をデータソースに指定可能57https://www.tableau.com/about/blog/2017/5/connect-your-s3-data-amazon-athena-connector-tableau-103-71105https://redash.io/help/data-sources/amazon-athena.html

API 経由での既存アプリケーションとの連携• クエリ実行とネームドクエリの 2つのカテゴリ• AWS SDK 経由で Python / PHP/ Ruby /Java などから接続でき，内製アプリケーションと連携可能• テーブル情報の取得やテーブル操作は，Glue API 経由でも実行することができる• AWS CLI からもアクセス58Category APIQueryExecutionBatchGetQueryExecutionGetQueryExecutionGetQueryResultsListQueryExecutionsStartQueryExecutionStopQueryExecutionNamedQueryBatchGetNamedQueryCreateNamedQueryDeleteNamedQueryGetListNamedQueryListNamedQuerieshttp://docs.aws.amazon.com/athena/latest/APIReference/Welcome.html

まとめ• Athena は S3 上のデータに対する，Presto ベースのインタラクティブなクエリサービス• ベストプラクティスに沿った使い方をすることで，非常に高いパフォーマンスを得ることができる• 昨年末のリリース以降，さまざまな機能追加や性能改善を行なっている• Athena と他のサービスを組み合わせることで，さまざまな形で分析を行うことができる60

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

Viewers also liked

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

More from Amazon Web Services Japan

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

Editor's Notes

Movatterモバイル変換

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

Recommended

More Related Content

What's hot

Viewers also liked

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

More from Amazon Web Services Japan

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

Editor's Notes

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

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

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