Contenu connexe Similaire à 大規模ログ分析におけるAmazon Web Servicesの活用 (20) Plus de Shintaro Takemura (6) 大規模ログ分析におけるAmazon Web Servicesの活用2. • ゲームログ分析の事例紹介
– 大人の事情により、弊社タトルの話はございません
– 恐縮ながら、その代わりに論文を紹介させて下さい
• バンダイナムコスタジオの大規模ログ集約・分析基
盤“Greco”の紹介
– ンフラについての話がメンになります
– 特に最近サービスンしたAmazon Redshiftについての
使用感を重点的にお伝えします
• ユーザー企業側の導入事例はまだ稀有なはず
• 分析に耐えうる「正確な」ログを作るために
– タトル開発の現場で実践できることをお話しします
発表の流れ
2
本発表は個人の見解であり、所属する組織の公式見解ではありません
3. • 名前の由来は 映画 Ocean‘s Thirteen(2007)から
– カジノの併設ホテルを守る、人工知能セキュリテゖと
いう設定
– 映画のGrecoはこんなに凄い!
• 瞳孔や体温から顧客の感情を推定
• Exabyteのデータをリゕルタム分析
• 派手なモニタルーム
– けどリブート中にカジノが侵入されるというオチ
• 人工的に地震を発生→システム再起動
• GrecoはAmazon Web Services (AWS)を全面採用
– 映画のようにはいきません
データ集約・分析基盤 “Greco”
3
4. • ゲームログの用途
• ゲームログの種類
• 上記のニーズに耐えられるシステムが求められる
ゲームログの用途と種類
ユーザーサポート 集計・分析
処理内容 On-Line Transaction Processing
単一レコードの取得がメン
On-Line Analytical Processing
大量レコードの集計がメン
システム
要求
ログの書き込み速度
1クエリ当たりのレテンシ
データ容量とクエリ性能に対す
るスケーラビリテゖ
イベントログ アクセスログ
形式 JSON(構造化データ) 平文(非構造化データ)
システム
要求
欠落がないこと
常時処理(タムラグ重視)
複雑な前処理が出来ること
バッチ処理(1日1回)前提
4
5. 5
• ゲームログの用途とその出力先
• ゲームログの種類とその前処理
Grecoの選択
ユーザーサポート 集計・分析
処理内容 On-Line Transaction Processing
単一レコードの取得がメン
On-Line Analytical Processing
大量レコードの集計がメン
システム
要求
ログの書き込み速度
1クエリ当たりのレテンシ
データ容量とクエリ性能に対す
るスケーラビリテゖ
出力先 Amazon RDS (MySQL) Amazon Redshift
イベントログ アクセスログ
形式 JSON(構造化データ) 平文(非構造化データ)
システム
要求
欠落がないこと
常時処理(タムラグ重視)
複雑な前処理が出来ること
バッチ処理(1日1回)前提
前処理
(ETL)
EC2で全件RDS/Redshiftに挿入
※RDSはパーテゖション必須
Hadoop (Elastic MapReduce) で処
理してからRedshiftに挿入
7. • データウェアハウス(Data Ware House, DWH)の定義
– Wikipediaより
In computing, a data warehouse or enterprise data warehouse
(DW, DWH, or EDW) is a database used for reporting and data
analysis.
• 一言でいえば
– 大規模集計のためのデータベース
(より正確にはOLTPではなくOLAPに特化したRDB)
– 巨大テーブルからのSELECTは得意だが、UPDATEや
DELETEが苦手(出来ないものもある)
– 数100万行以上のレコードから集計したいときに、
初めて採用を検討すべきもの(速いRDBではない!)
そもそもデータウェゕハウスって何?
7
8. • カラムナデータベース(Columnar Database)
– 大量の行に対する集約処理が得意
• 逆に少数の行や大量の列の取得は苦手
– データ圧縮によるI/O・ストレージ削減の効果が高い
• カーデゖナリテゖ(集合の要素の数)が低いデータや、
正規化されていない(JOIN不要な)データほど有利
– ンデックスやテーブルパーテゖションは自動的に設
定されているものと考えて良い
• 超並列(Massively Parallel Processing, MPP)
– シャーデゖングを自動化できる
• ノード数を増やすことで、データの挿入や操作が分散処
理で行えるようになる
近年のDWHの2大特徴
8
9. • PostgreSQL互換のものが多い
– Amazon Redshift は ParAccel を AWSに載せたもの
代表的な商用DWH (2013/6 ver.)
特徴 互換性
Oracle Exadata MPP Oracle
Teradata Aster MPP Postgre
IBM Netezza MPP Postgre
SAP Sybase IQ MPP TDS
MS SQLServer 2012 P.D.W. MPP TDS
EMC Greenplum MPP Postgre
Actian ParAccel MPP Postgre
HP Vertica MPP Postgre
Infobright SMP MySQL
Calpont InfiniDB MPP MySQL
[1] Gartner : "Dataware house DBMS magic quadrant".
Dashboard Insight. February 2, 2013. 9
※ParAccelは2013年4月にActianに買収される
10. • ゲーム業界での採用事例
– HP Vertica
• Zynga
– Oracle Exadata
• Square Enix
• 導入のネック「一言でいうと高い!」
• 安いもの(HWは自前で用意)で初期投資 数100万
• ゕプラゕンス製品なら数1000万円を要覚悟
• 弊社のケース
– 様々なDWHを検証後、費用対効果を吟味し、Amazon
Redshift ($1,000 ~ /TB/1Y)の導入を決断
DWHとゲーム業界
10
11. • パフォーマンスについて
– 集計は本当に楽になりました
• かなり無茶なSQLでも即なくこなせるように
• PostgreSQL 8.4の共通テーブル式が一部使えます
– WITH xxx AS (SELECT …) SELECT … from xxx, ….
• PostgreSQL 8.4のウゖンドウ関数も一部使えます
– SELECT RANK() OVER (PARTITION BY xxx ORDER BY yyy) …
• ARRAY型は使えません(これが一番残念)
– Redshift独自のチューニングやマグレーションについ
ての知識は必須
• 以降のスラドにて解説
Amazon Redshiftを導入してみて
11
12. • インデックスにもいろいろある
• DWHはHash型がデフォルトというケースが多い
– OracleやPostgreSQLでいうBitmapンデックス
– 範囲検索を多用する場合はDDLでの指定が望ましい
Redshiftのチューニング
アルゴリズム Hash B-Tree LSM-Tree
機能・性質 等価検索のみ
Bitmap Index可
In Memory向け
範囲検索可
Read性能重視
HDD向け
範囲検索可
Write性能重視
SSD向け
write 定数Order 1回のrandom I/O append
read 定数Order 1回のrandom I/O N回のrandom I/O
採用例 Postgre(Bitmap)
Oracle(Bitmap)
Memcached
Postgre(Default)
Oracle(Default)
MongoDB
Cassandra
Hbase
LevelDB
12
13. • DISTKEY
– 分散処理に用いるキーを指定
• RDSでいうShardingの基準としたいキー
• 1つだけ指定可能
– JOINを多用するキーに指定するのが適切
• ユーザーID と 年月日、どちらが望ましいかは用途次第
• SORTKEY
– 範囲検索したいキーを指定
– 時系列ログなら例外なく生成日時が適切
– ログの種類に応じてユーザーステータスも
• ゲームなら例えばユーザーLV
• (1-10), (11-20) … と集計することが多いため
DDLの記述(キー指定)
13
14. • 基本はテーブル設計時に決める
– 自動カラム圧縮機能もあるが…
• 空のテーブルに100,000 /slice以上のレコードをS3経由で
バルクンサートしたときのみ有効
• つまり頼りづらい
• 特に有用(使いやすい)なものは以下の2つ
– 辞書型(TEXT255, TEXT32K, BYTEDICT)
• カーデゖナリテゖ(集合の要素の数)が低いものに適用
• Enumを文字列で代用している場合とか
– 差分型(DELTA)
• Auto Incrementなカラムは迷わずこれ
DDLの記述(圧縮の指定)
14
18. 18
• 前提条件
– 実装担当者の裁量に任せず、企画者や分析担当者の意
見を反映した上で、仕様をかっちり決める
• その上で必要なコード出力を自動化
– ログのスキーマを何らかのフォーマットで記述
• 参考: Google Protocol Buffers, Open Data Protocols
– ログ仕様から下記コードを生成するコンバータを用意
• SQLのデータ定義言語(DDL)
• ベントログ(JSON)の出力関数
• 上記を徹底することで単純なミスを大幅に減らせる
– 実行時に難しいものは、ステージング環境でレポート
出力(これも極力自動化)を行うなど、工夫を重ねる
開発の現場で実践すべきこと