Amazon Web Services ブログ

Category: Amazon Redshift

Amazon Redshift Spectrum – S3のデータを直接クエリし、エクサバイトまでスケール可能

現在、数クリックでクラウド上にコンピュートリソースやストレージリソースを構築可能です。現在のチャレンジは、それらのリソースを活用して生のデータを出来る限り素早く、かつ効果的に活用可能な結果に変換することです。 Amazon Redshiftを活用することで、AWSのお客様はペタバイト級のデータウェアハウスを構築し、社内・社外の多様なデータソースからのデータを統合することが可能です。Redshiftは巨大な表に複雑なクエリ(複数の表をジョインする等)を実行することに最適化されているため、小売、在庫、ファイナンシャルデータといった膨大なデータを特別な苦労なく処理することができます。Redshiftにデータをロードした後は、Redshiftパートナーが提供するビジネスインテリジェンス(BI)ツールやエンタープライズレポーティングツールを活用することが可能です。 データウェアハウスを使い続ける上での1つの大きなチャレンジは、継続的に更新される、もしくは追加されるデータを速いペースでロードすることです。高速なクエリーパフォーマンスを提供するために、データをロードするというフェーズでは圧縮、データの正規化や最適化といった作業が行われます。これらの作業自体は自動化、スケールさせることは可能ですが、複雑なロード作業はデータウェアハウス維持にオーバーヘッドと複雑さを追加し、効果的な活用方法を得ることを阻害する場合もあります。 データフォーマットについては別の興味深いチャレンジが存在します。いくつかのアプリケーションはデータウェアハウスの外でデータ元々のフォーマットのままで処理を行っています。他のアプリケーションはデータウェアハウスにデータを取り込み、クエリーを実行しています。この利用方法だと同じデータが2つの場所に存在することになりますのでストレージを効率的に使えていないことになりますし、ロードがタイムリーに行われていない環境では、それぞれのアプリケーションで異なった結果が返る可能性があります。 Amazon Redshift Spectrum データを置いた場所によらず、そのままのデータフォーマットでAmazon Redshiftのパワーとフレキシビリティを活用できるようにするため、Amazon Redshift Spectrumをローンチいたします。Spectrumを使うことで、Amazon Simple Storage Service (S3)上に置かれたファイルをRedshiftにロードしたり特殊な準備をすることなく、高度なクエリを実行することが可能になります。 使い方はこれまで通り、データソース(データベースへの接続)を作成してクエリーをRedshiftに投入するだけです。クエリー実行の背後ではSpectrumが数千台までスケールするインスタンスが用意されており、データセットがエクサバイトを超えて大きくなっても、高速なデータ取り出しと一貫したパフォーマンスを実現します!S3上のデータを直接クエリーできるようになるということは、Redshiftのクエリーモデルや、全てのレポーティングツール、BIツールを維持したまま、コンピュートリソースとストレージリソースをそれぞれ独立してスケールさせることが出来るようになるということです。クエリーはRedshiftにストアされたデータとS3上に置かれたデータの任意の組み合わせを参照することが可能です。 クエリーが投入されると、Redshiftはクエリーを分解してクエリープラン(実行計画)を作成します。クエリープランはS3上に置かれたデータにおけるカラムナ(列指向)フォーマットの特性および日付等のキーでのパーティションの特性をいかし、読み取る量が最小になるように作成されます。クエリープランが出来るとRedshiftは巨大な共有プールに用意されているSpectrumワーカーに指示を出し、射影・フィルター・アグリゲーションといったSQL操作をS3上のファイルに対して実行させます。結果セットを作成する最終的なプロセスはRedshiftの中で実行され、ユーザに結果が返されます。 SpectrumはS3上に保存されたデータに直接アクセスできるということは、他のAWSサービス、例えばAmazon EMRやAmazon Athenaといったサービスを使ってそのデータを処理できるということです。また、頻繁にアクセスされるデータはRedshiftのローカルストレージに維持して、他はS3に置くであるとか、ディメンジョン表に加えてファクト表の直近データだけRedshiftに置き、他の古いデータはS3に置くといったハイブリッドな構成を実現することも可能です。より高いレベルでの並列実行を実現するために、複数のRedshiftクラスターを用意してS3上の同じデータを参照させるということも可能になります。 SpectrumはCSV/TSV、Parquet、SequenceFile、RCFileといったオープンなフォーマットをサポートします。ファイルはGzipかSnappyで圧縮しておくことが可能です。この他のフォーマットや圧縮アルゴリズムについては、今後サポートすることを計画しています。 Spectrum イン・アクション サンプルデータセットを使って、クエリーを実行することでSpectrumを試してみましょう! まずExternal SchemaとExternal Databaseを作成するところから始めます:(訳注:External Databaseはこの後で定義するExternal Tableの定義を格納しておくためのデータベースです。External SchemaはIAMロールの情報を保持し、SpectrumはそのIAM権限でS3上にアクセスします) そして、External Table (外部表)をデータベースの中に定義します: このExternal Tableで定義したデータの行数を得るために、簡単なクエリーを実行してみましょう(61億行): 最後に全ての列を使ったクエリーを実行します: ご覧いただいたように、Spectrumは60億行のデータ全体をスキャンする必要がある演算を4分と少々で実行できています。クラスターのパフォーマンスを確認すると、CPUパワーはまだ十分な余裕があり、同様のクエリーを多数並列実行することが可能であることが見て取れます: 本日からご利用可能です! Amazon Redshift Spectrumは、本日、今からご利用可能です! Spectrumの費用はクエリーによってS3から読み取られたデータサイズによって決まり、1TBあたり$5です(データを圧縮したり、カラムナフォーマットでデータを保存することで費用を節約することが可能です)。Redshiftのクラスターの稼動費用やS3の保存費用は通常通り必要になりますが、Spectrumを使ったクエリーを実行しない限りはSpectrumの費用は発生しません。 (訳注:Spectrumは各リージョンに順次展開されていき、展開後のメンテナンスウィンドウのタイミングでクラスターにパッチが適用されます。パッチ1.0.1293以降のRedshiftクラスターであればSpectrumが使用可能になっています。本稿執筆時点では東京リージョンにはまだ展開されていませんでしたが、例えばバージニア北部リージョン等にはすでに展開されています。Spectrumの使い方についてはこちらのドキュメントを参照してください) – Jeff; 翻訳:下佐粉 昭(@simosako)  

Read More

Amazon Redshift のデータ圧縮の強化で圧縮率が最大 4 倍に

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。 -Ana Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (Scholastic、King.com、Electronic Arts、TripAdvisor、Yelp など) は、Amazon Redshift に移行して機敏性を実現し、洞察が得られるまでにかかる時間を短縮して、同時にコストも大幅に削減しています。 列指向の圧縮は、Amazon Redshift の重要なテクノロジーです。このテクノロジーにより、ノードの効果的なストレージ容量を増やしてコストを削減し、SQL リクエストの処理に必要な I/O を削減してパフォーマンスを向上させることができます。I/O の効率を高めることは、データウェアハウスに非常に重要です。昨年、I/O の向上に伴ってクエリスループットは倍増しました。この度、Amazon Redshift に新しい圧縮の強化機能が追加されました。以下に、いくつかをご紹介します。 まず、Zstandard 圧縮アルゴリズムのサポートが追加されました。このアルゴリズムは、ビルド 1.0.1172 での高い圧縮率とスピードを適切なバランスに維持します。標準の TPC-DS、3 TB ベンチマークで raw データに適用した場合、Zstandard はディスク容量の 65% を節減します。Zstandard は幅広く適用できます。SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ のいずれのデータ型にも使用できます。 2 番目として、CREATE TABLE AS、CREATE TABLE、ALTER TABLE ADD COLUMN の各コマンドで作成されたテーブルに対する圧縮の自動化が強化されました。Amazon Redshift のビルド 1.0.1161 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 […]

Read More

Redshiftアップデート:列や表の名前に日本語が使用できるように

で列や表、もしくはビューといったオブジェクトの名前として日本語が利用可能になりました!これは以前から日本のお客様からご要望いただいていた機能ですので、以下で説明します。 Amazon Redshift introduces multibyte (UTF-8) character support for database object names and updated ODBC/JDBC Release: Amazon Redshift on 2016-11-10 Redshiftはこれまではデータとしては日本語を含むマルチバイト文字を格納可能でしたが、表や列の名前には使用できませんでした。これが改善され、Redshift v1.0.1122からは日本語のテーブル名や列名が利用可能になります。利用する前にご自身のRedshiftクラスターが1.0.1122以降に更新されているかをご確認ください。 列や表の名前は最大で127バイトまで利用でき、文字はUTF-8で保存されます(日本語の漢字やひらがなは1文字を表現するのに3バイト必要です)。以下のドキュメントも更新されています。現時点では日本語翻訳はまだ更新されていないので、英語に切り替えてご覧ください。 Names and Identifiers なおマルチバイト文字のテーブル名や列名を使用する場合は、RedshiftのJDBCドライバー 1.2.1以降、ODBCドライバー 1.3.1以降にアップデートする必要がある事に注意してください。どちらもRedshiftのマネジメントコンソールから、もしくは以下のリンクよりダウンロードが可能です(こちらも英語にしてご覧ください)。名前のマルチバイト対応だけでなく、バグフィックスや機能向上を含みますのでぜひこの機会にドライバを最新に更新して御利用ください。 Download the Amazon Redshift JDBC Driver Install and Configure the Amazon Redshift ODBC Driver on Microsoft Windows Operating Systems Amazon Redshift JDBC Driver 1.2.1リリースノート(リンク先PDF) Amazon Redshift […]

Read More

Redshiftアップデート:CTASで表を作成時に自動的に圧縮されるように

Amazon Redshiftに次回適用されるパッチ(ver. 1.0.1115)の情報がフォーラムで公開されています。 Announcement: Amazon Redshift Maintenance (October 27th – November 10th, 2016) メモリ確保やクエリーキャンセルの改善など、いくつかの機能改善に加えてCREATE TABLE AS SELECT (CTAS)のへ新機能が追加されていますので、ここではそれを紹介します。 CTASは、SELECTの結果(アンサーセット)を元にそのデータが入った表を作成するという構文です。Redshiftはデータウェアハウスとして利用される事が多いため、集計データの保存や、分析の途中のデータを表として保存して再利用する等のユースケースでCTASがよく利用されています。 このCTASを使って作成された表は各列が圧縮されないという課題がありました。CTASはSELECTの結果によって表が定義されるので、その元となる圧縮アルゴリズムが存在しないケースが考えられたためです。このためにCTASで作成されたデータはディスク領域をより多く使用することになり、処理のオーバーヘッドが大きくなってしまっていました。 今回のパッチではこれが改善され、自動的に各列にLZOで圧縮がかかるようになりました。列が含むデータの特性に関係なく一律でLZO圧縮を使用する形ですが、圧縮無しと比較して大きな改善ですし、多くのケースでLZO圧縮は安定した圧縮率を実現できるため有効なアプローチですね。特に大規模な利用ケースほど効果が高いと思われます。 ただし結果セットが返す列によっては圧縮されない場合もあります。列がソートキーである場合と、 BOOLEAN、 REAL、 DOUBLE PRECISION のどれかの型になった場合です。この場合その列はRAW、つまり未圧縮として作成されます。詳細は以下のドキュメントに記載されていますので、こちらもご覧ください。 CTAS Usage Notes ソートキー列を圧縮しないのはRedshiftのベストプラクティスに沿った動きです。こちらについては別の記事で解説しています。 Amazon Redshiftのパフォーマンスチューニングテクニック Top 10 フォーラムにもありますように、この機能を含んだ新バージョンはこれから2週間程度をかけて各リージョンにデプロイされていきます。ご利用のリージョンにデプロイされ、メンテナンスウィンドウでパッチが適用された後に利用可能になりますので、楽しみにお待ちください。 下佐粉 昭(@simosako)

Read More

新発表 – Redshift や QuickSight で AWS のコストや使用状況レポートのアップロードが可能に

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを や Amazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。 Redshift にアップロード まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。 次に請求レポート機能が有効になっていることを確認しました。 そしてコストと請求レポートに行き、Create report をクリックしました。 次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。 最後に配信オプションを選択しました。 次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。 待機している間に PostgreSQL を EC2 インスタンス (sudo yum […]

Read More

Redshiftアップデート:バックアップ不要表の指定、トランザクションのロック状況を出力する新しいビュー等

Redshiftに最近追加された新機能や、SASのRedshift対応強化についてアナウンスが出ていましたので、ご紹介します。 BACKUP NO オプションをCREATE TABLEで指定できるようになりました。名前の通り、この指定を付けた表はRedshiftの自動・手動SNAPSHOTでバックアップが取得されなくなります。Redshiftを活用する上で、一次的に中間データを置く表を作成することが良くあるのですが、これまではそのような一時表も自動SNAPSHOTの対象になっていました。このオプションでSNAPSHOT不要な表を指定することで、パフォーマンスの向上と、SNAPSHOTサイズの縮小が期待できます。 参照)BACKUP MD5ハッシュの文字列を使ったCREATE USER/ALTER USERが利用可能になりました。クラスターバージョン1.0.1046以降で利用可能です。 通常CREATE USERを実行する際には、引数でパスワードを指定する必要があります。これをシェルスクリプトに書いて実行する場合を想定すると、そのファイルからパスワードが漏洩してしまうリスクがありました。今回の機能改善では、予めMD5ハッシュ化した文字列をCREATE USERのパスワードに指定する事が可能になりました。Redshiftは与えられたパスワードをMD5ハッシュ化して格納していますが、これをユーザが直接指定することが出来るようになったわけです。MD5ハッシュ化した文字は簡単にはパスワードに逆変換できないため、漏洩時のリスクを小さくすることが可能です(漏洩しても絶対大丈夫という意味ではありません)。 パスワードとユーザ名を連結した文字列をRedshiftのMD5関数に通すことで、必要なハッシュ化文字列が得られます。詳しくは以下のCREATE USERのマニュアルをご参照ください。PASSWORD引数の書き方の部分に例とともに解説があります。(※執筆時点では英語版にして確認する必要がありました) 参考)CREATE USER 新しいSVV_TRANSACTIONSビューが提供されました。このビューをクエリすることで今実行中のトランザクション一覧が得られます。granted列が’t’になっているトランザクションが、今ロックを保持している、つまり今実行されているSQLです。これが’f’の場合はロックを待っているSQLという事になります。このビューでロック競合で待たされているトランザクションを発見することが容易になります。 参考)SVV_TRANSACTIONS SAS/ACCESSのRedshift対応が拡張され、自動的なプッシュダウン等がRedshiftに対して有効になりました。これまでもSASからRedshiftへ接続してデータ分析を行う事が可能でしたが、機能拡張され、 Implicit pass-through機能が有効になりました。これはSASへのクエリの一部をSQLに変換してRedshift側に移譲(プッシュダウン)し、パフォーマンスを向上させる事が可能になっています。 SAS 9.4M3から対応されています。この他にも機能拡張されておりますので、詳細はSAS/ACCESSのWebサイトをご覧ください。同様に、分析ソフトとしては、SPSS (IBM)もRedshiftへのプッシュダウンに対応しています。 参考)SAS/ACCESS (原文):https://aws.amazon.com/jp/about-aws/whats-new/2016/04/amazon-redshift-announces-enhancements-to-data-loading-security-and-sas-integration/ 翻訳:下佐粉 昭(@simosako)

Read More

Redshiftアップデート:COPYやUNLOADでIAMロールを指定可能に

Amazon Redshiftにデータを読み込む際(COPY)やエクスポートする際(UNLOAD)、その読み書き先(S3)に対してのアクセスを実現するため、これまではCOPYやUNLOADコマンドの引数にIAMのキー情報(アクセスクリデンシャル)を付与する必要がありました。 これが拡張され、Redshiftクラスターに対してIAMロールを付与して、その付与したロールでCOPY、UNLOADができるようになりました。以下がリリースノートの翻訳です。 1つ、もしくは複数のAWS Identity and Access Management (IAM)ロールをRedshiftクラスターにアサインし、データロードやエクスポート時に使用することが可能になりました。Redshiftクラスターはデータロード時(COPYコマンド)やエクスポート時(UNLOADコマンド)に指定されたIAMロールを使用し、結果としてRedshiftから各種AWSサービス(S3等)への操作時に確実にクリデンシャルを利用することになります。IAMロールを使うことで、SQLにAWSアクセスクリデンシャルを埋め込む必要がなくなり、クラスターのセキュリティを向上し、データのロードやエクスポートをシンプルにします。 Redshiftクラスターは長い時間の(COPYやLOAD)オペレーション時には、定期的にIAMロールを再アシューム(Re-assume)します。つまり、暗号化キーを使ったCOPY、UNLOADする場合においてもコマンドは変更されていません。   リリースノート(原文):https://aws.amazon.com/about-aws/whats-new/2016/03/amazon-redshift-now-supports-using-iam-roles-with-copy-and-unload-commands/ 翻訳:下佐粉 昭(@simosako)

Read More

Redshiftアップデート:COPYやVACUUMの機能向上、クラスターリサイズの速度向上等

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。 Release: Amazon Redshift on 2016-03-17 Announcement: Amazon Redshift improvements and maintenance (Mar 17 – Mar 31) このリリースには以下の新機能が含まれています。 ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように 接続ログに、SSLのバージョンとSSLサイファーが記録されるように 1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。 デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は(今までと同様)常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。 参考)VACUUMコマンド ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。 2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。 今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。 Loading Your Data in Sort Key Order ※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。  条件は以下の通りで、これらを全て満たしている必要があります。 表がコンパウンドソートキー(Interleaved Sort Keyではなく)を使っていて、かつソートキー列が1つのみ ソートキーの列がNOT NULL 表が100%ソート済か、もしくは空(から) 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造(時系列でデータを入れ続ける)の場合に役に立ちます。 3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。 この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上(リサイズに掛かる時間の短縮)、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。 この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。 なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。 下佐粉 昭(@simosako)

Read More