اگر گزارش مدیریتی شما هر صبح با داده‌های دیروز ساخته می‌شود، مشکل از ابزار گزارش‌گیری نیست. مشکل این است که داده دیر می‌رسد. Change Data Capture یا CDC همین فاصله را کم می‌کند.
CDC دقیقاً چیست؟
CDC یا Change Data Capture روشی برای شناسایی و انتقال تغییرات داده از یک سیستم مبدأ به سیستم‌های دیگر است. این تغییرات شامل درج رکورد جدید (Insert)، به‌روزرسانی رکورد موجود (Update) و حذف رکورد (Delete) می‌شوند.
به‌جای استخراج مجدد کل جدول در هر نوبت، CDC امکان انتقال تدریجی تغییرات را فراهم می‌کند. در روش لاگ‌محور، تغییرات از لاگ تراکنش پایگاه داده خوانده می‌شوند؛ رویکردی که معمولاً نیاز به خواندن مکرر کل جدول را کاهش می‌دهد. این روش می‌تواند داده‌ها را با تأخیر کم به انبار داده یا سایر سامانه‌ها برساند، اما رسیدن به تأخیر چندثانیه‌ای تضمین‌شده نیست و به حجم تغییرات، پیکربندی منبع، شبکه و توان پردازش مقصد بستگی دارد.
مطابق توضیحات Google Cloud درباره CDC، این فناوری برای یکپارچه‌سازی داده، تحلیل نزدیک به بلادرنگ و همگام‌سازی سامانه‌ها کاربرد دارد.
سه روش پیاده‌سازی CDC
۱. لاگ‌محور (Log-based)
در این روش، تغییرات از لاگ تراکنش پایگاه داده خوانده می‌شوند؛ برای مثال، Redo Log در Oracle و Write-Ahead Log یا WAL در PostgreSQL. در نتیجه، به‌جای اجرای پرس‌وجوهای مکرر روی کل جدول، تغییرات ثبت‌شده در لاگ دنبال می‌شوند.
این روش معمولاً برای جریان‌های پیوسته CDC مناسب‌تر است و می‌تواند عملیات حذف را نیز ثبت کند. البته استخراج و پردازش لاگ بدون هزینه نیست؛ میزان بار واردشده به پایگاه داده به نوع فناوری، پیکربندی و حجم تراکنش‌ها بستگی دارد.
۲. مبتنی بر تریگر (Trigger-based)
در این روش، تریگرهای پایگاه داده هنگام درج، به‌روزرسانی یا حذف رکورد، اطلاعات تغییر را در جدول کمکی ثبت می‌کنند. پیاده‌سازی آن در برخی سامانه‌ها ساده است، اما اجرای تریگر به مسیر پردازش تراکنش اضافه می‌شود و می‌تواند بر زمان پاسخ و منابع پایگاه داده اثر بگذارد. میزان این اثر به حجم تراکنش‌ها و پیچیدگی تریگرها وابسته است.
۳. مبتنی بر کوئری (Query-based)
در این روش، با استفاده از ستونی مانند updated_at یا یک شماره نسخه، رکوردهای جدید یا تغییر‌یافته به‌صورت دوره‌ای استخراج می‌شوند.
این رویکرد معمولاً ساده‌تر است، اما محدودیت‌هایی دارد: حذف سخت رکوردها (Hard Delete) را نمی‌توان صرفاً با بررسی جدول فعلی تشخیص داد و اگر یک رکورد چند بار بین دو نوبت خوانش تغییر کند، ممکن است فقط آخرین وضعیت آن دیده شود، نه همه تغییرات میانی. طراحی نامناسب زمان‌بندی و نشانگر آخرین خوانش نیز می‌تواند به ازدست‌رفتن تغییرات منجر شود.
معیار |
لاگ‌محور |
تریگرمحور |
مبتنی بر کوئری |
|
تشخیص حذف سخت |
بله، با تنظیمات مناسب |
بله، با تریگر مناسب |
معمولاً خیر؛ مگر با سازوکارهایی مانند حذف نرم |
|
اثر بر پایگاه داده مبدأ |
معمولاً کمتر از خواندن مکرر کل جدول؛ وابسته به پیکربندی |
سربار در مسیر تراکنش |
هزینه خوانش دوره‌ای و اجرای کوئری |
|
تأخیر |
بالقوه نزدیک به بلادرنگ |
وابسته به ثبت و انتقال تغییر |
تابع فاصله بین نوبت‌های خوانش |
|
پیچیدگی راه‌اندازی |
نسبتاً بالا |
متوسط |
معمولاً پایین |
معماری معمول یک خط CDC
یک خط لوله CDC معمولاً از اجزای زیر تشکیل می‌شود:
منبع: پایگاه داده عملیاتی، مانند Oracle یا PostgreSQL.
کانکتور CDC: مسئول دریافت تغییرات از منبع. Debezium یکی از گزینه‌های متن‌باز رایج برای این کار است.
لایه انتقال رویداد: در معماری‌های جریان رویداد، معمولاً از ابزاری مانند Apache Kafka برای توزیع تغییرات میان مصرف‌کنندگان استفاده می‌شود. این لایه برای همه پیاده‌سازی‌های CDC الزامی نیست.
مقصد: انبار داده، Lakehouse، سامانه جست‌وجو یا دیگر سیستم‌های مصرف‌کننده داده.
نکته مهم درباره Oracle: کانکتور Oracle در Debezium از سه روش LogMiner، XStream و OpenLogReplicator پشتیبانی می‌کند. LogMiner روش پیش‌فرض این کانکتور است. استفاده از XStream به مجوز Oracle GoldenGate نیاز دارد، هرچند نصب نرم‌افزار GoldenGate الزامی نیست. همچنین، پشتیبانی OpenLogReplicator در مستندات Debezium با وضعیت توسعه‌ای Incubating معرفی شده است؛ بنابراین بلوغ فنی و محدودیت‌های نسخه مورد استفاده باید پیش از انتخاب بررسی شود.
در ژوئیه ۲۰۲۶، نسخه ۳.۶ Debezium تغییراتی در الگوریتم تعیین پنجره‌های پردازش LogMiner ارائه کرد تا تنظیم آن در برخی راهبردهای استخراج ساده‌تر شود. این بهبود به تمام حالت‌های پیکربندی تعمیم‌پذیر نیست؛ بنابراین پیش از ارتقا یا راه‌اندازی، مستندات نسخه و راهبرد انتخاب‌شده را بررسی کنید. جزئیات تغییرات LogMiner در Debezium
CDC و ETL/ELT: رقیب نیستند
CDC جایگزین ETL یا ELT نیست. CDC سازوکاری برای شناسایی و انتقال تغییرات داده است؛ درحالی‌که ETL و ELT فرایند گسترده‌تری را برای استخراج، تبدیل و بارگذاری داده تعریف می‌کنند.
یک معماری رایج این است که CDC تغییرات را به ناحیه Staging منتقل کند و سپس داده‌ها بر اساس قواعد تعریف‌شده در انبار داده یا Lakehouse پردازش و ادغام شوند. در این معماری، CDC به تازه‌تر شدن داده کمک می‌کند، اما به‌تنهایی کیفیت داده، تبدیل صحیح یا نگهداری تاریخچه را تضمین نمی‌کند.
چه زمانی CDC ارزش استفاده دارد؟
گزارش‌گیری عملیاتی نزدیک به بلادرنگ: برای موجودی، وضعیت سفارش یا شناسایی تراکنش‌های مشکوک.
همگام‌سازی سامانه‌ها: زمانی که تغییر یک سیستم باید با تأخیر کم به سایر سامانه‌ها برسد.
مهاجرت پایگاه داده: برای انتقال تدریجی داده‌ها و همگام نگه‌داشتن مبدأ و مقصد در دوره مهاجرت.
ثبت تاریخچه تغییرات: به شرط ذخیره پایدار رویدادها و طراحی مقصد برای نگهداری تاریخچه موردنیاز.
اگر به‌روزرسانی روزانه برای گزارش‌های سازمان کافی است، اجرای یک فرایند Batch ممکن است ساده‌تر و کم‌هزینه‌تر باشد. انتخاب CDC باید بر اساس نیاز واقعی کسب‌وکار به تازگی داده انجام شود، نه صرفاً به دلیل امکان فنی آن.
خطاهای رایج
۱. نادیده‌گرفتن تغییر ساختار (Schema Change)
اضافه‌شدن یا تغییر نوع یک ستون در منبع می‌تواند پردازش مقصد را مختل کند. قرارداد داده، سیاست سازگاری نسخه‌ها و ابزارهایی مانند Schema Registry به مدیریت تغییر ساختار کمک می‌کنند؛ اما سازگاری باید در کل خط لوله، از کانکتور تا مقصد، بررسی شود.
۲. فرض‌کردن ترتیب یکسان برای همه رویدادها
در جریان‌های توزیع‌شده، ترتیب رویدادها لزوماً در همه پارتیشن‌ها یا میان چند جدول حفظ نمی‌شود. در Kafka، استفاده از کلید مناسب مانند شناسه رکورد به حفظ ترتیب رویدادهای یک کلید در یک پارتیشن کمک می‌کند، اما ترتیب سراسری همه رویدادها را تضمین نمی‌کند. پردازش مقصد نیز باید در برابر تکرار رویدادها مقاوم باشد.
۳. فراموش‌کردن Snapshot اولیه
CDC معمولاً برای ثبت تغییرات جاری به کار می‌رود؛ بنابراین اگر مقصد باید شامل داده‌های از قبل موجود نیز باشد، لازم است بارگذاری اولیه (Snapshot) و شروع جریان تغییرات هماهنگ شوند. در غیر این صورت، احتمال ناقص‌ماندن داده‌های مقصد وجود دارد.
۴. بی‌توجهی به تأخیر مصرف و نگهداری لاگ‌ها
اگر مصرف‌کننده متوقف شود یا از سرعت تولید تغییرات عقب بماند، پردازش به تأخیر می‌افتد. مدت نگهداری لاگ‌ها در مبدأ محدود است و حذف لاگ‌های موردنیاز پیش از مصرف می‌تواند بازیابی جریان را دشوار کند یا به بارگذاری مجدد نیاز داشته باشد. در PostgreSQL، انباشته‌شدن WAL نیز می‌تواند فضای دیسک را مصرف کند. پایش تأخیر، فضای ذخیره‌سازی و سیاست نگهداری لاگ‌ها ضروری است.
۵. بلادرنگ‌کردن بیش‌ازحد فرایندها
هر داده‌ای به انتقال چندثانیه‌ای نیاز ندارد. هدف باید تعیین تأخیر قابل‌قبول برای هر فرایند باشد. جریان‌های حیاتی را می‌توان به‌صورت پیوسته پردازش کرد و برای داده‌هایی که تصمیم‌گیری فوری به آن‌ها وابسته نیست، از Batch یا فاصله‌های طولانی‌تر استفاده کرد.
Agentic CDC: ترند ۲۰۲۶ یا هیاهو؟
اصطلاح Agentic CDC هنوز به یک فناوری مستقل با تعریف یکسان در همه منابع اشاره نمی‌کند. در کاربردهای جدید، دست‌کم دو مفهوم متفاوت زیر این عنوان مطرح می‌شوند: استفاده از جریان CDC برای تأمین داده تازه موردنیاز عامل‌های هوش مصنوعی و استفاده از عامل‌های هوش مصنوعی برای پایش و مدیریت خودکار پایپ لاین CDC؛ برای مثال، شناسایی افزایش تأخیر، بررسی تغییرات ساختار داده یا پیشنهاد اقدام اصلاحی.
در مفهوم نخست، CDC داده تازه را به سامانه مصرف‌کننده می‌رساند؛ در مفهوم دوم، عامل هوش مصنوعی به مدیریت عملیات پایپ لاین کمک می‌کند. بنابراین، صرف انتقال داده از CDC به یک پایگاه برداری یا حافظه عامل، لزوماً به معنای پیاده‌سازی Agentic CDC نیست.
نیاز به داده تازه برای عامل‌های هوش مصنوعی نیز موضوعی واقعی است. IDC در مقاله‌ای در مارس ۲۰۲۶ برآورد کرده است که ۸۰ درصد موارد استفاده از هوش مصنوعی عامل‌محور به داده بلادرنگ، متناسب با زمینه و در دسترس نیاز خواهند داشت. این برآورد درباره نیازهای داده‌ای این کاربردهاست؛ نه اینکه همه آن‌ها الزاماً باید با CDC پیاده‌سازی شوند.
نکته مهم این است که تازگی داده به‌تنهایی برای تصمیم‌گیری قابل‌اعتماد کافی نیست. عامل باید به داده مجاز و معتبر دسترسی داشته باشد و در صورت نیاز بتوان منشأ داده، مسیر تغییرات و سطح دسترسی آن را بررسی کرد. مستندات Atlan درباره مشاهده‌پذیری عامل‌های هوش مصنوعی نیز بر اهمیت منشأ داده، نشانه‌های کیفیت و کنترل دسترسی تأکید دارد.
در نتیجه، پیش از افزودن قابلیت‌های عامل‌محور به پایپ لاین CDC، باید کیفیت داده، حاکمیت، ثبت رویدادها، پایش و سازوکارهای بازیابی آن تثبیت شده باشند.
پرسش‌های متداول
CDC چیست؟
CDC یا Change Data Capture روشی برای شناسایی و انتقال تغییرات داده، شامل درج، به‌روزرسانی و حذف، از یک سیستم مبدأ به سیستم‌های دیگر است. در روش لاگ‌محور، تغییرات از لاگ تراکنش خوانده می‌شوند و نیازی به استخراج مکرر کل جدول نیست.
بهترین روش CDC کدام است؟
برای بسیاری از سامانه‌های عملیاتی پرتراکنش، روش لاگ‌محور گزینه مناسبی است؛ زیرا معمولاً نیاز به خواندن مکرر کل جدول را کاهش می‌دهد و امکان ثبت حذف‌ها را نیز فراهم می‌کند. بااین‌حال، انتخاب نهایی به قابلیت‌های پایگاه داده، مجوزها، حجم تراکنش‌ها و پیچیدگی راه‌اندازی بستگی دارد.
آیا CDC جایگزین ETL است؟
خیر. CDC سازوکاری برای دریافت تغییرات داده است، درحالی‌که ETL و ELT مراحل استخراج، تبدیل و بارگذاری داده را پوشش می‌دهند. CDC می‌تواند بخشی از معماری ETL یا ELT باشد.
آیا برای Oracle می‌توان از Debezium استفاده کرد؟
بله. کانکتور Oracle در Debezium از LogMiner، XStream و OpenLogReplicator پشتیبانی می‌کند. LogMiner روش پیش‌فرض است و استفاده از XStream به مجوز Oracle GoldenGate نیاز دارد. پیش از انتخاب روش، سازگاری نسخه، تنظیمات پایگاه داده و محدودیت‌های عملیاتی را بررسی کنید.
جمع‌بندی
CDC زمانی ارزشمند است که تأخیر انتقال داده برای کسب‌وکار هزینه ایجاد کند. برای شروع، یک جدول یا فرایند حیاتی را انتخاب کنید، تأخیر قابل‌قبول را مشخص کنید و اثر روش انتخابی بر پایگاه داده مبدأ را بسنجید. سپس بارگذاری اولیه، نگهداری لاگ‌ها، مدیریت تغییر ساختار و پایش تأخیر را در طراحی لحاظ کنید.
پس از تثبیت این زیرساخت، می‌توان درباره افزودن قابلیت‌های پیشرفته‌تر، از جمله کاربرد عامل‌های هوش مصنوعی در مدیریت جریان داده، تصمیم گرفت.