年末にウクライナ国立バレエを見て、最近とみにバレエに興味があります。 なので、まずはバレエ漫画を色々と調べて、読んでみようかなとリスト化してみました。
ジョージ朝倉
山岸 凉子
槇村 さとる
星合 操
- ユニコーンの恋人 合冊版1 (少女宣言)
- ユニコーンの恋人 (1) (宙コミック文庫)
- ユニコーンの恋人 (2) (宙コミック文庫)
- ユニコーンの恋人 (3) (宙コミック文庫)
- ユニコーンの恋人 (4) (宙コミック文庫)
- ユニコーンの恋人 (5) (宙コミック文庫)
ITコンサルタントのためのデータエンジニアリング入門 1
ITコンサルタントの仕事をするうえで、改めてデータをどう取り扱っていくのか、下記の記事に触発されて書いてみました。
なかなか、ざっくりとした内容なのでこういう視点で考えている、という目安ぐらいにしてもらえるとありがたいです。
1. アウトカムとKPI
1.1 プロジェクトの成果であるアウトカム
- あるプロジェクトが生まれた時、そのプロジェクトの成果であるアウトカムを確認する
- アウトカムは、プロジェクトに関わるステークホルダーが同じように認知しているもの
1.2 アウトカムを得るために必要な材料とそのプロセス
- アウトカムを得るために、プロジェクトでは必要な材料を揃えていく
- その必要な材料をそろえて、最終的なアウトカムになるまでのプロセスを描く
1.3 プロセスと各ステップを計測するためのKPI
- 必要な材料は、そのプロセスの中でステップごとに計測を行う
- 計測すべき数値を決め、KPIとして定量的に取得できるようにする
2. BPMLとデータフロー
2.1 プロセスを業務のフローで作るBPML
- プロセスは業務の流れを可視化するフローであるBPMLに書き出す
- 最初は全体像を把握できることを目的とし、細部は問わない
2.2 プロセスの各ステップのKPIをデータとして表す
- フローの各ステップのKPIに注目したフローを別に作る
- KPIはそれぞれプロセスで発生したデータから集計を行う
2.3 そのステップのデータの状態の遷移からデータフローを作る
- 各ステップごとに集計するデータの状態が変わっていく
- そのデータの状態がどう遷移していくのか、フローに落とし込む
3. 定義！定義！定義！
- データフローで扱うデータがどのようなものか、それがどうなっていくのか、定義する
3.1 データの項目を定義する
- データの状態を定量的に集計できるように定義を行うv
- 個々のデータの項目定義は、名前、型で表す
3.1.1 名前
- 名前は実態に即してわかりやすいものとする
- 似たような項目は共通した命名ルールに基づく
- 名前から項目の中身が想像できること
- 一般的な単語を使い、初見で誰もがイメージできる必要がある
3.1.2 型
- データがどのようなかたちで値として保持できるか、型を定義する
- 定義された型によって、その値をどのように取り扱うか決まる
3.1.2.1 Boolean
- True,Falseといった、その状態である、その状態でない、の2種類を持つ型
3.1.2.2 Numeric
- 数値
- 算術数字を持つ型、Integer、Float、Decimalなど、数値の表現の仕方で使い分ける
3.1.2.3 Character
- 文字列
- 文字として扱う型、String、Text、Char、VarCharなど、文字列の値の保持の仕方で使い分ける
3.1.2.4 DateTime
- 日時
- 年月日、時分秒、Timezoneとして扱う型、Date、Time、DateTime、DTZなど、日時の値の保持の仕方で使い分ける
3.2 データの状態の変化
- データの状態は項目ごとに型をともなって値が入る
- そのデータの値の取り扱いとしてCRDUがある
3.2.1 Create
- データが新しく作る
- データはもとになるものから作る
3.2.1.1 固定値からつくる
- True / False
- 決まった数値、文字列、日時
- 現在日時
- ランダムな値
3.2.1.2 他のデータから作る
- 他のデータに基づいてデータを作る
- データの数値を集計した合計や平均などの集合
- データの数値の閾値から判断したTrue / False
- 文字列の一部を切取や結合
3.2.2 Read
- データを参照する
- データがあること、ないことが判別できる
- 参照したデータをもとにCreate、Delete、Updateができる
3.2.3 Delete
- データを削除する
- 削除をすることで参照ができなくなる
3.2.4 Update
- すでにあるデータを更新する
- Createと同様に、固定値での更新や他のデータからの更新ができる
4. データの収集と加工と集計
4.1 データの収集
- ファイル保管やデータベースのレコードへの追加などデータを集める
- データは揃っていること、論理的に矛盾がないことが求められる
4.2 データの加工
- データは集計ができるように加工が必要である
- 集計する型や単位を揃える
- 関連する項目を分類し、集計する軸となるローデータを用意する
- 集計する軸など、分類や識別する項目などを定めたマスタデータを用意する
4.3 データの集計
バドミントン
週末の日曜日。たまにはのんびり過ごしたいと思って部屋に閉じこもっていると、妻がガラッとふすまを開けて入ってきた。何事かと思ったら、何度も呼んでいるのに反応がないと怒っていた。集中したいのは分かるけれど、ただでさえよく聞こえないのに、ふすまを閉めて、窓は開けて外の音が騒がしくて、どうやって反応するのと。確かにそうだなと、集中したいというのもそうだったけど、ふすまを開けて、また部屋で過ごしていた。
しばらくすると、また妻から声がかかり、確かにふすまを開けていれば聞こえるなと思い、妻の部屋へと移動した。ひとしきり雑談をして、日本の現状を憂い、さて部屋に戻ってまた集中しますか、と思っていたら、妻が部屋にやってきた。さて、今度は何かなと思ったら、今、そういう気分になった。今からバドミントンをしないか、との提案。運動が嫌いな妻が運動に誘うタイミングは確かに貴重だから、そう思って素早く準備をした。
妻はさて何を準備したらいいだろうと尋ねてきて、確かに運動に後ろ向きな姿勢だと、何を準備すればいいのかも自分で決めきれないのだなあと納得した。一番大事なのは水分補給のための飲み物。それと汗をかくと思うからタオル。自分は足を痛めるといけないから靴を履くので、靴下を用意する、と伝えた。私はサンダルでやるから、といってそそくさと準備をしていたが、玄関に来るときには靴下をちゃんと履いていた。
外は暑くもなく、ちょうどいい空気でバドミントンをやるには最適だよね、といつも以上に饒舌な妻。たぶん、運動が嫌いだからこそ、いっぱい喋って気分を盛り上げているのか、もしくはごまかしているのか。自分はさっさと公園に行こうと、妻を尻目にさくさく歩き、家の向かいの公園に入る。公園には子どもたちや親子連れ。レジャーシートをひいたうえで上で団らんをする若者。そこそこにぎわっていた。ラケットを取り、シャトルを出すと、妻はこのシャトルはプラスチックではなく、鳥の羽を使っている良いものだとしきりに伝える。しゃべってないで、早くバドミントンを始めようとせかしたい気分になった。
公園はそこそこ広いので、他の人たちに干渉しない場所を見つけて、妻と向かい合う。シャトルを叩き、妻の上や横、時には足元に打ち、互いに少しづつラリーができる。二人とも、特にうまいほうでもなく、自分が若干身長と手の長さで有利に進めているような気になる。5分ぐらいやって、疲れる前に休憩を取る。飲み物を飲み、汗を拭く。妻に疲れていないかと声をかけると、全然大丈夫とのことで安心する。それだったら毎朝仕事前にできるのでは、といったがそれは無理だと妻。
AppleWatchで運動の時間を測り、ゲーム再開。風が少し吹くだけで、シャトルは勢いをなくしたり、逆に勢いがついて驚く。休憩の後のほうが少し、体が重く感じたりするので、時折足を延ばしたり、足首を回したりしてごまかす。途中、飛んできたシャトルが自分の足元にきて、思わず踏んずけてしまった。慌てて元の形に戻して、ドキドキしながらやってみると、踏んだせいなのか、疲れているせいなのか、どちらとも分からず、とりあえず真っすぐは飛ばない。妻は途中でラケットの曲がりぐわいが気になり、やはり２本セットで千円のものより、１本千円のほうが良いものであると話していた。
何回か休憩をはさんで、日も少しづつ暮れたころ、そろそろ終わろうかと言って、自分が最後に１セットと言ってラリーをして終える。たくさんの汗をかき、一生分の運動したという妻と家に帰った。良い運動したととても満足気で、自分もとてもうれしい。
データ活用：コードを書いて定義をする
- 0. 要旨
- 1. きっかけ：セルフBIによるデータの民主化の先を考えた
- 2. 過去からの振り返り：BI以前
- 3. 次の世代のイメージ：第4世代
- 4. データとの向き合い方
- 5. 結果のアウトプット
- 6. まとめ：より主体性を高くする
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が職場に普及してくると、MicrosoftのExcelのような表計算ソフトが使われます。 縦と横に項目があり、数値の組み合わせがとても柔軟になってきます。 そしてPCを使う最大のメリットとして、ファイルで保存をして再利用もできるようになります。 業務事態もPCを使うようになると、業務システムが導入されます。 データの分析は業務システムからデータをファイルでもらうこともできるように。 もらったファイルはExcelに取り込んで使うことができます。
第3世代 BIツールとメールで仕事をする
ファイルでデータをもらうっていたものが、データ活用をするための分析システムに変わります。 分析のデータをとりまとめるためのシステムが整備されていきました。 Excelを使っていたユーザは、直接分析システムのデータを使うことが便利になりました。 そのツールこそがBIツールになります。 またデータのファイルも、メールや様々なメッセージアプリでのやり取りができるように。
3. 次の世代のイメージ：第4世代
ここまでBI以前を振り返ってどんな仕事の環境だったのか。 イメージしていくと、なんとなく整理できた気がします。 では、次の世代のイメージはどうなのか。 今キャッチアップした最近のトレンドから探ってみます。
Looker、Databricks、dbt：データをメタで取り扱う
LookerはセルフBIの次の形だと言われています。 具体的にはデータマートを抽象化して管理しやすくしたものです。 DatabricksはデータレイクとDWHのいいとこどり。 データのストレージを抽象化したデータレイクと、DBの構造をクエリエンジンで扱いやすくしたもの。 dbtはSQLでのデータ管理を抽象的かつ構造的にしたもの。 それぞれはツールやプラットフォームですが、データを抽象的、メタとして扱いたい感じです。
VSCode、Windowsターミナル、Winget：テキストによる操作
VscodeはテキストエディタをベースにしたIDE環境。 プログラミング言語での開発に役立つ機能拡張やGit、Markdown、CSV、ターミナルさえも使えます。 コマンドパレットと呼ばれるコマンドを呼び出しての操作も可能。 Windosターミナルは、コマンドプロンプトやPowerShellだけでなく、WSLなどのLinuxも使えるます。 このタイミングでテキストで処理をさせるためのターミナルソフトをMicrosoft純正で提供。 wingetも純正のコマンドベースのインストーラーです。 これらの一式はWindowsがGUIでの操作だけではなく、テキストによる操作を一方で推奨しているのです。
データガバナンス、データマネジメント：データを主体的に管理する
データをどう取り扱うのがよいか。 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の先により主体性を持ってデータ活用をする利用者であるということにつきます。
命名規約やデータに関する情報とか
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
- Delta tables
- Databricks SQL
- ad-hoc query
- create visualization
- share dashboards
データ環境の構成要素
- Storage（ストレージ）
- File Format（ファイル形式）
- Data Lake Table Formats（データレイクテーブル形式）
- Data Ware House（データウェアハウス）
- Query Engine（クエリーエンジン）
PowerShellでsqlファイルをinclude
PowerShellでsqlファイルを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