1000人規模で使う分析基盤構築 〜redshiftを活用したeuc
TRANSCRIPT
1000人規模で使う 分析基盤構築
～Redshiftを活用したEUC～
株式会社クラウドソース 宮島 一浩1
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用プロセス（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
2
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用プロセス（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
3
自己紹介
•宮島 一浩
• 株式会社クラウドソース 代表取締役CloudSource, Inc.
• SINCE 2011/34
みやじま かずひろ on Facebook
1. はじめに
こんなことやってます
•システム開発（Web / iOS / Android） アジア圏オフショア開発（ミャンマー・ベトナム・中国）
•AWSコンサルティング導入、設計、構築、運用支援
•データ分析サービス導入、ツール選定、設計、構築、運用支援
5
1. はじめに
•システム開発（Web / iOS / Android） アジア圏オフショア開発（ミャンマー・ベトナム・中国）
•AWSコンサルティング導入、設計、構築、運用支援
•データ分析サービス導入、ツール選定、設計、構築、運用支援
こんなことやってます
6
1. はじめに
今日の本題です
7
1. はじめに
1000人規模で使う 分析基盤構築
～Redshiftを活用したEUC～
8
1. はじめに
1000人規模で使う 分析基盤構築
～Redshiftを活用したEUC～
9
何これ？これが聞きたい
唯一目新しい？
End User Computing
1. はじめに
今日の概要
1. いわゆるエンタープライズ寄りな内容が大半です
2. 具体的な分析内容などは出て来ません
3. インフラはもちろんAWS
10
1. はじめに
excuse
今日の概要
1. いわゆるエンタープライズ寄りな内容が大半です • ある上場企業での取り組みのお話 • 売上2000億、社員1000人 • 業種：メインは卸売、制作～物流～小売M&Aでいろんな業態が混在。今後もM&Aで新規分野に参入
11
1. はじめに
今日の概要2. 具体的な分析内容などは出て来ません • データ分析は、重回帰分析、ABC分析、時系列データ分析（SARIMA、移動平均など）くらい
• こんな感じでデータ活用しようとしている人達がいるよ、というお話です
• データ量はそれなりに多いですが、ペタ単位といった超大量でもないです（3年後で数十TB）
12
1. はじめに
今日の概要3. インフラはもちろんAWS • ただしオンプレ基幹システムからデータ連携します • Redshift, DataPipeline, RDS, EC2, S3,Gracier, SQS, DirectConnect
• 可視化ツールはしょぼいので割愛 →Excel活用頻度は高いです→有力3製品の比較調査はやりましたが…→可視化ツールの話は議論でぜひ
13
1. はじめに
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
14
15
2. プロジェクトの概要
きっかけは、 基幹システムのリニューアル 当初、分析の「ぶ」の字もなかった
16
2. プロジェクトの概要
きっかけは、 基幹システムのリニューアル
当初、分析の「ぶ」の字もなかった
新基幹システムは直近データのみ素早く扱う 開発も少数精鋭・アジャイル採用
17
2. プロジェクトの概要
きっかけは、 基幹システムのリニューアル
当初、分析の「ぶ」の字もなかった
新基幹システムは直近データのみ素早く扱う 開発も少数精鋭・アジャイル採用
データ蓄積とレポートは後からゆっくり →DWH+BIの分析基盤を構築しよう！
コンセプト
1. 営業が提案に使えるデータ基盤
2. 気付きと思考を続ける仕組み
3. データと分析結果の共有
18
2. プロジェクトの概要
コンセプト
19
2. プロジェクトの概要
1. 営業が提案に使えるデータ基盤
• 卸業なので、基本はB2Bの商談ベースの営業どの商品を奨めるか、およびその根拠が肝 →提案型営業への移行
• 提案した商品の売上を収集・蓄積して、次回以降に活用蓄積・改善することで提案精度を高める
• 提案に活用できる「使えるデータはないか？」「収集した方がよいデータはないか？」を考えることが重要
コンセプト
20
2. プロジェクトの概要
2. 気付きと思考を続ける仕組み
• 社員一人ひとりが、ルーチンワークだけではなく、より利益を上げるための工夫を続けようとする仕組み
• 「人が主役、システムは脇役」 考える・決めるのは人、システムはデータ・分析結果・可視化などで思考をサポート
• 理想は、売上の80%は仕組みで誰でも達成可能、残り20%を人の智恵で生み出す
コンセプト
21
2. プロジェクトの概要
3. データと分析結果の共有
• 「誰か一人の智恵→全員に」全体の生産性向上、≠属人化・部分最適・現場最適
• システム部門としてのビジョン1. EUC実現： 自由度と満足度の提供2. ITサービスを提供する部門への転身： 利用料の徴収の仕組み化3. 社内のITリテラシー向上： システム部門→他部署に転属で実現 TCOの削減 （お前らちょっとしたことで問い合わせしてくんな…）
コンセプト1. 営業が提案に使えるデータ基盤
2. 気付きと思考を続ける仕組み
3. データと分析結果の共有
22
2. プロジェクトの概要
上記を通じた意識の変革1. 常に考えろ
2. みんなのためになれ（個を評価）
3. 組織・会社全体の売上を意識せよ
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
23
アーキテクチャ概要
24
3. アーキテクチャ
EDI
受発注 ＆
販売在庫
入出庫 ＆
現物在庫
経理 ＆
資金回収
マスタデータ＆ルール管理
DWH + BI
分析基盤
受発注 ＆
販売在庫
入出庫 ＆
現物在庫
アーキテクチャ概要
25
EDI
DWH + BI
分析基盤
経理 ＆
資金回収
マスタデータ＆ルール管理
ここが データの終着点
3. アーキテクチャ
アーキテクチャ概要
26
DWH+BI
基幹 システム
RedshiftS3 EC2 （可視化ツール）
ExcelData PipelineData Pipeline
3. アーキテクチャ
アーキテクチャ概要
27
DWH+BI
基幹 システム
RedshiftS3 Excel
新基幹 システム
あれ、スキーマ変わってる
EC2 （可視化ツール）
Data PipelineData PipelineData Pipeline X
3. アーキテクチャ
アーキテクチャ概要
28
DWH+BI
基幹 システム
RedshiftS3 Excel
新基幹 システム
S3 Redshift
EC2 （可視化ツール）
あれ、データを 更新できないの？
Data PipelineData Pipeline
3. アーキテクチャ
アーキテクチャ概要
29
DWH+BI
基幹 システム
RedshiftS3 Excel
新基幹 システム
S3
EC2 （可視化ツール）
ExcelEC2 （MartBuilder）
Redshift Redshift
Data PipelineData Pipeline
3. アーキテクチャ
30
iDC
基幹システム
社内PC
社内N/W
専用線
Direct Connect
RDSRedshift
SG: db, common
VPC Private Subnet 10.200.0.0/24
SG: web, common
バッチ 起動
SG:batch,common
EC2
Auto scaling Group
Availability Zone CAvailability Zone A
VPC Public Subnet 10.200.2.0/24
NATS3
Data Pipeline
Glacier
Logging
Redshift
インスタンス化 ＆実行指示
VPC Private Subnet 10.200.3.0/24
VPC Public Subnet 10.200.1.0/24
2年以前分を バックアップ
10.200.0.151
テスト サーバ
10.200.3.151
アーキテクチャ(AWS的表現)3. アーキテクチャ
アーキテクチャ
31
DWH+BI
基幹 システム
RedshiftS3 Excel
新基幹 システム
S3
EC2 （可視化ツール）
ExcelRedshift Redshift
Data PipelineData Pipeline
3. アーキテクチャ
EC2 （MartBuilder）
アーキテクチャ
32
基幹 システム
RedshiftS3 Excel
新基幹 システム
S3
EC2 （可視化ツール）
ExcelEC2 （Uploader）
Redshift Redshift
Data PipelineData Pipeline Data Pipeline
DWH+BI
3. アーキテクチャ
Original
New Upload
data mart共通
Redshift内のスキーマ
アーキテクチャ
33
基幹 システム
RedshiftS3 Excel
新基幹 システム
S3
EC2 （可視化ツール）
ExcelEC2 （Uploader）
Redshift Redshift
Data PipelineData Pipeline Data Pipeline
DWH+BI
3. アーキテクチャ
アーキテクチャ
34
基幹 システム
RedshiftS3 Excel
新基幹 システム
S3
EC2 （可視化ツール）
ExcelEC2 （Uploader）
Redshift Redshift
Data PipelineData Pipeline Data Pipeline
DWH+BI
3. アーキテクチャ
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
35
データ活用プロセス
36
計画 データ 整備 実装 業務での
施策実行 効果検証 次策検討
4. データ活用
データ活用プロセス
37
計画 データ 整備 実装 業務での
施策実行 効果検証 次策検討
誰が どの数値 なぜ、どう いつ どの程度 効果は？
人的プロセス
収集対象 更新者 取得頻度 加工内容
データの アップロード
計画実行
人が行動を 変える
予実比較 結果まとめ
継続／終了
継続なら 次策計画
4. データ活用
データ活用プロセス
38
計画 データ 整備 実装 業務での
施策実行 効果検証 次策検討
人的プロセス
収集対象 更新者 取得頻度 加工内容
計画実行
人が行動を 変える
予実比較 結果まとめ
継続／終了
継続なら 次策計画
システム的プロセスデータ取込 ビュー作成 マート作成
桁型変換 単位揃え 日付付与 タイムシリーズ
レポート作成 予測精度検証データ測定
4. データ活用
誰が どの数値 なぜ、どう いつ どの程度 効果は？
データの アップロード
データ活用プロセス
39
計画 データ 整備 実装 業務での
施策実行 効果検証 次策検討
人的プロセス
収集対象 更新者 取得頻度 加工内容
計画実行
人が行動を 変える
予実比較 結果まとめ
継続／終了
継続なら 次策計画
システム的プロセスデータ取込 ビュー作成 マート作成
桁型変換 単位揃え 日付付与 タイムシリーズ
レポート作成 予測精度検証データ測定分析基盤
4. データ活用
誰が どの数値 なぜ、どう いつ どの程度 効果は？
データの アップロード
データ活用事例•ある地域だけで特定カテゴリの商品が売れている→ 商品特性と人口統計
•特定カテゴリの商品は、連休前に集中して売れている→ 商品特性と時期
•市場全体の規模はあまり変わらないので、あるヒット商品が出ると他の商品の売上が下がる→ ツリーマップ
•ある地域では定番商品が売れていない→ 視聴率（というか視聴可能エリア）と製品特性
40
4. データ活用
41
データ 分析
気づき感覚
検証 発見
思考を続ける仕組み4. データ活用
42
皆さんはどちらが多いですか？
「ナウい」のはこっち
データ 分析
気づき感覚
検証 発見
ちなみに…
多いのはまだこっち
4. データ活用
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
43
経営との考えの乖離
課題経営の考えが現場作業に反映されない現場での工夫や実績が経営に認められない
解決策中期経営計画と連動した部署毎の計画と現場の施策
44
5. 技術以外の課題
経営との考えの乖離
45
5. 技術以外の課題
経営 GM 部長 リーダー中期経営計画 目標立案 行動立案 行動計画
年間数値目標 年間売上目標 年間売上目標 年間売上目標
日々の活動KPIKGIKSF
部署間の調整
課題データのメンテナンス・有効性の担保各部署で作成したデータの全社共有化
解決策データ活用専門部署の組織化
46
5. 技術以外の課題
データ分析の経験者不足
課題Excel分析アドインすら使える人がいない
解決策統計についての教育、育成機械学習活用の環境構築オープンデータを扱いやすいように整備（単位合わせ、時系列化）
47
5. 技術以外の課題
1. はじめに（3分） 2. プロジェクトの概要（10分） 3. アーキテクチャ（10分） 4. データ活用（5分） 5. 技術以外の課題（5分） 6. 技術的な課題（5分） 7. 質疑応答（20分）
目次
48
AWS的スペック
•Redshift： dc1.large x 13ノード •EC2： r3.xlarge x 2台 •RDS： db.t2.micro x 2台 •DataPipeline： c3.large処理は4～5本
49
RedshiftETL •独自のRuby＋Javaコード •カラム・日本語ー英語名・型マッピング •DataPipelineで実行 •毎日差分取込→View経由→マート作成（これは毎日全入替） •毎日2GBB増加 •全プロセス完了まで2時間程度 •マート200GB、5億行
50
6. 技術的な課題
Redshift同時接続数とパフォーマンス •1000人使ったときの性能予測 •Aurora検討も断念 •MySQLでindexとパラメータでチューニングしても、特定のクエリは良くなっても他がダメ → Redshiftすごい！
•dc1.8xlarge x 1ノードよりもdc1.large x 8ノードの方が安いし速い •そもそも1ノードで使えない（データ欠損）ので2ノード基本 •マートは非正規化 •正規化の場合と比較して10倍速い場合も •distkeyは未指定でラウンドロビン •allを指定したりしたが遅かった •sortkeyは主に日付カラム
51
6. 技術的な課題
Redshiftデータ容量と利用料金性能 •料金予測 •圧縮方式 •独自でカラム毎に指定（AUTOでもよいのかも） •容量計算 •最低ブロックサイズがカラム数に応じて計算され、スライス数分確保される ←しかもこのサイズ分課金
•真っ先にリザーブドインスタンスを検討
52
6. 技術的な課題
Redshiftデータ保持期間とバックアップ •会計データは2年オンライン、7年保持義務 •それ以外の過去データの分析要求 •3年分保持、その後Gracierへ •ただし、絶対3年以前のデータも見たいハズなので、様子見ながら保持期間決定
•バックアップは月1回S3に •S3でも30日後にGracierに自動移行設定
53
6. 技術的な課題
Redshiftデータの中身 •文字コードとバイト数 •元テーブルのカラム定義がEBCDIC •半角の仮名文字は1バイト→3バイトに，標準漢字は2バイト→3バイトに
•元テーブル定義の3倍を確保 ←でも一応4倍してます •TimeZone •UTCに変換して入れるべし ←これ一択 •入出力はJSTをUTCとして扱っても問題ないが、システム時間を使う処理（バッチなど）で困る
54
6. 技術的な課題
Redshiftデータの中身 •データ型と桁数 •DB2互換DB400のメタデータと合わせて解決 •char型で日付とか変換要 •何が正解？ •既存データと数値がズレる →どっちが正しいの？ •締め処理前後で数値が変わる →どっちが(ry •データが入っていない行、本来の使われ方ではない行 •アノマリーデータとするしかない
55
6. 技術的な課題
RedshiftRedshiftとRails •ActiveRecordはNG •理由は…わかりますよね •ActiveRecordが使えないと、便利なgemの多くが使えないので困ることに
•COPYコマンドはキューで実行 • lambdaを検討したが1分の壁で断念→SQSで対応予定
56
6. 技術的な課題
Redshift
新たな分類とマッピング •例えば商品に新たなカテゴリを設ける •大量の分類が必要 •分類指定→分類対象検索→ひもづけ、という一連の作業専用機能をMartBuilderに追加
57
6. 技術的な課題
まとめ
58
1000人規模で使う 分析基盤構築
～Redshiftを活用したEUC～
59
まとめ
1000人規模で使う 分析基盤構築
～Redshiftを活用したEUC～
60
意図伝わった？なんかわかった？
使えそう？
End User Computing
まとめ
今後の展望
•統計的データ分析、機械学習の活用Pandasサポートまだかよ…
•外部データの取込拡大とAPI化AWS API Gateway活用
•MartBuilderの販売？61
