ことの背景
特定の人には当てはまるのではないかと思うが、あるETL処理の特にキモになる部分について、コンセプトを図示して説明したいことがある。
ETL製品のモデリング機能やプログラミングほど厳密なものでなくても良い。むしろそれができるなら苦労はしないというところか。
細かくもなく大きくもなく、どちらかといえばビジネスルールやビジネスロジックあるいは前提条件をまとめたい。 ただし、図解やマンガにするほど読み手に合わせる必要はなく、かといって厳密な文章や論文風の説明では書く方も読む方も負担が大きい。 つまるところ、もっと軽量なものが良い。
このような図示が求められる状況自体、幸せなシチュエーションではないような気がする。 まあ、それはさておくとする。
都合の悪いことに、設計支援アプリケーションや設計図作成用のアプリケーションは使えないという症状を併発することも多い。
そう、Microsoft Officeしか実質使えないという状況。
としたところで、ふと気づく。
ETL処理のキモとなる、ビジネルルールやビジネスロジックを、読み書きの負担をできるだけかけずにまとめる記法ってこれといったものがない？
使えそうな記法 俺様調べ
何か見逃しているとシャクなので棚卸ししてみる。
| 記法 | 何が表現できるか/表現するものか | ETLのビジネスルールなどの記法にあたっての評価 |
|---|---|---|
| フローチャート | 作業の順序、あるいは作者の頭の中の「うまいやり方の流れ」。 | データやモノの流れやインとアウトの図示には向かない。これは不勉強で私がそう思っているにすぎないが、視点がふらつきすぎるので扱いづらい。勝手に別の用途をでっちあげて、それには向かないとケチをつけるのもどうかと思うが、フローチャートには、データやデータストアを表すオブジェクトも存在して、これらと分岐のダイヤが同じレベルで矢印で結ばれるのがしっくりこないんだろうな。 |
| DFD | データが発生して流れて永続化されてというしかけを表現 | EAレベルのビジネスモデルや要件、それらを実現するシステム構成は描ける。一見すると「データ」視点なのでETL処理と相性が良さそうだが、今回注目している実際のビジネスルール、ビジネスロジックを切り口した視点には向かなそう。 |
| アローダイアグラム | 依存関係・順序関係 | 別物 |
| ガントチャート | 計画通りに進むべきものの工程の大まかな流れと完了率 | 別物 |
| ステートチャート | ある特定の1件のモノの遷移 | 別物 |
| BPMN | 業務プロセス | 業務プロセスであってデータ処理プロセスではない。表現力が高いので使えるなら使いたいが、工程や登場人物の連携にスポットがアタている分、目的外使用だとかえってミスマッチが出るかな。 |
| ETL系製品のモデリングツール画面 | UNIXのシェルのパイプでコマンドを繋げて全体の処理を実現するのをビジュアル化したようなパイプライン風の表現 | 本当はこれが本命。実際いくつか製品を見て見る限りだと、大体みんな同じような考え方なので業界団体かなにかで標準化できるのではと思う。ただ、逆に差別化もろもろ商売の都合もあってそういう流れにはなりにくいのかもしれない。 |
番外： EIP(Apache Camel)
最初はこれが求めているものではないかと思って調べていた。
https://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.html
のようにアイコン化されているのもポイント高し。 ただ、これ自体の目的が、言葉は古いかもしらんが、EAI/SOAとかの視点なので今回やりたいことからすると違う。
仕方がないので...
自分が浅学なだけかもしれないが、しっくりくるものはなさそう。
世間の人は困っていない中、仕方がないのでというのも失礼な話だが、欲しいなら作るしかない。
まあ、作るというよりは、なんらかのドキュメントに軽めの凡例をつけておけば、経験者や未経験者だけどカンの良い人には伝わるというものが欲しい。 Powerpointの図形アイコンを目利きするというところだろう。
ということでしばらく時は流れ、次のような方針にいたる。
- 結局のところ、ETLの処理は、pandasのチートシートで挙げられている例ぐらいをアイコン化できていればサマになりそう。
- 用途からいうと、ビジュアルプログラミングの類ではないので、チューリング完全とかを目指す必要はない。
- じゃあ、何を図から読み取りやすければ、目的が果たせるだろうか。ETLの処理らしさとはなんぞや。上記の各チャート記法に欠けているものと一致する何かということになるだろう。それを重視した表記になるべきだ。（おおげさ）
俺々ETL処理表記法(1/2)
具体的には、パイプライン風のコンポーネント上を2次元の行列型のデータが流れていくことを図示する。
いくつか余所の概念を借りると、この行列型のデータはpandasやRのDataFrameだ。DataFrameをモチーフにするとすっきりする。
ETL処理、および今回の表記法では、コンポーネントはインプットのDataFrameに何らかの変換を繰り返して、最終のアウトプットのデータを作り上げる... と捉えることにする。
各アイコンは未定義だが、ひとまずこの考えの根底にある暗黙の表現ルールは次の図のようなイメージだ。
以下、重要（だと思う）アイコンの考え方をつらつらと定義していく。
ETLっていうぐらいだからT(Transform)に注目するが、つきつめるとカラムの追加だなという話
ETL処理を、DataFrameの行列型のデータが流れていく中で変換を繰り返してという処理の理解においては、各行に同じ処理を行うのが基本パターンだろう。
よって一行単位の処理かどうかがが視覚的にわかると良い。これは矢印の表記を使い分けて表現する。（次の図のD)
ETLの処理は、基本的には各行について、ある列を元に、変換や演算の結果として新しい列を追加することを繰り返すと言えると思う。 新しい列と元の列を組み合わせたり、追加した列どおしを組み合わせてさらに新たな列を生成する。 ETLのトランスフォームは列の追加の繰り返しとするなら、これをそれっぽく見せるアイコンを用意する。(次の図のA)
実際にはメモリの消費量を抑えるためや設計をシンプルにするために、以後必要な列のみに絞ったDataFrameを後続に引き継いでいくべきだが、それらは実装のテクニックなので、今回のビジネスルールなどのコンセプトを図示する目的からいうと、特定の列のデータにのみ絞り込むことを表す表記方法は不要だ。変数のマネジメントの表現は本記法においては必要ない。 と考えるとコトはかなりシンプルになる。
DataFrameの形が変わるような変換はOUTPUTの節目や最終段階を告げる変換として注目
カラム追加を繰り返していくだけで処理が進んでいけば良いが、場合によっては、縦持ちを横持ち(pandasならpivot)にしたり、横持ちを縦持ちにする(pandasならmelt)といった、ETLのLoad前の最後に出てくるような変換もある。
これは、前述の列追加型は行うもののDataFrameの行数を変えない例と区別したい。区別することで、カラム追加の処理なのか、DataFrameの形が変わるような行と列の縦横にまたがる変換が発生するのか視覚化されやすい（と思う） 。（一つ前の図のB)
一つ前の図のA、B以外になんらか吹き出しなどで説明することで、A、Bあるいはそれ以外の変換にあたるものを表現できるように保険のアイコンを設ける。ビジュアルプログラミングなどを目指すものではないので、こういう逃げも十分ありだろう。
データの選択
このほかに、そもそもデータを絞り込むコンポーネントはアイコンを使い分けたい。 個別のアイコンを用意することで、部分集合で表されるサブドメイン領域が処理対象となることが明確になる。
俺々ETL処理表記法(2/2)
以降は、実際の要件にそって、前項までのアイコンがしっくりくるか、また、ほかにアイコン定義をした方が良さそうな例を定義しながらまとめる。
取引明細から取引額がある基準のものについて優待パターンを決めてデータ出力する
SQL1本で実現可能な要件なので、例のための例だが、次のような図で表してみる。
- ドラム缶はデータベースなどの情報源。矢印の入り口に配置すると入力データ。出口に配置すると出力データ。
- フィルタの三角は、カラム追加変換の横にくっつけて追加したカラムの値をつかったDataFrameの行の絞り込みを表現できることにしよう。
- フィルタの三角を2つ並べている例は、DataFrameの各行のルーティング（あるカラムの値が特定の条件に当てはまる場合はそちらのルートにその行を流して処理する）を表す。フローチャートのような判断の分岐と一見似ているが実際は全く違うので注意。注意というか、そのような分岐はこのレベルの図示に含めないのが記法をシンプルに保つ秘訣だと謎のうんちくを述べてみる。
- ルーティングが複数の道に分かれる場合、それが合流することもある。よって、合流のアイコンを定義。まあ、なくても良いのだけどPowerPointで描くなら合流用のオブジェクトを作らないと矢印がうまく繋がらないので仕方なし。
取引明細CSVの形式変換を行う、顧客ID単位に取引額合計を計算
これも、幹の部分はSQL1本で実現可能だろう。同じく例のための例だが、こちらも次のような図で表してみる。
- ドラム缶とは別に、ファイル用のアイコン（図中のCSVファイルを読み込む....のところなど）を設けた。これはこの例だとそこまで重要な感じがしないが、ストレージには順序があるものとそうでないものに分けられると考えており、前者はファイル、後者はRDB。シーケンシャルアクセスとランダムアクセスと似ているが、ここではどちらかと言えば出力仕様で区別が必要かなという話。例えばCSVファイルの場合は、1行目はヘッダー、2行目以降はデータ行、データ行は、◯◯IDでソートしなければならないというのがアイコン見ただけで示唆されるのがありがたいかなと思ったため。
- 同じDataFrameを複数のルートに流すという表記も必要なので、二重丸とした。前の図の例の「合流」と似ているので一重丸のアイコンでも良いかと思ったが、こちらは同じデータが複数にルーティングされ、あちらは複数のデータがUNIONされるので別のアイコンで記載。
- フィルタの三角をここでも2つ並べたが、こちらは前の図の例と違って、両方に流れる行がありうるという例。
- 結合は、ベン図風で外部結合と内部結合を明示的に表現。われながらなかなか良いアイディアのような気がする。実は、表形式のデータの結合にベン図を使うのは、自分の直感には合わない*1ので他の表記を模索していたが、結局これに落ち着いた。
*1:ベン図は、1つの表形式のデータがあって、カラムAの値がXのものかつカラムBの値がYのもののANDを表すような例がしっくりくるという感覚だが、テーブル結合の外部結合・内部結合を表すベン図風の表現は、結合後のいびつな形の表のうち片方の入力テーブルに結合キーのレコードが存在するもの...のようなよくよく考えると回りくどいものを表している。たまたまビジュアル的に片方を全部、両方の共通といった部分を絵的に表しているように見えるにすぎないのではというのが自分の感覚。みんなはどう感じているのだろうか。
