AWS Data Wranglerを使って、簡単にETL処理を実現する | Amazon Web Services
Amazon Web Services ブログ AWS Data Wranglerを使って、簡単にETL処理を実現する 2019年9月、Github上にAWS Data Wrangler(以下、Data Wrangler)が公開されました。Data Wranglerは、各種AWSサービスからデータを取得して、コーディングをサポートしてくれるPythonのモジュールです。 現在、Pythonを用いて、Amazon Athena(以下、Athena)やAmazon Redshift(以下、Redshift)からデータを取得して、ETL処理を行う際、PyAthenaやboto3、Pandasなどを利用して行うことが多いかと思います。その際、本来実施したいETLのコーディングまでに、接続設定を書いたり、各種コーディングが必要でした。Data Wraglerを利用することで、AthenaやAmazo
Amazon Redshift 待望の PL/pgSQL のストアドプロシージャをサポートしました | DevelopersIO
はじめに ついにPL/pgSQLのストアドプロシージャがサポートされました。これはプロシージャの記述言語にPL/pgSQLが使えるようになり、更にPL/pgSQLを用いてストアドプロシージャが書けるようになるという２つの大きなアップデートを含みます。リリースバージョン 1.0.7562から利用可能になりました。新たに追加になったPL/pgSQLとそのストアドプロシージャについて解説します。 最新クラスタにアップデート PL/pgSQLとは PL/pgSQLの特長 ストアドプロシージャとは ストアドプロシージャの特長 ストアドプロシージャの例 ユースケース 最新クラスタにアップデート クラスタを確認して新しいクラスタ(Cluster Version 1.0.7562 )がスタンバイしている場合は、直ちにアップデートします。 PL/pgSQLとは PL/pgSQLは、PostgreSQLの手続
Amazon Redshift Spectrum 12 のベストプラクティス | Amazon Web Services
Amazon Web Services ブログ Amazon Redshift Spectrum 12 のベストプラクティス 2019/7/22 に一部内容を更新しました． Amazon Redshift Spectrum を使うことで、Amazon S3 に置かれたデータに対して Amazon Redshift の SQL クエリを走らせることができます。つまり Redshift Spectrum によって、データウェアハウスのローカルディスク内に保存されたデータ以外に対しても、Redshift の分析を拡張できるようになるのです。S3 の “データレイク” に貯まった大量のデータに対して、面倒で時間のかかる抽出・変換・ロード（ETL）処理を行うことなく、クエリを投げることができます。Redshift Spectrum は洗練されたクエリ最適化を用いて、数千ものノードにまでスケールして高
AWS News Blog
New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute
Amazon Redshift および PostgreSQL - Amazon Redshift
Amazon Redshift は PostgreSQL に基づいています。Amazon Redshift と PostgreSQL の間には非常に重要な相違点がいくつかあり、データウェアハウスアプリケーションを設計して開発するときはそれを考慮する必要があります。 Amazon Redshift は、具体的には、大規模データセットに対して複雑なクエリを行う必要があるオンライン分析処理 (OLAP) アプリケーションおよびビジネスインテリジェンス (BI) アプリケーション向けに設計されています。Amazon Redshift は多種多様な要件に対処するため、Amazon Redshift で使用する専用のデータストレージスキーマおよびクエリ実行エンジンは PostgreSQL の実装とは完全に異なります。例えば、オンライントランザクション処理 (OLTP) アプリケーションが一般的にデータ
4日間のNetezza研修に行ってきたのでNetezzaのアーキテクチャについて書いてみる。 Netezzaの全体像はこんな感じです。 SMP hostというのがクエリを受け付けてparseして最適化してプランを作ります。SMP hostのDiskはDRBDで二重化されています。 プランはSnippetという単位になりそれが各SPUにばらまかれて並列処理されます。 各SPUでC++コードの生成、コンパイル、実行という処理を行いますが、2回目以降はコンパイル済みのオブジェクトコードがキャッシュされるので早くなります。 SPUはSnippet processing unitの略でCPU, FPGA, Memoryを持ちます。 FPGAで解凍処理や行、列の絞り込みを行うことによって性能向上をはかります。 CPUの仕事を減らしてハード側でなるべく処理させるという感じでしょうか。 テーブルを作るとき
fluentdで集約したログをRedshiftに投入するのに、これまでは fluent-plugin-redshift を使っていたのですが、諸々の理由でこれを置き換えるツールをGoで書きました。 Rin - Redshift data Importer by SQS messaging. プロダクション環境に投入して、2週間ほど快調に動作しているので記事を書いておきます。 アーキテクチャと特徴 S3にデータが保存されたタイミングで、Amazon SNS または SQS にメッセージを飛ばすイベント通知機能がありますので、それを利用しています。 (何者か) S3 にデータを保存する (fluent-plugin-s3, その他どんな手段でも可) (S3) SQS に S3 の path 等が記述されたメッセージを通知する (Rin) SQS のメッセージを受信し、Redshift へ CO
レビュー自動承認化と精度100%を目指して。いち早く生成AIの導入に踏み出した「ユーザーレビュー基盤」の取り組み
Amazon Redshift クエリパフォーマンスチューニング ベストプラクティスを読んでみた | DevelopersIO
Amazon Redshiftでは『ベストプラクティス』なるテーマで、それぞれの局面でのお作法的な設定、改善の為のノウハウがドキュメントとして適宜追加or更新されています。ちょうど去年の8月にクラスメソッドにジョインした際もこの辺りのドキュメントについて幾らか目を通して参りましたが、英語ドキュメントを訪れてみると更に充実した形で『ベストプラクティス』が整備されているようです。そこで当エントリでは『クエリパフォーマンスチューニング』という切り口で更新されている以下ドキュメントを改めて読み直してみたいと思います。 Amazon Redshift Best Practices - Amazon Redshift 目次 1.パフォーマンスを考慮したテーブル設計を行う 1-a.最善のソートキーを選択する 1-b.最善の分散キーを選択する 1-c.COPY時に『自動圧縮あり』でデータをロードし、オスス
こんにちは！中の人です。 前回までのレシピでは、下記の３回にわたってRedshiftに対して負荷をかけるテストを行って来ました。 ■Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較（シングル）～ ■Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較（マルチ）～ ■Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較（XL vs 8XL）～ 今回は、それらの内容のまとめをお話したいと思います。 ■ 約8千行（10回平均）に対するクエリ実行 分かりやすくグラフにまとめてみました。 棒グラフ：実行時間(秒) 折れ線グラフ：CPU負荷率(%) となっております。 CPUは8XLが圧倒的に安定していますが、処理速度は件数が少ない場合にはかえってパフォーマンスが落ちることが確認できます。 ■ 約60万行（10回平均）に対するクエリ実行
Amazon Redshiftについて色々と聞く機会があった。その時聞いたことメモ。 Amazon EMRとAmazon Redshiftの違い まずは、よく比較されることになるEMRとRedshiftの違いから。 Amazon EMR HadoopクラスタとHiveを簡単に使うためのサービス。自由な台数のクラスタを自由なタイミングで起動したり破棄したりできる。 Hadoopクラスタ運用(初期設定、チューニング、等)の手間が完全に不要なのはものすごいメリット。 クエリの速さは、ログの量によりますが、数分～数十分くらいかかる。(ログの行数が数百万～数千万ある時) 利用者から見た基本的な用途・できることはEMRとほとんど同じ。ただ、仕組みが全く違う。 RedshiftはRDBのような(Postgresベースらしい)テーブル設計を持つ。例えば、VARCHAR(255)みたいなカラムを持つ。EMR
Amazon Redshift: WLM(Workload Management)のクエリ同時実行制限値が緩和されました | DevelopersIO
先日2014/04/18のRelease Notesにて、Amazon RedshiftのWLM(Workload Management)に於ける同時実行の制限(上限値)を増やせるようになりました。当エントリではその内容について実際に変更してみるなどしてみたいと思います。 Release: Amazon Redshift on 2014-04-18 : Release Notes : Amazon Web Services 目次 クエリキューの定義とは 変更前(デフォルト値)の内容及び挙動の確認 パラメータの変更及び反映内容の確認 まとめ クエリキューの定義とは Amazon Redshiftでは、ユーザー定義のクエリキューで最大50のクエリを同時実行出来るような設定が可能となりました。これにより、ユーザーがWLM構成を変更する事でシステムのパフォーマンス管理に対するより柔軟な対応が行える
最終的には縦持ちにしちゃえばどんなRDBでも扱えるんだけど、 某MySQLとか某Hadoopとかだと配列で持ってるじゃないですか。 ああいうのをどうやってとりこむか1年くらい考えてたんだけど ついに決定版を思いついた。 扱える個数の上限はあるんだけど、現実的にはほぼ上限を考えなくて済むと思う。 1. 文字列配列をJSONとしてRedshiftに取り込む => select * from slog order by 1; id | words ----+--------------- 1 | ["a","b","c"] 2 | ["xxx","yyy"] 2. 連番 1 カラムだけのテーブルを用意する この連番テーブルのサイズが扱える個数の上限になってしまうので注意 => select * from sseq order by 1; x --- 1 2 3 4 5 3. ジョインする 不等号
Amazon Redshiftで良く使いそうな便利系SQLをまとめてみた | DevelopersIO
Redshiftで色々環境構築や調査を進めて行くと、割とちょいちょい良く使うSQL等も出て来ます。そこでこのエントリでは、普段使っている便利系SQL、都度アクセスしてはコピペして使ってるようなSQL、更にはそれらにちょっと一手間加えたSQL等を集約し一覧としてみる事にしました。 必須なもの、また『これも使えるね』というようなものについては適宜追加更新を行っていこうと思ってますので、オススメのSQL文があれば是非教えて頂けると幸いです。 目次 S3からのCOPY処理エラーに関するログを確認する COPY処理時に出力させるエラー件数量を制御する 指定テーブルのテーブル定義を確認する(type1:psqlコマンドで簡易表示) 指定テーブルのテーブル定義を確認する(type2:distkey,sortkey等も表示) 指定テーブルのテーブル定義を確認する(type3:コメント文も併せて表示) テー
AWS SDK for Rubyでインスタンスをまとめて起動/停止するスクリプトを書きました。 特定の時間しか使わないインスタンスが複数あるのですが、これらをスケジュールにしたがってまとめて起動・停止するために、いままでCloudworksを使わせていただいていたのですが、スクリプトを書いてJenkinsから実行するようにしました。 まず、AWS SDK for Rubyのインストールですが、gemでインストールできます。Ubuntuの初期状態だと、他にいくつか必要なパッケージがありました。 sudo apt-get install ruby-dev sudo apt-get install libxslt-dev libxml2-dev sudo gem install aws-sdk スクリプトは以下のようなものです。 複数のインスタンスをまとめて操作するために、あらかじめAWS Co
更新版がこちらにありますので、こちらもぜひご覧ください。 これからAmazon Redshiftを始める技術者が注意すべき２２つのポイント Amazon Redshiftを使った実案件を経験してこれは注意したほうがいいなというポイントをまとめました。自分が経験した範囲で書いているので多少偏っているかもしれませんが、参考になれば幸いです。データウェアハウスって何？という方は以前入門記事を書きましたのでこちらの記事をご覧ください。 気軽に始めてみよう！クラウド時代のデータウェアハウス超入門 注意事項一覧 PostgreSQLと違う点に注意！ １件ずつINSERTするととても遅いので注意！ 主キー制約、一意制約、外部キー制約は違反してもエラーにならないので注意！ COPYコマンドは全件INSERTなので注意！ CSVでアップロードする場合の注意点！ サポートしているデータ型に注意！ エンコーディ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Redshiftの開発者がこれだけは知っておきたい10のTIPS / 第18回 AWS User Group - Japan
