Dolt で Ubie のマスターデータを管理してみる

Ubie Discovery のデータエンジニアの @yubessy です。この記事は Ubie Engineers & Designers Advent Calendar 2022 - Adventar の19日目です。

今回は Ubie 社内でのマスターデータの管理に Dolt (DoltDB, DoltHub) を使ってみる話を書きます。なお、この記事の執筆時点ではまだ Dolt を実運用しているわけではなく、他の選択肢も含めて検討している段階です。

ユースケース

我々のチームでは、「ユビーAI問診」と「症状検索エンジン『ユビー』」の内部で使われている、病気や症状などの医学データを提供するシステムを開発しています。チームには複数名の医師とエンジニアが在籍しており、医学データの整備は医師が担当し、それを提供するシステムの開発はエンジニアが担当します。そして医学データの整備に使う管理画面の開発もまたエンジニアの仕事です。

医師による医学データの変更は、システムに反映される前にその内容を社内の別の医師がレビューすることになっています。これはシステムの出力の医学的な妥当性を担保する上で欠かせないプロセスです。医学データは Git でバージョン管理され、レビューは GitHub 上で行われます。Git/GitHub を使っているのは、データ変更を追跡・切り戻しできるようにするのと、データ変更の権限管理や承認プロセスを担保するためです。

GitHub はエンジニア向けのツールであるため、医師が使いこなすには相当な習熟が必要です。加えて、疾患と症状の関連付けなどのデータ構造は本来ツリーではなくテーブルであるため、 Git/GitHub で扱うにはそれなりの苦労が伴います。

Dolt に注目した理由

こうしたユースケースは、データマネジメント分野では「マスターデータ管理」 (Master Data Management, MDM) に含まれます。MDMではビジネスの根幹となるエンティティやドメイン知識を組織内のドメインエキスパートが管理することを想定します。最近はMDMにおいてデータのバージョン管理やレビューに使えるソフトウェア・サービスが増えています。

Dolt はそんなソフトウェア・サービスのひとつです。DoltDB は、リレーショナルモデルのデータとスキーマをバージョン管理して、 Git のように fork, clone, branch, merge, push, pull などの操作ができるようにしたDBMSです。DoltHub は DoltDB の Web インタフェースで、データやスキーマの変更を GitHub のような Pull Request フローで管理できます。

What Is Dolt? - Dolt

これらを使えば、「ドメインエキスパートである医師が、テーブルデータで表現される医学データを変更し、その内容を別の医師がレビューする」というプロセスを一元的に管理できるのではないか、と考えて社内で検証をしています。以下は検証内容の一部をまとめたものです。

現状のプロセス

まずは現状の医学データ管理のプロセスとその課題を整理します。次の図がプロセスの概要です。

プロセスの各ステップは次のような作業です。

1. リポジトリ管理されている医学データが管理画面のバックエンドのRDBに同期される
2. 医師が管理画面上で医学データの変更案を作成・編集する
3. 医師が管理画面上で変更案を保存すると、リポジトリに変更案のプルリクが作成される
4. 別の医師が GitHub 上で変更案のプルリクをレビュー・承認する
5. プルリクがマージされると、新しい医学データがシステムにデプロイされる

このプロセスに登場する管理画面のバックエンドのRDBは、少し複雑なスキーマになっています。例えば症状と疾患の対応付けを表現する disease_symptom という種類の医学データがあるとします。これに対してリポジトリから同期されたデータと医師が作成中の変更案のデータを両方とも保持するため、次のようなテーブルを容易しています。

changeset: 変更案

id	name
1	病気 1 の関連症状を編集
2	病気 2 の関連症状を削除

original_disease_symptom: リポジトリから同期されたデータ

disease_id	symptom_id
1	1
1	2
1	3
2	1
2	2

change_disease_symptom: 医師が作成中の変更案のデータ

changeset_id	disease_id	symptom_id	is_deletion
1	1	3	true
1	1	4	false
2	2	1	true
2	2	2	true

この設計の難点の一つは、医学データの種類ごとに original_xxx と change_xxx テーブルを用意する手間がかかることです。加えて、変更案をファイルに出力して GitHub のプルリクを自動生成する実装もそれなりのコード量があり、今後の保守が問題になりそうです。

Dolt を使ったプロセスのイメージ

上記の RDB/GitHub を DoltDB/DoltHub で置き換えるアイデアを次に図示します。

変更案 (changeset) の概念は Dolt のブランチによって代替されます。これによってDBスキーマは医学データをそのままモデリングするだけで済み、 original_xxx, change_xxx のようなテーブルを作る必要がなくなります。プルリクの作成も DoltHub にブランチを push して Web インタフェースから操作するだけで実現できます。

具体的なイメージを掴むため、 DoltHub のインタフェースを使って説明します。

まず symptom_disease(disease_id, symptom_id) というテーブルに (1, 1), (1, 2), (1, 3), (2, 1), (2, 2) というレコードがあるとします。

ここで新しいブランチを作成して checkout し、以下のSQLを発行してレコードを追加・削除しします。これが上記のステップ (2) で管理画面から行う操作に相当します。

DELETE FROM disease_symptom WHERE disease_id = 1 AND symptom_id = 3;
INSERT INTO disease_symptom(disease_id, symptom_id) VALUES (1, 4);

このブランチを DoltHub に push し、 main ブランチにマージするプルリクを作成します。これが上記のステップ (3) に相当します。

プルリク画面ではレコードの diff を見ながらレビューができます。これが上記のステップ (4) に相当します。

プルリクがマージされると main ブランチが更新され、テーブルの状態が変化していることが確認できます。

実運用に向けた課題

このように Dolt を使うと医学データの管理プロセスをシンプルにできそうです。実際に簡単な Web アプリを作ってみたところ、概ね思い描いた設計通りのものが実現できました。ただ、実運用に向けてはいくつか考慮しなければならないことがあります。

ひとつは SQLAlchemy のようなセッション管理・ORMライブラリを介する際に工夫が必要なことです。DoltDB ではブランチを SQL の database/table の構文を拡張して扱います。例えば ブランチの切り替えは USE mydb/feature-branch;, 別のブランチのデータの参照は SELECT * from mydatabase/feature-branch.accounts; のようになります。一般的なライブラリはクエリ発行先の database/table を動的に切り替えることを想定していないので、自分たちでその機構を実装する必要があります。 database per tenant 型の multitenancy の考え方を応用すればできそうですが、単なる社内管理画面の実装としては少し複雑なものになります。

また DoltHub はデータのバージョン管理のための Web インタフェースを提供するだけで、DBサーバとして直接 Web アプリから接続する使い方はサポートされていません。このため DoltDB サーバのホスティングは基本的に自前で行う必要があります。 Hosted DoltDB というサービスもありますが、2022/12現在は DoltHub の private database を直接デプロイできず、まだ発展途上のようです。

おわりに

今回の検証によって、 Dolt が提供する機能は我々のマスターデータ管理プロセスと相性が良いことがわかりました。あとは実運用観点での懸念事項が解決すれば有力な選択肢になると考えています。

今後もこのような、ドメインやプロダクトと密接に関わるデータマネジメントについて、定期的に発信していきたいと思います。