Amazon Redshiftで顧客分析ソリューションを構築 | POSTD
このブログ記事では、私たちの製品の使用運転を基に、Amazon Redshiftを使った顧客分析の構築方法を説明していきます。この記事で扱う内容は以下の通りです。 なぜ顧客分析に移行しつつあるのか？ あなた は、顧客分析を構築すべきか？ Amazon Redshiftが普及してきている理由 データを可視化するBIツールの選択 Amazon Redshiftクラスタの設定 Alooma でデータパイプラインを構築 エンゲージメント、リテンション、ファネル、パフォーマンスダッシュボードを作成するための一般的なSQLクエリ 顧客分析の台頭 今日では、何かしらの分析ツールが実装されていないWebサイトやアプリケーションを探すことは難しいと言っていいでしょう。製品を作ったり、戦略的な意思決定をしたりする上でデータを活用することは常識ですし、消費者市場ではことさら必要不可欠なことです。製品の変更に対し
Amazon RedshiftとEC2のインスタンスタイプに於ける”MTU”の関係について | DevelopersIO
RedshiftとEC2に関するちょっとした小ネタです。 Redshiftに対してEC2サーバからのアクセス確認を行っていた所、『インスタンスタイプによってRedshiftにアクセス出来るものと出来ないものがある』という事象に直面しました。分かってみると『なるほど〜』という内容でしたのでここにその経緯と対応をまとめてみたいと思います。 当エントリについて結論から先に申しますと『EC2にはMTU(Maximum Transmission Unit: 最大トランスミッション単位)というものがあり、インスタンスタイプ毎にその値は異なる』『EC2からAmazon Redshiftにアクセスする際、そのMTUの値が影響する(インスタンスタイプによってアクセス出来るものと出来ないものがある)』のです。 当該問題の言及箇所 インスタンスタイプ毎のMTU値に関する言及はこちら。 インスタンスタイプ - A
Amazon Redshift クエリパフォーマンスチューニング ベストプラクティスを読んでみた | DevelopersIO
Amazon Redshiftでは『ベストプラクティス』なるテーマで、それぞれの局面でのお作法的な設定、改善の為のノウハウがドキュメントとして適宜追加or更新されています。ちょうど去年の8月にクラスメソッドにジョインした際もこの辺りのドキュメントについて幾らか目を通して参りましたが、英語ドキュメントを訪れてみると更に充実した形で『ベストプラクティス』が整備されているようです。そこで当エントリでは『クエリパフォーマンスチューニング』という切り口で更新されている以下ドキュメントを改めて読み直してみたいと思います。 Amazon Redshift Best Practices - Amazon Redshift 目次 1.パフォーマンスを考慮したテーブル設計を行う 1-a.最善のソートキーを選択する 1-b.最善の分散キーを選択する 1-c.COPY時に『自動圧縮あり』でデータをロードし、オスス
「RedshiftはHadoopキラーになる」、FlyDataの藤川氏に聞く
藤川幸一氏がシリコンバレーで起業した米フライデータ（FlyData）は、様々なデータソースから米アマゾン・ウェブ・サービス（AWS）のデータウエアハウス（DWH）サービス「Amazon Redshift」にデータを転送するというサービス「FlyData」を提供する。藤川氏はAWSのRedshiftが「Hadoopキラーになりつつある」との見方を示す。 フライデータのビジネスの現状はどうか？ 当社はもともとハピルス（Hapyrus）という社名で、「Hadoop」のPaaS（プラットフォーム・アズ・ア・サービス）を提供することを目指して起業した。しかしHadoopのPaaSが増えてきたことを考え、現在の「FlyData」の事業にピボット（事業転換）し、社名もFlyDataへと変更した。 事業を転換したもう一つの理由が、AWSが2013年初めにRedshiftを開始したことだ。Redshiftを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Change Data Capture | Datastream | Google Cloud
Amazon Redshiftによるビッグデータ分析環境の構築手順
