機械学習

機械学習のデータレイヤー

「機械学習の実務家の時間の 80% はデータクレンジングに費やされている」という話を耳にしたことがあるかもしれません。 この言説が事実かどうかはさておき、機械学習の問題において、最初から最後までその中心にあるのがデータであることは変わりません。 RAG パイプラインの構築、ファインチューニング、自前モデルの学習、モデル性能の評価など、いずれのケースでも各問題の根底にあるのはデータです。

データの管理は難しくなりがちであり、その副産物として、機械学習におけるデータ関連の特定の一部分を解決することで生産性を高めようとするツールが乱立してきました。 多くの場合、これは汎用的なソリューションの周りに抽象化レイヤーを設け、その上に一見すると特定のサブプロブレムに適用しやすくするための、明確な設計思想を持ったインターフェースを提供する、という形を取ります。 その結果として、特定のタスクに対する使いやすさと単純さを優先する代わりに、汎用ソリューションが本来持つ柔軟性が犠牲になります。

このアプローチにはいくつかの欠点があります。 汎用的なソリューションとそれを支えるアプリケーションコードの組み合わせに対して、用途特化型のツール・プロダクト・サービスが次々と連なる構成は、必要以上のアーキテクチャの複雑さやデータコストを招くリスクがあります。 気づかないうちに、単一のステップにしか使っていないツールやサービスが際限なく増えている、という状況に陥りがちです。

これらのリスクには、代表的に 2 つの側面があります。

1. 学習・保守・乗り換えコスト

機械学習アーキテクチャは、さまざまなツールやコンポーネントであふれかえり、学習や運用が難しく分断された環境となることがあります。 その結果、障害ポイントが増え、コストもじわじわと増大します。

2. データの重複と転送コスト

機械学習パイプラインの中で、複数の個別かつ重なり合うデータシステムを利用すると、システム間でデータをやり取りするための、不要かつ高コストになりがちなオーバーヘッドが発生する可能性があります。

このトレードオフをよく示す例がベクターデータベースです。 ベクターデータベースは、ベクトルを保存し検索するという、きわめて特化した機械学習タスク向けに設計されています。 一部のアーキテクチャではそれが最適な選択となり得る一方で、別のアーキテクチャにおいては、ベクターデータベースはテックスタックに不要な新要素を追加するだけかもしれません。 新たに統合し、運用し、データを送受信しなければならないシステムが 1 つ増えることになるからです。 多くの最新の汎用データベースは、標準機能（あるいはプラグイン経由）としてベクターをサポートしており、より幅広くクロスカッティングな機能を備えています。 言い換えれば、そのようなアーキテクチャでは、ベクター処理専用の新しいデータベースを導入する必要がそもそもない場合もあります。 重要なのは、（組み込みの埋め込みモデルなどの）ベクター特化の利便機能がミッションクリティカルであり、そのコストを正当化できるかどうかです。

データ探索

機械学習の問題設定、目標、成功基準を定義した後の、一般的な最初のステップは、モデルの学習と評価に使用する関連データを探索することです。

このステップでは、データの特性、分布、関係性を理解するために分析を行います。 この評価と理解のプロセスは反復的なものであり、多くの場合、データセットに対して一連のアドホッククエリを実行することになります。このとき、クエリの応答性は（コスト効率や精度といった他の要因と並んで）極めて重要です。 企業が機械学習のために活用すべく蓄積するデータ量が増えるにつれ、「手元のデータを調べる」という問題自体がより難しくなっていきます。

これは、従来型のデータシステムでは、分析や評価用のクエリがスケールした際に、退屈なほど、あるいは実用に耐えないほど遅くなりがちだからです。 大手ベンダーの中には、クエリ時間を短縮するために大幅なコスト増を強いるところもあり、クエリごと課金やスキャンしたバイト数に応じた課金によって、アドホックな評価を事実上抑制しています。 こうした制約に対する妥協策として、エンジニアがデータのサブセットをローカルマシンにダウンロードして処理することもあります。

一方、ClickHouse はリアルタイムデータウェアハウスであり、分析計算において業界最先端のクエリ速度をユーザーにもたらします。 さらに、ClickHouse は最初から高いパフォーマンスを発揮し、重要なクエリ高速化機能を高額な料金プランの背後に隠すことはありません。 ClickHouse はオブジェクトストレージやデータレイク上のデータに対して直接クエリを実行でき、Iceberg、Delta Lake、Hudi などの一般的なフォーマットをサポートします。 これはつまり、データがどこに存在していても、ClickHouse を機械学習ワークロードのための統一的なアクセスおよび計算レイヤーとして利用できるということです。

ClickHouse には、ペタバイト規模のデータに対してスケールする豊富な事前構築済みの統計・集約関数が用意されており、複雑な計算を実行するシンプルな SQL を容易に記述・保守できます。 また、最も細かい精度のデータ型やコーデックをサポートしているため、データの粒度を落とすことを心配する必要はありません。

データ探索

機械学習の問題設定、目標、成功基準を定義した後の、一般的な最初のステップは、モデルの学習と評価に使用する関連データを探索することです。

このステップでは、データの特性、分布、関係性を理解するために分析を行います。 この評価と理解のプロセスは反復的なものであり、多くの場合、データセットに対して一連のアドホッククエリを実行することになります。このとき、クエリの応答性は（コスト効率や精度といった他の要因と並んで）極めて重要です。 企業が機械学習のために活用すべく蓄積するデータ量が増えるにつれ、「手元のデータを調べる」という問題自体がより難しくなっていきます。

これは、従来型のデータシステムでは、分析や評価用のクエリがスケールした際に、退屈なほど、あるいは実用に耐えないほど遅くなりがちだからです。 大手ベンダーの中には、クエリ時間を短縮するために大幅なコスト増を強いるところもあり、クエリごと課金やスキャンしたバイト数に応じた課金によって、アドホックな評価を事実上抑制しています。 こうした制約に対する妥協策として、エンジニアがデータのサブセットをローカルマシンにダウンロードして処理することもあります。

一方、ClickHouse はリアルタイムデータウェアハウスであり、分析計算において業界最先端のクエリ速度をユーザーにもたらします。 さらに、ClickHouse は最初から高いパフォーマンスを発揮し、重要なクエリ高速化機能を高額な料金プランの背後に隠すことはありません。 ClickHouse はオブジェクトストレージやデータレイク上のデータに対して直接クエリを実行でき、Iceberg、Delta Lake、Hudi などの一般的なフォーマットをサポートします。 これはつまり、データがどこに存在していても、ClickHouse を機械学習ワークロードのための統一的なアクセスおよび計算レイヤーとして利用できるということです。

ClickHouse には、ペタバイト規模のデータに対してスケールする豊富な事前構築済みの統計・集約関数が用意されており、複雑な計算を実行するシンプルな SQL を容易に記述・保守できます。 また、最も細かい精度のデータ型やコーデックをサポートしているため、データの粒度を落とすことを心配する必要はありません。

データの変換は、SQL クエリを用いて ClickHouse 内で直接行うことも、挿入前に行うこともできますが、ClickHouse は chDB を介して Python などのプログラミング環境から利用することもできます。 これにより、組み込みの ClickHouse を Python モジュールとして公開し、ノートブック内で大規模なデータフレームを変換・操作するために利用できます。 そのため、データエンジニアはクライアント側で変換処理を実行し、その結果を集中管理された ClickHouse インスタンス上の特徴量テーブルとして永続化するといったことが可能になります。

データ準備と特徴量抽出

次にデータを準備します。クレンジングと変換を行い、モデルの学習と評価に使用される特徴量を抽出します。 このコンポーネントは、特徴量生成パイプラインや特徴量抽出パイプラインと呼ばれることもあり、新しいツールが導入されがちな機械学習データレイヤーの一部です。 Neptune や Hopsworks といった MLOps ベンダーは、このようなパイプラインをオーケストレーションするために使用される多様なデータ変換プロダクト群の例を提供しています。 しかし、これらは操作対象のデータベースとは別個のツールであるため脆くなりやすく、手動で修復する必要がある障害を引き起こすことがあります。

対照的に、データ変換は マテリアライズドビュー を利用することで ClickHouse 内で直接容易に実現できます。 これらは新しいデータが ClickHouse のソーステーブルに挿入されたタイミングで自動的にトリガーされ、到着したデータの抽出・変換・加工を簡単に行うために使用されます。これにより、自分で専用パイプラインを構築・監視する必要がなくなります。 これらの変換に、メモリに収まりきらない完全なデータセットに対する集約処理が必要な場合でも、ClickHouse を活用すれば、ローカルマシン上のデータフレームで動作するようにこのステップを無理に適合させる必要はありません。 ローカルで評価した方が便利なデータセットについては、ClickHouse local や chDB を利用することで、Pandas のような標準的な Python データライブラリと組み合わせて ClickHouse を活用できます。

学習と評価

この時点で、特徴量は学習・検証・テスト用のセットに分割されています。 これらのデータセットにはバージョン管理が施され、それぞれの段階で利用されます。

このパイプラインフェーズでは、機械学習データレイヤーにさらにもう 1 つの専用ツール、すなわち特徴量ストアを導入することが一般的です。 特徴量ストアは、モデルの学習・推論・評価用のデータ管理に特化した利便機能を提供する、データベースの上に構築された抽象化レイヤーであることが一般的です。 こうした利便機能の例としては、バージョニング、アクセス管理、特徴量の定義を SQL 文へ自動変換する機能などが挙げられます。

特徴量ストアにおいて、ClickHouse は次のような役割を果たすことができます。

データソース - ClickHouse は Iceberg や Delta Lake などのデータレイク形式を含む 70 以上のファイル形式でデータをクエリしたり取り込んだりできるため、データを長期保管・クエリするストアとして理想的です。 オブジェクトストレージを利用してストレージとコンピュートを分離することで、ClickHouse Cloud ではデータを無期限に保持できるうえ、コスト最小化のためにコンピュートをスケールダウンしたり完全にアイドル状態にしたりできます。 カラム指向ストレージとディスク上でのデータの並び順に加え、柔軟なコーデックにより圧縮率を最大化し、必要なストレージ容量を最小限に抑えます。 ユーザーは ClickHouse をデータレイクと容易に統合でき、オブジェクトストレージ上のデータに対してインプレースでクエリを実行する組み込み関数も利用できます。

変換エンジン - SQL はデータ変換を宣言するための自然な手段を提供します。 これに ClickHouse の分析関数や統計関数が組み合わさることで、変換処理は簡潔かつ最適化されたものになります。 ClickHouse をデータストアとして利用している場合の ClickHouse テーブルへの適用はもちろん、テーブル関数を使用すれば、Parquet などの形式でディスク上やオブジェクトストレージ上に保存されたデータ、さらには Postgres や MySQL といった他のデータストアに保存されたデータに対しても SQL クエリを記述できます。 完全並列のクエリ実行エンジンとカラム指向ストレージ形式の組み合わせにより、ClickHouse は PB 級のデータに対する集約処理を数秒で実行できます。インメモリのデータフレーム上での変換とは異なり、ユーザーはメモリの制約に縛られません。 さらに、マテリアライズドビューを利用することで、データを挿入するタイミングで変換を行い、クエリ時ではなくデータロード時に計算負荷を移すことができます。 これらのビューは、データ分析や要約に最適な同様の分析関数や統計関数の幅広いセットを活用できます。 既存の ClickHouse の分析関数では不十分な場合やカスタムライブラリを統合する必要がある場合、ユーザーはユーザー定義関数 (UDF) も利用できます。

オフライン特徴量ストア

オフライン特徴量ストアは、モデル学習に利用されます。 これは一般的に、特徴量自体が（前述のセクションで説明したような）バッチ処理型のデータ変換パイプラインによって生成され、これらの特徴量の提供レイテンシに厳しい要件がないことを意味します。

複数のソースからデータを読み取り、SQL クエリで変換を適用できるため、これらのクエリ結果は INSERT INTO SELECT ステートメントを用いて ClickHouse に永続化することもできます。 変換はしばしばエンティティ ID ごとにグループ化され、結果として複数のカラムを返しますが、ClickHouse のスキーマ推論機能は、これらの結果から必要な型を自動的に検出し、それらを保存するための適切なテーブルスキーマを生成できます。 乱数生成や統計的サンプリングのための関数により、モデル学習パイプラインへの入力として、データを 1 秒あたり数百万行というスケールで効率的に繰り返し処理できます。

多くの場合、特徴量は、特定の時点におけるエンティティと特徴量の値を示すタイムスタンプ付きのテーブルとして表現されます。 前述のとおり、学習パイプラインでは、特定の時点および特定のグループにおける特徴量の状態が必要になることがよくあります。ClickHouse のスパースインデックスは、ポイントインタイムクエリおよび特徴量選択フィルタを満たすために、データを高速にフィルタリングできます。Spark、Redshift、BigQuery などの他のテクノロジーが、特定時点での特徴量の状態を特定するために低速なステートフルなウィンドウ処理に依存しているのに対し、ClickHouse は ASOF (as-of-this-time) LEFT JOIN クエリと argMax 関数をサポートしています。 構文を簡素化することに加え、このアプローチはソートおよびマージアルゴリズムの利用によって、大規模なデータセット上でも非常に高いパフォーマンスを発揮します。 これにより、特徴量グループを迅速に構築でき、学習前のデータ準備時間を短縮できます。

オンライン特徴量ストア

オンライン特徴量ストアは、推論に使用される特徴量の最新バージョンを格納し、それらをリアルタイムに適用するために使用されます。 これは、これらの特徴量がリアルタイム機械学習サービスの一部として使用されるため、極めて低いレイテンシで計算される必要があることを意味します。

リアルタイム分析データベースとして、ClickHouse は低レイテンシで高い同時実行性を持つクエリワークロードに対応できます。 これは通常、データを非正規化しておく必要がありますが、学習時および推論時の両方で使用される特徴量グループの保存方法と整合しています。 重要な点として、ClickHouse はログ構造マージツリーのおかげで、高い書き込みワークロードを受けながらも、このクエリ性能を維持できます。 これらの特性は、特徴量を最新の状態に保つためにオンラインストアに求められる要件です。 特徴量はすでにオフラインストア内に存在するため、既存の機能、例えば remoteSecure などを用いて、同一の ClickHouse クラスター内、または別インスタンス内の新しいテーブルへ容易にマテリアライズできます。 Kafka との連携も、厳密な 1 回限りの処理を保証する Kafka Connect の提供や、ClickHouse Cloud における ClickPipes を通じて、ストリーミングソースからのストリーミングデータの取り込みを簡潔かつ信頼性の高いものにします。

多くのモダンなシステムでは、オフラインストアとオンラインストアの両方が必要であり、ここでは 2 つの専用の特徴量ストアが必要だと結論づけたくなるかもしれません。 しかしこれは、両方のストアを同期状態に保つという追加の複雑さをもたらし、当然ながら両者間でデータをレプリケーションするコストも含まれます。

ClickHouse のようなリアルタイムデータウェアハウスは、オフラインおよびオンライン両方の特徴量管理を支える単一のシステムになり得ます。 ClickHouse はストリーミングデータと履歴データを効率的に処理し、リアルタイム推論およびオフライン学習のために特徴量を提供する際に求められる、事実上無制限のスケール、性能、および同時実行性を備えています。

この段階で特徴量ストア製品を利用するか、あるいはリアルタイムデータウェアハウスを直接活用するかのトレードオフを検討する際には、バージョニングといった利便性の高い機能が、テーブルやスキーマ設計といった古典的なデータベースのパラダイムを通じて実現できる点を強調する価値があります。 また、特徴量定義を SQL ステートメントに変換するといった機能は、意見の強い抽象レイヤー内に存在するよりも、アプリケーションやビジネスロジックの一部として提供される方が、より高い柔軟性をもたらす場合があります。

推論

モデル推論とは、学習済みモデルを実行して出力を得るプロセスです。 推論がデータベース操作、たとえば新しいレコードの挿入やレコードのクエリによってトリガーされる場合、推論ステップは専用ジョブやアプリケーションコードによって管理される可能性があります。

一方で、データレイヤー自体で管理することもできます。ClickHouse の User Defined Functions (UDFs) は、挿入時またはクエリ時に ClickHouse から直接モデルを呼び出す機能をユーザーに提供します。 これにより、入力データをモデルに渡し、その出力を受け取り、取り込まれたデータとともに自動的に結果を保存することができます。これらはすべて、別のプロセスやジョブを起動することなく実行できます。 また、このステップを管理するためのインターフェースを単一の SQL に統一できる利点もあります。

Vector store

ベクターストアは、ベクトルの保存と取得に最適化された特定の種類のデータベースであり、通常はテキストや画像などのデータ片の埋め込みを格納し、それらの内在的な意味を数値的に表現します。 ベクトルは、現在の生成 AI の波の中核的な存在であり、数え切れないほど多くのアプリケーションで利用されています。

ベクターデータベースにおける主要な操作は「類似性検索」であり、これは数学的な指標に基づいて、互いに「最も近い」ベクトルを見つけることです。 ベクターデータベースが人気となっているのは、この処理 ― ベクトル同士の比較 ― を可能な限り高速に行うために設計された特定の手法を用いているためです。 これらの手法は一般に、入力ベクトルを保存されているすべてのベクトルと比較するのではなく、ベクトル比較を近似的に行うことを意味します。

この新しいクラスのツールに関する問題は、ClickHouse を含む多くの汎用データベースが、標準でベクトルをサポートしているうえに、その近似手法の実装もあらかじめ組み込んでいることです。 とりわけ ClickHouse は、高性能な大規模分析のために設計されており、近似ではないベクトル比較を非常に効率的に実行できます。 これはつまり、速度を犠牲にすることなく、近似に頼らずに正確な結果を得られることを意味します。

Observability

機械学習アプリケーションが本番稼働すると、モデルの挙動、パフォーマンス、改善の余地がある領域についての貴重なインサイトを提供するログやトレースデータなど、さまざまなデータを生成します。

SQL ベースのオブザーバビリティは ClickHouse にとってもう 1 つの重要なユースケースであり、ClickHouse は代替ソリューションと比較して 10～100 倍のコスト効率があることが確認されています。 実際、多くのオブザーバビリティ製品そのものが、内部的には ClickHouse 上に構築されています。 最高水準のインジェスト速度と圧縮率により、ClickHouse はあらゆるスケールで機械学習のオブザーバビリティを支えるコスト効率と驚異的なスピードを提供します。