OLAP 再定義: 2026 年の分散
- 年前、OLAP といえば Vertica、Redshift、Snowflake といった中央集権型の大規模分散クラスタが代名詞だった。2026 年の風景は一変している。サーバーレス化した ClickHouse Cloud が秒単位のスケールを実現する一方、DuckDB が単一プロセスで数百 GB をさばき、ブラウザ内 WASM で動く DuckDB でフロントエンドから S3 の Parquet を直接クエリする構成が現実になった。
KGA が 2026 年 Q1 に受けた分析基盤相談 23 件のうち、従来型の「Snowflake／BigQuery に全てを集約する」構成を最初から採ったのは 9 件だった。残り 14 件は「中央の data warehouse（Snowflake または BigQuery）と、現場の軽量 OLAP（ClickHouse／DuckDB）を役割分担させる」ハイブリッド構成を選んだ。事実、用途を分けることで総コストが 30～50% 削減されるケースが多い。
ClickHouse Cloud の 2026 年ポジション
ClickHouse Cloud は 2024 年のサーバーレス対応、2025 年の SharedMergeTree（コンピュートとストレージの完全分離）、そして 2026 年の Query Condition Cache と Parallel Replica 自動化で、運用の楽さと性能の両立が最高水準に達した。KGA の広告配信顧客では、毎秒 200 万イベントの取り込みと秒応答のダッシュボードクエリを、従来比で 40% 低いコストで賄えている。
ClickHouse が圧倒的に強いのは次の特性がすべて揃うワークロードだ。
- 書き込みが append-only の時系列／イベントログ: 広告インプレッション、ゲームイベント、IoT テレメトリ、APM トレース、ウェブアナリティクス。
- 単一／少数テーブルへの集計クエリが主: GROUP BY、SUM、COUNT、PERCENTILE。
- 低レイテンシのインタラクティブダッシュボード: P95 500ms 以下の応答を求める用途。
- カーディナリティの高い次元での集計: user_id、session_id、trace_id 軸の分析。
逆に、複数テーブル join が多く、update／delete が頻発し、ad-hoc な discovery が中心のワークロードは Snowflake／BigQuery の方が素直。2026 年の ClickHouse は Parallel Hash Join、Grace Hash Join の成熟で join 耐性はかなり上がったが、10 テーブル以上の star schema では依然として他 MPP の方が安定する。
DuckDB 1.2 の衝撃
DuckDB は「in-process OLAP データベース」で、ライブラリとしてアプリケーションに組み込める。1.2 での進化は三点重要だ。
HTTP server モード: これまで library-only だった DuckDB が、HTTP サーバーとして起動できるようになった。Python／Go／TypeScript から HTTP 経由でクエリを投げ、結果を JSON／Arrow IPC で受け取る構成が安定した。軽量なデータ API の裏側として ClickHouse より構築が早い。
Iceberg／Delta の読み書き: 1.1 時点で Iceberg 読み取り、1.2 で Iceberg 書き込みが実装された。S3 上の Iceberg テーブルを DuckDB から直接読み書きでき、レイクハウスへの軽量アクセスが成立する。
WASM パフォーマンス: ブラウザ内で動く DuckDB-WASM が、SIMD 最適化と並列 Worker 対応で、デスクトップ版の 60～70% の性能を出せるようになった。Observable、Evidence.dev、Perspective などの BI ツールがこの上に構築されており、「フロントエンドだけで 100GB の Parquet を分析する」がブラウザで完結する。
KGA の自治体顧客では、オープンデータの可視化ダッシュボードを DuckDB-WASM で実装した。S3 にある公開 Parquet を直接ブラウザが読み、集計・可視化を全てクライアントサイドで処理する。サーバー側の計算リソースがゼロで、スケールコストも実質ゼロ。100 万ユーザーまで負荷試験をクリアした。
MotherDuck の商用定着
MotherDuck は DuckDB を土台にしたマネージドサービスで、2024 年のベータから 2025 年の GA を経て、2026 年には中小規模の分析ワークロードで Snowflake／BigQuery の現実的な代替として定着した。
最大の特徴は「ハイブリッド実行」。クエリの一部（ファイル読み出し、フィルタ）をクラウド側で、残りをローカル DuckDB 側で実行することで、データ転送を最小化しつつローカル計算資源を活用する。特に Python 開発者にとって、ノートブック内で `motherduck` アタッチすれば、大規模なクラウド側テーブルと手元の CSV／Parquet をシームレスに JOIN できる体験は他で得難い。
料金も魅力的で、10GB 以下のデータであれば無料枠で運用可能。100GB～1TB クラスの分析であれば Snowflake の 1/5 程度のコストで回せる。ただし 10TB 以上の規模や、同時並列ユーザー 50 を超えるダッシュボード用途では、MotherDuck より Snowflake／ClickHouse が素直。
Turso と LibSQL の独自路線
Turso は SQLite のフォーク LibSQL をベースにしたエッジ分散 SQL データベースで、厳密には OLAP ではなく OLTP 寄りだが、2026 年に導入された Analytics 拡張（AlloyDB Columnar のように行指向と列指向を併用する仕組み）で小～中規模分析にも対応した。
特徴的なのは、データベースを世界中のエッジに複製できるマルチテナント構成。Cloudflare Workers や Vercel Edge Functions から単一ミリ秒でクエリできるのが強み。IoT 機器メーカーや SaaS の dashboard 用途で、地理分散ユーザーへの応答性能が問題になるケースで刺さる。
OLAP 純粋用途としては DuckDB／ClickHouse に劣るが、「OLTP 兼軽量分析を単一 DB で済ませたい」「エッジ配備したい」ケースでは第一候補。
Tiered storage と hot/cold 設計
- 年の OLAP 運用で必須になったのが tiered storage（階層型ストレージ）だ。ClickHouse Cloud は SharedMergeTree で S3／GCS がプライマリストレージ、ローカル NVMe がキャッシュ層という構造を標準とする。Snowflake／BigQuery も似た構造だが、ClickHouse では cache policy を明示的にチューニングできるのが差。
KGA の広告顧客では「過去 30 日 = hot（NVMe キャッシュ常駐）、31～180 日 = warm（S3、オンデマンドで NVMe にロード）、181 日以降 = cold（S3 Glacier、クエリ時は Athena で直接）」という 3 層設計で、ストレージコストを 80% 削減した。クエリパフォーマンスは hot／warm は実質同等、cold のみ 10～20 倍遅いが、180 日以上前のデータをインタラクティブに触る要件は稀なので許容される。
日本語ワークロードの落とし穴
日本企業のデータ分析特有の課題を 5 つ挙げる。
1. タイムゾーン: JST（UTC+9）と UTC の混在で日付境界が一日ずれるバグは、2026 年でも頻発する。ClickHouse は `DateTime64` の `'Asia/Tokyo'` タイムゾーンパラメータで明示化し、BigQuery／Snowflake は UTC 保存 + 表示時変換を徹底する。DuckDB は `TIMESTAMPTZ` 型の導入で 1.2 から安定した。
2. マルチバイト文字と collation: 全角スペース、半角・全角英数、旧字体を含む顧客名／商品名の比較で、UTF-8 のバイト比較だけでは不十分。ClickHouse は ICU 拡張で、DuckDB は NFKC 正規化関数で対応する。集計キーに使う場合は事前に正規化パイプラインを組むのが鉄則。
3. 漢数字・和暦: 「令和六年三月」みたいな表現を扱う場面が官公庁案件で避けられない。SQL レベルで完結させず、取り込み時に ISO 8601 に正規化して保存するのが健全。
4. CP932／Shift_JIS の混入: レガシー基幹システムからの CSV エクスポートで依然として現れる。DuckDB の `read_csv` は 1.2 から encoding パラメータ対応が正式 GA。ClickHouse は `INPUT` 関数で変換する。
5. 半角カタカナ: 銀行系データでは今も存在し、NFKC で全角に変換すると「ｶ」「カ」が同値になるが、元データがキーとして半角を期待している場合にトラブルる。変換ルールは早期に固めてドキュメント化する。
2026 年の推奨アーキテクチャ
KGA が顧客に推奨する「現代的な分析データスタック」は次の分業だ。
- 中央 DWH（Snowflake / BigQuery / Databricks）: 全社横断分析、財務、経営指標。レイクハウス（Iceberg）書き込みで外部に開く。
- リアルタイム OLAP（ClickHouse Cloud）: 秒単位ダッシュボード、広告・ゲーム・IoT イベント、APM。
- ノートブック／局所分析（DuckDB + MotherDuck）: データサイエンティストの試行錯誤、中間データマートの生成。
- ブラウザ側可視化（DuckDB-WASM）: パブリックダッシュボード、社内 BI の軽量フロントエンド。
- エッジ OLTP+Analytics（Turso）: 地理分散 SaaS のテナント別 DB。
この 5 層を Semantic Layer（Cube.dev など）で統合し、LLM エージェントから自然言語で全てを引き出せる構成が、2026 年版「モダンデータスタック」の到達点である。単一ベンダーで完結させるのではなく、役割ごとに最適ツールを選び、メタデータとセマンティクスで接合する設計が、長期的には最もコスト効率と拡張性が高い。