Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs
49.6kGet Started

SQL ServerからClickHouseへデータをストリーミングして高速分析を実現する: ステップバイステップガイド

View as MarkdownEdit this pageReport an issueSet up docs MCP

この記事では、SQL ServerからClickHouseへデータをストリーミングする方法を紹介するチュートリアルを、わかりやすく解説します。ClickHouseは、社内向けまたは顧客向けのダッシュボード用に超高速な分析を行いたい場合に最適です。ここでは、両方のデータベースのセットアップ、接続方法、そして最後にStreamkapを使ってデータをストリーミングする方法を、順を追って説明します。日々の業務処理はSQL Serverで行いながら、分析にはClickHouseの速度と高度な機能を活用したいなら、この記事はまさにぴったりです。

なぜ SQL Server から ClickHouse にデータをストリーミングするのか？

ここまでたどり着いたということは、おそらくこんな課題を感じているはずです。SQL Server はトランザクション処理には非常に堅牢ですが、高負荷なリアルタイム分析クエリを実行するようには設計されていません。

そこで ClickHouse の出番です。ClickHouse は分析向けに設計されており、非常に大規模なデータセットでも超高速で集計やレポート作成を行えます。つまり、トランザクションデータを ClickHouse に取り込むストリーミング CDC (変更データキャプチャ) パイプラインを構成すれば、きわめて高速なレポートを実行できます。これは、運用チームやプロダクトチーム、顧客向けダッシュボードに最適です。

代表的なユースケース:

  • 本番アプリに負荷をかけない社内レポート
  • 高速で、常に最新の状態を保つ必要がある顧客向けダッシュボード
  • 分析のためにユーザーアクティビティログを常に最新に保つようなイベントストリーミング

始める前に必要なもの

詳細に入る前に、次のものを準備しておいてください。

前提条件

接続情報

以下を確認してください。

  • SQL Server のサーバーアドレス、ポート、ユーザー名、パスワード。Streamkap が SQL Server データベースにアクセスするための専用のユーザーとロールを作成することを推奨します。設定については、こちらのドキュメントをご覧ください。
  • ClickHouse server のアドレス、ポート、ユーザー名、パスワード。ClickHouse の IP Access List では、どのサービスが ClickHouse データベースに接続できるかを制御します。こちらの手順に従ってください。
  • ストリーミングしたいテーブル。まずは 1 つから始めてください

Streamkap で SQL Server のソースを作成する

それでは始めましょう。

まずはソース接続を設定します。これにより、Streamkap はどこから変更を取得すればよいかを把握できます。

手順は次のとおりです。

  1. Streamkap を開き、SOURCES セクションに移動します。
  2. 新しいソースを作成します。
  • 識別しやすい名前を付けます (例: sqlserver-demo-source) 。
  1. SQL Server の接続情報を入力します。
  • ホスト (例: your-db-instance.rds.amazonaws.com)
  • ポート (SQL Server のデフォルトは 3306)
  • ユーザー名とパスワード
  • データベース名

バックグラウンドで行われること

この設定を行うと、Streamkap は SQL Server に接続してテーブルを検出します。このデモでは、events や transactions のように、すでにデータがストリーミングされているテーブルを選びます。

StreamkapでClickHouseの宛先を追加する

それでは、このデータをすべて送信する宛先を設定しましょう。

ソース側と同様に、ClickHouse の接続情報を使って宛先を作成します。

手順:

  1. Streamkap の destinations セクションに移動します。
  2. 新しい宛先を追加し、宛先タイプとして ClickHouse を選択します。
  3. ClickHouse の情報を入力します:
  • ホスト
  • ポート (デフォルトは 9000)
  • ユーザー名とパスワード
  • データベース名

スクリーンショット例: Streamkap ダッシュボードで新しい ClickHouse 宛先を追加する画面。

Upsert モード: これは何ですか?

これは重要なステップです。ここでは ClickHouse の「upsert」モードを使用します。これは内部的に ClickHouse の ReplacingMergeTree engine を利用するものです。これにより、受信レコードを効率よくマージし、ClickHouse でいう「パーツマージ」によって、取り込み後の更新にも対応できます。

  • これにより、SQL Server 側で変更があった場合でも、宛先テーブルが重複データで埋まるのを防げます。

スキーマ進化への対応

ClickHouse と SQL Server では、カラムが完全には一致しないことがあります。特に、アプリが本番稼働中で、開発者がその場でカラムを追加していくような場合はなおさらです。

  • 朗報です。Streamkap は基本的なスキーマ進化に対応しています。つまり、SQL Server で新しいカラムを追加すると、ClickHouse 側にもそのカラムが反映されます。

宛先設定で「schema evolution」を選択するだけです。必要に応じて、あとからいつでも調整できます。

Streamkapでパイプラインを設定する

ソースと宛先の設定が完了したら、いよいよ楽しい部分、データをストリーミングする段階です。

パイプラインの設定

  1. Streamkap の Pipelines タブに移動します。

  2. 新しいパイプラインを作成します。

  3. SQL Server のソース (sqlserver-demo-source) を選択します。

  4. ClickHouse の宛先 (clickhouse-tutorial-destination) を選択します。

  5. ストリーミングしたいテーブルを選択します。ここでは events とします。

  6. CDC (変更データキャプチャ) 用に設定します。

  • 今回は新しいデータをストリーミングします (最初はバックフィルを省略し、CDC イベントに集中するとよいでしょう) 。

パイプライン設定のスクリーンショット。ソース、宛先、テーブルを選択している画面です。

バックフィルは必要ですか？

「古いデータもバックフィルしたほうがよいのだろうか？」と思うかもしれません。

多くの分析用途では、まずはこれ以降の変更をストリーミングするだけで十分ですが、必要になれば後から古いデータを読み込むこともできます。

明確な必要がない限り、ひとまず「バックフィルしない」を選んでください。

データストリームを確認する

これでパイプラインの設定が完了し、稼働を開始しました。

動作は次のとおりです。

  • SQL Server のsource tableに新しいデータが入ると、Streamkap パイプラインがその変更をキャプチャして ClickHouse に送信します。
  • ClickHouse は、ReplacingMergeTree とパーツマージによってこれらの行を取り込み、更新をマージします。
  • スキーマも自動で追随します。SQL Server でカラムを追加すると、ClickHouse にも反映されます。

ClickHouse と SQL Server の行数がリアルタイムで増えていく様子を、ライブダッシュボードやログで確認できます。

SQL Server にデータが入るのに合わせて、ClickHouse の行数が増えていくのをそのまま確認できます。

-- Example: Checking rows in ClickHouse 
SELECT COUNT(*) FROM analytics.events; |

高負荷時には多少の遅延が発生する場合がありますが、ほとんどのユースケースではほぼリアルタイムでストリーミングされます。

内部では何が起きているのか: Streamkap は実際に何をしているのか？

その仕組みを少し見てみましょう。

  • Streamkap は SQL Server のバイナリログ (レプリケーションにも使われるログ) を監視します。
  • テーブルで行が挿入、更新、または削除されると、Streamkap はそのイベントを即座に検知します。
  • そのイベントを ClickHouse が理解できる形式に変換して送り込み、分析 DB に変更を即時反映します。

これは単なる ETL ではなく、リアルタイムでストリーミングされる本格的な変更データキャプチャ (CDC) です。

詳細オプション

Upsert モードと Insert モード

すべての行をそのまま挿入する (Insert モード) のと、更新や削除も反映する (Upsert モード) のでは、何が違うのでしょうか？

  • Insert モード: 新しい行はすべて追加されるため、更新であっても重複が発生します。
  • Upsert モード: 既存の行への更新はその内容を上書きするため、分析データを常に最新かつ整った状態に保つのに適しています。

スキーマ変更への対応

アプリは変化し、それに伴ってスキーマも変わります。このパイプラインでは、次のように対応できます。

  • 運用テーブルに新しいカラムを追加した場合は？ Streamkap がそれを検出し、ClickHouse 側にも追加します。
  • カラムを削除した場合は？ 設定によっては移行が必要になることもありますが、追加のほとんどはスムーズに反映されます。

実運用での監視: パイプラインの状態を把握する

パイプラインの状態を確認する

Streamkap には、次のことを確認できるダッシュボードがあります。

  • パイプラインの遅延を確認する (データはどの程度新しいか)
  • 行数とスループットを監視する
  • 何か異常があればアラートを受け取る

ダッシュボードの例：遅延グラフ、行数、正常性インジケーター。

確認すべき主要なメトリクス

  • 遅延: ClickHouse が SQL Server に対してどれくらい遅れているか
  • スループット: 1 秒あたりの行数
  • エラー率: ほぼゼロであるべき

本番運用: ClickHouse のクエリ

データが ClickHouse に入ったので、高速な分析ツールを使ってクエリを実行できます。基本的な例を以下に示します。

-- 過去1時間のアクティブユーザー上位10件を表示
SELECT user\

Grafana、Superset、Redash などのダッシュボードツールと ClickHouse を組み合わせれば、本格的なレポート作成が可能です。

次のステップと詳細ガイド

この手順ガイドで紹介したのは、できることのほんの一部にすぎません。基本を押さえたら、次は以下の内容も検討してみてください。

  • フィルタリングしたストリームの設定 (一部のテーブル/カラムのみを同期)
  • 複数のソースを1つの分析用DBにストリーミング
  • これをS3/データレイクと組み合わせてコールドストレージに活用
  • テーブル変更時のスキーマ移行の自動化
  • SSLとファイアウォールルールによるパイプラインの保護

より詳しいガイドについては、Streamkap blogをぜひチェックしてください。

よくある質問とトラブルシューティング

Q: クラウド上のデータベースでも動作しますか？ A: はい。この例では AWS RDS を使用しています。必要なポートが正しく開放されていることを確認してください。

Q: パフォーマンスはどうですか？ A: ClickHouse は高速です。ボトルネックになるのは通常、ネットワークかソース DB の binlog の速度ですが、ほとんどの場合、遅延は 1 秒未満です。

Q: 削除も処理できますか？ A: もちろんです。upsert モードでは、削除もフラグ付けされ、ClickHouse 側で処理されます。

まとめ

以上で、Streamkap を使って SQL Server のデータを ClickHouse にストリーミングする方法の概要はひととおり完了です。高速で柔軟性があり、本番データベースに大きな負荷をかけることなく最新の分析を必要とするチームに最適です。

試してみる準備はできましたか？ Sign up page にアクセスして、次のようなトピックも取り上げてほしい場合はぜひお知らせください。

  • upsert と insert の違いと、それぞれの細かなポイント
  • エンドツーエンドの latency: 最終的な分析ビューをどれだけ速く得られるか
  • パフォーマンスチューニングと スループット
  • このスタック上での実運用ダッシュボード

お読みいただきありがとうございました。ぜひストリーミングをお試しください。

Navigation