BIMデータをETLしよう - OLAP向けにEAVで正規化して列指向に保存する理由

自己紹介などは次号に回して、本題から突っ込んでいきます。

前提理解

とりあえず用語の整理をしましょう。

• BIMデータ: 建築情報モデルのデータ。要素（壁・梁・設備など）の属性（寸法、材質、メーカー、コスト、工程、IFC属性など）が大量かつ不均一に含まれる。業界内に様々なソフトウェがありますが、今回の記事では基本的にAutdesk社のRevit中心のBIMの世界線を前提においてます。
• ETL: 抽出（Extract）・変換（Transform）・ロード（Load）。元データの源泉から必要なデータを取り出し、用途に適した形へ変換し、最終的に変換後のデータを格納先へ書き込む一連の過程。ざっくり言えば、データを集めて整え、活用できる形で蓄えるための工程。
• EAV型（Entity-Attribute-Value）: エンティティ（enitty）・属性名(attribute)・値(value)。エンティティの属性を列ではなく行（縦持ち）で表現するスキーマ。疎で可変な属性を扱いやすい一方、クエリが複雑化しやすく、整合性や型管理も難しいため、ユースケースを誤るとアンチパターンと見なされがち。
• OLAP: OLTPと異なり、主用途はデータ分析・解析によるデータ活用の支援。OLTPが短い書き込み中心の業務トランザクションを重視するのに対し、OLAPは大量なデータに対する広く深い集計・探索クエリを高速に処理するよう最適化されている。
• 列指向データ形式: 同じ列で行ごとに重複する値が多い場合に特に効果的な形式。Parquet に代表されるファイル形式があり、重複値を圧縮（例: 辞書・RLE・ビットパッキング）するため、重複が多いほどファイルサイズを小さくできる。

なぜBIMデータを外部出力(ETL)したいか

今回の記事の趣旨的に正確に言うと、なぜRevitみたいな専用BIMソフトからデータを出力したいかのモチベ。

• 俗に言うベンダーロックインみたいなのを避けてオープンBIMとして自由にデータを活用したい。
• 古いRevitモデルを開けようとなった時の時間がかかるアプデ作業を飛ばしてとりあえずサクッとモデルの中身を概要だけでも確認したい（開けてみてこれ違った...は何度も経験済み）。
• 外部の協力事務所から頂いた重たいモデルの中身の概要をサクッと掴んだり、業務に必要なデータや値だけをサクッととりたい。
• ↑と同じようなことを会社内部でもしたい。それぷらす他部署との連携やオペさんの進行状況掴むのに元モデルを編集することなく色々パラメータの値を取得できたりしたら良いなと。

なぜプラグインじゃAPSじゃダメなのか

正直な話、Revit内でプラグイン開発してもAPS(Autodesk Platform Service)でもほぼ同じできる事できます、自由以外は得られる。個人的には別に自由ってゆうより嫌だなと思うのが、基本的にAPI経由でデータ取得するの、アプリ内でも遅いなと感じる事多い等々かなと。そもそも開発者体験がそこまで良くないなと。そしてQA/QC用途とか別用途のためだけに新たに集計表とかモデルを編集して足すのはアンチパターンだなと思っているし。

APSは素晴らしいけども、前提として組織レベルできちんと整備されてないと厳しいなとゆう感じるサービスなのでとりあえずパス。そしていくら所属組織が整備してあっても、そんなの知らない〜とゆうお客さんが現れてお仕事しないといけない現実があるわけで。

そんなわけで、月並みな表現ながらデータ活用の為にRevitモデルのデータまるまる外部出力とゆうアイディアはロマンを抱いていました。

BIM Open Schema (BOS) の出現

buildingSMARTさんとかIFCのOpen BIMと名前が似ててややこしいのですが、無関係なプロジェクです。ベンダーにとらわれないBIMデータの活用をと長年考えられてたカナダ人のクリスさんのベンチャー企業Ara3dが開発してる新たなスキーマで、彼が開発しているAEC（建築・建設業界）向けのゲームエンジンの基盤のデータ形式として始められたプロジェクトです。詳しくはこちら。

こう新たな形式あるよとなると、もうIFCがあるじゃないかとか云々叩かれるのですが、個人的に面白いなと感じてるのが、計算処理効率重視でゼロベースから新たな建築・建設向けのデータモデリングの手法を模索してるところにあるなと。そして、プロ・ソフトウェアエンジニアの知見がまだまだ足りないと感じるこの業界で、そのような方が開発してるのも推す理由の一つかと。

なぜ効率が良いのか

いわゆる純EAVではなく、EAVの属性モデリングを下敷きにしつつ、データ指向（DoD）/ECSの観点で列指向的な物理設計と圧縮を施したスキーマです、利点として。

• データ型ごとにテーブルを分けているため、読み込み時の無駄が少なくメモリ局所性が高い。連結リスト辿るより連続領域の配列を辿る順走査する方が早いやってゆうやつです。

• 全ての値を保存してるのではなく、この値がいくつありますかとゆう表現で保存してるからファイルのサイズが小さくなる（RLE）。雑な例え：りんご三つの重さを表現するのに🍎三つ用意するのではなく、りんごがあってそれが三つありますとゆう表現をしてる＝つまり実質🍎の重量三分の一で表現できる。

このりんごみたいに、列毎に行を跨いで重複するデータって建築系のデータによくあるなって感じてたのでBOSの出現の初期（つい数ヶ月前ですが）に興奮だった理由の一つです。一応例を挙げるとすれば、柱の中心って大抵x・yで揃ってたりとか、長さとかもそうだよねと。連番は別としてもパラメータの値をいくつかの値から一つを選ぶことも結構多いし。

まあそしてだいぶ飛ばしてますが、そんなデータ形式を保存するのが最適なのが列指向データ形式（正しく↑の🍎の例のようにデータを保存してくれる）であるparquetとなるわけです。

そしてparquetとなると、我らが最強最速ローカルOLAPができるDuckDB様がつかえるじゃん！っとゆう結論になるのですが、長いので一回区切って次回の記事で解説します！