embulk-output-redshiftを使えばテキストファイルを簡単にAmazon Redshiftにインポートできる。 だが、やはり気になるのはパフォーマンスだ。 という訳で、embulk-output-redshiftのパフォーマンスを計測してみた。 計測環境 AWSのリージョンはTokyoを使用した。 Redshiftのインスタンスはdc1.large。クライアントのインスタンスはm1.xlarge（4コア）だ。 インポート先のテーブルは、以下を用意した。 create table example ( id integer, num decimal(12,0), value1 varchar(60), value2 varchar(60), value3 varchar(60), value4 varchar(60), value5 varchar(60), value6 va

今回は、EmbulkでRedshiftにデータをロードするのを試してみたい。 マシンの準備 まずはRedshiftのインスタンスを準備する。 とりあえずは動作確認なので、一番安いdw2.largeにした。 うちの社内からデータをロードしようとすると、ユーザ認証が必要なプロキシを越えなきゃいけないので、めんどい。 そこで、EC2のインスタンスを立ち上げ、そこからロードすることにした。 テーブルの準備 JDBCドライバをダウンロードし、Redshiftのセキュリティ設定をして、SQLクライアントから接続する。 そこそこいろいろな型があるテーブルを作ってみた。 create table test1 ( id char(4), varchar_item varchar(20), integer_item int, numeric_item numeric(10,2), date_item date

先日、Redshiftのワークロードに割り当てたメモリや最大並列実行数を再起動なしで変更可能になりました。この機能を利用すると、日中はBIツールにリソースを優先的に割り当て、夜間はバッチ処理用といった異なるワークロードに対して柔軟にリソースの割り当て変更するなどの応用が考えられます。実際にバッチ処理用のキューを割当て動的変更した時の動作やこの機能の使い勝手についてレポートします。 WLM（ワークロードマネジメント） Redshiftには実行に長い時間を要するクエリー（ロングクエリー）は、クラスタ全体のボトルネックとなり、ショートクエリを待たせる可能性があります。そこで、用途ごとにクエリーの並列度やメモリ（％）の上限を設けた複数のキューを定義することでクエリー処理の制御が可能になります。 WLM（ワークロードマネジメント）の詳細につきましては、以下の資料を御覧ください。 AWS Black

Amazon Redshift が標準で提供している Redshift Console は 複数ノード構成のアクティビティの確認に便利な Performance ビューを提供しています。今回はメトリックスの読み解き方と、CloudWatchへのアラーム設定のポイントについてご紹介します。 Performance ビューとは Performance ビューとは Redshift メトリックスに対して、ノードごとのアクティビティをグラフ表示することで、Redshift の稼働状況をひと目で確認できる便利な機能です。また、メトリックスに対して、CloudWatchのしきい値とアラーム設定をすることで、これらアクティビティの監視を自動化できます。 メトリックスの目のつけどころ まずは各メトリックスの目的と、着目するポイントについて、ざっくりと解説します。 以下のメトリックスの例は、データをロード（

Amazon RedshitとTableau Softwareのパフォーマンスチューニング・改善ネタはこれまでも幾つかご紹介して来ましたが、Tableau Desktopのパフォーマンスチューニングで情報を検索してみたところ、Tableauの中の人が書いたと思しき関連資料を発見しました。 Basic Performance Tips.pdf | Tableau Support Community 当エントリではその資料をざっくりと読みつつ、Tableau Desktopの面からのパフォーマンス改善の策を探ってみたいと思います。 目次 環境 クライアントマシン ネットワーク環境 Tableau Server ブラウザ データベース アプリケーションチューニング インデックス 大きなデータ対応 NULLの扱い 計算 サマリーテーブル テクニック 自動更新設定をOFFにする データソースの設定

アプリケーションのログファイルをfluentdでS3に転送、S3からRedshiftに読み込んで集計、という流れはもはや鉄板パターンです。 これまではTSV形式で蓄積されているケースが多かったと思うのですが、2014年03月25のリリースでCOPY文がJSONフォーマットに（一応）対応したこともあり、とりあえずJSONで が最新のベストプラクティスになります。 おさらい 〜 fluentdを使ってJSON形式でS3にログを蓄積する 必要なもの fluentd本体 fluent-plugin-tail-ex fluent-plugin-s3 fluent-plugin-s3-alternative s3-alternativeを使うのは、 output_include_time false output_include_tag false 上記の設定を有効にして、純粋なJSON形式のフォーマ

昨年(2013年)8月にクラスメソッドにJOINして以来、『Amazon Redshift』と『Tableau Software』の両プロダクトに割と密接に携わって来ておりますが、気付けばAmazon Redshift周りで50本近く、Tableau Software製品についても20本以上、個人的にエントリを書いて来てました。(以下それぞれのエントリ一覧リンクとなります) Redshift ｜ 特集カテゴリー ｜ Developers.IO tableau ｜ 検索結果: ｜ Developers.IO そこで当エントリでは、この両プロダクトについてそのテーマや内容関する『まとめページ』を構成してみました。(以後、関連エントリ投下後に適宜更新・追記して行く予定です。) Amazon Redshift 公式 Amazon Redshift （ペタバイト級の データウェアハウス サービス）

Redshiftで色々環境構築や調査を進めて行くと、割とちょいちょい良く使うSQL等も出て来ます。そこでこのエントリでは、普段使っている便利系SQL、都度アクセスしてはコピペして使ってるようなSQL、更にはそれらにちょっと一手間加えたSQL等を集約し一覧としてみる事にしました。 必須なもの、また『これも使えるね』というようなものについては適宜追加更新を行っていこうと思ってますので、オススメのSQL文があれば是非教えて頂けると幸いです。 目次 S3からのCOPY処理エラーに関するログを確認する COPY処理時に出力させるエラー件数量を制御する 指定テーブルのテーブル定義を確認する(type1:psqlコマンドで簡易表示) 指定テーブルのテーブル定義を確認する(type2:distkey,sortkey等も表示) 指定テーブルのテーブル定義を確認する(type3:コメント文も併せて表示) テー

今回のre:Inventに参加して、この勢いは止められないとつくづく感じます。オンプレミスとAWSのすり合わせもかなり進んでおり、スタートアップからはAWSをベースにした新たなクラウドソリューションが次々と出ています。ほかのクラウドベンダとの差は縮まるどころか、拡がる一方でしょうね。 既存のRDBMSからRedshiftにJOIN ─⁠─前回お話を伺ったときはRedshiftが出てまもないころでしたが、その後、Hapyrusのビジネスも含め、Redsiftの市場における認知度はどれくらい高まってきた感じですか。 藤川：ものすごく応用範囲が拡がってきていると実感します。現在AWSが公開している事例から紹介すると、英BBCがグローバルで展開するコンテンツの分析をRedshift経由でオンデマンドで行うなど、大規模環境での利用が増えてきています。米国では金融やアドテクの事例が多いですね。とくにト

Redshiftでテーブル定義やエラーログの確認・調査を行いたいときによく使うクエリを3つ紹介します。 テーブル定義の確認 既存のテーブル定義を確認したいときは次のクエリを発行します。 SELECT * FROM pg_table_def WHERE tablename = 'テーブル名' 確認できる情報は以下の通りです。 schemaname（publicとか） tablename（テーブル名） column（カラム名） type（カラムのデータ型・VARCHARなど） encoding（圧縮アルゴリズム。deltaとかtext255とか） distkey（DISTKEY指定フラグ） sortkey（SORTKEY指定フラグ） notnull（NotNULL制約フラグ） 自動選択されたCompression Encodingsを確認したい場合にもこのクエリを利用します。 テーブル一覧の確

新年あけましておめでとうございます！しんやです。今年もよろしくお願いしますと言う事で2014年1発目のエントリです。 本日1/6は仕事始め。社内での全体朝礼の後、社員皆で秋葉原の弊社から10分程歩き、神田明神へ参拝に行ってきました。 神田明神 - Wikipedia 神田明神｜東京都千代田区外神田2-16-2 当初、10分程ちょちょい〜と歩いて、15分程軽くお参りしてそのまま帰ってくるのかな〜、という位のノリだったのですが、付近まで来てみると...予想以上の、想像以上の人の列!! 列の最後尾は緩やかな坂の下まで続いておりました。そして鳥居の辺りからは一面びっしり人の波。 参拝後は逆サイドから回って鳥居入り口まで戻り、来た道を帰って行ったのですが、正直ここまでの混雑、正直神田明神を甘く見てました...神田明神パネぇ!! さて、ここから本題。Amazon Redshiftにアクセス出来る専用ツ

This domain may be for sale!

Amazon Redshiftには、復数のクエリキューを定義し、実行時にクエリを適切なキューで走らせる事が出来るワークロード管理(WLM:Workload Management)というものがあります。 実行時間の長いクエリは、パフォーマンスのボトルネックになる事があります。例えば、あるデータウェアハウスで、ユーザーが2つのグループを持っているとします。1つのグループは、幾つかの大規模なテーブルから行を選択し、並べ替え、時折実行時間の長いクエリを送信します。2つ目のグループは頻繁に1〜2つのテーブルから少数の行を選択し、数秒で終るような実行時間の短いクエリを送信します。この状況では、実行時間の短いクエリは長く実行時間の掛かるクエリが完了するまで待機する必要が出て来ます。 実行時間の長いクエリ及び短いクエリに対する個別のキューを作成する際、WLM構成を変更する事により、システムのパフォーマンス

頭の中の整理と備忘録として。 前提条件 ・Redshiftのクラスタが作成済みであること。 ・psql等でRedshiftに接続できる環境が用意済みであること。 ※私はこちらの記事を参考にしました。 Amazon Redshiftを始めてみよう(入門ガイド翻訳＆実践：前編) ｜ Developers.IO Amazon Redshiftを始めてみよう(入門ガイド翻訳＆実践：後編) ｜ Developers.IO 現在の圧縮エンコードやdistkey、sortkeyの情報を確認するクエリ select * from pg_table_def where tablename = 'table_name'; ロードエラー時のエラー内容を確認するクエリ 1.エラー参照用のviewテーブルを作成する create view loadview as ( select distinct tbl, tri

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

お盆真っ盛り＆暑さ最高潮＆夏休みムード漂う今日この頃ですが皆様いかがお過ごしでしょうか。 最近はAmazon Redshiftに関して色々調査実践等を行なっているのですが、Amazon Redshiftで収集したビッグデータを扱う『分析ツール』もまた欠かせないものであると思います。今回、BI(ビジネス・インテリジェンス)ツールとして『Tableau』という企業の製品が良い感じですよ、という情報を得たのでトライアル版を導入し、動作確認やRedshiftとの連携等を試してみました。 目次 Tableau Softwareとは Tableau Softwareの製品一覧 Tableau Desktopを試しに使ってみる Tableau Desktop: オンライン無料入門トレーニング Tableau製品に関する各種ドキュメント Amazon Redshiftとの連携 まとめ Tableau So