プロセスマイニングを小さく始めるためのデータ前処理
・データ分析の必要性に気づいたが、まだ予算はない
・CDPやDWHは社内に導入しているが、自由にいじることはできない
という状況から「データ分析を社内に広めるために、まずは小さく事例を作る」ことを目的にした構成を考えてみます。
■前処理に必要なポイント
分析の分野は以前にまとめたプロセスマイニングを想定しています。プロセスマイニングツールの前提は、イベントログが作成されていることでした。またトライ&エラーな分析の中で、必要なレコードや項目は変化していきます。
●実施する必要があること
・各種システムからデータを収集する
・イベントログを作成する（= 前処理）
レイアウトをイベントログに揃える
分析に不要なデータを除外する
担当者を名寄せする
アクティビティを名寄せする
タイムスタンプのフォーマットを揃える
など
・イベントログをプロセスマイニングツールにアップロード
・ボトルネックを分析し対策を練る
早く前処理を済ませて、プロセスを分析し、改善の仮説を検証することが必要です。所属する部署内に対象を絞り、小さく素早くプロセス改善の効果を得て、社内に広めていくアプローチです。
そこで今回の前処理のしくみに求められるのは下記のポイントです。
・イベントログを得るまでの早さ
・無料で始められる
・分析が終わったら作り捨てできる
・うまく分析が回るまでは試した履歴を残すことができる
●前処理
前処理は、後続のデータ分析の品質を大きく左右します。数多くの記事や書籍で「データ分析業務の8割を占める」「必要不可欠な工程」と説明されています。前処理には学問として体系だった知識が存在しないので、現場の絶え間ない工夫によって生まれてきたものが多いです。
データエンジニアとデータアナリストの間で、誰が実施するのかグレーな作業でしたが、この役割にデータアーキテクトやデータ整備人と名前がついてきました。
●前処理の最前線に触れられるコミュニティ
・データ分析とインテリジェンス
・Data Pipeline Casual Talk
●ELTアプローチ
求められるポイントを下記のようにと捉えると、OSSのETLツールが近いカテゴリになります。
・イベントログを得るまでの早さ
→ コーディング量の少なさ → GUI
・無料で始められる
→ OSS or 無料枠
・分析が終わったら作り捨てできる
→ docker or インストール不要
・うまく分析が回るまでは試した履歴を残すことができる
→ 設定をファイルで管理 & VCS
Talend Open Studioが有名ですが、GUIとコネクタは充実していますが、OSS版ではファイル管理ができない制約があります。digdag × embulk で組み立てるアプローチもありますが、コーディングが必要なので今回の目的には少しマッチしません。
そもそもETLの、fromのスキーマを洗い出し、toのスキーマを設計、変換方法を定義・実装、一気にデータをロードするというアプローチは、これからデータ分析を始める、toのスキーマが曖昧な状況では、手戻りが大きく、時間がかかってしまいます。
分析に必要なスキーマを探索していくので、アジリティの高さが必要になります。この状況では、スキーマを意識せず、抽出したデータをそのまま読み込み、データを加工し利用できるようにするELTアプローチがマッチしそうです。
・ETLアプローチ
1. すべてのスキーマを集める
2. スキーマを分析する
3. 何を使用しないかを決める
4. スーパースキーマを作成する
5. ETLジョブをプログラミングしてデータを読み込む
6. 変更があった場合、このプロセスを再度実行する
・ELTアプローチ
1. データをそのまま読み込み
スキーマを意識せずに読み込み
検索可能にする
2. データをハーモナイズする
元データのスキーマを維持しつつ
複数スキーマ間で項目を揃える
3. データをエンリッチする
元データのスキーマを維持しつつ
必要な項目を追加
4. さらにデータを読み込む
ELTアプローチを提唱しているMarkLogicが無償で利用できるので、これを利用した構成を考えます。
■MarkLogic DataHub Platform
MarkLogicデータハブプラットフォームは、全ての多構造化データをまとめ、トランザクションと分析の両方の目的でキュレーションできる統合データプラットフォームです。データハブは、任意のソースからそのままデータを読み込み、すぐにクエリを実行できるようにインデックス付けして、検索、ハーモナイズ、マスタリング、エンリッチメントのプロセスを通してキュレーションします。
説明は捉えにくいですが、動画はイメージが湧きやすいです。
●MarkLogic DataHub Platformの構成
・MarkLogic DataHub Platform
・MarkLogic
NoSQLデータベース
・MarkLogic DataHub
PlatformのUI部分
OSS公開
●MarkLogic DataHub
MarkLogic DataHub PlatformのUIに相当するwebappです。Apache Lisence 2.0 で公開されています。
・GitHub
・ドキュメント
https://docs.marklogic.com/datahub/5.0-jp/
●MarkLogic
ドキュメント型データベースにグラフ型、RDBの機能を追加した、マルチモデルデータベースです。開発者向けにdocker imageが提供されています。
・製品紹介ページ
・DockerHub
■アーキテクチャ
分析対象のプロセスで利用しているシステム群から、加工せずにデータを抽出します。DataHubの機能でMarkLogicに抽出ファイルをそのまま読み込みます。対象システムから直接MarkLogicに読み込むツールも提供されています。
DataHubの画面から前処理を定義、実行します。機能が不足している場合はCustomスクリプトも定義できます。
MarkLogic内で作成したイベントログはそのまま利用できますが、プロセスマイニングツールに合わせて、CSVファイルにexportします。exportにはDataHubの機能が利用できます。
・MarkLogic DataHub Platformの構築方法
・前処理の流れ
・前処理設定のファイル管理
を紹介していきます。
●公式チュートリアル
公式チュートリアルに従って、前処理の流れを紹介します。詳細な手順はこちらを参照してください。
■環境構築
●MarkLogic
DockerHubでライセンスに同意
Docker Desktopのメモリ設定
後続のDataHubでの初期構築でメモリを使うようで、2GBの割り当てで動かした時は、MarkLogicからのレスポンスがタイムアウトしてしまいました。4GB程度は割り当てが必要なようです。
docker run
ユーザー / パスワードは admin / admin を指定していますが、任意の値で大丈夫です。後ほどDataHubからの接続でも利用します。volumeを指定していないのでコンテナ停止時にデータは破棄されます。
docker run -d -it \
-p 8000:8000 -p 8001:8001 -p 8002:8002 \
-p 8010:8010 -p 8011:8011 -p 8013:8013 \
-e MARKLOGIC_INIT=true \
-e MARKLOGIC_ADMIN_USERNAME=admin \
-e MARKLOGIC_ADMIN_PASSWORD=admin \
store/marklogicdb/marklogic-server:10.0-3-dev-centos●MarkLogic DataHub
warファイルをダウンロード
GitHubのreleaseからwarファイルをダウンロードできます。今回は5.2.1を利用しました。
warファイルを実行
実行したディレクトリに、設定内容がファイル出力されます。管理しやすいディレクトリで実行してください。
java -jar ./marklogic-datahub-5.2.1.war初期化
http://localhost:8080 からウィザードに従って初期化します。
■前処理の流れ
●抽出
想定データを手動で作成しています。2つのシステムから抽出した想定の顧客リストです。実際に分析する場合は、分析対象システムのcliやembulkなどのツールを利用して抽出した、無加工のデータファイルです。
●ファイル読み込み
抽出データごとのFlowを定義して、Ingestion機能でMarkLogicに読み込みます。読み込んだデータは画面から確認できます。MarkLogic付随のQuery Consoleで登録データを全文検索できるので、詳細にスキーマを把握していなくても必要なデータを見つけることができます。
・Flow
※https://www.youtube.com/watch?v=yNYe5kaGEew から引用
・Step / Ingestion
・Query Console
●エンティティの定義
利用時に必要なレイアウトのエンティティを定義します。後で変更できるので、この時点でレイアウトを確定させる必要はありません。分析に必要なレイアウトが見えてきたらブラッシュアップできます。
・Entity
●マッピング
読み込んだレイアウトから定義したエンティティに項目間でマッピングします。一般的な加工用の関数は用意されていますが、独自の処理を実行する場合はスクリプトを追加できます。
・Step / Mapping
●マスタリング
2つのデータを定義したルールでマッチングし、マッチ具合に応じて、マージしたデータの出力を切り替えることができます。一般的な名寄せ処理に必要な機能が実装されています。
・Step / Mastering / Matching
・Step / Mastering / Merging
●CSVファイル出力 ※チュートリアル外
DataHubの機能で、MarkLogic内のCollectionを指定してjson lines形式のexportができます。export結果からエンティティを取り出し、CSV形式に変換します。実際に分析する場合は、イベントログのエンティティをCSVファイルに出力し、プロセスマイニングツールにアップロードします。
# export
./gradlew mlExportToFile \
-PexportPath=/tmp/export.jsonl \
-PwhereCollections=sm-Customer-mastered
# jsonl -> csv
cat /tmp/export.jsonl | # jsonlの各行から
jq -c '.envelope.instance.Customer' | # Entityを取り出し
jq --slurp | # json arrayに変換
json2csv > /tmp/export.csv # csv変換
cat /tmp/export.csv・json2csv
■設定のファイル管理
●ディレクトリ構成
warファイルを実行したディレクトリ配下に、設定ファイルが出力されます。初期構築後のディレクトリ構成はこのような内容です。
datahub
├── build
│ ├── com.marklogic.ml-app-deployer
│ └── ml-javaclient-util
├── entities
├── flows
├── gradle
│ └── wrapper
├── mappings
├── src
│ └── main
│ ├── entity-config
│ ├── hub-internal-config
│ │ ├── database-fields
│ │ ├── databases
│ │ ├── security
│ │ │ ├── amps
│ │ │ ├── privileges
│ │ │ ├── roles
│ │ │ └── users
│ │ ├── servers
│ │ └── triggers
│ ├── ml-config
│ │ ├── database-fields
│ │ ├── databases
│ │ │ └── data-hub-staging-SCHEMAS
│ │ │ └── schemas
│ │ ├── security
│ │ │ ├── privileges
│ │ │ ├── roles
│ │ │ └── users
│ │ └── servers
│ ├── ml-modules
│ │ └── root
│ │ └── custom-modules
│ │ ├── custom
│ │ ├── ingestion
│ │ ├── mapping
│ │ ├── mapping-functions
│ │ ├── mastering
│ │ ├── matching
│ │ └── merging
│ └── ml-schemas
└── step-definitions
●git管理のサンプル
チュートリアル実施後はこのようなファイルの更新があります。git管理しておけばノウハウを他の分析に流用できます。
■まとめ
探索するアプローチには高いアジリティが必要
分析には正解がないので、常により良いものを探索するアプローチになります。探索には何度もやり直しが必要なので、先に理想的な設計を固める進め方では時間がかかります。アジリティを高めるために、決定を遅らせる方法を選んでいく必要があります。
目的に合わせて手段を選ぶ
今回の目的は、組織にデータ分析を広めていくために、小さく早く成果を出すことでした。そのために、できるだけ小さく早く分析を始める手段を考えました。分析範囲や分野、関わる人、環境などの状況によって目的は変化します。
分析の範囲が広がればワークフローやリランの考慮が必要になります。digdagやairflowで構築している事例をよく伺います。
組織で継続的にビッグデータを分析・活用していく場合は
・必要なコネクターが揃った製品を購入して初期開発コストを抑える
・性能、価格面で圧倒的なBigQueryを中心にデータ分析基盤を構築する
のどちらかが効率的なアプローチになりそうです。
今回の構成でのノウハウが溜まっていったなら、MarkLogic DataHub Platformをスケールする方がスムーズな状況もあるかと思います。状況に合わせて目的を捉え直し、手段を選ぶ流れが作れたらすてきですね。
いつも応援していただいている皆さん支えられています。