この記事はNovasell Advent Calendar 2025の17日目の記事です。
自己紹介
はじめまして。福與 岬(ふくよ みさき)と申します。ノバセルにてフルスタックエンジニア(業務委託)として勤務しています。
今の業務内容は主に広告データ集計のモデル設計と開発、またテストの記述をしています。
このエントリの概要
いろんなものを見て作ってきたフルスタックエンジニアとして、多様な視点から「データ集計関連技術」を見てみよう！という試みです。
ので、普段はデータ集計してないよ！ゲーム作ってるよ！画像加工してるよ！AI設計してるよ！みたいな人にも楽しく読めるように頑張って書いてみました。
その分野が専門分野の人には少し物足りない例えや不正確な記述になっている箇所もあるかと存じます。その際はどうぞ寛大な心で「案外いろんな技術って似てるんだな」と思ってくださいませ。
また、アドベントカレンダーということで普段データエンジニアをしていない人たちへの贈り物となればと考え、それぞれの項タイトルに「〜〜の人へ」と付しました。
用語解説
まずそもそもここで出てくるデータエンジニアリングの用語や技術スタックなどについて簡単に解説します。例えられても例えが通じないと困っちゃいますからね。
一用語一行で記載します。シンプルに。
- Snowflake
- サービス名。大量のデータを高速に集計するための大規模データベース。集計はSQLで実行する。
- dbt
- SQLラッパー言語 / フレームワーク。SnowflakeのSQL言語をラップし記述しやすくして、テストをYAML / CSVなどで記載できるようにする。
- dbt モデル
- dbtでいうところの「ひとつのSQLファイル」を指す。このSQLを順次実行・結果読み込みしそれを元に読み込みすることで実際のデータ集計が動く。
- dbt マクロ
- dbtの中で埋め込み記法を用いることで、SQLトランスパイル時にマクロを展開して分岐したり同様のロジックをまとめるなどの処理ができる。埋め込み記法にはJinja記法を用いる。
dbtってUnity HLSLだよね: ゲームエンジニアの人へ
私の職業エンジニアとしてのキャリアはUnityでのゲーム開発からはじまりました。
Unityを含め、現代のGPUを用いたレンダリングのためにはシェーダが必要です。
そして、Unity上でシェーダを記述するためのHLSLという言語があります。HLSL自体は元々DirectX向けですが、Unityは他のレンダリング環境へも自動的に変換してくれます。
これ、dbtに似てるんです。ノバセルでは基本的にSnowflakeをターゲット環境としてdbt SQLを変換しますが、dbtはAWS RedshiftやPostgresなどにも対応します。
もちろんターゲット環境によっては動かないものもありますが、それはHLSLがターゲットレンダリング環境をOpenGL ESにしたときなども同じですね。
用語解説
- Unity
- ゲームエンジン。スマホゲームやWindows, mac, 最近ではSwitchなどのゲーム開発にも使われている。あなたの遊んでいるスマホゲーもこれで作られてたりするかもしれない。
- ゲームエンジン
- 現代のゲームは綺麗なグラフィックのために超絶技巧が要求されるが、そのうち「だいたいのゲームを作る上でこの機能は必要だよね」という共通の機能や仕組みを提供してくれるもの。
- GPU
- PCやスマホの画面に3D / 2Dのグラフィックを出力するときに効率的に処理することを主な目的として作られた専用のハードウェア。
- レンダリング
- (主にGPUを用いて)グラフィックを画面に出力するために計算すること。
- シェーダ
- レンダリングをどのようにするか・色をどのように表現するかなどを決定する指定を行うプログラム。
- HLSL
- シェーダのプログラムのために用いる言語で、さまざまな環境で概ね同じ記述で実行ができる
- OpenGL ES
- GPUに指示を与えるための共通の仕組みを提供するOpenGLという規格の派生版。スマートフォンやWebブラウザなどの実行速度が限られた環境でも使えるが、その分機能が限定的になっている。
dbtのモデル, マクロってPhotoshopだよね: グラフィックデザイナの人へ
小さな規模での業務にも携わることがあり「もしデザイナーがそこにいなければあなたがデザイナーだ」みたいなことも結構ありました。
そのためPhotoshopファイルを受け取って簡単な編集や色調整などはできるようになりました。
というわけで、Photoshopはかなりdbtです。逆にdbtはかなりPhotoshopだと思います。
Photoshop含め様々な画像編集ソフトは複数枚のレイヤーを上から下に複数枚合成して目的の画を作ることが多いです。
これはdbtのモデルを前方から後方につなげて最終的な結果を得ることと近い構造だと言えると思います。
また、場合によっては目的の画のパターンを出すためにレイヤーの合成パターンを変えたりします。
モデル中で必要なデータだけをフィルタしたり切り出したりして後続のモデルに渡す処理に似ていますね。
また、Photoshopにはレイヤーエフェクトという機能がありますが、これはかなりdbtのマクロです。
レイヤーエフェクトはレイヤーに導入することでレイヤーに対して見た目を大きく変えるような効果をかけることができ、またこのエフェクトに向けてパラメータを付与することができます。
dbtのマクロも同様に、モデル内に導入することで指定のパラメータで複雑な変換、たとえば文字列の複雑な変換や、その変換をどうするかをパラメータで設定することができます。
用語解説
- レイヤー
- Photoshop含め多くの画素処理ソフトウェアでは1枚の画像を作るために複数枚の画像を1枚ずつ合成していく、この1枚ずつの画像のことをレイヤーと呼ぶ
- レイヤーの合成パターン
- 前のレイヤーを後ろのレイヤーに合成するとき、どのように合成するか？の定義で、色が明るいほうを用いる、色を加算して重ねる、などがある
- レイヤーエフェクトという機能
- 例としては「画像の色のピクセルを濃く / 淡くする」「色を反転する」などがある
SQLのディメンジョンでのジョインって行列の掛け算・深層学習の層結合だよね: 数学が好き・AIのコードを書いたことがある人へ
弊社では大規模な広告配信データの集計を行っています。
特に広告・マーケ分野ではデータの粒度情報が1つの行に対して複数存在し、それらをjoinで別のデータと結合しようとすると5個10個とあるカラムの数と情報を合わせる工夫が必要です。
さて、大学時代の線形代数の講義、あるいは数学Cでの行列の授業をみなさんは覚えていますでしょうか？
覚えてない人やそもそもそんなのやったことないよ、という人に簡単に説明すると、行列の掛け算は、掛け合わせる前後の列・行の個数を合わせる必要があります。
3行5列 x 5行4列 = 3行4列 というような形ですね。
簡単に説明すると、こんな感じです。
引用元: 行列のかけ算のやり方まとめ。例題から分かる行列の積の考え方｜アタリマエ！
この「列と行を合わせる」というのは、かなりSQLのjoinっぽいと思いました。
データの結合でも、足らない情報やカラムを埋め合わせてディメンジョンを合わせることがあるように、行列でも足らない行・列を埋め合わせるような事前計算をしたりします。
これにミスがあると計算結果はまるで違うものになるし、データの量も大幅に増えたり逆に減ったりします。
また、深層学習の各層間でもそれぞれのTensorの次元数を合わせるような処理が必要になったりしますが、これも類似した概念ですね。
終わりに
私もこれまでの開発経験としてゴリゴリのデータモデル設計や集計を行っていたわけではありませんでした。
それでも今までの経験と直面した課題の類似点を見つけ、最近は少しずつこなれたデータ集計・分析モデルのコードを書けるようになってきました。
もちろん、一つの興味ある技術について深めていくのも楽しいことです。個人的なことでいえば画像処理については興味があり、かなり深い画像処理の実装まで学んだことがあります。
そしてそうやって深めていくとき、思いがけず全く関係ないと思っていた他の技術・概念がメタファーとして頭に浮かんできたらもっと楽しく学べるし実装できると考えます。
このアドベントカレンダーを読んで、年末年始などに「普段と違うことやってみようかな」と思い新たな技術に触れてみる一歩になれれば幸いです。
