ケイパビリティ
取り込み、モデリング、品質、ガバナンスを一つのシステムとして設計します。ダッシュボード上の数値も、モデルが検索したパッセージも、その出所までたどれるようにするためです。
データエンジニアリングは、データを生成するシステムから、それを利用する人やソフトウェアへとデータを運び、その過程で正確さを保つ仕事です。取り込み、保存、変換、モデリング、品質管理、ガバナンス、提供までを対象とします。成果物はパイプラインではありません。意味、鮮度、所有者が明確になっているデータセット群です。
この領域が重要なのは、下流のあらゆる利用が上流の欠陥を引き継ぐためです。重複したイベントは売上を水増しし、名前の変わったカラムはモデルの特徴量を壊し、古いドキュメントは検索システムにもっともらしい誤答を出させます。こうした障害はたいてい表面化しにくいため、この領域ではテスト、コントラクト、リネージがスループットと同じだけの重みを持ちます。
Staroneは、課題の規模に見合ったデータプラットフォームを構築します。立ち上げ期のプロダクトにはPostgreSQLのリードレプリカとdbtが適切な答えになり得ますし、多数のソースと利用者を抱える組織にはストリーミング取り込みを備えたレイクハウスが適しています。鮮度、データ量、コストの前提を最初に明示し、それに合わせて設計します。
エンジニアリング領域
データの到着方法は三つあります。スケジュールされたバッチ抽出、データベースログからの変更データキャプチャ（CDC）、イベントストリームです。どれだけの鮮度が必要か、ソースシステムがどの程度の負荷に耐えられるかに応じて、ソースごとに選択します。CDCはプライマリにクエリを発行せずにニアリアルタイムのレプリケーションを実現しますが、パイプラインがソースのスキーマに依存するようになります。
ウェアハウスは、SQL分析向けの構造化データを保存し、性能の管理はサービス側に任せられます。レイクハウスは、オブジェクトストレージ上のオープンテーブルフォーマットでデータを保持するため、複数のエンジンから読み取ることができ、非構造化データをテーブルと並べて置けます。ワークロードの構成、オープン性、そして運用するチームの対応能力をもとに選択します。
モデリングは、生のレコードを、事業部門が合意したエンティティと指標に変えます。分析にはディメンショナルモデルを用い、変換はバージョン管理されたSQLで保持し、各指標を一度だけ定義します。二つのダッシュボードで同じ指標が食い違うことがないようにするためです。
データコントラクトは、スキーマ、意味、鮮度について、生産者と利用者の間で交わされ、自動的に検証される合意です。テストはパイプラインの内部で実行され、不正なデータを事後に報告するのではなく、公開される前に止めます。
オーケストレーションは依存関係に基づいて処理をスケジュールし、再実行を安全にします。ガバナンスは、データセットの所有者、読み取りを許可される対象、各カラムの由来を記録します。カラムレベルのリネージは、インシデント対応者が知るべき二つのことに答えます。何が障害の原因か、そして下流の何に影響するかです。
データは、ダッシュボード、業務システム、モデルに提供されます。機械学習では、特徴量パイプラインが学習時とオンライン推論時で同じ値を算出しなければなりません。LLMシステムでは、埋め込みパイプラインがドキュメントを解析、チャンク化、埋め込みし、ソースの変更や権限にインデックスを追従させます。
ストリーミングは要望されることが多い一方で、実際に必要となる場面はそれより少ないものです。見極めの基準は、データが1時間前のものではなく1分前のものであることで、どの意思決定が変わるかです。不正検知のスコアリング、在庫、運用上のアラートには秒単位の鮮度が必要です。財務報告やほとんどのプロダクト分析には必要ありません。
ストリーミングは構築にも運用にもコストがかかります。状態を管理し、遅延したイベントや順序の乱れたイベントをウォーターマークで処理し、各境界での配信保証を理解し、バックフィルを別途設計しなければなりません。バッチのほうがテストも再実行も簡単です。よくある中間的な方法は、CDCやマイクロバッチで増分モデルに取り込むことで、運用負荷を大きく抑えながら数分単位の鮮度が得られます。
両方が必要な場合でも、同じロジックのために二つのコードベースを保守することは避けます。一つの方法は、ストリームを信頼できる唯一の情報源として扱い、そこからバッチビューを導出することです。もう一つは、同じ変換を両方のモードで実行できるエンジンを使うことです。
アーキテクチャ
取り込みと保存
ソース
データベース、SaaS、イベント、ファイル
取り込み
バッチ、CDC、ストリーミング
生データストレージ
不変のランディングゾーン
レイクハウス
オープンテーブル形式またはウェアハウス
カタログ
スキーマ、リネージ、オーナーシップ
変換と提供
変換
バージョン管理しテストしたSQLモデル
品質チェック
鮮度、件数、スキーマのテスト
BIへの提供
ダッシュボードと統制された指標
APIでの提供
アプリケーション向けデータプロダクト
MLと埋め込み
特徴量とベクトルインデックス
ガバナンス
アクセスポリシー、マスキング、監査
データインシデントの多くは、ソースシステムでのもっともな変更から始まります。カラム名の変更、enumへの値の追加、タイムスタンプのUTCへの切り替えなどです。アプリケーションチームのテストは通り、被害は数日後にレポートやモデルで表面化します。コントラクトは、その障害を、修正コストの低い生産者側のCIへと移します。
実用的なコントラクトは、スキーマ、NULL許容、キーの一意性、許容値、鮮度、所有者を定めます。強制するのは二つの時点です。生産者がスキーマを変更するときと、データが到着するときです。失敗したバッチは隔離し、直近の正常なバージョンを公開したままにします。古くても正しいデータのほうが、新しくても誤ったデータより害が小さいことが多いためです。
検索品質の上限は、取り込みの品質で決まります。ドキュメントには、構造を保つ解析、意味を尊重したチャンク化、絞り込みのためのメタデータ、そしてすべてのチャンクに付与されたソースシステムの権限が必要です。ドキュメントが編集または削除されたら、インデックスもそれに追従しなければなりません。さもなければ、モデルはすでに存在しない内容を引用することになります。
埋め込みパイプラインにもバージョン管理が必要です。埋め込みモデルを変更するとコーパス全体の再埋め込みが必要になるため、パイプラインは、古いインデックスの隣に新しいインデックスを構築し、アトミックに切り替えられるようにしておくべきです。予測モデルでは、ポイントインタイムで正しい特徴量により、予測時点では得られなかったはずの情報で学習してしまうことを防ぎます。これは、テストでは良好なのに実運用では性能が出ないモデルのよくある原因です。
エンジニアリングの進め方
データの利用者から出発し、ソースへとさかのぼって設計します。
データに依存する意思決定、レポート、特徴量、モデルを洗い出し、それぞれが必要とする鮮度と正確さを整理します。
各ソースのデータ量、変更頻度、スキーマの安定性、データ品質を調べ、ソースシステムが受け入れられる負荷について合意します。
エンティティ、キー、指標定義、オーナーシップを定め、リスクの最も高いインターフェースからコントラクトを作成します。
変換はバージョン管理下に置いてCIでテストし、ロードを冪等にし、すべての環境をコードから再構築できるようにします。
リネージ、鮮度とコストの監視、アクセスポリシー、カタログを、プラットフォームの利用者が増えた後ではなく、増える前に整備します。
クエリコスト、遅いモデル、使われていないデータセットを定期的に見直し、読まれなくなったものは廃止します。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
アクセスは、テーブル、カラム、行の各レベルでロールと属性に基づいて付与し、PIIは分類したうえで既定でマスキングします。データは転送中も保存時も暗号化し、サービスの認証情報は有効期間を短くして単一のパイプラインにスコープを限定します。
ストレージとコンピュートを分離し、それぞれが独立してスケールできるようにします。テーブルは実際のクエリパターンに基づいてパーティショニングおよびクラスタリングし、変換は増分で行い、ストリーミングのコンシューマーはパーティション単位でスケールします。
各データセットに鮮度、件数、品質のチェックを設け、アラートを受け取る所有者を定めます。リネージが障害の下流への影響を示し、クエリコストはチームとワークロードに配賦します。
パイプライン、スキーマ、インフラストラクチャはバージョン管理下に置き、代表的なデータに対するテストを備えたCIを通じてデプロイします。スキーマ変更は後方互換とするか二段階で移行し、バックフィルは正式な運用作業として扱います。
ソースはCDC、API、ファイル、イベントを通じて接続し、利用者はSQL、セマンティックレイヤー、データAPI、リバースETL、特徴量ストアや埋め込みストアを通じて接続します。各境界のコントラクトにより、生産者と利用者はそれぞれ独立してデプロイできます。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
ダッシュボードが表示するのは、パイプラインが生成したものです。レポートごとに定義が異なる、数値が後から変わる、ある数字の出所を誰も説明できない、といった状況であれば、問題はダッシュボードより上流にあり、モデリング、テスト、リネージによって解決します。
ストリーミングによる秒単位から、バッチによる日次までです。鮮度の高いデータほど構築と運用のコストがかかるため、支える意思決定に応じてデータセットごとに鮮度を設定します。
はい、そうすべきです。特徴量パイプラインと埋め込みパイプラインは、分析用データと同じ取り込み、品質チェック、アクセスポリシー、リネージを再利用します。これにより、ガバナンスの及ばない組織データの複製がもう一つ生まれることを避けられます。
ワークロードごとにコストを可視化し、増分で処理し、実際に実行されるクエリに合わせてテーブルをパーティショニングし、保持期間の階層を設定し、誰も読んでいないデータセットとジョブを削除します。
