ESC را فشار دهید تا بسته شود

زمیوس آموزش، یادگیری و سرگرمی

Delta Lake چطور ACID را به Data Lake می‌آورد و مشکل Upsert را برای همیشه حل می‌کند؟

Delta Lake چطور ACID را به Data Lake می‌آورد و مشکل Upsert را برای همیشه حل می‌کند؟

اگه تا حالا با Data Lake‌ سنتی کار کرده باشی، احتمالاً این دردها برات آشناست:

آپدیت نداره، Delete افتضاحه، Upsert تقریباً غیرممکنه و اگه دو تا Job همزمان بنویسن… خدا به دادت برسه 😅

اینجاست که Delta Lake وارد می‌شه.

Delta Lake اومده که Data Lake رو از یه انبار فایل ساده، به یه Lakehouse واقعی با Transaction تبدیل کنه.

تو این مقاله آموزش مهندسی داده، قراره خیلی شفاف و اصولی ببینیم:

  • Delta Lake دقیقاً چطوری ACID رو روی Data Lake پیاده می‌کنه
  • و مهم‌تر از اون، Upsert رو چطور منطقی، scalable و production-ready حل می‌کنه

اگر با دیتابیس، انبار داده یا سیستم‌های تجزیه و تحلیل کار کرده باشی، احتمالاً اسم «معماری مدالین» (Medallion Architecture) یا همان معماری سه‌لایهٔ «Bronze – Silver – Gold» را شنیده‌ای.

پیشنهاد می کنم این مقاله زیر رو حتما مطالعه کنی.

در این مقاله شما می خوانید

مشکل Data Lake کلاسیک از کجاست؟

Data Lake به‌صورت پیش‌فرض فقط storage ـه:

  • فایل‌های Parquet
  • روی S3 / HDFS / ADLS
  • بدون هیچ مفهومی از Transaction

یعنی چی؟

  • INSERT → اوکی
  • UPDATE → فاجعه
  • DELETE → بازنویسی کل دیتا
  • MERGE → عملاً غیرممکن

خلاصه:

Data Lake = Storage

Database = Storage + Transaction

Delta Lake دقیقاً همون Transaction Layerه.

معماری Delta Lake؛ همه‌چیز از اینجا شروع می‌شود

هر Delta Table دو بخش اصلی دارد:

  1. فایل‌های Parquet (Immutable)
  2. پوشهٔ _delta_log

ایدهٔ کلیدی:

Delta Lake هیچ‌وقت فایل‌ها را overwrite نمی‌کند؛

فقط می‌گوید کدام فایل معتبر است و کدام نه.

و این «گفتن» داخل Transaction Log ثبت می‌شود.

Delta Log چه کاری می‌کند؟

Delta Log مثل ژورنال یک دیتابیس عمل می‌کند:

  • هر Insert، Update، Delete → یک Commit
  • Commit شامل:
    • Add فایل جدید
    • Remove فایل قدیمی
    • Metadata
    • Schema

نتیجه؟

جدول همیشه یک Snapshot سازگار دارد

Delta Lake چطور ACID را پیاده می‌کند؟

Atomicity ✅

یا کل عملیات commit می‌شود، یا هیچ‌چیز.

Job اگر fail شود، جدول سالم می‌ماند.

Consistency ✅

Delta Lake schema دارد، نه فقط schema-on-read.

دادهٔ ناسازگار؟ Reject.

Isolation ✅

با Optimistic Concurrency Control:

  • چند Job همزمان
  • بدون Lock کردن کل جدول
  • بدون Corruption

Durability ✅

commit بعد از ثبت در log معتبر است.

Crash بعدش؟ دیتا از بین نمی‌رود.

چرا Upsert در Data Lake کابوس است؟

در Data Lake کلاسیک:

  • Update یعنی rewrite کل table
  • Delete یعنی rewrite کل table
  • CDC؟ 😐

برای pipeline واقعی این اصلاً قابل‌قبول نیست.

Delta Lake چطور Upsert را حل می‌کند؟

با دستور MERGE INTO (SQL واقعی):

				
					MERGE INTO customers t
USING updates s
ON t.customer_id = s.customer_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

پشت صحنه چه اتفاقی می‌افتد؟

  • فقط فایل‌های مرتبط read می‌شوند
  • نسخهٔ جدید ساخته می‌شود
  • فایل قدیمی منقضی می‌شود
  • commit در delta log

✅ بدون rewrite کل دیتا

✅ کاملاً scalable

Time Travel؛ برگ برندهٔ Delta Lake

چون همه‌چیز version دارد:

				
					SELECT * FROM customers VERSION AS OF 10;

  • کاربردها:

    • Debug
    • Audit
    • Rollback
    • ML reproducibility

چرا Delta Lake برای معماری Lakehouse حیاتی است؟

چون:

  • Query Analytics
  • CDC
  • Feature Store
  • Streaming + Batch
  • ML

همه روی یک Data Source واقعی اجرا می‌شوند.

سوالات متداول درباره Delta Lake در مهندسی داده

Delta Lake یک لایه‌ی Transaction است که روی Data Lake قرار می‌گیرد و قابلیت‌هایی مثل ACID Transaction، Upsert، Delete، Time Travel و کنترل همزمانی را به Data Lake اضافه می‌کند.

در حالی که Data Lake معمولی فقط شامل فایل‌هایی مثل Parquet است و هیچ مفهومی از Transaction و Update ندارد، Delta Lake این خلا را پر می‌کند و Data Lake را به یک Lakehouse واقعی تبدیل می‌کند.

Delta Lake با استفاده از Transaction Log (پوشه‌ی _delta_log) همه‌ی تغییرات را به‌صورت versioned ثبت می‌کند.

هر Insert، Update یا Delete به شکل یک Commit اتمیک در Log ذخیره می‌شود و به‌جای overwrite فایل‌ها، فایل‌های جدید اضافه و فایل‌های قدیمی منقضی می‌شوند.

به این مدل، Optimistic Concurrency Control گفته می‌شود که باعث حفظ Atomicity، Consistency، Isolation و Durability می‌شود.

Upsert در Delta Lake با دستور MERGE INTO انجام می‌شود و این امکان را می‌دهد که داده‌ها به‌صورت همزمان Insert یا Update شوند.

برخلاف Data Lake سنتی که برای Update باید کل جدول بازنویسی شود، Delta Lake فقط فایل‌های مرتبط را تغییر می‌دهد.

این approach باعث می‌شود Upsert کاملاً scalable، سریع و مناسب CDC pipeline باشد.

Delta Lake برای سناریوهای production-grade عالی است، از جمله:

  • CDC و Streaming Data
  • Slowly Changing Dimensions (SCD)
  • Feature Store در Machine Learning
  • Real-time Analytics
  • Lakehouse Architecture

به‌طور خلاصه، هر جا که Data Lake به Update، Delete و Transaction قابل اعتماد نیاز دارد، Delta Lake بهترین انتخاب است.

جمع‌بندی

Delta Lake دیتابیس نیست،

ولی رفتار دیتابیس را به Data Lake می‌دهد.

اگه Data Lake بدون Delta مثل:

انبار بدون قفل و دفتر حساب است

Data Lake با Delta:

Lakehouse واقعی و production-grade است

سؤالی درباره این مقاله داری؟

اگر نکته‌ای در این مقاله برات مبهم بود یا خواستی بیشتر بدونی، همین حالا برام بنویس تا دقیق و صمیمی پاسخت رو بدم — مثل یه گفت‌وگوی واقعی 💬

برو به صفحه پرسش و پاسخ

میثم راد

من یه برنامه نویسم که حسابی با دیتابیس اوراکل رفیقم! از اونایی ام که تا چیزی رو کامل نفهمم،ول کن نیستم، یادگرفتن برام مثل بازیه، و نوشتن اینجا کمک می کنه تا چیزایی که یاد گرفتم رو با بقیه به شریک بشم، با هم پیشرفت کنیم.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *