DX時代に必須の、データ分析基盤構築に必要な事

Transcript

1. DX時代における、 データ分析基盤構築に必要な事 クラスメソッド株式会社 2020/12/22

2. 2 本日お話すること • クラスメソッドの紹介 • データ分析基盤の具体例 • データ構造設計について • データ構造設計とは？

   • データ構造設計の理想と現実 • データカタログの重要性

3. 3 クラスメソッドの紹介

4. 会社概要 オープンな発想と高い技術力によりすべての人々の創造活動に貢献し続ける 4 事業内容 子会社 および 関連会社 認定 • クラウド（AWS）に関するコンサルティング、設計、構築、運用

   • サーバーレスアーキテクチャ基盤に関するコンサルティング、設計、 構築、運用 • ビッグデータ分析基盤に関するコンサルティング、設計、構築、運用 • モバイルアプリケーションに関する企画、デザイン、開発、運営 • マーケティング・システム構築のためのサービス「カスタマーストー リー」の企画、開発、運用 • 音声認識（Amazon Alexa）技術に関するコンサルティング アノテーション株式会社 （http://an.classmethod.jp/） アンダースコア株式会社 （https://us.classmethod.jp/） プリズマティクス株式会社 （https://prismatix.jp/） ネクストモード株式会社 （https://nextmode.co.jp/） Classmethod (Europe) GmbH （https://classmethod.de/） Classmethod Canada Inc. （https://www.classmethod.ca/） 名称 代表者 設 立 本 社 拠 点 資本金 従業員 クラスメソッド株式会社 （英語表記：Classmethod, Inc.） 横田 聡 2004年7月7日 東京都千代田区神田佐久間町1丁目11番地 産報佐久間ビル８階 東京、札幌、大阪、岡山、福岡、上越、沖縄、 ベルリン、バンクーバー、グルガオン、バン コク 1億円 500名

5. 5 月間290万PVを誇る技術ブログ Developers.IO https://developers.io/ 5 月間290万PV、80万UUを誇る、社員が執筆するIT技術に特化し たオウンドメディアです。 AWS、ビッグデータ、モバイル、IoT などの記事を掲載中です。 ユーザに有益な情報であれば社内のノウハウも

   余すところなく記事化 現在25,000本以上の記事を掲載（2020年8月現在） AWS関連の技術記事を約10,000本掲載 憶測やセオリーだけでなく、 実地検証に基づく「やってみた」記事を公開 日次で記事一覧を取得できるRSSの提供 [RSS]https://feed.classmethod.jp/blog/daily.rss 5

6. アマゾンウェブサービス様とクラスメソッド 「APN Cousulting Partner of the Year 2018」を受賞 6年連続「AWSプレミアムコンサルティング パートナー」に認定

   全エンジニアがAWS認定資格を保有 世界トップクラスの技術認定数 6

7. インフォマティカ様とクラスメソッド 7 https://classmethod.jp/news/201102-informatica/

8. 8 自己紹介 甲木 洋介（@yokatsuki） データアナリティクス事業本部プリセールスアーキテクト データ分析お悩み相談～システム妄想～設計 ～見積～提案～プロジェクト引き渡し、運営

9. 9 クラスメソッドが手掛けている データ分析基盤の例

10. 10 例１（Informatica製品活用）

11. 11 例２（ピュアAWS導入基盤）

12. 12 データ構造設計について

13. 13 データ分析基盤構築の最初の段取り 基盤構築目的を明確にする • この基盤を使って達成したい事は何？ • 見える化…「何を」見える化したいのか？ • いい感じに…「どういう状態が」いい感じなのか？ データの「入」と「出」を特定する

    • 入…分析に使われる素材 • どこに、どのような形でデータが存在するのか？ • 出…経営層、業務担当者が受け取る情報 • どのような形式で、どのような形で提供するか？

14. 14 「入」の話：データソース情報の集約 連携情報の整理 • 連携システム名 • プロトコル（sftp, REST API, …）

    • ファイル定義 • 文字コード（UTF-8, SJIS, …） • ファイル構造（CSV, JSON, …） • ファイル命名規則 • 頻度（毎日0:00, 毎時, …） • 範囲（全件分, 前回連携からの差分, …）

15. 15 「出」の話：データ分析に適したデータ格納形式 ディメンショナルデータモデル • 分析の次元（ディメンション）を持つ • ファクト • 主に時系列で発生する事実情報 •

    POS売上/アクセスログなど • ディメンション • 分析に必要な切り口の情報 • 「〇〇毎に」の部分

16. 16 データ構造設計の理想 分析基盤にアクセスすれば、すぐに分析が実施できる • 分析したいデータが全て分析基盤上に存在している • データ構造が全て統一されている • 業務視点でデータが検索できる •

    データの用途が理解できる • etc…

17. 17 データ構造設計の現実 分析に適したデータ構造になってない • データの形式がソースごとに異なったまま • データの欠損、間違いが含まれる → ETL/ELT等の前処理でデータ構造を統一する 分析データがどこに何があるかがわからない

    • 論理データと物理データの対応がわからない • 単位など、データの読み方が分からない • データ発生元からの流れ（リネージ）がわからない → データカタログの導入を検討

18. 18 データ活用の為に必要な「データカタログ」 自社が扱える情報の実態（データ）を知る手段 • システム面におけるデータカタログ • データが格納されているシステム（サーバ） • テーブル、フォルダ名、カラム名、データ型 •

    データのライフサイクル（タイムスタンプ） • 業務面におけるデータカタログ • データ（コード体系）の意味 • データ発生、管理部門および責任者 • データの信頼性（評価）

19. 19 データカタログの実現例 商用製品の導入 • Informatica Enterprise Data Catalog (EDC) •

    AWS Glue Data Catalog 自前で調達、構築 • オープンソースプロダクト活用 • SchemaSpy（RDBMSからテーブル構造取得） • Wiki他マークアップ系ドキュメント共有サービス • Excelも選択肢としてアリ

20. 20 例１（Informatica製品活用）

21. 21 例２（ピュアAWS導入基盤）

22. 22 まとめに代えて • データ分析基盤の処理構成は、要件によって様々 入力と出力の特定は必須 • データ活用の効率化～分析の民主化の為には 事前のデータ整備が必要 • データを知る仕組みとして、データカタログの

    導入が有効

23. 23