Content-Length: 333665 | pFad | http://b.hatena.ne.jp/girled/AWS/Redshift/
AWS Payments が Redash から Amazon Redshift クエリエディタ V2 に移行した話 | Amazon Web Services
Amazon Web Services ブログ AWS Payments が Redash から Amazon Redshift クエリエディタ V2 に移行した話 この記事は How AWS Payments migrated from Redash to Amazon Redshift Query Editor v2 の翻訳記事です。 AWS Payments は、AWS 請求書の支払いというカスタマーエクスペリエンスを提供する AWS コマースプラットフォーム (CP) 組織の一部です。AWS のお客様が支払い方法と支払い設定を管理するのに役立ち、お客様が AWS にセルフサービスで支払いするのに役立ちます。 AWS Payments の機械学習、データ、分析 (MLDA) チームは、一連のスケーラブルなデータ、インサイト、ML 推論に関するサービス群を通じてデータ、ビジネスインサイ
SnowflakeとRedshiftの比較検証
300コア近くのRedshiftクラスタを運用している広告配信プロダクトでSnowflakeを検証した結果をご紹介します。
Amazon Redshift 新しい圧縮エンコーディング『AZ64』とLZO、ZSTDの徹底比較 | DevelopersIO
Amazon Redshift 新しい圧縮エンコーディング『AZ64』とLZO、ZSTDの徹底比較 これまでは主に高速なLZO、高圧縮なZSTDの2つ圧縮エンコーディングをノードタイプやワークロードに応じて選択していましたが、新たに追加されたAZ64は高速と高圧縮な特性を兼ね備えています。今回は新たに追加されたAZ64について検証したいと思います。 Amazon Redshift が最適化されたストレージと高クエリパフォーマンス向けの新しい圧縮エンコーディングである AZ64 をリリース 以下、本文の抜粋です。 高い圧縮率と改善されたクエリパフォーマンスの達成を目的として設計された独自の圧縮エンコーディングである AZ64 が利用可能になりました。革新的な AZ64 アルゴリズムは、データ値の小さなグループを効率的に圧縮し、SIMD 命令を活用してデータを並列処理します。このエンコード
近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している - データエンジニアの酩酊日記
久しぶりにペラペラな思いつきを書き捨てて、寝ます。 2、3年前ぐらいにSIerやコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。 AWSのReadshiftしかり。 なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。 Treasure Dataは基本的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。 Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変って
Amazon Redshift：ALTER TABLE文でVARCHAR型の桁数を増やせるようになりました | DevelopersIO
小ネタです。 Amazon Redshiftのメンテナンスアップデートにて、You can now use the ALTER TABLE command to increase the size of VARCHAR columns.(ALTER TABLEコマンドを使用してVARCHAR列のサイズを増やすことが出来るようになります)というものがありましたので試してみました。 AWS Developer Forums: Amazon Redshift Maintenance (February 20th - March 21st 2019) なお、検証は管理コンソールにて現時点でのクラスタ最新バージョンにアップグレードを行った上で行っています。 コマンド1つでVARCHAR型の桁数定義を変更(増分)可能に 検証用に、簡易ではありますが以下テーブルを用意しました。 $ CREATE TAB
Amazon Redshift で VACUUM DELETE の自動実行が開始
Amazon Redshift で、VACUUM DELETE オペレーションが自動実行されるようになりました。これにより、それまでの UPDATE および DELETE オペレーションで削除マークが付けられていた行により占有されていたディスク空間が返却されます。また、テーブルのデフラグが実行されるため、断片化で消費されていた空間が解放され、ワークロードのパフォーマンスが向上します。 VACUUM DELETE の実行スケジュールは、クエリ負荷とテーブル内の削除済み行数に基づいて設定されます。例えば、ユーザーやクエリへの影響を抑えるため、負荷の高い期間には VACUUM DELETE の実行頻度が下がります。VACUUM DELETE の実行は、入力されたクエリの負荷が高いときには自動的に一時停止し、しばらくたってから再開されます。Amazon Redshift ではバキューム処理が不要な
【新機能】Amazon Redshift の Interleaved Sorting機能を試してみた | DevelopersIO
はじめに 2015年05月11日にAmazon Redshift の Interleaved Sorting機能のリリースが発表されました。 データ分析では複数の分析軸によるデータディスカバリーが求められますので、DWHは高速に異なるカラムの検索や集計が必要とされます。既存のソートキー(COMPOUND SORTKEY)は、ソートキーの定義に無いカラムでは全てのブロックのスキャンが発生するので相対的に早くないという課題がありました。今回の Interleaved Sortingのリリースによって、ソートキーに指定した複数のカラムに対して、クエリーのフィルタを柔軟かつ高速に行えるようになりました。 昨年のre:invent2014のSDD414 - Amazon Redshift Deep Dive and What’s Next の "Multidementional indexing w
Amazon Redshift 新機能：『Elastic Resize』で短時間でのノード数変更(リサイズ)が可能になりました | DevelopersIO
Amazon Redshift 新機能：『Elastic Resize』で短時間でのノード数変更(リサイズ)が可能になりました 日本時間の2018年11月16日、下記ツイートにありますようにAmazon Redshiftにて『Elastic Resize』なる機能・仕組みが新たに導入されました。 Today's #AWSLaunches! 3/5 ⭐ AWS Cost & Usage Reports add Athena integration, Apache Parquet Output & Report Overwrite ⭐ Amazon Redshift announces Elastic resize, so you can add & remove nodes in minuteshttps://t.co/r8ekyCt1bR pic.twitter.com/6469grjiY
これからAmazon Redshiftを始める技術者が注意すべき２２つのポイント | DevelopersIO
はじめに ２年ほど前にRedshiftを使う際に注意すべき点をまとめた記事を書いたのですが、その後Redshift案件をいくつか経験し、項目を追加したくなったのでもう一度まとめました。Redshiftを業務で使う方はぜひ読んでほしいです。1から11までは以下のページになります。 これからAmazon Redshiftを始める技術者が注意すべき１１つのポイント 注意事項一覧 ALTER TABLE RENAMEでテーブル名を変更するとViewの参照先が変わるので注意！ ALTER TABLE APPENDで移動したデータは未ソートになるので注意！ UDFのパフォーマンスに注意！ TO_TIMESTAMP関数がないので注意！ VARCHAR(65535)は推奨されていないので注意！ 統計情報の鮮度とソートされていない行の割合に注意！ 削除マーク付きのレコードが増えるとパフォーマンスが落ちるので
Amazon Redshift: VACUUM処理が必要なテーブルを改めて洗い出す | DevelopersIO
当エントリで紹介しているものより、もうちょっと便利なSQLを 下記エントリで紹介しています。宜しければご参照ください。 Amazon Redshift: ソートキーを指定してないとVACUUMの恩恵に預かれないというお話(&VACUUM対象テーブル抽出 改良版SQL付) ｜ Developers.IO 超小ネタです。 以前、以下のエントリを投稿しましたが、スキーマを分割していたりすると、そもそも『このテーブル、どこのスキーマだっけ？』となる事がありました。なので、以前の内容を踏まえつつ、若干の手直しを加えたものを備忘録として投稿しておこうと思います。 Amazon Redshift Useful SQL: VACUUM処理が必要なテーブルを洗い出す ｜ Developers.IO 手直し版が以下SQL。svv_table_infoテーブルからスキーマの情報を参照して、併せて出しています。
Amazon Redshift とは - ablog
AWS Black Belt Online Seminar Amazon Redshift from Amazon Web Services Japan Amazon Redshift は高速で完全マネージド型、ペタバイト規模のデータウェアハウスです。既存のビジネスインテリジェンスツールを使用して、すべてのデータをシンプルかつコスト効果の高い方法で分析できます。 Amazon Redshift（高速でシンプルなデータウェアハウス）｜AWS Amazon Redshift, a hosted data warehouse product, forms part of the larger cloud-computing platform Amazon Web Services. It is built on top of technology from the massive paralle
Amazon Redshiftで良く使いそうな便利系SQLをまとめてみた | DevelopersIO
Redshiftで色々環境構築や調査を進めて行くと、割とちょいちょい良く使うSQL等も出て来ます。そこでこのエントリでは、普段使っている便利系SQL、都度アクセスしてはコピペして使ってるようなSQL、更にはそれらにちょっと一手間加えたSQL等を集約し一覧としてみる事にしました。 必須なもの、また『これも使えるね』というようなものについては適宜追加更新を行っていこうと思ってますので、オススメのSQL文があれば是非教えて頂けると幸いです。 目次 S3からのCOPY処理エラーに関するログを確認する COPY処理時に出力させるエラー件数量を制御する 指定テーブルのテーブル定義を確認する(type1:psqlコマンドで簡易表示) 指定テーブルのテーブル定義を確認する(type2:distkey,sortkey等も表示) 指定テーブルのテーブル定義を確認する(type3:コメント文も併せて表示) テー
Amazon Redshift編～データをインポートしてみよう！(エラー編)～
こんにちは！中の人です。 今回も前回のレシピに引き続き、Amazon Redshift編です！ 今まで4回にわたってAmazon Redshiftでのデータのインポート方法について紹介させてもらいましたが、実際に操作を行なっていると様々なエラーが返ってきます。 記事を書く中でも数々のエラーが出ました。今回のレシピでは、エラーメッセージとその対処方法について紹介します。 ※ 『SQL Workbench』での操作をベースとして記述しております。 今までのAmazon Redshiftでのデータのインポートに関するレシピは下記を参照してください。 ■ Amazon Redshift編～CSVファイルのデータをインポートしてみよう！～ ■ Amazon Redshift編～MySQLのデータをインポートしてみよう！～ ■ Amazon Redshift編～複数ファイルを一括インポートしてみよう！
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/girled/AWS/Redshift/
Alternative Proxies:
Redshift - Unsupported PIVOT column type： text - Stack Overflow