新しい統合 SYS ビューを使用して Amazon Redshift のモニタリングを簡素化 | Amazon Web Services
Amazon Web Services ブログ 新しい統合 SYS ビューを使用して Amazon Redshift のモニタリングを簡素化 Amazon Redshift は、クラウドにおけるフルマネージド型のペタバイト規模のデータウェアハウスサービスであり、他のどのクラウドデータウェアハウスよりも最大 5 倍優れたコストパフォーマンスを実現し、追加費用なしですぐにパフォーマンスの革新的な向上を実現できます。 何万ものお客様が Amazon Redshift を使用して毎日エクサバイト単位のデータを処理し、分析ワークロードを強化しています。 この記事では、Amazon Redshift SYS モニタリングビューについて説明し、Amazon Redshift のワークロードとリソース使用量のモニタリングを簡素化する方法について説明します。 SYS モニタリングビューの概要 SYS モニタ
ドコモ3年目社員がRedshiftの10年モノの技術負債解消にチャレンジしてみた - ENGINEERING BLOG ドコモ開発者ブログ
はじめに システム概要 長時間Vacuumの回避 列指向データベース Vacuumが走りにくい処理への変更 Truncateの積極活用 時系列テーブルの使用 ディープコピーの実行 Vacuumの頻度・範囲見直し 他にも改善策として挙げられるもの Concurrency Scalingの導入 Redshift Serverlessの導入 おわりに はじめに NTTドコモ データプラットフォーム部（以下DP部）木村です。 NTTドコモでは「通信」だけでなく「決済・保険・投資」「エンタメ」をはじめとした様々なサービスをコンシューマー向けに提供しています。 DP部では様々なサービスに対して、データドリブンの価値創造をあたりまえにすべく、データ基盤開発・データ分析・ナレッジ集約・データ活用人材育成を実施しています。 本記事では私が3年目社員だった22年度に取り組んだ、約10年前から稼働しているデータ
クエリプランを Amazon Redshift のクエリレポートと関連付ける
簡単な説明 Amazon Redshift でクエリを実行するのに必要な使用方法を判断するには、EXPLAIN コマンドを実行します。EXPLAIN コマンドから返される実行プランには、関連するクエリプランと実行ステップの概要が記載されています。次に、SVL_QUERY_REPORT システムビューを使用して、クラスタスライスレベルでクエリ情報を表示します。スライスレベルの情報を使用して、クエリのパフォーマンスに影響を与える可能性のあるクラスター全体で不均一なデータ分散を検出できます。 Amazon Redshift はクエリプランを処理し、ステップ、セグメント、ストリームに変換します。詳細については、「クエリプランと実行ワークフロー」を参照してください。 解決策 テーブルを作成し、クエリの実行プランと SVL クエリレポートを取得する テーブルを作成して実行プランと SVL クエリレポー
Simplify Online Analytical Processing (OLAP) queries in Amazon Redshift using new SQL constructs such as ROLLUP, CUBE, and GROUPING SETS | Amazon Web Services
AWS Big Data Blog Simplify Online Analytical Processing (OLAP) queries in Amazon Redshift using new SQL constructs such as ROLLUP, CUBE, and GROUPING SETS Amazon Redshift is a fully managed, petabyte-scale, massively parallel data warehouse that makes it fast, simple, and cost-effective to analyze all your data using standard SQL and your existing business intelligence (BI) tools. We are continuou
Amazon Redshift のパフォーマンスチューニング 十ヶ条まとめ - Qiita
Amazon Redshift は Serverless版もGAされ、さらにATO：Automatic Table Optimization（自動テーブル最適化）など、従来からある Provisioned版含めてパフォーマンスチューニングがどんどん自動化されてきている。 一方で、実運用では高負荷など使い方によって問題が全く起こらないことは考えにくく、困った時にチューニングの余地があることはメリットでもある。 以下の公式ブログの Tips をもとに困った時のチューニング対処ポイントをまとめる ※ 記事は 2020年 のものなので、その後新機能でカバーできる点や、主観的な考えについて適宜補足しています。 [1] マテリアライズドビューを使う 予測可能で何度も繰り返されるクエリに特に効果を発揮する 内部テーブルだけでなく、外部テーブル（Spectrumやフェデレーション）にも使える マテビューの
【Redshift】2022年下半期の最新情報まとめ - Qiita
クラウドデータウェアハウスの雄、Redshiftの2022年下半期最新動向をまとめてみました。 普段からRedshiftを触っていても、最新動向のキャッチアップは優先度が低くなりがちだと思いますので、本記事をお役立てください。 2022年上半期の最新動向はこちらにまとめておりますので、是非あわせてお読みください。 Redshiftについて Redshiftは、データウェアハウス、運用データベース、データレイクにわたる構造化・半構造化データを、あらゆる規模でコスパ良くSQLで分析できるサービスです。 2012年に初めてのクラウドデータウェアハウスサービスとしてリリースされました。 今年が10周年となります。 出典: Redshift公式ページ 約半年前の公式ページの画像は以下のものだったのですが、現在は上の画像に変更されており、Redshiftの機能がさらに拡充されていることを印象付けられま
Redshift 覚書
Redshift AWS で利用可能なサービス。パブリッククラウドサービスで安価に利用できるDWH製品。 列指向型データベースで列の集計処理などに最適化されているため、その類の用途で非常に有用なデータベースと言える。 特定のワークロードにに特化したデータベースのため用途を考慮して利用すべき。 向いているワークロード 大規模なデータセット(数GB~PB) データの更新は一括。OLTPのような処理は想定しない 1つ1つのSQLは複雑だが同時実行数は少ない。 仕組み Redshift は主にリーダーノード、コンピューティングノードの2コンポーネントから物理的にはクラスターが構成される。 また、コンピューティングノードの中は、ノードスライスという処理の実行単位に論理的に分割されている。 リーダーノード クライアントプログラムから直接接続されるいわば司令塔。 実行計画に基づいて、コードをコンパイルし
【AWS Redshift】導入前に知っておくべきこと - packpak’s diary
AWS Redshiftを導入する前に知っておくべき、AWS Redshift の特性、長所、他所を開発・運用してきた中で要所っぽいところをいくつかTips的にまとめた。 字量が非常に多くて申し訳ないが、参考になれば。 RDBに比べて有用なケース/苦手なケース 下記のケースに合致する。 SQL文をベースとした、複雑で演算コストの高いETL（分析用途用のデータ加工処理の通称）の実行 BIツールのような、3～5列程度の列を利用した参照クエリの実行。 下記のケースは向かない。 短時間で非常に多くのクエリを実行するアプリケーション（1秒に5～10クエリなど）のバックエンド 短時間で非常に多くのCommitを実行するアプリケーション（Webフレームワークが勝手に）のバックエンド 一度に多くの列を取得するクエリを発行するアプリケーション（CSV出力など）のバックエンド 性能について クエリの性能 1つ
Redshift クエリのパフォーマンス分析 - Qiita
Redshiftで遅いSELECT文のパフォーマンス分析した時の手順等メモ。 1. 分析対象SQLの実行 -- このセッション中でクエリ結果キャッシュを無効にする SET enable_result_cache_for_session TO off; -- 分析対象SQLを実行 -- SQLのコンパイル時間を除くため、分析対象SQLを再度実行 -- 現在のセッションで最後に実行されたクエリのクエリIDを取得 SELECT pg_last_query_id(); -- アラートが出てないか -- https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_STL_ALERT_EVENT_LOG.html SELECT * FROM stl_alert_event_log WHERE query = クエリID; -- 実行計画 -- http
最新のログもすぐクエリできる速くて容量無限の最強ログ基盤をRedshift Spectrumで作る - クックパッド開発者ブログ
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
RedshiftとBigQueryでよく使うSQLの違いTips - Gunosyデータ分析ブログ
データ分析部インターン生の小川です。インターンでは主に動画収集のロジック実装に取り組んでいました。 Gunosyではログの管理にRedshiftとBigQueryを使用しています。 サービスはAWS上で動いているものも多いので基本はRedshiftで、ログの量が多いものやアドホック分析に用いるものはBigQueryに格納しています。 この2つのサービスでSQLの書き方が微妙に異なるところがあり、もどかしい経験をしたので、今回は、よく使うSQLの文法でRedshiftとBigQueryで表現が異なる所をまとめてみようと思います。 BigQueryの導入についてはこちらの記事をご覧ください。 また、この記事ではBigQueryはStandard SQLで記述していきます。 data.gunosy.io 日付・時刻関数 現在時刻(UTC) 現在時刻(JST) 現在の日付(UTC) 現在の日付(J
ドリコムを支えるデータ分析基盤がTD+AWSに移行した話 - かにぱんのなく頃に
はじめに これは ドリコムAdventCalendar の7日目です 6日目は、keiichironaganoさんによる iTunes 使用許諾更新のとき一旦キャンセルしてほしい話 です 【その2】ドリコム Advent Calendar 2015 もあります 自己紹介 @ka_nipan 去年の ドリコムを支えるデータ分析基盤 に引き続き、今年もドリコムのデータ分析基盤を担当しています。 分析基盤をTreasure Dataに移行 オンプレ環境の Hadoop からTreasure Data に移行しました。 また、ジョブ管理ツールやBIツールといったサーバーもAmazon EC2 に移行しており、 徐々にオンプレ環境を離れつつあります。 背景 オンプレ環境で Hadoop を運用して3年も経つと考えなければならないのが HW の寿命です。 さてどうしようかとなった時に、ほぼ迷いなく外部
Amazon SQSを利用してS3からRedshiftにデータ投入するRinというツールを書いた - 酒日記 はてな支店
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
『アドテクスキルアップゼミ カラムナーデータベース検証まとめ』
皆様こんにちは。 アドテク本部カラムーデータベースゼミチームです。 今回の記事ではゼミチームが行った検証結果について発表させていただきます。 また、この記事につきましては 11/12 に行われた db tech showcase Tokyo 2014 にて発表させて頂きました内容になります。 プレゼン資料はこちらにあがっています。 ※追記 Impala / Presto の File Format についてご指摘を頂きましたのでデータロード及びまとめの部分に追記しました。 アドテクスキルアップゼミ カラムナーデータベース検証まとめ目的 広告システムでは大量のデータをデータベースに入れて解析を行います。 小規模から中規模なデータはRDBMSで行えますが、数TBを超えると RDBMS以外の選択肢を探さないといけません。 ビッグデータ用のデータベースは比較資料が少なく、 また、あったとしても検証
AWS Casual 02: ふつうのRedshiftパフォーマンスチューニング
ふつうのRedshiftパフォーマンスチューニング @ AWS Casual 02, 2014-04-18Read less
MPP on Hadoop, Redshift, BigQuery - Go ahead!
Twitterで「早く今流行のMPPの大まかな使い方の違い書けよ！」というプレッシャーが半端ないのでてきとうに書きます．この記事は俺の経験と勉強会などでユーザから聞いた話をもとに書いているので，すべてが俺の経験ではありません(特にBigQuery)．各社のSAの人とかに聞けば，もっと良いアプローチとか詳細を教えてくれるかもしれません． オンプレミスの商用MPPは使ったことないのでノーコメントです． MPP on HadoopでPrestoがメインなのは今一番使っているからで，Impalaなど他のMPP on Hadoop的なものも似たような感じかなと思っています． もちろん実装の違いなどがあるので，その辺は適宜自分で補間してください． 前提 アプリケーションを開発していて，そのための解析基盤を一から作る． 簡単なまとめ データを貯める所が作れるのであれば，そこに直接クエリを投げられるPre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Aurora MySQL と Amazon Redshift の Zero-ETL Integration について使い所を考えてみた！
GitHub - aws/awesome-redshift
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
amazon-redshift-utils/src/AdminScripts at master · awslabs/amazon-redshift-utils