Data Engineering Study #7「Redshift最新アップデートと活用事例」での発表資料です。 https://forkwell.connpass.com/event/203403/
Data Engineering Study #7「Redshift最新アップデートと活用事例」での発表資料です。 https://forkwell.connpass.com/event/203403/
AWS Summit Tokyo 2018 で5月31日に行われた「Amazon Redshiftの設計・運用大原則」セッションに参加してきました。 セッション紹介と登壇者 仲谷 岳志 アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス シニア・インフラストラクチャー・アーキテクト Amazon Redshift は、高速で完全マネージド型のデータウェアハウス(DWH)です。Redshift により、DWH のローカルディスクに保存されたデータや、Amazon S3 上にある膨大な量の非構造化データに対して、簡単に分析クエリを実行することができます。本セッションでは、Redshift および S3 を活用してクラウド上にデータウェアハウスシステムを構築する上で、意識すべき設計と運用のポイントについてご説明します。 引用元:AWS Summit Tokyo 2018 セ
AWS Redshiftを導入する前に知っておくべき、AWS Redshift の特性、長所、他所を開発・運用してきた中で要所っぽいところをいくつかTips的にまとめた。 字量が非常に多くて申し訳ないが、参考になれば。 RDBに比べて有用なケース/苦手なケース 下記のケースに合致する。 SQL文をベースとした、複雑で演算コストの高いETL(分析用途用のデータ加工処理の通称)の実行 BIツールのような、3~5列程度の列を利用した参照クエリの実行。 下記のケースは向かない。 短時間で非常に多くのクエリを実行するアプリケーション(1秒に5~10クエリなど)のバックエンド 短時間で非常に多くのCommitを実行するアプリケーション(Webフレームワークが勝手に)のバックエンド 一度に多くの列を取得するクエリを発行するアプリケーション(CSV出力など)のバックエンド 性能について クエリの性能 1つ
目次 はじめに 最新クラスタにアップデート Concurrency Scalingとは Concurrency Scaling の仕組み Concurrency Scaling の利用条件 Concurrency Scaling の設定方法 Concurrency Scaling を設定したクラスタにクエリを実行 Concurrency Scaling の料金 最後に はじめに 本日、未明にAWS Blogにて昨年のre:Invent2018で発表のあった『Concurrency Scaling for Amazon Redshift』のリリースが発表されました。『Concurrency Scaling for Amazon Redshift』は、従来クラスタに加えてスケーリングするクラスタを組み合わせて、従来より遥かに高い同時実行性と一貫した高速なパフォーマンスを提供する新機能です。(r
技術部データ基盤グループの青木です。 ここ1、2年はなぜか成り行きでBFFをでっちあげたり、 成り行きでiOSアプリリニューアルのPMをしたりしていたので あまりデータ基盤の仕事をしていなかったのですが、 今年は久しぶりに本業に戻れたのでその話をします。 突然の1人チーム、そして0人へ…… 今年のデータ基盤チームは消滅の危機から始まりました。 間違いなく去年末は5人のチームだったと思うのですが、 メンバーがイギリスへグローバルのデータ基盤チームを作りに行ったり、 山へ検索システムを直しに行ったり、川へレシピ事業の分析業務をやりに行ったり、 海へ広告のエンジニアリングをしに行ったりするのをホイホイと気前よく全部聞いていたら、 なんと4月から1人だけのチームになってしまいました。 事はそれで終わりません。 恐ろしいことに10月にはわたし自身も育休に入ることになったので、 10月はデータ基盤が0
AWS Database Blog Integrating Teradata with Amazon Redshift Using the AWS Schema Conversion Tool David Gardner is a solutions architect and Pratim Das is a specialist solutions architect for Analytics at Amazon Web Services. Teradata provides long-standing data warehouse solutions, with many customers and applications running on its platforms. As companies migrate to the cloud, they are using Amaz
行指向データベースは行単位でページ(Oracle Database でいうデータブロック)にデータを格納しているのに対して、列指向データベースは列ごとにページに格納している。クエリ実行時に結果セットを返す際に列別にバラバラのページに格納されているデータをどうやってタプル(レコード)に復元している*1のかと思ったがやはり行IDのようなものを持っているようだ。 行ID は C-Store では pid、MonetDB では BAT(Binary Association Tables) の oid と呼ばれている。 The Design and Implementation of Modern Column-Oriented Database Systems NSM(N-ary Storage Model): 行方向でブロック(ページ)にデータを格納する方式 DSM(Decomposition
2019-07-01データウェアハウスとして使う Amazon Redshift についてはじめにこんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは概要Redshiftとは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としてはBigQueryやHadoop、また同じ AWS サービスではAmazon Athenaも同様の位置付けになると思います。 データベースとしての特徴Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行(レコード)単位で保持している事に対し、Red
一意性、プライマリキー、および外部キーの制約は情報提供のみを目的としており、テーブルに値を入れるときに Amazon Redshift によって強要されるわけではありません。例えば、依存関係のあるテーブルにデータを挿入する場合、制約に違反していても挿入は成功します。ただし、プライマリキーと外部キーはプランニング時のヒントとして使用されます。アプリケーションの ETL プロセスまたは他の何らかのプロセスによってこれらのキーの整合性が強要される場合は、これらのキーを宣言する必要があります。 例えば、クエリプランナーは、特定の統計計算でプライマリキーと外部キーを使用します。これは、サブクエリの非相関化手法に影響を与える一意性と参照関係を推測するために行われます。これにより、多数の結合を配列し、冗長な結合を排除できます。 プランナはこれらのキーの関係を活用しますが、Amazon Redshift
AWS Big Data Blog Migrating IBM Netezza to Amazon Redshift using the AWS Schema Conversion Tool The post How to migrate a large data warehouse from IBM Netezza to Amazon Redshift with no downtime described a high-level strategy to move from an on-premises Netezza data warehouse to Amazon Redshift. In this post, we explain how a large European Enterprise customer implemented a Netezza migration str
小売業の特徴は、いわゆる「ニッパチの法則」(売り上げを支える売れ筋商品は全体の2割という法則)。いかにして売れ筋商品の在庫を把握し、将来の需要を予測して、欠品なく並べ続けるかは生命線だ。 一方、ダイソーの特徴は、取り扱う商品点数が非常に多いことだ。 大創産業情報システム部課長の丸本健二郎氏によると、ダイソーは全世界27カ国で5270店に展開し、新商品は毎月約800。「均一価格」は日本と同じだが、価格レンジは各国地域の物価に合わせている。 こういう状況では、「人間の能力では在庫を把握するのは難しい」という前提に立って、丸本氏が取り組んだのが、POSデータの統計的解析から個店ごとの需要予測をして欠品をなくす「自動発注システム」(2015年導入)だった。 着想後、いくつかの店舗で試験的に導入したところ、着実に欠品率が下がり、「チャンスロス」が解消された。
こんにちは。インフラストラクチャー部データ基盤グループの小玉です。 先日Amazon Redshift(以下、Redshift)で32TBのテーブルを全行スキャンするクエリを3本同時に走らせたまま帰宅し、クラスターを落としてしまいました。 普段はRedshiftのクエリをチューニングしたり、データ基盤周りの仕組みを慣れないRubyで書いたりしています。 突然ですが、スキュー(skew)という単語をご存じでしょうか。 「skew 意味」で検索すると「斜め」とか「傾斜」といった訳が出てきますが、コンピューティング界隈では「偏り」という訳語が定着していると思います。 さらに、分散並列DB界隈で単にスキューもしくは偏りと言った場合、それはしばしばデータの偏りを指します。 データが偏っているとは データが偏っているとは、複数ノードで構成される分散並列DBにおいて、各ノードが保持するデータ量(行数)に
AWSでビッグデータ分析環境を整える際、まずはAmazon Redshiftにデータを集約するところを一つの目標にするところから始める事になるかと思いますが、現在ではAWSサービス間の連携も増え、またRedshiftの機能追加・改善も相俟って実に様々な方法が存在しています。 そこで当エントリでは、現時点で様々用意されている『Amazon Redshiftへのデータ投入・連携方法』そして『Amazon Redshiftから連携可能なサービス』の情報について一度整理を行ってみたいと思います。 目次 to Amazon Redshift(Amazon Redshiftへのデータ連携) AWS IoT Amazon CloudFront AWS CodeCommit Amazon Cognito AWS Data Pipeline Amazon Database Migration Service
はじめに これは ドリコムAdventCalendar の7日目です 6日目は、keiichironaganoさんによる iTunes 使用許諾更新のとき一旦キャンセルしてほしい話 です 【その2】ドリコム Advent Calendar 2015 もあります 自己紹介 @ka_nipan 去年の ドリコムを支えるデータ分析基盤 に引き続き、今年もドリコムのデータ分析基盤を担当しています。 分析基盤をTreasure Dataに移行 オンプレ環境の Hadoop からTreasure Data に移行しました。 また、ジョブ管理ツールやBIツールといったサーバーもAmazon EC2 に移行しており、 徐々にオンプレ環境を離れつつあります。 背景 オンプレ環境で Hadoop を運用して3年も経つと考えなければならないのが HW の寿命です。 さてどうしようかとなった時に、ほぼ迷いなく外部
トレンド調査ラボの青木峰郎(id:mineroaoki)です。 好きなRubyのメソッドは10年前からString#slice(re, nth)ですが、 最近はRubyよりCoffeeScriptとSQLのほうが書く量が多くて悩んでいます。 今日はわたしが開発している「たべみる」の背後で働いている 巨大バッチの構成について話したいと思います。 たべみるのバッチは約3000行のSQLで構成されており、 処理時間が1日で4時間程度かかる、そこそこの規模のプログラムです。 このバッチ処理プログラムをBricolage(ブリコラージュ)というフレームワークで構造化する手法について説明します。 「たべみる」とは まず最初に、「たべみる」がどういうものなのかごく簡単にお話ししておきましょう。 「たべみる」は企業のみに提供しているB2Bの分析サービスで、 クックパッドのレシピ検索の分析をすることができま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く