« AWS Black Belt Online Seminar「IoT向け最新アーキテクチャパターン」の資料およびQA公開 | メイン | 【開催報告】AWS re:Invent 2016 Security Follow Up セミナー »

AWS Black Belt Online Seminar「Amazon Athena」の資料およびQA公開

こんにちは、ソリューションアーキテクト 焼尾です。

2017/3/1 に開催いたしました AWS Black Belt Online Seminar「Amazon Athena」の資料を公開しました。当日ご参加頂いた皆様からのご質問の回答とあわせて紹介させて頂きます。 

 

 
【Q&A】
Q1. 最大クエリ容量は、S3の容量要件に準拠されるのでしょうか?
 
A1. そう考えていただいて問題はないですが,より現実的な制約として,実行に30分以上かかるクエリはエラーとなりますので,実質的にはこちらが最大クエリ容量に影響するとお考えいただければと思います.なお,クエリの実行時間上限は,緩和申請を行うことが可能です.
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
 
Q2. (S3に用意する)フォルダは、必須でしょうか?
A2. S3はオブジェクトストレージであるため,フォルダという概念は存在しません.DDL で指定する場合には,一般的なファイルシステムにおけるフォルダまでのパスの形(最後が"/"で終わる形)で,S3のロケーションを指定する形となります.それ以外の形式だと,エラーになります.
 
Q3. ログ解析の用途になるかと存じますが、複数のファイルを1テーブルとして取り扱い、クエリを発行することは可能でしょうか?また、CSVだけでなく、固定長テキストや、tsvなどを解析することは可能でしょうか?
A3. DDLで指定したS3のロケーションに前方一致する全てのオブジェクトが,テーブルに含まれる形となります.そのテーブルに対して,特に範囲を制限せずクエリを投げることで,それらオブジェクトはすべてスキャンされます.TSVは読み込み可能です.また固定長テキストは,正規表現を扱うSerDeを使うことで,読み込み可能となります.

Q4. QuickSightの説明でAthenaはSPICEに対応していないとの事でしたが、画面上はSPICEを選択できたと記憶しています。SPICEを選択してもインポートされないという事でしょうか?
A4. ドキュメントでは,SPICEに対応していないという記述となっておりますが,実際の挙動としてはSPICEにインポートすることが可能となっております.
 
Q5. union型はどのような型になりますでしょうか?
A5. Hive JSON SerDe のドキュメントをご参照ください.
https://github.com/rcongiu/Hive-JSON-Serde#uniontype-support-please-read-if-you-use-it
 
Q6. では、ETLはどのように行うのがオススメですか?
A6. ETLのワークロードによるので一概にはいえませんが,例えば大量のデータに対して,全データを舐めて加工整形をする場合には,EMRにてHiveやSparkを使って行っていただくか,Glueをお使いいただくのが良いかと思います.
 
Q7. アプリケーションから呼び出す方法はありますでしょうか?
A7. JDBC経由での呼び出しとなりますので,Javaアプリケーションから呼び出すことが可能です.それ以外の言語のアプリケーションの場合には,AthenaにアクセスするためにJavaでAPIを作っていただき,それ経由で呼び出しを行う形となります.
 
Q8. Amazon Kinesis Firehose を利用してCloudWatch LogsをS3に転送してそれをAthena で分析したいのですが、Kinesis Firehoseを通すと{json}{json}のように1行に複数のJSONオブジェクトが保存されるようです。このデータを効率的にAthenaで分析するにはどういった方法がありますか??
A8. Amazon Kinesis FirehoseにはData TransformationをAWS Lambdaで行う機能がございますので,こちらを使って所望の形式に変換すると良いです.
http://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html
Amazon CloudWatch Logsからのサブスクリプションであれば、Lambda functionに渡ってくる各レコードを、Base64デコード=>gunzip=>logEventsを取り出す=>中のmessageに改行文字を追加して結合=>Base64エンコードして返り値として渡せば、FirehoseがAmazon S3にmessageを改行付きで配置してくれるので、スキーマを定義してAthenaからクエリ可能です.
 
Q9. 向いていない処理に高頻度な分析ありますが、どれくらいの頻度のことを示しているのでしょうか?
A9. Athenaの同時クエリ実行数は5という制約がありますので,それ以上の頻度でクエリが投げられる場合には向いていないといえます.
こちらも上限緩和申請をいただくことが可能です.
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
 
Q10. 向かない処理の中で、大量データを長時間処理するのには向かないとあるが、大量データとは具体的なサイズの目安はあるか

A10. クエリ実行時間の上限である,30分以内に終わらないようなデータサイズは向いていないものとなります.ただ具体的なサイズはワークロードによって異なるため,一概にこれということはできません.実際に試していただくことをお勧めします.
こちらも上限緩和申請をいただくことが可能です.
http://docs.aws.amazon.com/athena/latest/ug/service-limits.html
 
Q11. S3のファイルは最適なサイズがございますか?Hadoop/Hiveではワーカーが水平分散できるようにファイルを分割したり、逆にファイルが小さくなりすぎないような考慮が必要ですが、Athenaでも同様に考慮したほうがよろしいでしょうか?それとも、S3は読み込みはチャンクなので1つのファイルでも問題ない等ございますでしょうか?
A11. 最適なファイルサイズを一概に定義することは難しいですが,Hiveと同様に,数百MBなど,ある程度のかたまりでファイルを分割していただくことをお勧めします.最適なファイルサイズについてはクエリによっても異なりますので,実際に検証していただくことをお勧めします.また上記の前処理を行うのと合わせて,列指向フォーマットに変換していただくこともご考慮ください.
 
Q12. JDBCやBIツールからの接続について、接続元の制限方法はどのようにしたらよいでしょうか?
A12. IAMを使用することで,JDBCやBIツールから接続するIAMユーザの接続元IPを制限することが可能です.
 
Q13. S3がServer Side Encryptionの場合特別な対応は必要でしょうか?
A13. 特に対応の必要はなく,そのままクエリを実行することが可能です.
 
Q14. 型に一致しないデータは*として扱われるという理解で良いでしょうか?
A14. 型に一致しないデータが含まれる場合には,クエリがエラーとなります.
 
Q15. Amazon Mobile Analyticsのカスタムイベントが多くある出力データのクエリには適していますか?
A15. Amazon Mobile Analytics のログの場合,JSONの入れ子データとなります.スキーマさえ定義していただければ,問題なくクエリしていただくことが可能です.
入れ子になったJSONデータのスキーマ定義については,以下のブログ記事を参照ください.
https://aws.amazon.com/jp/blogs/big-data/create-tables-in-amazon-athena-from-nested-json-and-mappings-using-jsonserde/
 
Q16. 検索対象のテーブルサイズによって課金?
A16. テーブル全体のデータサイズに関わらず,実際にスキャンしたデータ量に対して課金されます.
 
Q17. CREATE TABLE 後、格納するデータの構造の変更は可能でしょうか?
A17. できません.再度テーブルを作り直していただく必要があります.
 
Q18. S3のバケットポリシーにはどのようなアクションを許可すればよろしいでしょうか
A18. マニュアルの以下の部分をご参照ください.
http://docs.aws.amazon.com/athena/latest/ug/setting-up.html
 
Q19. パーティションを指定ない状態でwhereをしてもスキャンデータは減らせるのでしょうか?whereでのスキャンデータの削減はパーティションが前提なのでしょうか?
A19. ParquetやORCなどの列指向フォーマットであれば,クエリの内容によってはメタデータ参照によるスキップの効果で,スキャン量を削減することが可能です.
 
Q20. バッチ処理は、リトライを行わないため適していないとのことですが、バッチ処理内でリトライを行う場合は、問題ありませんか?
A20. クエリの内容と処理するデータサイズによっては,再現性のある形でメモリ溢れが起こる可能性があります.
Hive等のリトライ機構が備わっているミドルウェアを使用いただくことをお勧めします
 
Q21. クエリが自動的に並列的に実行されるとのことだが、 どのような仕組みで行っているのか。 具体的に何GBで何並列になる、というような設定はあるのか。
A21. 詳細については,Prestoのドキュメントやコードをご覧いただければと思います.
 
 
今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。
 

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2017年4 月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30