ログベースCDCの実装とクラウドDWHへのデータ連携 ⼤規模データ運⽤に向けたCData Syncの活⽤ポイント

クラウドDWH を活⽤したデータ基盤の構築が進む中、オンプレミスの業務データをいかに効率よく連携するかが重要な課題となっています。その中でも、ログベースのChange Data Capture（CDC）による差分抽出は広く知られている⼿法ですが、RDBMS ごとにログの仕様や取得⽅法が異なるため、実装や運⽤には⼯夫が求められる場⾯も少なくありません。

さらに、抽出したデータをクラウドDWH にどう送るかという転送アーキテクチャの構成も重要な要素です。⼤量データや⾼頻度更新に対応するには、各DWH の特性を踏まえた運⽤⽅法や転送の仕組みに⼯夫が必要になります。

本セッションでは、RDB 別CDC 実装／運⽤のポイントと課題、およびデータパイプラインツールの「CData Sync」を活⽤したクラウドDWH への効率的なデータ転送⼿法を解説します。

Transcript

1. Connect Your Data. Any Application. Anywhere. CData Sync ログベースCDCの実装とクラウドDWHへのデータ連携 ⼤規模データ運⽤に向けたCData Syncの活⽤ポイント CData Software Japan 合同会社 宮本 航太 株式会社コーソル 渡部 亮太
2. 2 Speaker 宮本 航太 シニアプロダクトスペシャリスト、PM for Apps - 2019 年よりCData Software にジョイン - 5年ほどApps 系を中心にサポートチームで活動 - 2024 年からApps 系のローカルPMに従事 © 2025 CData Software Inc
3. 3 基幹DBから分析基盤へのデータ連携で こんな課題はありませんか？ リアルタイム性が足りない 連携処理が遅くて 業務に支障 システム負荷が⼤きい CDC による変更データ取得 Cloud DWH への効率的な データ転送 © 2025 CData Software Inc
4. 4 今日お話しする内容 環境に適したCDC アプローチの見極め方 CDC 導入・ログベースCDC運用時の勘所 （CData Sync における）Cloud DWH への効率的な転送手法 © 2025 CData Software Inc
5. Why CDC？ CDCのアプローチの種類
6. 6 実際の現場での課題解決事例 大手製造業様におけるCDC活用 © 2025 CData Software Inc
7. 7 実際の現場での事例・大手製造業様におけるCDC活用 現場で直面した課題 - サイロ化したことによる本番システム負荷 - 手作業Excel 収集によるリアルタイム性の欠如 CDC 活⽤で解決 - 最短1分でニアリアルタイム同期 実現させたいこと - 製造品質における歩留まり等の分析 導入効果 - 開発期間短縮：1/10 - 最短同期：1分 - 連携テーブル数：100 サイロ化した工場システムを CDC でニアリアルタイム統合 © 2025 CData Software Inc
8. 8 「データ連携の課題」と「ビジネスサイドからの要求」 ビジネス要求の変化 従来のバッチ処理の限界 データ量に比例した処理時間増大 本番システムへの負荷集中 リアルタイム性の欠如 ビジネス部門からの要求 「データをすぐに分析して判断したい！」 - リアルタイム分析・意思決定、機会損失回避 IT 運⽤部門からの要求 「本番システムは絶対に止められない！」 - システム可用性の確保、安定した運用の継続 経営層からの要求 「コストを抑えつつ効果を最大化したい！」 - 投資対効果の向上、迅速な経営判断基盤 © 2025 CData Software Inc
9. 9 これらの課題を解決するCDC アプローチ 従来のバッチ処理の限界 データ量に比例した処理時間増大 © 2025 CData Software Inc 本番システムへの負荷集中 リアルタイム性の欠如 Change Data Capture で変更情報を取得 （クエリベース、トリガーベース、ログベース）
10. 10 3つのCDC アプローチ比較 クエリベース トリガーベース ログベース 仕組み 更新日時でクエリ実行 SELECT * FROM table WHERE updated_at > '...' 変更時にトリガー実行 シャドウテーブルに 変更履歴を記録 トランザクションログ監視 DBのログファイルから 変更情報を読み取り メリット • DB設定不要 • すぐ実行可能 • 実装が簡単 • 全変更検知可能 • リアルタイム対応 • 削除も検知 • DB負荷最小 • 管理が容易 • 全変更検知可能 デメリット • DB負荷大 • 削除検知不可 • 更新日時項目必須 • 運用複雑化 • 性能影響あり • スキーマ変更時対応 • 実装複雑 • ツール依存 • 古いDB未対応 適用場面 小規模データ 簡単な要件 中規模システム リアルタイム要件 大規模・本格運用 高可用性要件 総合評価 お手軽だが制約多め 自分たちで制御できるが 運用が大変 高機能で運用しやすい © 2025 CData Software Inc
11. © 2025 CO-Sol Inc. 11 © 2025 CO-Sol Inc. ログベースCDC 実装／運⽤上のポイント
12. © 2025 CO-Sol Inc. 12 講師自己紹介+所属会社紹介 • 渡部 亮太（わたべ りょうた） – Oracle ACE Pro (Oracle Database分野、日本に5名のみ) – Japan Oracle User Group 代表 – 著書・講演実積多数 – ORACLE MASTER Platinum 12c/11g MySQL OCP 5.6, OSS-DB Gold (PostgreSQL, INACTIVE) • 株式会社コーソル – 「CO-Solutions＝共に解決する」の理念のもと、 Oracle技術および仮想化技術に特化した事業を展開中。 心あるサービスの提供とエンジニアの育成に注力している – 社員数: 159名 (2025年4月時点) – ORACLE MASTER Platinum取得者数 日本一 2日間の実技試験で認定されるOracle DB最高位資格
13. © 2025 CO-Sol Inc. 13 ログベースCDCの技術的側面 • RDBMSにはトランザクションログがあり、変 更内容が逐一記録される • ただし、一般にデフォルトでトランザクショ ンログに記録される情報からだけでは、 変更内容をSQLレベルで再現できない → 情報が追加で必要！ RDBMS データファイル UPDATE t1 SET c2 = 'XXX' WHERE pk = 1; UPDATE t1 SET c2 = 'YYY' WHERE pk = 2; COMMIT; トランザクション ログファイル 更新済み ブロック …→XXX …→YYY トランザクション ログ UPDATE t1 SET c2 = 'XXX' WHERE pk = 1; update "UNKNOWN"."OBJ# 93296" set "COL 3" = HEXTORAW('58585820202020202020202020202020') where ROWID = 'AAAWxwAACAAAAIBAAB'; …→XXX …→YYY 実行したSQL トランザクションログから再現／構築したSQL （ソースDBの物理構造に依存したSQL）
14. © 2025 CO-Sol Inc. 14 Oracle - 変更内容をSQLレベルで再現するための設定 • ⇒ サプリメンタルロギング (*1) 設定 update "UNKNOWN"."OBJ# 93296" set "COL 3" = HEXTORAW('58585820202020202020202020202020') where ROWID = 'AAAWxwAACAAAAIBAAB'; UPDATE t1 SET c2 = 'XXX' WHERE pk = 1; *1: 厳密にはサプリメンタルロギングだけではな く、ディクショナリの参照も使用する 上記の追加情報を使用することで、ソースDBの物理構造に依存したSQLを、 ターゲットDBで実際に実行可能なSQLに変換できるようになる ソースDBの物理構造に依存したSQL ターゲットDBで実行可能なSQL
15. © 2025 CO-Sol Inc. 15 Oracleサプリメンタルロギング負荷の軽減 • ソースOracleでCDCを実行するにはサプリメンタルロギングを有効化する必要 があるが、REDOログ（トランザクションログ）の出力量が増加し、ストレージ消 費および負荷が増加する • 負荷増加を軽減するには、レプリケーション対象の表についてのみ、サプリメ ンタルロギングを有効化する ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER TABLE <表> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
16. © 2025 CO-Sol Inc. 16 PostgreSQL - Oracleサプリメンタルロギング相当の設定 • ⇒ wal_level=logical (デフォルトはreplica) WALにトランザクション境界の明示的レコード、スキーマ・カタログ変更のログ、 DMLによる「論理的な変更内容」が記録されるようになるため、ターゲットDBで実際 に実行可能なSQLを作成できるようになる
17. © 2025 CO-Sol Inc. 17 MySQLではログベースCDC向けの設定は原則不要 • バイナリログには、行レベルの論理的な変更内容が記録される – binlog-format=ROW – MySQL 8.0以降では、バイナリログ出力はデフォルト有効 • 物理的な変更内容を、論理的な変更内容に変換する必要がない – そもそもバイナリログにはDML/SQLが記録されている • また、OracleやPostgreSQLのトランザクションログとMySQLのバイナリログ は役割が異なる UPDATE `db1`.`t1` WHERE @1=1 @2='old' SET @1=1 @2='XXX'
18. © 2025 CO-Sol Inc. 18 [参考] MySQLのバイナリログとInnoDBログ データファイル バイナリログ ファイル 更新済み ブロック X→Y A→B イベント （更新系SQL) B Y A→B X→Y Y B A→B InnoDBバッファプール mysqld プロセス UPDATE t1 SET col1='B' WHERE col1='A'; UPDATE t1 SET col1='Y' WHERE col1='X'; COMMIT; …-bin. …10 InnoDB ログファイル A→B X→Y …-bin. …11 …-bin. …12 X→Y A→B REDOログ ・・・ X→Y 更新系SQL（イベント）を書 き込むバイナリログファイル は連番で順次生成される REDOログは InnoDBログファ イルに循環書き込 みされる
19. © 2025 CO-Sol Inc. 19 © 2025 CO-Sol Inc. CData Syncで ログベースCDCレプリケーション を活⽤する
20. © 2025 CO-Sol Inc. 20 弊社 コーソル 視点でのCData Syncの利点 • ログベースCDCを⽤いた差分レプリケーションに対応 – データが大量な場合、差分レプリケーションは事実上必須 – [注意] CData Sync Professional以上が必要 – 別方式の差分レプリケーションにも対応 • クエリベース : 差分チェックカラムを用いた差分レプリケーション • 異種RDBMS間でレプリケーション可能 ＋ 低価格 – 例: Oracle → PostgreSQL / 基幹系RDBMS → クラウド系DWH • 処理の高速性 – データ転送 指向 / バルク的なレプリケーション処理 • 多数のデータストア、SaaS間のデータレプリケーションに対応 – 同期元: 400種以上のデータストア、SaaSなどに対応 – 同期先: 30種程度のデータストアに対応 • オンプレミス環境 / クラウド環境 / 混在環境で使⽤可能 – 稼働環境が柔軟
21. © 2025 CO-Sol Inc. 21 CData SyncはログベースCDCに対応 同期元 CData Sync 対応データストア、SaaS 400 種以上 同期先 対応データストア 30 種以上 Oracle, MS SQL Server, MySQL, PostgreSQL, Snowflake, Redshift, BigQuery, … CDC対応 RDBMS : 7種 • Oracle Database • Microsoft SQL Server • PostgreSQL • MySQL • MariaDB • IBM Db2 • IBM Informix CData Syncは上記7種のRDBMSに ついて、ログベースCDCに対応
22. © 2025 CO-Sol Inc. 22 異なるDB製品間のログベースCDC差分レプリケーション 構成例 OLTP系DBMS(CData Sync CDC対応) → 分析系DBMS/データストアサービス Snowflake Google BigQuery Amazon Redshift Amazon S3 Azure Synapse Azure Data Lakes MySQL Heatwave Oracle Autonomous Databricks Vertica … OLTP系DBMS(CData Sync CDC対応) → OLTP系DBMS ORACLE MySQL PostgreSQL SQL Server MariaDB IBM Db2 Informix ORACLE MySQL PostgreSQL SQL Server MariaDB IBM Db2 Informix ORACLE MySQL PostgreSQL SQL Server MariaDB IBM Db2 Informix ニア リアルタイム 連携 ニア リアルタイム 連携
23. © 2025 CO-Sol Inc. 23 1ライセンス/1サーバで多くのレプリケーションを構成可能 CData Sync Professional 1ライセンスで最⼤10接続使⽤可能 (有償オプション追加で接続数を追加可能） ORACLE SQL Server Google BigQuery CData Sync ORACLE ORACLE ORACLE SQL Server Snowflake MySQL PostgreSQL データソース 8接続 同期先 2接続 構成例
24. © 2025 CO-Sol Inc. 24 活⽤ユースケース CData Sync ユースケース1：基幹データの社内活⽤ 基幹システム Oracle Database 社内業務用DB PostgreSQL データ参照業務 社内システム利用 ユースケース2：データ分析基盤のデータ連携 CData Sync 顧客情報/営業情報 SaaS 業務システム SQL Server データ分析基盤 Amazon Redshift データ分析 レポーティング
25. © 2025 CO-Sol Inc. 25 処理の高速性 : データ転送 指向 / バルク的なレプリケーション処理 ソースDB ターゲットDB ② グローバル一時表 ターゲット表 ① JDBCバッチ更新 複数行を一括でINSERT ③ MERGE文でUPSERT ダイレクトパス処理 CData Sync LogMiner 過去の変更処理を 取得 [注意事項] • 本資料で記載する内部処理については、コーソル渡部の調査に 基づくものであり、CData Syncの仕様として公開されている ものではない点に注意ください。 • 条件によって異なる振る舞いをする可能性があります。また、 今後変更される可能性もあります。 差分レプリケーションの仕組み （Oracle → Oracle）
26. © 2025 CO-Sol Inc. 26 MERGE /*+ APPEND */ でUPSERT 1. MERGE文を用いて、UPSERT処理を実行 → 差分更新のため – 既存の行があれば、UPDATE – 既存の行がなければ、INSERT 2. /*+ APPEND */ ヒントを指定 → ダイレクトパスロード MERGE /*+ APPEND */ INTO "T1" A USING "T1__r_2088587615" B ON (A."N"=B."N") WHEN MATCHED THEN UPDATE SET A."S"=B."S", A."_cdatasync_deleted"=B."_cdatasync_deleted" WHEN NOT MATCHED THEN INSERT ("N","S","_cdatasync_deleted") VALUES (B."N",B."S",B."_cdatasync_deleted")
27. （CData Sync による） Cloud DWHへの効率的なデータ 転送アプローチ
28. 28 大量の変更データをCDCで効率よく抽出できました。 では次の課題は？ ⼤量の変更データを早く同 期先に取り込みたいが… よくある一般的な課題 実は1件ずつ INSERT/UPDATE ⇒処理が終わらない API 制限に抵触 ⇒大量のリクエスト や同時接続数超過 DWH 特性の機能を利 用してない ⇒大量データの取り込み方 法が利用できない 全件メモリ保持 ⇒大量データ一括保 持でOOM ETLツール © 2025 CData Software Inc
29. 29 Snowflake への転送アプローチ（従来方式） 変更レコード全件をメモリで保持 ⇒OOM の懸念 1回の転送処理が完了してから次の転送処理を 開始 ------------------------------------ PUT（ファイルアップロード） ↓↓ COPY INTO （データロード） ------------------------------------ の繰り返しで、レコードが多いほどオーバーヘッ ドが増大 そもそもCOPY INTO では1000ファイルまで指定 可能・・・ 従来方式 CData Sync でもこのような問題がありました © 2025 CData Software Inc
30. 30 Snowflake への転送アプローチ（新方式） 新方式 ファイルベースの処理に変更 ・全データをローカルエリアにファイル出力 ・ファイルストリームでデータ読み出しながら 処理 転送処理を効率化 ・転送データは指定サイズで区切り、gzip圧縮 ・gzip ファイルをPUTリクエストで全て転送 ・転送完了後、COPY INTO を実行 （1000ファイルまで同時指定） © 2025 CData Software Inc
31. 31 Snowflake への転送結果（新旧比較） ※Warehouse のサイズを拡張することで、さらにパフォーマンス向上が期待できる。 © 2025 CData Software Inc
32. 32 各DWH 向けに最適化された共通アプローチ コスト BigQuery BQ JDBC Batch 方式からGCS 経由のCopy Into 方式に 変更 コスト Redshift RS JDBC Batch 方式からS3 経由のCopy コマンド方式に 変更 コスト DataBricks DB JDBC Batch 方式からDBFS 経由のCopy Into 方式に 変更 100K：54s → 46s 15% ↑↑ 800K：359s → 187s 48%↑↑ 100K：78s → 50s 36% ↑↑ 800K：300s → 117s 61%↑↑ 100K：139s → 37s 73% ↑↑ 800K：755s → 160s 79%↑↑ ストレージ経由での圧縮ファイル転送に切り替え © 2025 CData Software Inc
33. 33 まとめ 環境に適したCDC アプローチの見極め方 ⇒ ログ運用設定の可否を先に検討、加えてデータ量やリアルタイム性要件・運用スキルで総合判断 CDC 導入・ログベースCDC運用時の勘所 ⇒ ソースDBへの追加設定が必要。 Oracleでは必要最小限のサプリメンタルロギング設定が有効 （CData Sync における）Cloud DWH への効率的な転送手法 ⇒ ストレージ経由の圧縮ファイル転送により最大79% の性能向上を実現 （Snowflake、BigQuery、Redshift、Databricks で検証済み） © 2025 CData Software Inc
34. © 2025 CO-Sol Inc. 34 コーソルが提供するCData Sync関連サービス トライアルから運用まで各フェーズに応じた支援メニューをご用意しています。 トライアル支援 （無償/有償） CData Syncでは「30日間の無償トライアル」および「3か月間の有償PoCライセンス」の 2種類のトライアル方法がございます。コーソルでは導入手順書のご提供をはじめとする 支援メニューにて、お客様のトライアルをサポートします。 ライセンス販売 コーソルはCData Syncの認定販売パートナーです。特にOracle Databaseを用いた レプリケーション環境については、導入支援や運用支援のサービスもご提供可能です。 導入支援 （有償） コーソルにはOracleをはじめとする商用RDBMSのスペシャリストがいます。Oracleや SQL Serverを使ったCData Syncのレプリケーション環境の導入にあたっては、データ ベースの知見も交えたより専門性の高い支援をご提供します。 運⽤支援 （無償） 運用支援サービスでは、データベースの知見を有したエンジニアがQ&A対応から操作レク チャー、設定変更時の作業支援、トラブル対応まで、お客様の運用を幅広くサポートしま す。
35. 35 さいごに アンケートにご協力お願いします！ ご希望の方には、アンケート内で個別相談の 申込みも可能です！ © 2025 CData Software Inc https://jp-go.cdata.com/l/1017622/2025-07-03/4577x