by shigemk2

当面は技術的なことしか書かない

メモ セプテーニで分析基盤(Treasure Data)を導入した話 #shinjukugl

勉強会

www.septeni-holdings.co.jp

  • PYXIS
    • 広告配信最適化
    • 代理店業務改善
    • データ分析
  • いろんなデータ
    • PYXISのデータ
    • セプテーニの各部門DB
    • 外部ベンダーのデータ
    • 媒体社のデータ
  • その問題点とソリューション DWH
    • データの2次利用がしづらい
      • 非構造化データ
        • ビッグデータのストレージ
        • 雑にデータを入れられる
    • データの分散管理
      • データの集約
    • パフォーマンスが悪い
      • 分散処理
        • CSVやJSONなどを横断的に検索する
    • ETL処理の乱立
      • 簡素化 ツール利用
    • 要件すべてを満たしたのがTD(PlazmaDB/Presto)

TDを利用したアーキテクチャ

  • ほとんどが外部サービス
    • S3→Embulk→PlazmaDB→Presto
    • S3
      • 生データをそのまま保存することで運用を少しでも楽にする
      • ファーストにすることでAWSサービスとの応用も楽になる
      • 構造化データは境界付けられたコンテキストに閉じる
      • PYXISのアプリケーション境界の命名にする
      • PATH: TDデータベース名/TDテーブル名/yyyy/MM/yyyymmdd(Embulkで読みやすくするため Athenaのパーティションで指定しやすくするため)
    • Embulk
    • PlazmaDB
    • Presto

TDの領域

  • フルマネージドサービスを利用する
    • インフラの運用コストを削減
    • Treasure Workflow(Digdagのマネージド)
    • Data Connector(Embulkのマネージド)
    • Data Tank(PostgreSQLのマネージド)
    • S3からtd_load
    • 銀の弾丸はない
      • Treasure WorkflowとDigdagの使い分け(TW SQLだけの処理はできない場合Digdagも検討している)
      • Data Connectorでは欲しい集計粒度が得られない→Embulkプラグインの組み込みと開発

TDを利用した業務フロー

  1. データ蓄積(開発者がデータを格納)
  2. データ分析/価値検証(非エンジニアによるTDのGUIを利用)
  3. Digdagによるオートメーション化(開発者が管理 データアナリストとシームレスに業務連携する)

TDを選択してよかった点

  • 分析業務に集中する
    • フルマネージドな分析基盤をスピーディに手に入る
    • AWSやGCPを自前で構築するとサービスの知見を知った上で保守運用する必要がある
  • 外部システムとの連携が容易
    • データのインポート/エクスポートのエコシステムが充実
    • データベースやファイルサーバーとの疎通のバリエーションが多い
  • データ分析/価値検証までのスピード感と安心感
    • データの蓄積さえすればデータアナリストが分析する状態に
    • 従量課金じゃないので無邪気なselectクエリとかを投げてもクラウド破産しない