Abell 2218 / NASAblueshiftというわけで、ということもないですが、わたしがとってきたメモを残しておこうと思います。
※後ほど、少し追記等の更新をするつもりでいます。
短いですが、最初に所感を書くと、AWS が提供する BigData 関連プロダクト（ EMR, DynamoDB, そして Redshift ）を一挙に聞け、各プロダクトをどのように使い分けるべきなのか理解が進んだという意味で、とても有意義なセミナーでした。
※今日の資料は当日のアンケートに資料送付希望と回答することで後日もらえるらしいので、改めて資料をもらったら、復習したいな、と。
ちなみに、今回のセミナーの概要は以下のとおりで、
- 開催場所：AWS目黒オフィス (東京都目黒区下目黒1-8-1 アルコタワーアネックス)
- 概要：DynamoDB, EMR, Redshiftと言ったAWSのビッグデータに関連する様々なサービスが近年ローンチしています。これらサービスの連携方法や国内・海外の様々なお客様事例を中心にご説明します。DynamoDB, EMR, Redshiftを利用したログ解析やアドテク、ゲーム会社、人気サマホアプリでのハイトランザクション処理事例など実際の業務でどのようにAWSを利用しているかご理解いただくために具体事例を数多く盛り込んだセッションとなっています。
- 参考：7月16日 AWSのビッグデータサービスを使いこなせ！(東京都)
アジェンダは以下のとおりでした。
- セッション1:Amazon DynamoDB[No SQLデータベース]
- 「DynamoDB概要」 AWS, DynamoDB Business Development Manager, David Pearson
- 「DynamoDBお客様事例紹介」株式会社マイネット
- セッション2:Amazon Elastic Map Reduce(EMR)[マネージドされたHadoopクラスタ]
- 「Amazon EMR概要」アマゾンデータサービスジャパン株式会社 ソリューションアーキテクト 今井 雄太
- 「Amazon EMRお客様事例紹介」Klab株式会社
- セッション3:Amazon Redshift[クラウド型データウェアハウス]
- 「Amazon Redshift概要」アマゾンデータサービスジャパン株式会社 ソリューションアーキテクト 松尾 康博
- 「Amazon Redshiftお客様事例紹介」株式会社AMoAd, 株式会社ALBERT
では、以降にわたしのメモを残しておこうと思います。
セッション1:Amazon DynamoDB[No SQLデータベース]
「DynamoDB概要」AWS, DynamoDB Business Development Manager, David Pearson
- differentieated effort increases the uniqueness of an application.
➤ Amazon Dynamo DB
- Distributed Database at Amazon
- Early Phase - RDBMS を使っていたが、スケーラビリティが問題になっていた
- 小売業としては Chrismas season にどうやってスケールをマッチさせるかが課題になっていた。
- Availability, Durability, Scalability を兼ねそろえていた DB とはどんなものがあるのかを考えるようになっていた。
＊＊＊＊＊
- そこで、 Dynamo の論文
- Replicated DHT with consistency management
- Consistent hashing
- Optimistic replication
- Sloppy quorum
- Anti-entropy mecanism
＊＊＊＊＊
- それでもまだパフォーマンスの課題
- それを解決したのが DynamoDB
＊＊＊＊＊
- 1年半ほどまえに DynamoDB がローンチ
- 4つの特徴
- Predictable Performance
- Massiblely Scalable - いかようにもスケールできる
- Fully Managed - AWS 上から管理できる
- Low Cost
- 4つの特徴
＊＊＊＊＊
- Devops のための DynamoDB
＊＊＊＊＊
- for Developers
- DynamoDB をプライマリのDBとして使う場合、いかに早くつくって本番環境で使える用意するかということを考えないといけない
- DynamoDB を使用すれば、圧倒的なスピードで環境を提供できる
- その事例： SHAZAM（Super Bowl のプロモーション、3日で設計から production-ready）, EarthNetworks（気象予報のアプリ、 SQL base で作っていたアプリと比べて 1/20 のコストで）
- Fast Application Development の3つの特徴
- Relationship Modeling
- Simple API
- High Scale Query Patterns
- DynamoDB の構成をする上で覚えておくべき3つの単語
- Tables, Items, Attributes
- A Table is a collection of Items
- An items is a collection of Attributes
- Data is indexed by the PK (hash; hash maps)
- Modeling 1:1 Relationships
- Use a table with a hash key
- Traditional key value
- e.g. Users and Games tables
- Modeling 1:M Relationships
- Use a table with hash and range key
- e.g. One(1) User can play many (N) Games. (multi-tenancy use)
- UserGames Table
- Hash key = UserID
- Range key = GameID
- DynamoDB Operations
- アプリケーションを変更するための API だけが提供されている
- manage tables, query ....
- Query Patterns
- Available for hash+range PK tables
- Retrieve all items by hash key
- Range key conditions: ==, >, <, >=, <=
- Sorted results , Counts, Top and bottom n values. Paged responses.
- List や Messaging を必要とするアプリケーションにはとても向いている
- Local Secondary Indexes
- Designed for high scale multi-tenant applications
- index local to the hash key (=partition)
- CONS: 書き込みコストがあがる (for index updates)
＊＊＊＊＊
- DynamoDB For Op(ertaion)s
- 運用コストは運用期間が長くなればなるほど煩雑になるものだが、、、それに対して DynamoDB は Aim for Admin-Free(at any scale)
e.g SmugMug(), sumologic() - Provision/Configure Server and Storage
- Monitor and Handle HW Failures
- Update HW and SW
- Repartion data and Balance Clusters
- Manage Cross-Availability Zone Application
- Provisioed Throughput
- お客様にどれくらいの Throughput がほしいか教えてもらえたらそれにあわせた Throughput を提供できるようにしている
- Throughput is declared and updated via the API ro the console
- DynamoDB handles the rest
- Capacity is reserved and available when needed ...
- 運用コストは運用期間が長くなればなるほど煩雑になるものだが、、、それに対して DynamoDB は Aim for Admin-Free(at any scale)
＊＊＊＊＊
- DynamoDB for USERS
- user is simple, they want superfast response time, all the time. but please don't lose my data.
- urable and Low Latency
- WRITES: replicated continuously to 3 AZ's. Persisted to Disk(Custom SSD)
- READS: Strongly or eventurally consistent Thoughput, not latency, trade off
- server-side latency accross all APIs
- Avarage < 3ms
- TP90 < 4.5ms (90% の call の responce time)
＊＊＊＊＊
- 様々な分野で活用されているが、 adtec での事例紹介
- real-time bidding の例を紹介、相性がよいと。
- AdRoIL is the most used retargeting platform (Retargeting の説明もしてくれていた)
- AdRoIL's DynamoDB by the numbers
- Using DynamoDB in 4 resions
- 7B wroldwide daily requests
- 350GB of data stored per resion
- 6B+ items stored in each resion
- Query latency: 3ms
- 99.95% end to end latency: 10ms
- Number of Operations Staff=0
- Relative Costs per Month
- Developer:Snacks:Dynamo=100:55:50
- DynamoDB = FAST
- Fast Application Development
- Admin-Free
- Durable Low Latency
- Seamlessly connected with other AWS BigData Product
- DynamoDB integration with Redshift and EMR.
- Parallel data movement for optimal performance
- Low-cost, integrated data lifecycle.
- 用途に応じて、適切なデータストアを選べるというメリット
「DynamoDBお客様事例紹介」株式会社マイネット
- 2006 年創業の Android 専用のソーシャルゲーム会社
➤ DynamoDB の用途について
- For BigData:
- For Applicaiton: 無限の負荷分散能力をもって大規模サービスを実現する（マイネットさんの場合はこちら）
＊＊＊＊＊
- DynamoDBのすごいところ
- 無制限に性能を拡張することができる
- 負荷がたかくなっても応答速度が低下しない
- データ保全性も万全、 3 つの AZ で冗長化
- メンテナンスフリー、 CloudWatch で負荷状況をみてるだけ
➤ マイネットでの活用事例
- ファルキューレの紋章の Android 専用アプリ
- DynamoDB を使用して初めて実装したはじめてのサービス
- のちに MySQL ハイブリッドへ移行
＊＊＊＊＊
- 大激闘！キズナバトル、登録ユーザ数15万人
- 最初から MySQL ハイブリッド
- メインDB にDynamoDB、集計DBおよびランキング用としてMySQL
- 毎日、12,19,22 に実施されるチームバトルの際にスパイク型の負荷が発生するが、さばくことができている
- バトルで使用するテーブルは負荷予約を高めにしている。負荷予約を超えない限り応答速度は低下しない
＊＊＊＊＊
- AWS 利用料金比率
- EC2 73%
- DyamoDB 11%
- RDS 4%
- Others 12%
＊＊＊＊＊
- DynamoDB を使用してよかったこと
- Scaleout の心配をしなくてよくなった
- データ保全の心配をしなくてよくなった
- 意外と料金は安い
- 性能と費用のバランスコントロールがしやすい
- MiddleWare 以下の勉強をする必要性から解放された（システムをつくりたいのだ、と）
＊＊＊＊＊
- DynamoDBで苦労したこと
- トランザクションとバックアップの仕組みをアプリケーションで実装しなければならなくなった
- 苦手なこともあるので他システムとお組み合わせが必要（検索と集計ができない）
- ソースコードの品質をあげなくてはいけなくなった（データの論理破壊が発生してしまったり）
- エンジニアの教育が大変になった（情報工学の基礎から教えないといけないことも）
➤データ集計処理の実装
- DynamoDB-MySQL レプリケーション
- SQL で集計ができる
- システム構成が小規模で済む
- 開発が簡単
- 規模が大きくなると RDS インスタンスの性能がボトルネックになってしまう
＊＊＊＊＊
- 適している場面
- 10万人以下の活動データの集計
- 集計対象が頻繁に変わる案件
＊＊＊＊＊
- DynamoDB-EMR 連携
- DynamoDBのDumpを使用して EMR に流しこむ方法
- メリット：大量のデータでも高速
- デメリット：コスト
- DynamoDBのDumpを使用して EMR に流しこむ方法
➤まとめ
- For Application
- 同時接続 1 万人以上にも耐えられるシステムの構築に挑戦したい
- 費用も安く抑えたい
- DB のメンテナンスはもうしたくない
- MW 以下の勉強はもうしたくない
- source code の品質には自信がある
- For BigData
- ストレージ容量を気にするのはもういやだ
- データ保全のことを気にするのはもういやだ
- DB の拡張メンテをするのはもういやだ
- お金をかけてもいいから読み出し性能がもっとほしい
- お金をかけてもいいから書き込み性能がもっとほしい
➤ QA.
- DynamoDB-EMR と Dynamo-MySQL でのコストの差は？
- 100 万人ユーザ以上にならないとメリットがなく EMR は現状つかっていないので、回答できない
＊＊＊＊＊
- Backup をやめた
- 対物理故障はやめた。論理破壊はジャーナルを DynamoDB に記録するようにしている。修復することをしないといけなくなっている。
＊＊＊＊＊
- エンジニアの教育、かかる期間は？
- 人による
＊＊＊＊＊
- DynamoDB-MySQL の構成
（完全には聞き取れなかったので、メモは断念）
＊＊＊＊＊
- DynamoDB のコスト
- 同時接続数、キズナバトル、 22 時に 6,000 同時アクセスの規模
セッション2:Amazon Elastic Map Reduce(EMR)[マネージドされたHadoopクラスタ]
「Amazon EMR概要」 アマゾンデータサービスジャパン株式会社 ソリューションアーキテクト 今井 雄太
- EMR デザインパターン＆ベストプラクティス
➤ AWS Ecosystem for BigData
- BigData x AWS
- DynamoDB, EMR, RedShift, S3, Data Pipeline, Glacier, RDS
＊＊＊＊＊
- Workflow Example
- Data->S3-(ETL)->EMR->DynamoDB(WebApp), Redshift(BI)
- Data->S3-(SUM)->EMR->RDS(Dashboard)
＊＊＊＊＊
- Simple Storage Service (Amazon S3)
- AWS最初のサービスのひとつ
- データ堅牢性高く、格納容量に制限がないのが大きな特徴
- 他の AWS サービスとの併用（裏で使われている）
＊＊＊＊＊
- データがS3にあればあとは必要に応じて解析クラスタを起動して利用できる
- EMR, DynamoDB, Redshift へ
➤ EMR & Redshift
- どう使い分けるのか？
＊＊＊＊＊
- EMR のジョブの分布
- ほとんどが Hive
＊＊＊＊＊
- EMR 特徴
- Hadoop
- MR, Hive, Pig, Streaming
- SQL っぽく使うのであれば、 Redshift のほうが速いし簡単 (TRANSFORM, UDF/UDAF などのメリットはあるが)
- 正規化しづらいデータを扱うのが得意
＊＊＊＊＊
- Redshiftの特徴
- 基本的な使い勝手は RDB
- SQL を使って解析
- BIツールのバックエンドとして
- ある程度正規化されたデータが前提条件
- 複雑な Join も可能
＊＊＊＊＊
- EMR か Redshift か？
- SQL を使った分析解析なら Redshift のほうがいい
➤ EMR おさらい
- AWS が提供している managed Hadoop
- Managed とはなんぞ？
- クラスタの構築・監視・復旧
- ワークフローマネジメントなどを AWS が行う
- Managed とはなんぞ？
＊＊＊＊＊
- ワークフローマネジメント
- elastic-mapreduce (ruby 製)を配っている
- EC2 の instance が立ち上がってくる
＊＊＊＊＊
- ジョブフローとジョブステップ EMR 用語
- ジョブフロー：いわゆるクラスタのこと
- ジョブステップ：いわゆるジョブのこと
- 起動時に alive オプションがついていない限り、ジョブフローはシリアルにジョブステップを処理して終了したら Terminate される
＊＊＊＊＊
- CloudWatch によるモニタリング
＊＊＊＊＊
- S3のデータを扱える
- HDFS とシームレスにS3上のデータを扱える
- Input, Output に s3:// を指定できる
- Hive でも使える
➤ EMR Design Pattern
- 大きく2つ
- Transient Cluster (一時的なクラスタ)
- Alive Cluster(起動しっぱなし)
＊＊＊＊＊
- Alive Cluster
- あらかじめキャパシティを決めて運用する
＊＊＊＊＊
- Transient Cluster
- Workload Driven でクラスタを起動する
- オリジンとなるデータは S3 上に
＊＊＊＊＊
- EMR なら時間とリソースを等価交換できる
- 急いで仕事をしたい場合はその分、クラスタのリソースを追加してもらえばよい
＊＊＊＊＊
- Transient Cluster を利用すべきケースは
- 24 時間以内におわるなら Transient Cluster, そうでないなら Alive Cluster
＊＊＊＊＊
- Alive Cluster がマッチするケース
- 1日に1回より頻度の高いバッチ処理
- 多数のユーザが共有利用する解析プラットフォーム
➤ EMR Best Practice
- EMR/Hadoop 全体としては input data から reduce の output までの利用空間効率を高めることが重要
↓- サイジングにおけるベストプラクティス
- クラスタのサイジング：ノード編（インスタンスごとにデフォルト値は決まっているのでそんなにここは考えなくていいところ）
- クラスタのサイジング：クラスタ編（入力データサイズに依存
＊＊＊＊＊
- S3を利用する上での注意点
- S3上のデータは split できない
- S3 の入力オブジェクト数=mapタスク数
- 1TBのデータを1オブジェクト（ファイル）としてS3上に配置して、そのデータをEMRで処理する場合、map task はひとつしか起動しない→結局 1 プロセスで処理することに
- S3上のデータは split できない
＊＊＊＊＊
- S3利用のプラクティス
- ポイントしては小さすぎるファイルは避ける（まんま Hadoop で注意することと同じ）
＊＊＊＊＊
- 入力データの配置最適化：s3Distcp, Hive の insert
＊＊＊＊＊
- ログ集約のためのアーキテクチャの説明
- 適切なファイルサイズに集約、再分散。整理して S3 に再配置 / HDFS に load
＊＊＊＊＊
- チューニングの話（クラスタ最適化のベストプラクティス）
- CPU →利用率を監視する
- CPUが最大限に利用されていたなかったら map/reduce のスロット数を増やす、ちっさすぎるならクラスタノード数を減らす
＊＊＊＊＊
- Memory→利用率を監視する
＊＊＊＊＊
- DiskIO→これも監視
- Spill が確認されたら、mapper/reducer のメモリ割り当てを増やす
➤ Summary
- Hive が使いたいだけなら Redshift を一度検討
- ユーザ側としては hadoop として利用できる。インフラが AWS managed なのが一番の違い
➤ QA.
- AWS のコンソールでジョブフローが実行し終わったあとに残っているようだが…
- 自然にそのうち消えるはず（追加料金は発生しないのでご安心を）
＊＊＊＊＊
- Redshift と EMR の使い分け
- Redshift で普段使っていて、それを EMR に受け渡したいということが起こったらどうしたらいいか
- データの規模にもよるが、 S3 を経由するのが一般的な使い方
- 数十TBクラスのデータになるのであれば、同時に Redshift, EMR に書いたほうがいいだろう
＊＊＊＊＊
- S3 上に格納するときには圧縮したほうがいいのか
- いい
＊＊＊＊＊
- 宣伝：
- EMR Bootcamp というのがある
参考：Amazon Elastic MapReduce Training
- EMR Bootcamp というのがある
「Amazon EMRお客様事例紹介」Klab株式会社
➤データ分析にかかわる技術
- データ抽出、データ蓄積・加工および分析、レポートFB
- KLabでは分析に AWS のプロダクトを利用している
- kg_kpi
- マスタは S3 上。
➤システム構成
- python によるバッチスクリプト群で構成
- kg_kpi_tool
- 一部 EMR を使用している
- apache のアクセスログの変換に使っている
＊＊＊＊＊
- apache ログのバイナリ化
- msgpack: JSONのような構造化データをシリアライズするバイナリフォーマット
- msgpack ログ
＊＊＊＊＊
- ログ変換プログラムの工夫
- python
−-- mrjob, Hadoop Streaming を利用
-
-
- appexporttools
-
＊＊＊＊＊
- msgpack ログからの集計
- 常時集計：個々のユーザの滞在時間・ログイン回数
- たまに取得： hourly UU/PV, 特定のパスへのアクセス
＊＊＊＊＊
- hive の活用
- 変換したログの集計は高速だが、長期の集計には時間がかかる（現在、検証中）
- msgpack-hadoop を試してみているとのこと （msgpack ログデータを外部テーブルとして読み込みできる）
- スピーカーの github にバグ修正したものが fork されている
➤まとめ
- EMR で何度もジョブを書くのは非効率
- なので、最初に集計に都合のいい形式に変換しておくことが重要（ライブラリ化）
- hive は SerDe さえ用意すれば、様々なフォーマットに対応。(hadoop のライブラリには不安定なもの多し)
セッション3:Amazon Redshift[クラウド型データウェアハウス]
「Amazon Redshift概要」アマゾンデータサービスジャパン株式会社 ソリューションアーキテクト 松尾 康博
➤ DWH の状況
- 既存のDWH の課題
- 初期投資、環境構築に膨大な初期投資が必要
- DWH に付随するその他の投資、 backup, monitoring
- 箱一個買いました、ではすまない
＊＊＊＊＊
- 運用管理
- 日々のメンテナンス、バックアップ
- disk usage, upload monitoring
＊＊＊＊＊
- 成長予測・費用対効果
- 投資に見合ったビジネスへの貢献があったか＝価値のあるデータ分析ができたか？がわかりにくい
＊＊＊＊＊
- cloud & managed DB
- scripting & coding, performance tuning 以外をしなくて済むようになる、本業に専念してもらうことを第一に。
➤ Redshift の概要
- DWH as a Service
- 拡張性：数TB - 数 PB
- 高速：カラムナ型、超並列演算 (MPP)
- 低コスト：インスタンスの従量課金、初期費用、ライセンス費用なし
- 試してみてダメだったら（業務に役立たなかったら)やめる
- 耐久性：S3へのバックアップ
- 連携：input は S3 、 DynamoDB, EMR といった AWS サービスとの連携
- PostgreSQL JDBC/ODBC ドライバを使った SQL Client , BI tool をサポート
＊＊＊＊＊
- 行型 vs カラムナ型
- 行型： OLTP 向き
- カラムナ型： OLAP 向き
- 分析は集計処理をするわけではないので、すべての列を取得する必要はない
＊＊＊＊＊
- オンプレとのデータ連携
- まずはなにはなくとも S3 にあげてもらう（一番 Amazon が可用性が高いと自負している）
- AWS Direct Connect を利用してオンプレから S3 に upload する
➤ Redshift のアーキテクチャ
- リーダノードを経由して Query を実行
- 各コンピュートノードで演算を並列実行
- 各コンピュートノードにローカルストレージを保持
＊＊＊＊＊
- データの load をするときに S3 から各コンピュートノードが能動的にデータをかき集めるようになっている
＊＊＊＊＊
- スペックは2タイプしかない
- high storage extra large DW node
- high storage eight extra large DW node
＊＊＊＊＊
- 拡張性
- 構成パターンは3パターン
- single node
- 2-32 node scalable cluster (non leader node)
- 2-100 node (32TB-1.6PB), 8 Extra Large Node
- 構成パターンは3パターン
＊＊＊＊＊
- クエリー：全ノードに分散・並列処理
- ロード：S3, DynamoDB との連携（初期 load, 追加 load） psql コマンドで接続し、 copy 拡張コマンドをたたくだけで S3 からの load ができる
- バックアップリストア：自動的/手動で S3 バックアップ（保持期間も指定可）
- リサイズ：新しいクラスタをバックグランドでプロビジョニングして構築している, DNS によるエンドポイントのスイッチが起こる
＊＊＊＊＊
- セキュリティ
- VPC への対応
- データの暗号化
- Client - Cluster 間のSSL通信
＊＊＊＊＊
- 可用性
- replica set があるのでコンピュートノードが一台なくなるくらいでは特に問題ない
- S3 上にもバックアップ
＊＊＊＊＊
- 金額
- 従量課金
- ノード x 時間単価
- コンピュートノードのみ課金（リーダーノードは課金されない）
- オンデマンド、 [1,3] 年リザーブド
＊＊＊＊＊
- BIツールとの連携
- MicroStorategy, Pentaho etc...
＊＊＊＊＊
- データロードを速くするためのソリューション
- Amazon S3 へのアップロード
- AWS Direct Connect
- partner との協業 (cloudpack にデータ直持ち込みという選択肢もある)
➤ 海外利用時例
- NetFlix の利用例：数百万会員へのリコメンデーション
- Amazon でももちろんつかっている
➤ QA.
- BI tool について
- Amazon 上で BI tool を使いたいなら BI vender をまずはつついてみてほしい
＊＊＊＊＊
- Resion またぎの Redshift copy
- 現状は方法を提供していない
- 現状でやろうとすると S3 にいったんおいてあるとおもうのでそれをバケットコピーしてほしい
「Amazon Redshiftお客様事例紹介」 株式会社AMoAd
➤ ビッグなデータの処理を全部 EMR から Redshift に乗り換えちゃったんだけど （2013年春） 株式会社AMoAd
- どのような経緯で、どうやって。
＊＊＊＊＊
- Redshift を利用する前の課題
- 集計処理での問題：バッチ時間が長い、単体テストがない(Hive で UT しずらい)、そもそも MR である必要があるのか
- 分析処理での問題：集計の準備をしてもらうのがめんどうくさい、分析に集中したい
- 運用・調査の問題：全サーバのログを探すのはキツイ
↓解決するために Redshift - S3 にはそもそも upload してあった、 PostgreSQL にも知見があった
＊＊＊＊＊
- まずはじめにやったこと
- とにかく対象のログを S3 upload
- テーブル設計は重々に考慮する必要がある
＊＊＊＊＊
- 用意した Cluster 構成
- 300GB/day x 60days = 18TB
- -> 8XL x 2 を用意
＊＊＊＊＊
- upload の性能
- >10GB file を 40sec 以内で upload 可能
＊＊＊＊＊
- coding : PostgreSQL ができれば
- UT
- EMR からのリプレイスは 2w で完了（がんばったからもあるが）
- 実行時間は 20 min が 1min に （EMR の準備フェーズの時間がなくなっただけ、もともと使い方を間違っていたようにみえる）
- Dataminer は分析に集中できるようになった
- 調査は2ヶ月分のログが Redshift にあがっているので調査は楽になりました
＊＊＊＊＊
- 困ったこと
- PostgreSQL base であって、 PostgreSQL ではない（対応していない構文もある、たとえば alter column
- 週に1回30分のメンテナンスがある
- 構造体のデータはそのまま入らない（事前にパースが必要）
- 安いんだけど高い：自前で DWH をもつことよりは安いが、という話。
＊＊＊＊＊
- テーブル設計の勘所などは今後 AMoAd のブログにあげたりしていくとのこと
➤ QA.
- EMR と比べたコスト
- EMR のほうが安かった、明確な数字は出していないが。
Amazon Redshift 活用事例 株式会社ALBERT
- サイジングできているか？
- しかし、完璧なサイジングは無理。
- データは変容する、ビジネスのスピードについていけないインフラの変化
＊＊＊＊＊
- 最近は、小さいほうがいい
- サイジングに心血をそそぐくらいならスケールアウト・HA 構成を考えるのに時間を注ごう
➤ 事例1： ADreco
- レコメンドバナー特化型 DSP
- ログデータの分析が不可欠
＊＊＊＊＊
- Redshift(analytics) + S3 + Glacier(archive)
- S3 では lifecycle を設定し、 1 day で Glacier へ移動するようにしている
＊＊＊＊＊
- 共起性の処理、最初の集計を Redshift
- 続きを pyhon のオンメモリや EMR で
＊＊＊＊＊
- ローンチはスモールにできた
- アプリ設計がシンプルになった
- DB 運用からは解放された
➤ 事例2：プライベート DMP (Data Management Platform) での Redshift 利用事例
- 構成要素：あくまでスピーカーの定義（広告のシステムだから以下）
- DWH, Data mining engine, Campaign management, DSP, BI
＊＊＊＊＊
- DWH の部分で Redshift を利用
＊＊＊＊＊
- 疎結合からはじめる
- 一部のデータから取り扱う
- 一つのサービスから展開する
➤ 技術視点からのポイント
- PostgreSQL からの注意点
- データ型は限定
- クエリも一部非対応
- DISTKEY, SORTKEY の取り扱い（RDBMS でいう partitioning, index ）
- カラム毎の圧縮形式の選択
＊＊＊＊＊
- その他
- 1Cluster = 1DB = 1 USER と思いきや、 Create DB, Create USER できる
- 検証目的、レイテンシ我慢出来るなら U.S. もあり (Tokyo より若干安い)
- Reserved を視野にいいお付き合いを。
➤ QA.
- Redshift 以外で検討したものがあるか？(recomendation で)
- 最初は EC2 上に hive をたてようとした
- 社内では redis をリアルタイム演算では使用しているが。
＊＊＊＊＊
- レコメンデーションのアルゴリズム
- R, Mahout を使っているが、ブラックボックス的に使うのは嫌っている
- Java で書いたり、と。
