トップ > データ基盤 > データカタログの本格導入に向けたdbt-osmosisへの貢献について紹介します

データカタログの本格導入に向けたdbt-osmosisへの貢献について紹介します

データ基盤

Analytics Engineerの吉田(id:syou6162)です。BigQueryを中心に10X社内のデータ管理の仕事をしています。

最近、データカタログの本格導入の準備を進めていて、それに向けた補助ツールとしてdbt-osmosisもゴリゴリと使い倒すようになってきました。その中で「10Xでの運用を考えるとこういうケースで困るし、前職までの経験を踏まえると解決できると他社でも役に立ちそう」「この挙動は普通にバグっぽいな...」というものがあったので、立て続けにPull Requestを送りました。ありがたいことに全部マージしてもらえましたが、せっかくなのでデータカタログの導入に向けてdbt-osmosisを採用した背景やどういったPull Requestを送ったか紹介します。

データカタログ導入の必要性

つい先日もStailerが新規導入されたプレスリリースが出ました。「Stailerを導入していただいたらそれで終わり」ということは当然なく、導入後は

  • 初回購入者の獲得 (First Order UU)
  • 店舗 / エリア / アクセスの開設 (Accessibility)
  • キャパシティの最大化 (Capacity)
  • 品揃え / 価格の最適化 (Selection)

など様々な観点でデータを見ながら改善を進めていく必要があります。分析の対象も多様ですし、短期や中長期でも分析が必要なため、10XではアナリストだけでなくBizDevやPdMがSQLを書くことも多いです。アナリストであれば分析したいテーブルに不明点があっても元のSQLを読み解いて意味を理解することができますが、他職種の人にそれを求めるのは困難です。また、そもそもBigQuery内にテーブル / カラムが多数あるため、自分の分析に必要なテーブル / カラムがどれかを探すのが難しいというData Discoveryの観点で課題を感じている人が多い、ということも社内のアンケートで明らかになりました。

そこで、テーブルやカラムのdescriptionを充実させ、他職種の人でも自分が必要なデータを探したり、データの意味や定義をさっと分かるようにしてデータ分析を自走してもらえるように、データカタログの導入を進めています。導入にはDataplexを予定しており、検討した際の項目については以下のエントリを参照してください。

メタデータをいかに効率よく入力するか: dbt-osmosisの導入

データカタログを機能させるためには前提条件があり「(テーブルや)カラムのdescriptionがいかに充実しているか」が鍵となります。これが不足していると、検索にそもそも引っかからないですし、きちんとメンテナンスされていなければ古い定義のまま分析してしまい、誤った意思決定に繋がってしまうこともありえます。

「カラムのdescriptionが充実しているのがいかに大事か」は分析に関わる人であれば痛いほど理解できるかと思いますが、これをカバレッジ高く継続的に人手でメンテナンスし続けるのは非常に大変です。

10Xではdbtを導入していますが、dbtはエコシステムが非常に充実しており「最小限のカラムのdescriptionを埋めれば、それを参照しているカラムのdescriptionも自動的に埋めてくれる」dbt-osmosisという便利なOSSが存在します。

dbt-osmosis導入以前は体感だと1割もカラムのdescriptionが入力されておらず、データカタログが機能する状況ではありませんでした。しかし、導入後は10X社内でよく使われるデータセット内において、5割から8割程度のカラムのdescriptionが入力されている状況*1に改善され、自動で行なえるため運用コストもグンと抑えられます。dbt-osmosisの詳細については以下のエントリを参照してください。

dbt-osmosisの導入に伴ない、最小限のカラムのdescriptionを埋める箇所に関しては以下の方針で取り組みました。

  • 伝播元になるデータレイク側のカラムのdescriptionの入力
    • アプリケーションのコードを参照しながら、分析に頻出するテーブルのカラムについては気合いで埋める
    • より継続的なメンテナンスをしやすくするため、開発チームとデータコントラクトなどの枠組みでデータの仕様について握っていくことを今後進めていければと思っています
  • データマートに登場する独自のmetricsなどのカラムのdescriptionの入力
    • 伝播する必要のないデータマートだけで使うaggregateされた指標などを想定
    • データマートを作成することが多いAnalytics Engineerやアナリストで入力
    • なぜ入力する必要があるか、入力することでどういったメリットがあるかについて説明会を開催しました
    • メンテナンスが難しいSQLと向き合う機会が多かったり、データマートについて質問を受けるメンバーが多かったことから、入力のモチベーション部分についても納得感を持ってもらいやすい状況でした

取り込まれた修正

このように非常に便利なdbt-osmosisですが、10Xのdbtプロジェクトに導入する際に課題となった点がいくつかありました。修正自体は大したものではないですが、運用面ではクリティカルなものもあったため、これらを解決するために私が送ったPull Requestについて紹介します。

CamelCaseからsnake_caseにrenameした際にも伝播できるようにする

「データソースの都合で取り込まれたデータレイクのカラムがCamelCaseになっているが、データウェアハウスやデータマートの構築はsnake_caseで命名規則を統一している」というケースは多いと思います。dbt-osmosisはこれまでは依存関係にあるモデル内のカラムで完全一致*2した場合のみ、カラムのdescriptionに伝播していました。つまり、CamelCaseからsnake_caseへの変換が入ると、それ以降のレイヤーへのカラムのdescriptionが伝播できるカバレッジが途端に下がってしまう、という問題がありました。カラムのdescriptionはなるべくデータレイクに付与するのがメタデータ管理の基本と思ってこれまで生きているので、こういったケースでもカラムのdescriptionを伝播できるように修正しました。

ネストしたフィールドがある際に、ルートレベルのカラムの情報が欠損してしまう問題を修正

これはバグの修正ですね。dbtはBigQueryのstructやrecordのような構造があってもカラムのdescriptionを記述できますし、dbt-osmosisもそれらの構造を考慮した上でカラムのdescriptionを伝播してくれます。しかし、この伝播をする際にルートレベルのカラムの情報が吹き飛んでしまうというバグがあり、自分の事例でもせっかく付与したカラムのdescriptionがそれなりに存在したため、修正しました。

カラムのdescriptionがどこから伝播されたものか分かる情報を埋め込む

dbtはrefを使ってモデルを小さく構成した上でそれらに対してテストを書くことができますし、多段のレイヤリングになったとしてもデータリネージをきちんと管理できることが強みの一つです。しかし、そうした構成の中でdbt-osmosisを運用していると

  • このカラムのdescription、ちょっと意味が分かりにくいから修正したい
  • データレイク側で調べてみたけど、どうもこのdescriptionはデータレイクで付与されて伝播されたわけではなさそうだ
    • 中間レイヤーのどこかで付与されて伝播されてきたらしい
  • うーん、どこが大本か、データリネージとgit grepを駆使しながら探すかぁ...
    • 自分がやるなら「手間だな...」くらいで済むけど、アナリストなど他職種の人がやるのはハードルがぐっと上がってしまう...

ということで困ることが出てきました。「このカラムのdescriptionはどこから伝播されたか」という情報は実はログに出力されており、この情報をモデルのymlファイル内に埋め込むことで伝播元がどこかをさっと分かるようにするオプションを追加しました。

このオプションを使うと、meta.osmosis_progenitorに伝播元のモデルが記載されるため、どこを修正すればいいか分かりやすくなりました。

version: 2
models:
  - name: mart_order
    columns:
      - name: my_description
        description: "This is description"
        meta:
          osmosis_progenitor: source.my_project.my_dataset.order

こういったメタ的な情報を保存しておくのにmetaは便利なので、必要があれば要所要所で使っていきたいですね。

tagsやmetaの伝播をスキップするオプションを追加

dbt-osmosisはカラムのdescriptionだけでなく、実はカラムに付与されているtagsやmetaの情報もディフォルトで伝播します。これは便利なのですが、先ほどのmeta.osmosis_progenitorや自社独自の運用用のmetaのフィールドが存在する場合、無闇に伝播されると困ります。不要な場合はこれらの伝播をスキップできるオプションを追加しました。

まとめ

このエントリでは

  • パートナー数の拡大やグロースフェイズの最適化において、BizDevやPdMでも自走して分析できる環境が必要になっている
  • 自走できるようにデータカタログの導入を検討しているが、descriptionの入力のカバレッジの低さが課題
  • descriptionの入力をある程度自動で行なえるdbt-osmosisを導入したが、課題があったためPull Requestを送ってそれらを改善

について紹介しました。同じような課題は他社でもあると思いますし、そういった課題に対してdbt-osmosisを通じて多少は貢献できたかなと思います。

こういったメタデータ管理やデータカタログ、データ基盤の運用や改善に興味がある方はぜひお話しましょう。

*1:INFORMATION_SCHEMA.COLUMN_FIELD_PATHSビューを用いて集計しました

*2:正確に言うと、case-insensitiveでも一致するようになっており、これはSnowflakeで役に立つようです