ELT
読み: イーエルティー
ELTとは先に格納し後で変換
ELTはシステムからデータをExtract抽出しデータウェアハウスやデータレイクに直接Load格納したのち強力な計算能力を用いて分析用にTransform変換するデータ処理アプローチ。
かんたんに言うと
釣った魚を船上で捌かず、とりあえず巨大な冷凍庫に放り込んでから、陸の巨大工場で一気に加工するようなものである。
まずロードし後から変換するELTのデータ処理アプローチ
データウェアハウスやデータレイクに生のデータをそのまま突っ込む。それがELTの基本思想である。
Extract抽出、Load格納、Transform変換。この順番がすべてを決定づける。
かつてはデータを変換してから格納していた。
なぜ今は違うのか。
ストレージが安くなったからである。
AI分析基盤を構築する際、事前にどんなデータが必要になるか完璧に予測できる人間はいない。だからこそ、まずはすべてのデータをロードしておく。後から必要な形に変換すればいいという割り切りが、このアプローチの根底にある。
データ抽出から変換までの具体的な処理プロセス
従来のETLは、変換処理を行うサーバーのスペックが常にだった。
ELTは違う。クラウドコンピューティングのスケーラビリティを暴力的に使い倒す。
とりあえず生データを全部ロードし、変換は後回しにする。
このアプローチは本当に正しいのか。
現場のエンジニアとしては判断が分かれる。
計算資源が無限にあると錯覚しがちだが、クラウドの裏側には物理的なサーバーが存在する。無駄なデータをロードし続けることで、ネットワーク帯域を圧迫し、結果的にシステム全体のパフォーマンスを落とすケースを私は何度も見てきた。
物流ネットワークにおける活用事例と代表的なツール
物流の現場を想像してほしい。
トラックのGPSデータ、倉庫の温度センサー、配送伝票。これらをFivetranで吸い上げ、Google BigQueryやSnowflake、Amazon Redshiftに流し込む。
そしてdbtを使って、AIが需要予測しやすい形に変換する。
ツールは揃っている。
だが、使いこなせるかは別問題である。
特に物流データは欠損や異常値が多い。dbtで鮮やかに変換できるのは、元のデータがある程度まともな場合だけである。ゴミデータをいくらクラウドに集めても、出てくるのはゴミでしかない。
クラウド環境で発揮される強みと運用上の注意点
非構造化データをそのまま保持できるのは強い。
後から新しい切り口で分析したくなったとき、生データが残っていればどうにでもなる。
ただ、コスト最適化の罠がある。
クエリを叩くたびに課金されるBigQueryで、無邪気に全件スキャンを繰り返すデータサイエンティスト。月末の請求書を見て青ざめるのは経理である。
コンプライアンスの観点でも、個人情報がマスキングされずに生データとして残るリスクは悩ましい。
生データを保持するメリットと、それを管理するコスト。どちらを取るか。
自社のAI導入プロジェクトに最適なデータ基盤の選び方
機械学習の精度を上げるには大量のデータが要る。
リアルタイム処理が絶対条件なら、ELTのバッチ処理的な動きは要件に合わないかもしれない。
データガバナンスをどう担保するか。
生データが散乱するデータスワンプを作ってしまえば、誰も手を出せなくなる。
結局のところ、自社のデータエンジニアのスキルセットと、クラウドの課金体系を天秤にかけて決めるしかない。
流行りのアーキテクチャだからといって飛びつけば、維持費だけで予算が吹き飛ぶ。自社のデータ量と運用体制に本当に見合っているのか、泥臭く計算し直す時間が必要である。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。