45億！増え続けるデータセットと基盤と私

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright © 2024 Looop Inc. 3 名前⼤堀元所属株式会社Looop システム統括部エキスパート役割部付きのエンジニアとして、技術責任者をやっています。今回ご紹介するデータチームの⽴ち上げとDatabricksの導⼊にも携わり、現在は、データ分析チームとインフラ基盤チームを主管しています。好きなもの・Laravel ・ダイビング・プログラミング（⼩学⽣のころにN88-BASICに触れてからずっと）・DatabricksのLakeviewダッシュボード⾃⼰紹介

Slide 4

Slide 4 text

Copyright © 2024 Looop Inc. 4 会社名株式会社Looop 設⽴ 2011年4⽉4⽇所在地東京都台東区上野三丁⽬24番6号従業員数 272名（2023/2/28現在、派遣社員除く）代表者代表取締役社⻑ CEO 森⽥卓⺒資本⾦ 4,094百万円（資本準備⾦3,773百万円）※2023年3⽉末現在売上⾼ 67,282百万円 ※2023年3⽉期連結事業内容電⼒⼩売、電⼒⼩売事業に関わる各種業務委託業太陽光発電所システムの開発・販売・⼯事・管理・保守、他会社概要

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © 2024 Looop Inc. 12 当社は⼤きく2つのビジネスを⾏っています。 • 電⼒事業 → 使⽤量データが45億/年ずつ増加 • to C、to B向けに、電⼒の仕⼊れと販売 • 再エネ事業 → 発電量データが19億/年ずつ増加 • 太陽光、⾵⼒などの再⽣可能エネルギーの発電所建設 • 部材販売、運⽤と保守、発電所の保有合わせると、1年に64億ずつデータが増加しています当社のビジネスモデル

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © 2024 Looop Inc. 17 Databricks導⼊前は、社内の⼀部メンバー向けにデータベースへの直接アクセスの権限を付与し、個々⼈で分析業務を⾏っていた。それぞれが分析環境を構築したりCPUリソースを調達していたため、分析環境、コード、データが分断し、サイロ化が進み課題となっていた。⼯数に対する⾮効率 •データ利⽤と前処理の⾮効率 •データ取得はIT部⾨が対応 •データ前処理が毎回⼿間 •開発環境不統⼀、属⼈化 •マシン毎にPythonバージョンやライブラリが異なる •コード管理が属⼈化 CPUリソースとコスト⾮効率 •計算リソースの硬直性 •ダイナミックに変動するCPU需要に対して硬直的なリソース •⼤規模計算をするために⼤容量のサーバを契約するとリソースが余り⾮効率セキュリティとガバナンス •アクセス制御の問題 •DB直接アクセスのリスク •アクセス情報使いまわし •個⼈情報へのアクセス •分析者が⾮マスクの個⼈情報データにアクセスできてしまう Databricks導⼊前の課題

Slide 18

Slide 18 text

Copyright © 2024 Looop Inc. 18 Databricks導⼊前の課題オンプレ共有PC 共有EC2 計算マシン1 Google Colaboratory 共有EC2 計算マシン2 社内DB 社外データ Excel分析者インフラ担当者 Python分析者システム部⾨ CSV ダウンロードデータ抽出依頼リモート接続ブラウザでアクセス Databricks導⼊前はこのような状態他部署データ抽出依頼ファイルで報告個⼈貸与PC 個⼈貸与PC 個⼈貸与PC 個⼈貸与PC 経営層・マネージャ RDPでアクセス Excelで連携

Slide 19

Slide 19 text

Copyright © 2024 Looop Inc. 19 Databricks導⼊前の課題オンプレ共有PC 共有EC2 計算マシン1 Google Colaboratory 共有EC2 計算マシン2 社内DB 社外データシステム部⾨ CSV ダウンロードリモート接続ブラウザでアクセスデータ抽出の⾮効率ローカルPCでの⾮効率な分析開発環境の不統⼀ソースコードの属⼈管理データ取得の⾮効率同時ログインの問題データ前処理の⾮効率他部署 Excel分析者インフラ担当者 Python分析者ファイルで報告情報鮮度の低さデータ抽出依頼個⼈貸与PC 個⼈貸与PC 個⼈貸与PC 個⼈貸与PC 経営層・マネージャデータ抽出依頼計算リソースの硬直性 RDPでアクセス Excelで連携 Excel分析の限界 Databricks導⼊前はこのような状態 →データのサイロ化が問題

Slide 20

Slide 20 text

Copyright © 2024 Looop Inc. 20 Databricks導⼊後の姿個⼈貸与PC 社内DB 社外データシステム部⾨個⼈貸与PC 他部署パイプライン構築・管理個⼈貸与PC 個⼈貸与PC 個⼈貸与PC SQL分析者 ML分析者経営層・マネージャ Python分析者個⼈貸与PC ノートブックで⼤量データ処理と分析 MLモデルを作り予測・評価、事業部にフィードバック SQLで抽出・集計しダッシュボード構築ダッシュボード構築数字をもとに⽇々判断 BIに直接アクセス

Slide 21

Slide 21 text

Copyright © 2024 Looop Inc. 21 Databricks導⼊後の姿個⼈貸与PC 社内DB 社外データシステム部⾨個⼈貸与PC 他部署パイプライン構築・管理個⼈貸与PC 個⼈貸与PC 個⼈貸与PC SQL分析者 ML分析者経営層・マネージャ Python分析者個⼈貸与PC 全てのデータを⼀箇所に集約迷わない、探さない全員がブラウザでアクセス開発環境と実⾏環境を統⼀オートスケールするクラスターによる、柔軟な計算リソースデータパイプラインで処理、監視⾮整形データをそのまま取り込み前処理を統⼀ユーザ部⾨が⾃分達で分析できるように SQLやPythonを使って分析ダッシュボードを直接参照情報鮮度が⾼いノートブックで⼤量データ処理と分析 MLモデルを作り予測・評価、事業部にフィードバック SQLで抽出・集計しダッシュボード構築ダッシュボード構築数字をもとに⽇々判断 BIに直接アクセス

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Copyright © 2024 Looop Inc. 23 ダッシュボード数、Databricks格納データ数スキーマ数 55 テーブル数 772 レコード数 494億データ数 3兆以上 Databricks格納データ数 ※2024.04.20現在総数 73 1年以内に作成 40 3ヶ⽉以内に作成 32 ダッシュボード数 Databrick導⼊から約2年が経過した時点での利⽤実態をまとめました。 • 導⼊後1年間は、データエンジニア2⼈、データアナリスト4⼈体制で利⽤。 • 直近半年は、⼀部の事業部メンバー向けにSQLを開放し、ダッシュボードを⾃由に作成。

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright © 2024 Looop Inc. 27 Databricksの活⽤例 3/3 0 10000 20000 30000 40000 50000 60000 70000 2/1/2023 2/15/2023 3/1/2023 3/15/2023 4/1/2023 4/15/2023 5/1/2023 5/15/2023 6/1/2023 6/15/2023 7/1/2023 7/15/2023 8/1/2023 8/15/2023 9/1/2023 9/15/2023 初回ダウンロード数(累積実績) 新規ダウンロードキャンペーンを実施した際に、アプリのダウンロード数にどの程度影響するのかを検証 • 時系列データ予測ライブラリ Prophet を利⽤し、機械学習と予測を⾏った。 ①︓2/1〜8/21の累積数を学習し、8/21〜8/28の累積数を予測するよう、モデルのハイパーパラメータをチューニング ②:①で抽出したパラメータで2/1 〜8/28の累積数を学習させ(キャンペーン期間) 、8/29〜9/30の累積数を予測 4/24︓⼤規模リリース (持続7⽇間) 5/19及び5/26︓メール通知 ①(持続3⽇間) 7/14、8/19、8/28、9/13、9/28 メール通知 ②(持続3⽇間)

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Copyright © 2024 Looop Inc. 32 Slackヘルプチャンネルの様⼦（2/2）さらに・・・当初はユーザ部⾨の開発者からIT部⾨への問い合わせ⽤ ↓ ダッシュボードのユーザが問い合わせるようになる ↓ （⾃発的に）ダッシュボードの開発者が答えるようになる ↓ さらにユーザ部⾨同⼠で意⾒交換が始まる・・・︕ ↓ IT部⾨は関わることなく問い合わせがクローズ︕︕ ダッシュボード利⽤者（マーケティング担当）ダッシュボード開発者（⾮エンジニア）別のダッシュボード開発者（⾮エンジニア）

Slide 33

Slide 33 text

Copyright © 2024 Looop Inc. 33 Slackヘルプチャンネルの様⼦（2/2）さらに・・・当初はユーザ部⾨の開発者からIT部⾨への問い合わせ⽤ ↓ ダッシュボードのユーザが問い合わせるようになる ↓ （⾃発的に）ダッシュボードの開発者が答えるようになる ↓ さらにユーザ部⾨同⼠で意⾒交換が始まる・・・︕ ↓ IT部⾨は関わることなく問い合わせがクローズ︕︕ データはIT部⾨のモノではなく、⾃分達（事業部）のモノであるという意識変⾰が起き始めている（と思う）これがデータの⺠主化か・・・︖︕ ダッシュボード利⽤者（マーケティング担当）ダッシュボード開発者（⾮エンジニア）別のダッシュボード開発者（⾮エンジニア）

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Copyright © 2024 Looop Inc. 36 導⼊後の苦労話 • データ連携依頼が多すぎる問題 • 連携後の加⼯依頼が多すぎる問題 • データ分析依頼が多すぎる問題 • アカウント・権限付与依頼が多すぎる問題 • 分析結果の妥当性検証が⼤変 • インポート元のデータベースが破損してダッシュボードが停⽌ • エンジニアが⾜りない問題 • コストが積み上がってきている問題⼀つずつお話していきます。

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Copyright © 2024 Looop Inc. 41 • AWS DMS（Database Migration Service）＋CDCを使ってデータ取り込みをすると、Op列、 OpTimestamp列が⾃動付与されるので、これらの列を⾮表⽰にしたい。 • データベースの全項⽬だと多すぎるので、よく使う主要項⽬のみに絞って欲しい。 • 個⼈情報をマスクしたい。（これはガバナンス上必須） → データ取り込み後の様々な加⼯が必要。メダリオンアーキテクチャを採⽤し、Databricks上でデータパイプラインを構築していくことで対応。 https://www.databricks.com/jp/gl ossary/medallion-architecture ELT（not ETL）⾮マスクマスク⼀般ユーザには⾮開放ブロンズ DBデータを何も加⼯せずに全量取り込みシルバー不要なカラムを削除最低限のクレンジングゴールド分析し易い形へ加⼯データの⾮正規化も⾏う導⼊後の苦労話 ②連携後の加⼯依頼が多すぎる問題

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Copyright © 2024 Looop Inc. 43 様々なデータをDatabricksに取り込むようになると、もっと⾊々な⾓度から分析したい︕ というニーズが増えてきた。とはいえ、IT部⾨のリソースも分析エンジニアの数もそれほど多くなく、全てに対応することが難しい・・・であれば、⾃分たちで分析できるように、SQL勉強会を実施して広めていこう︕ ということになりました。導⼊後の苦労話 ③データ分析依頼が多すぎる問題

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Copyright © 2024 Looop Inc. 47 利⽤部⾨拡⼤と、中途⼊社社員への開放のため、逐次ユーザ追加依頼が届く。 Slack WFで依頼が届くため、GUIでポチポチ追加する必要がある。現在は、Workspace管理者のみアカウント追加が出来るため、⼀部の管理者（私）に若⼲の負担あり。 → Databricksさん、アカウント改廃の権限をユーザにつけられるようにして欲しいです︕（相談済み）今後はID管理を外部のIdPに寄せていき、SSO認証にすれば、負担はかなり減る・・・はず。ただ、ユーザごとの権限（ワークスペースへのアクセス、クラスター作成の権限）の管理は課題。導⼊後の苦労話 ④アカウント追加・権限付与が多すぎる問題

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Copyright © 2024 Looop Inc. 49 利⽤が拡⼤することにより、作ったダッシュボードが間違っているのでは︖と指摘されることが増えてきた。システム部⾨が管理しているデータパイプラインに問題があることもあるが、ユーザ部⾨が作成したSQLに問題があることもある。 BIは試⾏錯誤しながら改善していくものですし、何よりチャレンジしている姿勢を評価したい︕ とはいえ、データパイプラインとBIの品質をどのように上げていくのかは今後の課題。（対応⽅針検討中）導⼊後の苦労話 ⑤分析結果の妥当性検証が⼤変

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Copyright © 2024 Looop Inc. 51 導⼊後の苦労話 ⑥インポート元のデータベースが破損してダッシュボードが停⽌当社はインフラ基盤としてAWSを採⽤、データベースの標準はAurora MySQL とあるDB AWS DMS (Database Migration Service) S3 S3 社外アカウントとあるDB 社内アカウント Databricksアカウント BIユーザ

Slide 52

Slide 52 text

Copyright © 2024 Looop Inc. 52 とあるDB AWS DMS (Database Migration Service) S3 S3 社外アカウントとあるDB 社内アカウント Databricksアカウント BIユーザ ︖︖︖ 以後、全てのデータが破壊、ダッシュボードが異常となった当社はインフラ基盤としてAWSを採⽤、データベースの標準はAurora MySQL 先⽇⾏われたAuroraのマイナーバージョンアップによって、DBのインポート時に実⾏される「カラム⼀覧取得クエリ」の結果が仕様変更され、DBの中⾝が破損する問題が発⽣した。カラム⼀覧を取得するクエリの結果が変更導⼊後の苦労話 ⑥インポート元のデータベースが破損してダッシュボードが停⽌

Slide 53

Slide 53 text

Copyright © 2024 Looop Inc. 53 当社はインフラ基盤としてAWSを採⽤、データベースの標準はAurora MySQL 先⽇⾏われたAuroraのマイナーバージョンアップによって、DBのインポート時に実⾏される「カラム⼀覧取得クエリ」の結果が仕様変更され、DBの中⾝が破損する問題が発⽣した。とあるDB AWS DMS (Database Migration Service) S3 S3 社外アカウントとあるDB 社内アカウント Databricksアカウントカラム⼀覧を取得するクエリの結果が変更 BIユーザ ︖︖︖ → Databricksに取り込む際のデータ異常検知の実装課題が浮き彫りに︕ 以後、全てのデータが破壊、ダッシュボードが異常となった導⼊後の苦労話 ⑥インポート元のデータベースが破損してダッシュボードが停⽌

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Copyright © 2024 Looop Inc. 55 導⼊後の苦労話 ⑦エンジニアが⾜りない問題増え続ける分析依頼とデータ連携依頼・・・データアナリストだけではなく、データエンジニアも⾜りない・・・優先度をつけて対応はしているものの、圧倒的エンジニア不⾜・・︕ SQLを書ける社員を増やすだけではなく、パイプラインも実装できるPythonエンジニアを社内で増やしていく︖ 中途採⽤と、既存社員のリスキリングをどのように強化・推進していくのか︖ （SQL勉強会とは別に、Python勉強会も開始。⻑期の対応⽅針は検討中）

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Copyright © 2024 Looop Inc. 58 AWSアカウントを組織に⼊れ、監査対象としたことでコストが増⼤同じタイミングでユーザが増え、実⾏されるノートブックも増加 EC2使⽤量が増⼤・クラスターのワーカー数を調整・定期実⾏をジョブランに変更 EC2とConfigの急激な増加利⽤が拡⼤することによりコストが増⼤定期的に⾒直しをしているが、ユーザ数とデータが増えることでコストは上昇導⼊後の苦労話 ⑧コスト増加問題

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Copyright © 2024 Looop Inc. 61 導⼊後の苦労話利⽤が拡⼤することによりコストが増⼤定期的に⾒直しをしているが、ユーザ数とデータが増えることでコストは上昇 • Databricksでコストを可視化し、定期的に⾒直しをしましょう。 • 当社では運⽤チームでコストダッシュボードを⽉に2回以上確認し、⾒直しを図っています。 • トータルコストだけではなく、AWSのサービスごとにコストを⾒ていきましょう。 • 時間帯ごと・曜⽇ごと・クラスターごとに⾒ていくと、回りっぱなしのジョブが⾒つかったりします。定期的なコストの観察は⾮常に重要。さらに、将来の利⽤拡⼤を加味して、頑張って予算を確保しましょう︕

Slide 62

Slide 62 text

Copyright © 2024 Looop Inc. 62 導⼊後の苦労話 • データ連携依頼が多すぎる問題 • 連携後の加⼯依頼が多すぎる問題 • データ分析依頼が多すぎる問題 • アカウント・権限付与依頼が多すぎる問題 • 分析結果の妥当性検証が⼤変 • インポート元のデータベースが破損してダッシュボードが停⽌ • エンジニアが⾜りない問題 • コストが積み上がってきている問題どれも利⽤者が増えてくれたことに起因。有り難い話︕ チーム体制を強化して対応してまいります︕

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Copyright © 2024 Looop Inc. 64 今後の展望 • 社内の全てのデータを連携したい • 直近ではSalesforceのデータに対する分析ニーズあり • 将来的には社内のあらゆるデータを分析できるようにしていく • どんどんダッシュボード化していきたい • Excelやスプシでの分析は、1回だけで済む業務のみにしていく • 2回以上⾏う分析はSQLを書いていき、どんどん⾃動化していく • データの⺠主化推進 • SQL勉強会の開催拡⼤ • 現在はレベルを統⼀した画⼀的な勉強会のみ。中級〜上級者向けを作っても良さそう • Databricks社のトレーニングをもっと取り⼊れたい • さらなる普及活動（全社利⽤への拡⼤） • データ利活⽤ • ノーコード・ローコード開発基盤との連携（Fivetranでデータ連携、Workatoでノーコード開発） • MLを作って将来予測するだけではなく、サービングして社内外にサービスを提供 → MLOps︕︕

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Copyright © 2024 Looop Inc. 66 Looopでんき、いかがですか︖ ⽇中は太陽光発電量が多く、電気が余りやすいため、市場単価が安い。この安い電気をたくさん使っていただける「市場連動型」プランをご⽤意しました。グッドデザイン賞を受賞したスマホアプリとともに、ぜひご利⽤ください︕ 0 2 4 6 8 10 12 14 16 0:00 0:30 1:00 1:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00 6:30 7:00 7:30 8:00 8:30 9:00 9:30 10:00 10:30 11:00 11:30 12:00 12:30 13:00 13:30 14:00 14:30 15:00 15:30 16:00 16:30 17:00 17:30 18:00 18:30 19:00 19:30 20:00 20:30 21:00 21:30 22:00 22:30 23:00 23:30 JEPXスポット価格 (2023.10.15 九州）最安値0.01円最⾼値13.49円円/kWh (税抜き） Looopでんきアプリは 2023年度グッドデザイン賞を受賞しました︕ https://looop-denki.com/

Slide 67

Slide 67 text

Copyright © 2024 Looop Inc. 67 データエンジニアさん・データアナリストさん⼤募集現在Looopでは、データエンジニア職、データアナリスト職を積極的に採⽤しています。ビッグデータを扱うパイプラインの構築、データ分析、機械学習モデルを⽤いた事業への貢献に興味がある⽅、ぜひ⼀緒に働きませんか︖募集要項は以下をご確認ください。まずはお話を聞いてみたい⽅は、カジュアルにお話しましょう︕ 募集要項カジュアル⾯談はこちらから︕

Slide 68

Slide 68 text