tetsuwan blog

鉄ワン(@tetsuwan30)の気ままなダイアリー

バドミントン

週末の日曜日。たまにはのんびり過ごしたいと思って部屋に閉じこもっていると、妻がガラッとふすまを開けて入ってきた。何事かと思ったら、何度も呼んでいるのに反応がないと怒っていた。集中したいのは分かるけれど、ただでさえよく聞こえないのに、ふすまを閉めて、窓は開けて外の音が騒がしくて、どうやって反応するのと。確かにそうだなと、集中したいというのもそうだったけど、ふすまを開けて、また部屋で過ごしていた。

しばらくすると、また妻から声がかかり、確かにふすまを開けていれば聞こえるなと思い、妻の部屋へと移動した。ひとしきり雑談をして、日本の現状を憂い、さて部屋に戻ってまた集中しますか、と思っていたら、妻が部屋にやってきた。さて、今度は何かなと思ったら、今、そういう気分になった。今からバドミントンをしないか、との提案。運動が嫌いな妻が運動に誘うタイミングは確かに貴重だから、そう思って素早く準備をした。

妻はさて何を準備したらいいだろうと尋ねてきて、確かに運動に後ろ向きな姿勢だと、何を準備すればいいのかも自分で決めきれないのだなあと納得した。一番大事なのは水分補給のための飲み物。それと汗をかくと思うからタオル。自分は足を痛めるといけないから靴を履くので、靴下を用意する、と伝えた。私はサンダルでやるから、といってそそくさと準備をしていたが、玄関に来るときには靴下をちゃんと履いていた。

外は暑くもなく、ちょうどいい空気でバドミントンをやるには最適だよね、といつも以上に饒舌な妻。たぶん、運動が嫌いだからこそ、いっぱい喋って気分を盛り上げているのか、もしくはごまかしているのか。自分はさっさと公園に行こうと、妻を尻目にさくさく歩き、家の向かいの公園に入る。公園には子どもたちや親子連れ。レジャーシートをひいたうえで上で団らんをする若者。そこそこにぎわっていた。ラケットを取り、シャトルを出すと、妻はこのシャトルはプラスチックではなく、鳥の羽を使っている良いものだとしきりに伝える。しゃべってないで、早くバドミントンを始めようとせかしたい気分になった。

公園はそこそこ広いので、他の人たちに干渉しない場所を見つけて、妻と向かい合う。シャトルを叩き、妻の上や横、時には足元に打ち、互いに少しづつラリーができる。二人とも、特にうまいほうでもなく、自分が若干身長と手の長さで有利に進めているような気になる。5分ぐらいやって、疲れる前に休憩を取る。飲み物を飲み、汗を拭く。妻に疲れていないかと声をかけると、全然大丈夫とのことで安心する。それだったら毎朝仕事前にできるのでは、といったがそれは無理だと妻。

AppleWatchで運動の時間を測り、ゲーム再開。風が少し吹くだけで、シャトルは勢いをなくしたり、逆に勢いがついて驚く。休憩の後のほうが少し、体が重く感じたりするので、時折足を延ばしたり、足首を回したりしてごまかす。途中、飛んできたシャトルが自分の足元にきて、思わず踏んずけてしまった。慌てて元の形に戻して、ドキドキしながらやってみると、踏んだせいなのか、疲れているせいなのか、どちらとも分からず、とりあえず真っすぐは飛ばない。妻は途中でラケットの曲がりぐわいが気になり、やはり2本セットで千円のものより、1本千円のほうが良いものであると話していた。

何回か休憩をはさんで、日も少しづつ暮れたころ、そろそろ終わろうかと言って、自分が最後に1セットと言ってラリーをして終える。たくさんの汗をかき、一生分の運動したという妻と家に帰った。良い運動したととても満足気で、自分もとてもうれしい。

データ活用:コードを書いて定義をする

0. 要旨

  • BIによるデータの分析は、コードによるデータの定義が重要になる
  • ついでにクラウドといった環境により、アウトプットがスケール可能になる

1. きっかけ:セルフBIによるデータの民主化の先を考えた

この前、知人とTableauやPowerBIといったBIツールの話をしたのが最初。 そこでふと今のBIってどうなんだろうと考えました。

BIツールでの分析

BIツールを使うと、データを取り込んで自分で分析することができます。 例えば、社員ごとの売り上げの一覧のデータがあれば、一覧をそのまま見ることも、合計や平均を計算したり集計ができます。 ツールの操作が、マウスや簡単なキーボード操作で出来るのも、メリットです。

セルフBIでデータの民主化

業務でより高度な分析が必要になると、データを組み合わせが必要になります。 例えば、社員ごとの売上の内訳、どの商品が売れたのか。またその商品の原価はそれぞれいくらか。 社員が営業のそれぞれどの組織に所属しているか。組織ごとに特徴があるか。 組み合わせるデータがまるでレゴのブロックのように、パーツが増えるとできることが増えます。 そうやって組み合わせを、分析したい人自身が行うことがセルフBIです。 組み合わせができるデータがあれば、誰もがデータができます。

組み合わせのプロを目指す?

そんなセルフBIですが、問題も抱えています。 問題が起きるのは、業務の規模が大きくなる時。 業務ごとにデータの種類が増えたり、時間とともにデータの量が増えたり。 そのためには、どう組み合わせるのが良いのか、高いレベルが求められます。 いわば、BIツールを使う人みんなが、データを組み合わせるプロである。 そんなプロを目指していくのはとても大変です。

セルフゆえに他の人まで配慮が難しい

また、個人がレポートを一人で作りこむことの問題もあります。 BIツールの中でどのような組み合わせをしたのか、作った人の暗黙知になりがちです。 もちろん作ったレポートの中身を見て確認もできますが、その作業も大変です。 セルフBIができるデータの民主化は、その人自身で終わりがちです。

データの組み合わせはデータ基盤で

そのため、データの組み合わせをレポートを作るユーザではなく、データを提供する基盤で行う。 そのような流れがあります。 個人で管理をするより、共通の管理をした方がいいのは間違いないですね。

セルフBIの先で必要なもの

昔は確かにシステム側でデータを取りまとめて、ユーザは貰ったデータでレポートを作る。 だからユーザのデータ分析のできる範囲が限られていました。 では、そこに戻るだけなのか、たぶんそうではないはずです。 セルフBIの先でユーザは何をするのか、考える必要があるのでは。 そんな話がきっかけでした。

2. 過去からの振り返り:BI以前

セルフBIの先で必要なものは何か。 ユーザの視点で考えていきました。

データ活用は業務の課題を解決するため

ユーザにとってデータ活用の目的は何か。 簡単にいうと、業務の課題を解決するためです。 業務の課題をどう解決するか、分析とは何か。 それを考えていくとよさそうです。

データ活用をBI以前からふりかえる

分析をするためにBIツールを使うとしたら、今まではどうだったのか。 BIツールが生まれる以前から仕事の中でデータを活用しているはず。 そう思って、BI以前のデータ活用を振り返ってみました。

第1世代 電卓と紙で仕事をする

まだPCも無かった時代。 紙の書類で手書きをするか、ワープロで印刷した紙を使っていた時。 そろばんを使う人もいたかと思いますが、電卓を使っているイメージ。 職場がWindows95のPCが発売されるまでは本当にそんな環境でした。 ただ、そんな中でも紙には項目を一覧で書くこともできました。 電卓で四則演算を駆使して、合計や平均も出してデータを使っていました。

第2世代 表計算とファイルで仕事をする

それからPCが職場に普及してくると、MicrosoftExcelのような表計算ソフトが使われます。 縦と横に項目があり、数値の組み合わせがとても柔軟になってきます。 そしてPCを使う最大のメリットとして、ファイルで保存をして再利用もできるようになります。 業務事態もPCを使うようになると、業務システムが導入されます。 データの分析は業務システムからデータをファイルでもらうこともできるように。 もらったファイルはExcelに取り込んで使うことができます。

第3世代 BIツールとメールで仕事をする

ファイルでデータをもらうっていたものが、データ活用をするための分析システムに変わります。 分析のデータをとりまとめるためのシステムが整備されていきました。 Excelを使っていたユーザは、直接分析システムのデータを使うことが便利になりました。 そのツールこそがBIツールになります。 またデータのファイルも、メールや様々なメッセージアプリでのやり取りができるように。

3. 次の世代のイメージ:第4世代

ここまでBI以前を振り返ってどんな仕事の環境だったのか。 イメージしていくと、なんとなく整理できた気がします。 では、次の世代のイメージはどうなのか。 今キャッチアップした最近のトレンドから探ってみます。

Looker、Databricks、dbt:データをメタで取り扱う

LookerはセルフBIの次の形だと言われています。 具体的にはデータマートを抽象化して管理しやすくしたものです。 DatabricksはデータレイクとDWHのいいとこどり。 データのストレージを抽象化したデータレイクと、DBの構造をクエリエンジンで扱いやすくしたもの。 dbtはSQLでのデータ管理を抽象的かつ構造的にしたもの。 それぞれはツールやプラットフォームですが、データを抽象的、メタとして扱いたい感じです。

VSCodeWindowsターミナル、Winget:テキストによる操作

VscodeテキストエディタをベースにしたIDE環境。 プログラミング言語での開発に役立つ機能拡張やGit、MarkdownCSV、ターミナルさえも使えます。 コマンドパレットと呼ばれるコマンドを呼び出しての操作も可能。 Windosターミナルは、コマンドプロンプトPowerShellだけでなく、WSLなどのLinuxも使えるます。 このタイミングでテキストで処理をさせるためのターミナルソフトをMicrosoft純正で提供。 wingetも純正のコマンドベースのインストーラーです。 これらの一式はWindowsGUIでの操作だけではなく、テキストによる操作を一方で推奨しているのです。

データガバナンス、データマネジメント:データを主体的に管理する

データをどう取り扱うのがよいか。 DMBOKでも記載がありますが、それがデータガバナンスとデータマネジメントです。 これらはデータを使うユーザこそデータがちゃんとしていないことの影響を受けると説いています。 そのため、データを主体的にユーザが管理することが重要です。

第4世代:コードとクラウドで仕事をする

それらを踏まえると、まずテキストベースでのデータの取り扱いが考えられます。 例えばSQLのようにコードを書いて、コードベースでデータを取り扱うこと。 PythonやRのようにプロットやグラフもコードで表現するのもイメージできそうですね。 また、紙からファイル、メールといった流れから、クラウドでの仕事と言ってよさそうです。 クラウドを使うというのは、URLをシェアしたり、APIで連携したりといったイメージになります。

4. データとの向き合い方

ここまで世代を振り返り、次世代をイメージしてきました。 その世代ごとに何が変化したのか、データとの向き合い方が進化したのでは。 そういった視点で考えていきます。

データ活用のイメージ

データとの向き合い方を考えるうえで、参考までにデータのイメージがあるといいかもしれません。 例えば、ある事業の課題の解決のデータ活用です。 その業務の「目標を定めて」「所定の期間で」「現状から実績を積み上げます」。 目標値、期間、実績値。 他にも、費用や担当者といったデータがありそうですね。

第1世代 計算

電卓を使うことで、計算を駆使することができるようになりました。 平均、割合、比率。 どれぐらいのペースで実績を出しているのか。 費用が効果的か。 統計的な考え方ができるようになったといってもいいでしょう。

第2世代 集計

表計算を使うことで、データは値からリストに、リストから表になっていきます。 すると、クロス集計やピポットといった表計算でお馴染みの比較ができます。 グループ分け、フィルター抽出、結合などもあります。

第3世代 分析

BIツールを使うことで、グラフや図によるデータの可視化。 操作がさらに直感的にできるようになったインタラクティブ性。 さらにデータの自動更新が可能になり、レポーティングとしての機能も重視されます。 大局的に特徴を捉えること、試行錯誤を伴うPDCAを回していくことが可能になっていきます。

第4世代 定義

では、コードを使うことがデータ活用になった場合。 コードで実現できることは、型、条件、範囲、命名、分岐といった定義になります。 定義を行うことでデータ活用に必要な要素を定める。 それが一番重要になります。 要素が定まれば、あとはその範囲の中で変化する値としてパラメータを調整します。

5. 結果のアウトプット

データの向き合い方が進化からセルフBIの次を考えました。 もう一つの視点として、データ活用をその結果をどのようにアウトプットするのか。 アウトプットの進化から考えていきます。

第1世代 記録

紙の一番の役割は記録ができることです。 計算した結果、収集したデータ。 それをすべて紙に記録することで結果を別のところにアウトプットすることができます。 まず結果を残そうというのは今でももちろん重要です。

第2世代 デジタル

PCでファイルを取り扱えるというのは、デジタルであるということです。 デジタルとしての特徴。同一性が担保していること、再利用ができることです。 アウトプットとして、データの品質にかかわる重要なところです。

第3世代 コラボレーション

メールやメッセージアプリの役割は、アウトプットの相手とやり取りがしやすくなったということです。 アウトプットを別の利用者に展開できることで、価値がさらに高まっていきます。

第4世代 スケール

クラウドでのアウトプットとは、同時に複数の利用者と利用できること。 人だけではなく、APIがつながるあらゆるシステムとその先の利用者をつなぎます。 アウトプットの利用の広がりを最大化していく、そのような進化になっていくでしょう。

6. まとめ:より主体性を高くする

BIによるデータの分析は、次の世代ではコードによるデータの定義が重要になると予想します。 それは業務のこれまでの変化と、さらにデータの取り扱い方の進化を踏まえたものです。 ついでにクラウドといった環境により、アウトプットが進化し、よりスケールしていきます。 それは、セルフBIの先により主体性を持ってデータ活用をする利用者であるということにつきます。

命名規約やデータに関する情報とか

コードの可読性 code-readability

engineering.linecorp.com

engineering.linecorp.com

engineering.linecorp.com

engineering.linecorp.com

engineering.linecorp.com

初心者プログラマーのための英語命名

qiita.com

GitLabチームハンドブック

about.gitlab.com

Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops

speakerdeck.com

データモデリング

speakerdeck.com

データの共通理解推進ガイド

www.ipa.go.jp

Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス

zenn.dev

データサイエンティスト向け性能問題対応の基礎

www.slideshare.net

PMBOK

speakerdeck.com

GitLabで学んだ最高の働き方

learn.gitlab.com

Databricksや一般的なデータ環境の構成要素をまとめてみた

  • Databricksのことを調べつつ、構成しているものって何?とか思いながら、まとめてみました。

背景・経緯

  • 昨年までGoogle CloudでBigQueryを中心にデータ分析基盤を扱っていた
  • 単純な、Storage(データレイク)→DWH→BIだけでは無さそう
  • よりデータ環境の要素を整理して、レイヤーの重なりとそのプロダクトを押さえていきたい

Databricks Components

  • Delta Lake
    • Data Lake Table Formats
  • Databricks Lakehouse
    • Delta tables
      • ACID transactions
      • Data versioning
      • ETL
      • Indexing
    • Unity Catalog
      • Data governance
      • Data sharing
      • Data auditing
  • Databricks SQL
    • ad-hoc query
    • create visualization
    • share dashboards

データ環境の構成要素

  • Storage(ストレージ)
  • File Format(ファイル形式)
  • Data Lake Table Formats(データレイクテーブル形式)
  • Data Ware House(データウェアハウス)
  • Query Engine(クエリーエンジン)
    • Hive
    • Presto / Amazon Athena
    • Spark SQL + DataFrame / AWS Glue ETL operations
    • Photon

PowerShellでsqlファイルをinclude

PowerShellsqlファイルをimport

$testCaseFilePath = "./unique.sql"
$testCaseFile = (Get-Content $testCaseFilePath) -as [string[]]

$targetModelFilePath = "./target_model.sql"
$targetModelFile = (Get-Content $targetModelFilePath) -as [string[]]

$targetColumnFilePath = "target_column.sql"
$targetColumnFile = (Get-Content $targetColumnFilePath) -as [string[]]

$outputFile = $testCaseFile.replace('%%target_model%%',$targetModelFile).replace('%%target_column%%',$targetColumnFile)

Write-Output $outputFile > ./output.sql

unique.sql

WITH target_model AS(
  
%%target_model%%

)
SELECT
  CASE
    WHEN COUNT(%%target_column%%) = COUNT(DISTINCT %%target_column%%) 
    THEN True
    ELSE False
  END AS result
FROM
  target_model

target_model.sql

/* メンバーの一覧 */
SELECT
  id
  ,member_name
  ,team_id
FROM
  sample_scores.members

target_column.sql

id

dbt覚書

  • dbtについての覚書 ** 元の記事は、githubに置いてます github.com

  • 確認したバージョン

% dbt --version
Core:
  - installed: 1.2.0
  - latest:    1.2.0 - Up to date!
Plugins:
  - bigquery: 1.2.0 - Up to date!

1. dbt CLI

  • インストールして使用するCoummunity版のツール

1.1. インストール

1.2. ざっくりとした使い方

% dbt --version                 # dbtのインストールされたバージョンを確認する
% dbt init [プロジェクトフォルダ]   # 初期セットアップ 
% cd [プロジェクトフォルダ]         # 作成したプロジェクトフォルダの中に入る
% dbt debug                     # 設定ファイル通りにデータベースに接続できるかチャックする
% dbt deps                      # 追加設定したパッケージを取り込む
% dbt run                       # モデルを作成する
% dbt test                      # 作成したモデルをテストする

1.3. フォルダ・ファイルの構成

.
├─ .dbt
│  └─ profiles.yml        # 設定ファイル
└─ プロジェクトフォルダ
   ├─ dbt_project.yml     # プロジェクトの設定ファイル
   ├─ analyses
   ├─ dbt_packages        # 追加でインストールしたパッケージを格納するフォルダ
   ├─ logs                # 実行したログが出力されるフォルダ
   ├─ macros              # SQLで使うマクロを保存するフォルダ
   ├─ models              # モデルのスキーマやSQLを保存するフォルダ
   │  ├─ schema.yml       # モデルのスキーマを設定するファイル、テストも書く
   │  └─ hogehoge.sql     # モデルのSQLを書くファイル
   ├─ seeds               # インポートするCSVファイルを保存するフォルダ
   ├─ snapshots           # スナップショットを保存するフォルダ
   ├─ target              # モデルやテストで作成したSQLを保存するフォルダ
   └─ tests               # テスト用のSQLを保存するフォルダ

2. テスト

2.1. dbtのテストパターン

  • モデルやカラムごとに行いたいテストパターンをまとめました

カラム

No. 分類 テスト事項 機能 書き方
1 値の確認 ユニークな項目か 標準 unique
2 値の確認 必ず値が入っているか 標準 not_null
3 値の確認 指定した値が入っているか 標準 accepted_values
4 値の確認 指定した値が入っていないか dbt_utils not_accepted_values
5 値の確認 値が指定した範囲内に入っているか dbt_utils accepted_range
6 値の確認 条件通りの結果になるか dbt_utils expression_is_true
7 列の確認 他のテーブルと結合できるか 標準 relationships

モデル

No. 分類 テスト事項 機能 書き方
1 行の確認 他のモデルと、モデルの行数が同じか dbt_utils equal_rowcount
2 行の確認 他のモデルより、モデルの行数が少ないか dbt_utils fewer_rows_than
3 列の確認 他のモデルと、共通の項目になっているか dbt_utils equality
4 列の確認 指定された項目が入っているかj dbt_expectations expect_table_columns_to_contain_set
5 列の確認 指定された項目が入っていないか dbt_expectations expect_table_columns_to_not_contain_set
6 列の確認 指定された項目と一致しているか dbt_expectations expect_table_columns_to_match_ordered_list
7 列の確認 列数があっているか dbt_expectations expect_table_column_count_to_equal
8 値の確認 条件通りの結果になるか dbt_utils expression_is_true

2.2. Generic tests

version: 2

models:
  - name: teams_all
    description: "teams all"
    columns:
      - name: pos
        description: "list postion"
        tests:
          - not_null
      - name: id
        description: "team id"
        tests:
          - unique
          - not_null

2.3. Singular tests

  • testsフォルダにテスト用のSQLを書く

最速データガバナンス

  • 前提条件
    • まだ全社のデータガバナンスの部門や担当がいない状態

1. ステークホルダの特定

1-1. 組織情報を探す

  1. 組織図や体制図などを探す
  2. データに関わる部門や担当者を探す
  3. 社内ポータルやイントラネット、ファイルサーバなどを検索する
  4. 自身のやり取りするメールや転送メールから検索する
  5. SlackやTeamsなど社内SNSから検索する

1-2. 各事業部門を特定する

  1. 事業部を探す
  2. 各事業部内の企画部門を探す
  3. 各企画部門の責任者を特定する

1-3. データエンジニアリング部門を特定する

  1. エンジニア部門を探す
  2. エンジニア部門内のデータエンジニアリング部門を探す
  3. データエンジニアリング部門の責任者を特定する

1-4. 情報セキュリティ部門を特定する

  1. 法務やコンプライアンス担当部署を探す
  2. 情報セキュリティ担当部門を探す
  3. 情報セキュリティ担当部門の責任者を特定する

1-5. 各事業部の横断し、全体の統括部門を特定する

  1. 事業部を統括する横断組織を探す
  2. 横断組織の責任者を特定する

2. 情報の収集

2-1. 各企画部門の責任者との対話

  1. 各企画部門の責任者と下記の話をする
    • 事業のケイパビリティやKPI
    • 事業の抱える主な課題とその対応状況
    • 現在のデータ活用の状況や課題
    • 課題解決にデータ活用が寄与するか
    • 各事業の全体像の共有
    • 各事業に関するドキュメントの運用や共有状況

2-2. データエンジニアリング部門の責任者との対話

  1. データエンジニアリング部門の責任者と下記の話をする
    • 各事業部とのデータ領域での接点や対応状況
    • 情報セキュリティ部門とのデータ領域での接点や対応状況
    • データエンジニアリング部門の抱える主な課題とその対応状況
    • データインフラやICTの全体像の共有
    • データに関するドキュメントの運用や共有状況

2-3. 情報セキュリティ部門の責任者との対話

  1. 情報セキュリティ部門の責任者と下記の話をする
    • 各事業部との情報セキュリティでの接点や対応状況
    • データエンジニアリング部門との情報セキュリティでの接点や対応状況
    • 情報セキュリティ部門の抱える主な課題とその対応状況
    • 情報セキュリティ取り組みの全体像の共有
    • 情報セキュリティに関するドキュメントの運用や共有状況

2-4. 全社トップのメッセージを確認する

  1. 全社集会や全社ポータルなどトップのメッセージを確認する
  2. 上場していれば、IRなど社外へ発信している資料を確認する
  3. グループ会社に所属している場合は、グループトップのメッセージを確認する

2-5. オウンドメディアを確認する

  1. 会社がオウンドメディアを持っていれば、その情報からデータに関する

2-6. マーケットを確認する

  1. 自社が属する業界の市場を確認する
  2. 業界団体や監督官庁があれば、その団体が発信する情報を確認する
  3. 特にデータ利活用やデータガバナンス、DXに関する情報がないか確認する
  4. 同業他社が発信している情報を確認する
  5. 業界関係者が発信している情報を確認する

3. データ利活用の課題の整理

3-1. ヒアリングした情報をまとめる

  1. 自社の組織、関係性、データ利活用に関わるステークホルダーをまとめる
  2. 各事業の特徴とそのKPI、データ利活用との相関、課題を整理する
  3. 各事業部とデータエンジニアリング部門、情報セキュリティ部門の依存関係を可視化する
  4. 社内のドキュメントの運用状況をまとめる

3-2. 全社の課題に関わるリスクやコストを特定する

  1. トップのメッセージが提示するミッション、ビジョンとヒアリングした内容を比較する
  2. 比較して合致した部分、合致しなかった部分を明確にする
  3. 明確になった部分からデータ利活用にとって、リスクやコストが大きな部分を特定する

3-3. 社外情報と比較して、自社の置かれている状況を把握する

  1. 事業やそれに関わるデータ利活用の課題に対して、社外との情報を付き合わせる
  2. 自社の優位性や劣位性、自社の課題解決に関わりそうな情報を探す

4. 課題の共有と検討

4-1. 横断組織の責任者との対話

  1. 横断組織の責任者と下記の話をする
    • 各事業部と横断組織の接点や対応状況
    • データ利活用の課題とその認識の齟齬の有無
    • 組織を横断した課題解決としてのデータガバナンスの提案
    • 取り組みの体制と今後の進め方について

5. データガバナンスの実施

  1. 体制と計画の作成
  2. 計画の実行
  3. 計画の振り返りと再計画