20140620 dbts osaka_redshift_v1.0_slideshare

Amazon Redshift Deep Dive アマゾンデータサービスジャパン株式会社事業開発部マネージャー大久保順 2014/06/20

本日のアジェンダ • Amazon Web Servicesとは？ • Amazon Redshiftのアーキテクチャ • 速さを引き出すためのベストプラクティス

Amazon Web Servicesとは？

アマゾンについて創業：1994年7月本社：米国ワシントン州シアトル創業者&CEO：ジェフ・ベゾス 744.5億ドルの総売上高(2013年度) 2億1500万超のアクティブカスタマー(2013年10月時点)

コンシューマービジネス 1億を超えるアクティブなアカウント８カ国で展開 : 米国, 英国, ドイツ, 日本, フランス,カナダ, 中国, イタリアセラー（売り手）様向けビジネスアマゾンのウェブサイト上で販売自社小売ウェブサイトに Amazonの技術を利用フルフィルメントセンター（物流センター）の活用 IT インフラビジネスウェブスケールでのクラウド基盤の提供 190以上の国にて、数十万に及ぶ登録アカウント

データセンターインターネット

AWS(Amazon Web Services)とは Amazonがビジネス課題解決のために作り上げたITを誰でもサービスとして利用できるようにしたもの一般的にはクラウドコンピューティングと呼ばれている

AWSの特徴オンデマンドで、必要な時に必要なだけ、初期投資ゼロワンクリックで、数分後にはITリソースが手元に貴重な人的リソースは、インフラではなくビジネス成長に集中

低価格にこだわりお客様に還元規模の拡大とイノベーションサービス開始から42回の値下げを実施

Amazon Redshiftのアーキテクチャ

2013年2月のローンチ以降多数の新機能を追加 • Regions – N. Virginia, Oregon, Dublin, Tokyo, Singapore, Sydney • Certifications – PCI, SOC 1/2/3, FedRAMP, others • Security – Load/unload encrypted files, Resource-level IAM, Temporary credentials, HSM, ECDHE for perfect forward security • Manageability – Snapshot sharing, backup/restore/resize progress indicators, Cross-region • Query – Regex, Cursors, MD5, SHA1, Time zone, workload queue timeout, HLL • Ingestion – S3 Manifest, LZOP/LZO, JSON built-ins, UTF-8 4byte, invalid character substitution, CSV, auto datetime format detection, epoch, Ingest from SSH

2013年2月のローンチ以降多数の新機能を追加 Service Launch (2/14) PDX (4/2) Temp Credentials (4/11) Unload Encrypted Files DUB (4/25) NRT (6/5) JDBC Fetch Size (6/27) Unload logs (7/5) 4 byte UTF-8 (7/18) Statement Timeout (7/22) SHA1 Builtin (7/15) Timezone, Epoch, Autoformat (7/25) WLM Timeout/Wildcards (8/1) CRC32 Builtin, CSV, Restore Progress (8/9) UTF-8 Substitution (8/29) JSON, Regex, Cursors (9/10) Split_part, Audit tables (10/3) SIN/SYD (10/8) HSM Support (11/11) Kinesis EMR/HDFS/SSH copy, Distributed Tables, Audit Logging/CloudTrail, Concurrency, Resize Perf., Approximate Count Distinct, SNS Alerts (11/13) SOC1/2/3 (5/8) Sharing snapshots (7/18) Resource Level IAM (8/9) PCI (8/22) Distributed Tables, Single Node Cursor Support, Maximum Connections to 500 (12/13) EIP Support for VPC Clusters (12/28) New query monitoring system tables and diststyle all (1/13) Redshift on DW2 (SSD) Nodes (1/23) Compression for COPY from SSH, Fetch size support for single node clusters, new system tables with commit stats, row_number(), strotol() and query termination (2/13) Resize progress indicator & Cluster Version (3/21) Regex_Substr, COPY from JSON (3/25)

Amazon Redshiftアーキテクチャ図

リーダーノード • クライアントからのSQLエンドポイント • データ分散の管理 • クエリの実行計画生成と実行 – SQL文の実行計画をC++のコードに変換し、コンパイル – コンパイルした実行コードを各コンピュートノードに配布し、結果を収集 – SQL文の特定の関数はリーダーノードのみで実行される http://docs.aws.amazon.com/redshift/latest/dg/c_SQL_functions _leader_node_only.html

コンピュートノード • リーダーノードで生成されたコンパイル済コードを実行し、中間結果をリーダーノードに返す – リーダーノードが最終的な集計を行い、クライアントへ結果を返す • コンピュートノードは各ノードにCPU, メモリ, ローカルディスクストレージを持つ。（処理能力やリソース容量はクラスタのインスタンスタイプにより決定） – DW1 – Dense Storage Nodes ハードディスクベースのインスタンスタイプ。データ量が多い用途に向く。 – DW2 – Dense Compute Nodes SSDベースのインスタンスタイプ。計算量が多い、またディスクI/Oが多い用途に向く。

スライス • 各コンピュートノードのメモリとディスクストレージは「スライス」と呼ばれる単位に分割して管理されている • スライス数は各コンピュートノードのプロセッサコア数と同じ • パラレルクエリ実行は、スライス毎の負荷が極力均等になるよう分散される

• カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ • 行指向のストレージでは、必要なデータを得るために全カラムのデータを取得する必要がある ID Age State Amount 123 20 CA 500 345 25 WA 250 678 40 FL 125 957 37 WA 375 I/Oを減らすための仕組み

• カラムナー型ストレージでは、必要なデータだけを読み取ることができる ID Age State Amount 123 20 CA 500 345 25 WA 250 678 40 FL 125 957 37 WA 375 I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ

I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ 10 | 13 | 14 | 26 |… … | 100 | 245 | 324 375 | 393 | 417… … 512 | 549 | 623 637 | 712 | 809 … … | 834 | 921 | 959 10 324 375 623 637 959 • 各ブロックに含まれる最小値と最大値を保持 • 必要なデータを含んでいないブロックは読取りをスキップ

I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ • パフォーマンス向上のため、各コンピュートノードに直結したローカルストレージを使用し、スキャンレートを最大化 • データの複製とバックアップは自動的に行われる • HDD/SSD の2種類のプラットフォーム

I/Oを減らすための仕組み • カラムナー型ストレージ • データ圧縮 • ゾーンマップ • 直結ストレージ • データブロックサイズ • 1MB/block • 参考：RDBMSの一般的なデータブロックサイズは、 8KB~32KB/block

並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ

• Amazon S3, Amazon DynamoDB, 任意のSSH接続から、パラレルにローディングを実施 • DDLに従い、データは自動的に分散・ソートして格納される • ノード数に従ってスケール並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ

• Amazon S3へのバックアップは自動的、継続的かつ差分で取得される • スナップショット保持期間は設定可能。任意のタイミングでのスナップショット取得も可能 • DR用途向けにリージョンをまたいでバックアップを取得することが可能 • ストリーミング・リストアですぐにクエリ受付可能な状態に並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ

• リサイズ中もオンライン状態を維持 • バックグラウンドで新しいクラスタをプロビジョニング • 新旧ノード間でのデータコピーはパラレルに処理並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ

• SQLエンドポイントの切替はDNS 更新で行われる • コンソール / API経由で実行並列・分散処理 • クエリ • ロード • バックアップ/リストア • リサイズ

速さを引き出すためのベストプラクティス

サポートするデータ型 • 次の種類のデータ型をサポート – 数値: Integers up to 64 bits, fixed precision up to 128 bits, floating point up to 64 bits – 文字列: fixed width or varying up to 64K characters – ブーリアン – 日付・時刻: from 4713 BC to 5874897 AD with a precision of 1 microsecond • 注）N[VAR]CHARとTEXTは[VAR]CHARとして格納

正しいデータ型を選ぶ • Redshiftのパフォーマンスは「如何にI/Oを最適化するか」にかかっている • 列幅を必要以上に取らない – 例）国コードにBIGINTを使う – 例）国名にCHAR(MAX)を使う • 適切なデータ型を使う – 日付・時間にはCHARではなくTIMESTAMPやDATEを使う – 列幅が分かっている時はVARCHARよりもCHARを使う

データの分散 • Redshiftは分散型システム – クラスタは1台のリーダーノードと複数のコンピュートノードから構成される – コンピュートノードは複数のスライス（1 CPUコアあたり1つ）を持つ • データは3種類の分散方式がある – Even – ラウンドロビン方式で行を分散（デフォルト） – Key – 分散キー（指定したカラムのハッシュ）に基づいて行を分散 – All - 全てのスライスに行を複製 • クエリは全てのスライスで並列に実行 – 全てのスライスに均等にデータが分散されている時にクエリのスループットが最も引き出される

データのソート • スライス内（＝ディスク上）では、データはソートキー順に格納されている – ソートキーが指定されていない場合、Redshiftは挿入された順にデータを格納する • 実行するクエリで条件句によく使う列をソートキーとして選択する – 日付、ID、等々 – 結合キーとして使うもの • ソートキーを使うことで、Redshiftは不必要なブロックを読まずに処理を行うことができる – 例）タイムスタンプ型の列がソートキーと指定されたテーブルに対し、直近のデータだけ抽出するクエリを実行すると、古いデータを含むブロックはスキップされる

データの圧縮 • 列方向の圧縮でパフォーマンス向上・低コスト両方のメリットがある • COPYコマンドは新規テーブルへのロード中にデータを自動的に分析し、適切な形式で圧縮を行う • ANALYZE COMPRESSIONコマンドは既存のテーブルに対し実行することで、各列に適した圧縮形式を提案する • ストレージの使われ方の情報はシステム表に格納されている

データ圧縮のアルゴリズム • ロー・エンコーディング (RAW) – 圧縮なし • バイト・ディクショナリ (BYTEDICT) – 繰り返し値に辞書を使用 • デルタ・エンコーディング (DELTA / DELTA32K) – 連続値や近い値に適する (日付時刻、順序等) • LZO – 大きな文字列に適する • モストリー・エンコーディング (MOSTLY8 / MOSTLY16 / MOSTLY32) – 分布の低い方に値が集まっている場合に有効 • ランレングス・エンコーディング (RUNLENGTH) – 同じ値が連続していることが多数ある場合に有効 • テキスト・エンコーディング (TEXT255 / TEXT32K) – テキスト値向け、含まれる単語を辞書を使用して圧縮

制約の定義 • Redshiftはnot null, primary key, foreign key, unique valuesといった制約を実際には有効化しない • キーとユニーク制約は、オプティマイザがクエリ最適化のヒントとして使用 • Redshiftはデータが制約通りに入っていると仮定して動作 – 投入したデータが制約に反する場合、結果不正などの問題が起きる可能性がある

データベースをクエリに最適化する • 各カラムを適切な形式で圧縮する • 頻繁に結合するテーブルはDISTSTYLE=ALLで全スライスに複製し、ノード間でのデータ転送を減らす • 結合するテーブルは、結合するカラムをソートキーとすることで、高速なマージ結合を行うことができる • テーブルの非正規化は、クエリを単純化し結合を減らすことに役立つ。圧縮により、ストレージ消費も問題とはならない • VACUUMとANALYZEは定期的に実行する

Redshift向けの最適化とは • DWH用途向けのデータベースであり、 OLTP向けのデータベースではない – 読み込み処理に最適化されている – 大きく長いクエリを速く処理することに注力 • ペタバイト級のデータセットをサポート – 「Redshift向けに最適化する」＝「I/Oを最適化する」 • 大事なこと – 汎用的な「good design」はない – データとワークロードの特徴を押さえることが肝要

Amazon Redshiftへのデータ投入方法 AWS CloudCorporate Data center DynamoDB Amazon S3 Data Volume Amazon Elastic MapReduce Amazon RDS Amazon Redshift Amazon Glacier logs / files Source DBs VPN Connection AWS Direct Connect S3 Multipart Upload AWS Import/ Export Amazon EC2 or On-Premise Remote Loading using SSH

Amazon Redshiftへのデータ投入方法 AWS CloudCorporate Data center DynamoDB Amazon S3 Data Volume Amazon Elastic MapReduce Amazon RDS Amazon Redshift Amazon Glacier logs / files Source DBs VPN Connection AWS Direct Connect S3 Multipart Upload AWS Import/ Export Amazon EC2 or On-Premise Remote Loading using SSH Loading Data from S3

S3からのデータローディング Slice 0 Slice 1 Slice 0 Slice 1 Client.txt. 1 Client.txt. 2 Client.txt. 3 Client.txt. 4 Node 0 Node 1 コンピュートノード Copy customer from ‘s3://mydata/client.txt’ Credentials ‘aws_access_key_id=<your-access-key>; aws_secret_access_key=<your_secret_key>’ Delimiter ‘|’; 投入データ

テーブルのANALYZE ANALYZEコマンドデータベース全体単一のテーブルテーブルの特定の列 ANALYZEコマンドは行のサンプルを取得し、計算を行った後に統計情報を保存全テーブルの全列を定期的に ANALYZEする必要はない次のようによく使われる列はANALYZEを行う • ソートやグループ化を行う • 結合する • WHERE句の条件テーブルの統計情報を最新に保つには • クエリを実行する前にANALYZEを実行 • データ投入や更新の後、定期的にデータベース全体にANALYZEを実行 • 新しいテーブルを作ったらANALYZE を実行統計情報

テーブルのVACUUM 1 RFK 900 Columbus MOROCCO MOROCCO AFRICA 25-989-741-2988 BUILDING 2 JFK 800 Washington JORDAN JORDAN MIDDLE EAST 23-768-687-3665 AUTOMOBILE 3 LBJ 700 Foxborough ARGENTINA ARGENTINA AMERICA 11-719-748-3364 AUTOMOBILE 4 GWB 600 Kansas EGYPT EGYPT MIDDLE EAST 14-128-190-5944 MACHINERY 1,2,3,4 RFK,JFK,LBJ,GWB 900 Columbus,800 Washington, 700 Foxborough,600 Kansas Column 0 Column 1 Column 2 各列の値はシリアルに格納されている

テーブルのVACUUM 1 RFK 900 Columbus MOROCCO MOROCCO AFRICA 25-989-741-2988 BUILDING 2 JFK 800 Washington JORDAN JORDAN MIDDLE EAST 23-768-687-3665 AUTOMOBILE 3 LBJ 700 Foxborough ARGENTINA ARGENTINA AMERICA 11-719-748-3364 AUTOMOBILE 4 GWB 600 Kansas EGYPT EGYPT MIDDLE EAST 14-128-190-5944 MACHINERY 1,2,3,4 RFK,JFK,LBJ,GWB 900 Columbus,800 Washington, 700 Foxborough,600 Kansas Column 0 Column 1 Column 2 Delete customer where column_0 = 3; x xxx xxxxxxxxxxxxxxx

テーブルのVACUUM 1,2,4 RFK,JFK,GWB 900 Columbus,800 Washington,600 Kansas VACUUM Customer; 1,2,3,4 RFK,JFK,LBJ,GWB 900 Columbus,800 Washington, 700 Foxborough,600 Kansasx xxx xxxxxxxxxxxxxxx DELETE/UPDATEによって空いたスペースは、自動的に再確保・再利用されるわけではない。VACUUMコマンドを実行することで空きスペースが再確保され、ストレージの空き容量が増えるだけでなくパフォーマンスも向上する。

同時書き込み時の挙動同じテーブルにCOPY/INSERT/DELETE/UPDATE を同時に発行した場合トランザクション1 トランザクション2 CUSTOMER Copy customer from ‘s3://mydata/client.txt’…; Copy customer from ‘s3://mydata/client.txt’…; Session A Session B トランザクション1は CUSTOMERテーブルに書込ロックをかけるトランザクション2はトランザクション1がロックを開放するまで待機

同時書き込み時の挙動同じテーブルにCOPY/INSERT/DELETE/UPDATE を同時に発行した場合 Transaction 1 Transaction 2 CUSTOMER Begin; Delete one row from CUSTOMERS; Copy…; Select count(*) from CUSTOMERS; End; Begin; Delete one row from CUSTOMERS; Copy…; Select count(*) from CUSTOMERS; End; Session A Session B トランザクション1は CUSTOMERテーブルに書込ロックをかけるトランザクション2はトランザクション1がロックを開放するまで待機

同時書き込み時の挙動同時実行トランザクションによりデッドロックになり得るシチュエーション例トランザクション1 トランザクション2 CUSTOMER Begin; Delete 3000 rows from CUSTOMERS; Copy…; Delete 5000 rows from PARTS; End; Begin; Delete 3000 rows from PARTS; Copy…; Delete 5000 rows from CUSTOMERS; End; Session A Session B トランザクション1はCUSTOMER テーブルに書込ロックをかける PARTS トランザクション2はPARTSテーブルに書込ロックをかける Wait Wait

データロードのベストプラクティス • データロードには極力COPYコマンドを使う • テーブル毎に1つのCOPYコマンドを使う • データは複数ファイルに分割 – 少なくともスライス数と同じ数にする – データファイルはGZIPかLZOPで圧縮 – 1ファイルあたりのサイズは1~2GBくらいが良い（経験則） • なるべく複数行まとめてINSERTする • 一括挿入(INSERT INTO…SELECTとCREATE TABLE AS)の方がパフォーマンスが良い

データロードのベストプラクティス • 後でVACUUMしなくて済むよう、データはソートキー順にロードする • ソートキー順にデータをロードしていない場合、大量の行追加/削除/変更を行ったらVACUUMコマンドを実行する • COPYとVACUUMコマンドが使うメモリ量を増やすにはwlm_query_slot_countパラメーターで調整 • データに少なからず変更がある場合はANALYZEコマンドを実行し、統計情報を最新に保つ

Questions?

20140620 dbts osaka_redshift_v1.0_slideshare

by Jun Okubo

on Jun 20, 2014

Statistics

Views

Actions

1 Embed 4

Accessibility

Categories

Upload Details

Usage Rights

Report content

20140620 dbts osaka_redshift_v1.0_slideshare Presentation Transcript