Downloaded 32 times
![Athena のクエリ
• Presto と同様，標準 ANSI SQL に準拠したクエリ
• WITH句，Window関数，JOINなどに対応
• Presto で⽤意されている関数は，基本的に使⽤可能
[ WITH with_query [, ...] ]
SELECT [ ALL | DISTINCT ] select_expression [, ...]
[ FROM from_item [, ...] ]
[ WHERE condition ]
[ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ]
[ HAVING condition ]
[ UNION [ ALL | DISTINCT ] union_query ]
[ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ]
[ LIMIT [ count | ALL ] ]](https://image.slidesharecdn.com/awsdatabaseupdate-public-170424084629/85/AWS-2017-50-320.jpg)
More Related Content
![[AWS Start-up ゼミ] よくある課題を一気に解説！〜御社の技術レベルがアップする 2017 夏期講習〜](https://cdn.slidesharecdn.com/ss_thumbnails/awsstartupzemi-2017summer-170816032526-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Black Belt Online Seminar] AWS上でのログ管理](https://cdn.slidesharecdn.com/ss_thumbnails/aws-log-mgmt-161201043056-thumbnail.jpg?width=640&height=640&fit=bounds)
![[PGConf.ASIA 2018]Deep Dive on Amazon Aurora with PostgreSQL Compatibility](https://cdn.slidesharecdn.com/ss_thumbnails/20181212pgconfasiaaurorapostgresql-181212055637-thumbnail.jpg?width=640&height=640&fit=bounds)
![[MANABIYA] 20180323 Amazon Aurora with PostgreSQL Compatibility](https://cdn.slidesharecdn.com/ss_thumbnails/20180323manabiyaaurorapostgresql-180323071750-thumbnail.jpg?width=640&height=640&fit=bounds)
![[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015a34amazon-auroraamazondataservicejapan-150623010528-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://cdn.slidesharecdn.com/ss_thumbnails/auroradeep-150322203758-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](https://cdn.slidesharecdn.com/ss_thumbnails/20220126-anti-220126190603-thumbnail.jpg?width=640&height=640&fit=bounds)
AWSデータベースアップデート2017
- 1. AWSデータベースアップデート 2017 JAWS DAYS2017 Amazon Web Services Japan K.K.
- 2. 内容についての注意点 • 本資料では2017年3⽉11⽇時点のサービス内容および価格についてご説明しています。最新 の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。 • 資料作成には⼗分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に 相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。 •価格は税抜表記となっています。⽇本居住者のお客様が東京リージョンを使⽤する場合、別途 消費税をご請求させていただきます。 • AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.
- 3. AWSのデータベースサービス群⼀覧 (⼀部) • AmazonRelational Database Service (RDS) – マネージドRDBMS • Amazon DynamoDB – マネージドNoSQL • Amazon ElastiCache – マネージドインメモリキャッシュ • Amazon Redshift – マネージドDWH • AWS Database Migration Service (DMS) – マネージドDB移⾏
- 4. Amazon RDS Amazon S3 Request Rate HighLow Latency Low High Data Volume Low High Amazon Glacier Amazon CloudSearch Structure Low High Amazon DynamoDB Amazon ElastiCache HDFS
- 5.
- 6. • Redis Cluster •3.5TB in-memory capacity • ~4.5 million writes per second • ~20 million reads per second • Auto-Sharding with support up to 15 shards • Cluster Level Backup and Restore • Faster Failover (~30 seconds, 4X times faster) • Enhanced Redis Engine for Improved Robustnes s and Stability • Redis 3.2 Engine Redis Cluster
- 7.
- 8. • Ex: Throttlingrequests to an API • Leverages Redis Counters ELB Externally Facing API Reference: http://redis.io/commands/INCR FUNCTION LIMIT_API_CALL(APIaccesskey) limit = HGET(APIaccesskey, “limit”) time = CURRENT_UNIX_TIME() keyname = APIaccesskey + ":” + time count = GET(keyname) IF current != NULL && count > limit THEN ERROR ”API request limit exceeded" ELSE MULTI INCR(keyname) EXPIRE(keyname,10) EXEC PERFORM_API_CALL() END Use Case - Rate Limiting
- 9.
- 10. WRITE PERFORMANCE READPERFORMANCE インスタンスサイズによるスケール Aurora MySQL 5.6 MySQL 5.7
- 11. P o st g r e S Q L F o r A u r o r a Aurora is now fully compatible with both PostgreSQL and MySQL
- 12. 1/10th The CostOf Commercial Grade Databases Fully PostgreSQL Compatible Several times better performance than typical PostgreSQL database Scalable, Durable and Secure Migrate From RDS For PostgreSQL Amazon Aurora PostgreSQL-Compatible Edition
- 13. Performance Insights • DBの知識を持ったエンジニアがいな くとも、クエリパフォーマンスの評 価やDBの状態チェックを実施可能に する機能 •Amazon Aurora PostgreSQL- Compatible Editionには既に組み込 まれた状態でリリースされる • 他のデータベースエンジンにも順次 展開予定
- 14.
- 15.
- 16. ゼロダウンタイムパッチ Network ing state Applicati on state Storage Service App state Net state App state Net state Before ZDP New DB Engine Old DB Engine New DB Engine OldDB Engine WithZDP セッションはパッチ 適⽤時に切断される パッチ適⽤中でも セッションは維持される Storage Service
- 17. ゼロダウンタイムパッチ - 現在の制限- • ゼロダウンタイムパッチは以下の状態の場合、現在の⽅法でパッチを適⽤する • ⻑時間実⾏中のトランザクションが存在する • バイナリログが有効 • パラメータの変更が適⽤されずpending状態 • ⼀時テーブルが開かれている • テーブルがロックされている • SSLコネクションが使⽤されている • リーダインスタンス
- 18. Online DDL (Lab.mode)
- 19. Online DDL: Auroravs. MySQL § フルテーブルコピー: 全てのインデックスを 再構築 - 数時間から数⽇かかることも § DMLクエリ実⾏のために⼀時領域が必要 § DDLクエリがDMLクエリスループットに影響 § DMLクエリ実⾏中にテーブル・ロックが起こる Index LeafLeafLeaf Leaf Index Root table name operation column-name time-stamp Table 1 Table 2 Table 3 add-col add-col add-col column-abc column-qpr column-xyz t1 t2 t3 § メタデータテーブルにエントリーを追加し、 スキーマバージョニングを利⽤する § 変更を適⽤するために最新のスキーマへブロック をアップグレードする際はmodify-on-write § 現在はテーブルの最後にNullableなカラムを 追加する場合に対応 § 他のadd column, drop/reorder, modify datatypesに対応するために実装を⾏っている MySQL Amazon Aurora
- 20. Online DDL performance Onr3.large On r3.8xlarge Aurora MySQL 5.6 MySQL 5.7 10GB table 0.27 sec 3,960 sec 1,600 sec 50GB table 0.25 sec 23,400 sec 5,040 sec 100GB table 0.26 sec 53,460 sec 9,720 sec Aurora MySQL 5.6 MySQL 5.7 10GB table 0.06 sec 900 sec 1,080 sec 50GB table 0.08 sec 4,680 sec 5,040 sec 100GB table 0.15 sec 14,400 sec 9,720 sec
- 21.
- 22. Aurora Auditing MariaDB server_auditplugin Aurora native audit support • We can sustain over 500K events/sec Create event string DDL DML Query DCL Connect DDL DML Query DCL Connect Write to File Create event string Create event string Create event string Create event string Create event string Latch-free queue Write to File Write to File Write to File MySQL 5.7 Aurora Audit Off 95K 615K 6.47x Audit On 33K 525K 15.9x Sysbench Select-only Workload on 8xlarge Instance
- 23.
- 24. 様々な性能改善 • Improved indexbuild • Throughput improvement for workloads with hot row contention • Aurora独⾃のSpatial indexing • Insert performanceの向上 • などなど
- 25. Faster index build §MySQL 5.6 はLinuxの先読みを活用しています が、これにはbtreeに連続したブロックアドレスが 必要です。そのためエントリーをトップダウンで新 しいbtreeに挿入する際に、分割とたくさんのロギ ングを引き起こします。 § Auroraはtree内のポジション(ブロックアドレスで はなく)を元にブロックをスキャンしてプリフェッチ § Auroraはリーフブロックを作製してからブランチを 作製していく • 分割が発生しない • 各ページは1度のみ参照される • 1ページに1ログレコード 2-4X better than MySQL 5.6 or MySQL 5.7 0 2 4 6 8 10 12 r3.large on 10GB dataset r3.8xlarge on 10GB dataset r3.8xlarge on 100GB dataset Hours RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016
- 26. Cached read performance •Catalog concurrency: データ・ディク ショナリの同期とキャッシュ破棄の効率化 • NUMA aware scheduler: NUMA を考慮 したスケジューラへ変更すること、複数 CPUが搭載されているインスタンスで性能 向上 • Read views: read viewを作成する際に ラッチフリーなread viewを作成するアルゴ リズムに変更 0 100 200 300 400 500 600 700 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 1,000 read requests/sec * R3.8xlarge instance, <1GB dataset using Sysbench 25% Throughput gain
- 27. • Smart scheduler:IOヘビー・CPUヘ ビーなワークロードそれぞれに動的に処理 スレッドを割り当てるスケジューラに変更 • Smart selector: 最も良いパフォーマンス のストレージノードにあるデータを選択す ることでリードレイテンシーを軽減 • Logical read ahead (LRA): btreeの順序 に応じて事前にpageを読み込んで置くこと で、IO waitを軽減 0 20 40 60 80 100 120 MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016 1,000 requests/sec * R3.8xlarge instance, 1TB dataset using Sysbench 10% Throughput gain Non-cached read performance
- 28. § プライマリーキーでソートされている データのバッチインサートの速度を改善。 インデックス⾛査を⾏う際のカーソル位 置をキャッシュ § データパターンに応じて動的に機能を有 効・無効化 §ツリーを下⽅向に⾛査する際のラッチ ロックの競合を軽減 § 双⽅向で全てのINSERTワークロードで 有効 – LOAD INFILE, INSERT INTO SELECT, INSERT INTO REPLACE, Multi-value inserts. Insert performance Index R4 R5R2 R3R0 R1 R6 R7 R8 Index Root Index R4 R5R2 R3R0 R1 R6 R7 R8 Index Root MySQL: 全てのINSERTがrootからB-treeをトラバースする Aurora: indexトラバースを抑制
- 29. Spatial Index Benchmarks Sysbench– points and polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . * r3.8xlarge using Sysbench on <1GB dataset * Write Only: 4000 clients, Select Only: 2000 clients, ST_EQUALS 0 20000 40000 60000 80000 100000 120000 140000 Select-only (reads/sec) Write-only (writes/sec) Aurora MySQL 5.7
- 30. AWS Database MigrationService AWS Schema Conversion Tool
- 31. 同種DB間で、ダウンタイムを最⼩限に移⾏ ソース: オンプレミス、EC2、 RDS上のOracle AWS Database Migration Service ターゲット: RDS上のOracle ソース: オンプレミス、EC2、 RDS上のMySQL AWSDatabase Migration Service ターゲット: Amazon Aurora
- 32. 異なるDB間で、ダウンタイムを最⼩限に移⾏ ソース: オンプレミス、EC2、 RDS上のOracle AWS Schema Conversion Tool ターゲット: AmazonAurora ソース: オンプレミス、EC2、 RDS上のOracle AWS Database Migration Service ターゲット: Amazon Aurora
- 33. 対応データベース詳細 プラットフォーム ソース ターゲット OracleDatabase 10g R2, 11g, 12c 10g, 11g, 12c Microsoft SQL Server 2005, 2008, 2012, 2014 2005, 2008, 2012, 2014 SAP ASE 15.7以降 15.7以降 MySQL / MariaDB / Aurora 5.5以降 5.5以降 PostgreSQL 9.4以降 9.3以降 Redshift - すべて
- 34.
- 35. 継続的なデータレプリケーション ソース: Amazon Aurora AWS Database MigrationService ターゲット: 異なるリージョンのAurora、 テスト用Aurora、 オンプレミスMySQL
- 36. AWS Schema ConversionTool（SCT） • 異なるRDB間での各種オブジェクトの 移⾏（変換）を補助するツール • Windows, Mac, Linux にダウンロードして利⽤ • 稼動OSは64bit版のみサポート • ODBCで接続。SSLサポートあり • ソースコード内のSQL分析に対応 • 移⾏対象： • 表、インデックス、トリガー、プロシージャ、制約、ビュー
- 37. 対応データベース詳細 Source Database TargetDatabase on Amazon RDS Microsoft SQL Server (version 2008 and later) Amazon Aurora (MySQL or PostgreSQL), Microsoft SQL Server, MySQL, PostgreSQL MySQL (version 5.6 and later) Amazon Aurora (PostgreSQL), MySQL, PostgreSQL Oracle (version 10.2 and later) Amazon Aurora (MySQL or PostgreSQL), MySQL, Oracle, PostgreSQL PostgreSQL (version 9.1 and later) Amazon Aurora (MySQL), MySQL, PostgreSQL Greenplum Database (version 4.3 and later) Amazon Redshift Netezza (version 7.2 and later) Amazon Redshift Oracle (version 11 and later) Amazon Redshift Teradata (version 14 and later) Amazon Redshift
- 38.
- 39.
- 40.
- 41. 埋め込みSQLの変換⽀援 • ソースコードをスキャンして、 埋め込みSQL（DML）を発⾒し、 変換（右表の対応） • C++,Java, C#に対応 • 事前にスキーマ（DDL）の変換が必要
- 42. Migrating Databases ToAWS 20,000+ databases migrated Migrate between on-prem and AWS Migrate between databases Automated schema conversion Data replication for zero downtime migrations
- 43.
- 44. よくある課題 • Amazon S3内のデータを分析するための ⼯数が多い • ユーザーは明細データにアクセスできない • HadoopクラスターやDWHの管理には 専⾨知識が必要
- 45. Amazon Athena とは 標準SQLを使って直接Amazon S3 から データ分析を簡単に⾏える インタラクティブ クエリ サービス
- 46. Athenaはサーバーレス • インフラ管理不要 • すぐに起動する •⾃動アップグレード
- 47. Athena の想定ユースケース ユースケース データユーザ 新しく取得したデータに対して， DWに⼊れる価値があるか探索的に検証 新しく取得したデータ アナリスト 利⽤頻度の低い過去のデータに対する， BIツール経由のアドホックな分析 コールドデータ アナリスト Webサーバで障害が発⽣したときに， ログを漁って原因追求 アクセスログ サーバ運⽤ ⼤規模でないデータに対しての， 低頻度で実施するETL処理 ⽣データ 開発者
- 48. Athena のデータ形式 /圧縮形式 項⽬ 値 注意点 データ形式 CSV, TSV, Parquet, ORC, JSON, Regex, Avro • 2017/2/16 に Avro と OpenCSV Serde* をサポート • JSONについては Hive-JsonSerDe と Openx-JsonSerDe の2つが利⽤可能 圧縮形式 Snappy, Zlib, GZIP • 現状，LZOはサポートしていない * Serialize/Deserialize の略で，データの⼊出⼒形式の変換クラス
- 49. Athena のテーブル定義 • 標準のテーブル定義の後に，データ形式，圧縮形式，データの場所などを指定 •既に Hive DDL がある場合，Athena で実⾏すれば，すぐクエリを投げられる • 既存の EMR の Hive メタストア⾃体に，直接アクセスすることはできない • schema-on-read なので，同⼀データに複数のスキーマを定義可能 CREATE EXTERNAL TABLE IF NOT EXISTS action_log ( user_id string, action_category string, action_detail string year int, month int, ) PARTITIONED BY (year int, month int) STORED AS PARQUET LOCATION 's3://athena-examples/action-log/’ TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY'); パーティション データ形式 データの場所 圧縮形式
- 50. Athena のクエリ • Prestoと同様，標準 ANSI SQL に準拠したクエリ • WITH句，Window関数，JOINなどに対応 • Presto で⽤意されている関数は，基本的に使⽤可能 [ WITH with_query [, ...] ] SELECT [ ALL | DISTINCT ] select_expression [, ...] [ FROM from_item [, ...] ] [ WHERE condition ] [ GROUP BY [ ALL | DISTINCT ] grouping_element [, ...] ] [ HAVING condition ] [ UNION [ ALL | DISTINCT ] union_query ] [ ORDER BY expression [ ASC | DESC ] [ NULLS FIRST | NULLS LAST] [, ...] ] [ LIMIT [ count | ALL ] ]
- 51. データ設計に影響する Athena の特性 •OLTP* ではなく OLAP** 向け – そもそもトランザクションは未サポート • ETL ではなく 分析向け – データをフルスキャン & 変換するのは⾼コストな設計 – リトライ機構がないため，安定的なバッチ処理には向かない • いかにして読み込むデータ量を減らすかが重要 – パーティション – 列指向フォーマット – 圧縮 * Online Transactional Processing ** Online Analytical Processing
- 52. 簡単に使えるAthena • コンソールにログイン • テーブルを作成 –Hive DDL で記述 – テーブル追加ウィザードをコンソールから使⽤ • クエリ実⾏
- 53.
- 54. Athenaの冗⻑構成 • サービスエンドポイントまたはコンソールにログインするだけ • 複数のアベイラビリティゾーンにまたがった複数台のサーバー を使⽤ •データは Amazon S3 にあり、⾼い可⽤性と99.999999999% の耐久性を実現
- 55. Amazon S3 から直接クエリ •データのローディング不要 • そのままのフォーマットでクエリ可能 – テキスト、CSV、JSON、ウェブログ、AWSサービスログ – さらなる性能向上とコスト削減のためにORCやParquetなどを利⽤することも 可能 • ETL不要 • Amazon S3 から直接ストリーム可能 • Amazon S3 の耐久性と可⽤性を享受
- 56. Athenaの⾼速性能 • パフォーマンスチューニング済み • ⾃動パラレルクエリ •結果はコンソールにストリームで表⽰ • 結果はS3に同時保存 • データの圧縮や列指向フォーマットの 利⽤でさらなるパフォーマンス向上も可能
- 57.
- 58. 現⾏のデータ処理フロー 複数のソースから S3にデータを アップロード Amazon EMR を 使⽤してETL ETLされた データを S3に保存 データを Redshiftに ロード QuickSightで 分析 SQLを使⽤して⽣データに アドホックアクセス 集計したデータを クエリすることも可能
- 59.
- 60. ユースケース: DataXu 社 Athena CDN RealTime Bidding Reporting Platform Kinesis ETL (Spark SQL) S3 Data Visualization Reporting 180TB / ⽇のデータを Athena で分析 http://www.slideshare.net/AmazonWebServices/announcing-amazon-athena-instantly-analyze-your-data-in-s3-using-sql
- 61.
- 62.
- 63. 直感的なビジュアライゼーション • 簡単な操作で可視化を実現 • データ型を認識し、⾃動的にグラフを サジェストするオートグラフ •複数の分析結果を「ストーリー」 としてまとめて、共有 • 読み取りのみ許可したいグラフは 「ダッシュボード」として共有
- 64. 13種類のVisual + AutoGraph • 13種類のVisualを利⽤可能 – 棒グラフ（⽔平・垂直） – 積み上げ棒グラフ（⽔平・垂直） – 100%積み上げ棒グラフ（⽔平・垂直） – 折れ線グラフ – エリアラインチャート（⾯グラフ） – ピボットテーブル – 散布図 – ツリーマップ – 円グラフ – ヒートマップ • Auto Graphでグラフを⾃動選択可能
- 65. SPICE • インメモリ処理に最適化された⾼速データベース • カラムナ：1/2~1/4のサイズに圧縮 •フルマネージド：運⽤管理不要 – ⾃動的にスケール、⾼い可⽤性 • RDBのデータやファイルをSPICEに保存することで ⾼速なクエリを実現 • QuickSight Standard Edition １ユーザあたり 10GBのSPICE⽤領域が利⽤可能（追加可能） ※ SPICE = Super-fast, Parallel, In-memory, Calculation Engine
- 66.
- 67. RedshiftとAthenaの⽐較 Redshift • 形式化および整理された 企業全体の「信頼できる 唯⼀の情報源」として データを保存 • ⾮常に⼤規模なデータに 対する複雑なクエリを ⾼速に実⾏可能 Athena •⼀部のウェブログなどに すばやくクエリし、 サイトのパフォーマンス 問題解決を⾏なう • データの形式化や インフラ管理について 意識する必要がない
- 68.
- 69. Athenaでの課題解決 • Amazon S3内のデータを分析するための⼯数が多い ETL不要。ローディング不要。データに直接クエリ • ユーザーは明細データにアクセスできない ユーザーが欲しい粒度のデータにクエリ可能 • HadoopクラスターやDWHの管理には専⾨知識が必要 インフラ管理不要
- 70. AWS Glue (comingsoon)
- 71. AWS Glue • データストア間でデータ移動を簡単に⾏うための マネージドETLサービス • データ検出、変換、マッピング、ジョブスケジューリングの タスクを簡単に、⾃動で⾏える • ETL ジョブをスケジュールし、必要なすべての インフラストラクチャのプロビジョニングとスケーリングを⾏う • AWS Glue では、Amazon S3、Amazon RDS、 Amazon Redshift と統合し、JDBC 準拠のデータスト アに接続可能 • データソースを⾃動的にクロールし、データフォーマットを 識別してからスキーマと変換を提案するため、データフローを ⼿作業でコーディングする時間を費やす必要がなくなる
- 72. Amazon Glue • データカタログを構築 •JSON、CSV、Parquet などの⼀般的な ソースフォーマットやデータタイプに 対して、あらかじめ作成された分類⼦ を 使⽤してデータソースをクロールし作 成 • 独⾃の分類⼦を追加することや、 AWS Glue コミュニティから分類⼦を 選択してクロールに使⽤することも可 能
- 73. Amazon Glue • データ変換を⽣成、編集 •AWS Glue によって Pythonコードが ⽣成されてソースからデータが 抽出され、そのデータがターゲットの スキーマに合わせて変換されて ターゲットにロードされる • ⽣成されるコードは⼀般的な エラーハンドリングなども⼊っている • IDEを使って編集も可能
- 74. Amazon Glue • ジョブをスケジュールして実⾏ •フローを定期的に、トリガーに応じて、 または AWS Lambda イベントに 対応して実⾏ • ETL ジョブが Apache Spark ノードに ⾃動的に配布されるためデータ量が 増加しても ETL の実⾏時間を⼀定に 保つことが可能 • ジョブの実⾏を適切な順序で調整し、 失敗したジョブを⾃動的に再試⾏可能。 時間通りにジョブを完了させてコストを 最⼩限に抑えるために、必要に応じて スケーリングすることも可能