پردازش دسته‌ای Batch Processing

پردازش دسته‌ای یعنی داده را به‌صورت انبوه و یک‌جا پردازش کنید؛ نه رکورد به رکورد و لحظه‌ای. کتاب Designing Data-Intensive Applications این رویکرد را در برابر سیستم‌های آنلاین قرار می‌دهد: در سیستم آنلاین، درخواستی می‌رسد و بلافاصله پاسخ می‌گیرد؛ در پردازش آفلاین (دسته‌ای)، یک کار، تمام ورودی را می‌خواند و در پایان خروجی را می‌نویسد. Batch processing means you process data in bulk as one job. You do not handle each record in real time. Designing Data-Intensive Applications contrasts this with online systems: online is request and response. Offline is a job that reads all input and writes an output.

در معماری داده، این کار یکی از قطعه‌های یک پازل بزرگ‌تر است: معماریِ خوب اجزای پرکاربرد را هوشمندانه برمی‌گزیند، برای خرابی برنامه‌ریزی می‌کند و سیستم‌ها را از هم مستقل نگه می‌دارد. کار دسته‌ای معمولاً همان قطعه‌ای است که دادهٔ عملیاتی را به دادهٔ تحلیلی تبدیل می‌کند؛ بی‌آنکه بار اضافه‌ای روی API فروش بگذارد. In a data architecture, this job is one piece of a larger picture. Good architecture picks common parts wisely, plans for failure, and keeps systems loosely coupled. A batch job is often the piece that turns operational data into analytical data — without loading down the sales API.

نیمهٔ دوم فصل ۴ کتاب DDIA به یک نکتهٔ مهم اشاره می‌کند: کارهای تحلیلی به چیدمان دیگری برای داده‌ها روی دیسک نیاز دارند. سیستم‌های آنلاین (OLTP) هر سطر را کامل می‌خوانند؛ مثلاً یک سفارش با همهٔ ستون‌هایش. اما کار تحلیلی معمولاً فقط چند ستون خاص را از میان میلیون‌ها سطر جمع می‌کند. برای چنین کاری، ذخیره‌سازی ستون‌محور به‌مراتب به‌صرفه‌تر است. The second half of DDIA Chapter 4 says analytical work needs a different layout on disk. An online system (OLTP) wants a whole row: one order, every column. An analytical job usually sums a few columns across millions of rows. For that, column-oriented storage is better.

پیش‌تر، در صفحهٔ ایندکس‌ها با B-tree و LSM-tree و ایندکس هش آشنا شده‌اید؛ اینجا دوباره به آن‌ها نمی‌پردازیم. نکتهٔ تازه این است: موتوری که برای یافتن سریع یک سفارش عالی است — همان ذخیره‌سازی سطرمحور — برای محاسبهٔ «جمع فروش کل سال» بسیار پرهزینه می‌شود. You already met B-trees, LSM-trees, and hash indexes on the Indexes page. We will not teach them again. The new point: the same row store that finds one order fast is expensive for "sum of sales this year."

بعد از تعریف کار دسته‌ای و محل ذخیرهٔ دادهٔ تحلیلی، حالا نوبت خودِ پردازش است؛ و ساده‌ترین شکل آن، خط‌لولهٔ یونیکس است. فصل ۱۱ کتاب DDIA با ابزارهای خط فرمان شروع می‌شود: لاگ را با grep، awk، sort و uniq به هم زنجیر می‌کنید؛ هر برنامه یک کار کوچک انجام می‌دهد و خروجی هر کدام، ورودی مرحلهٔ بعد می‌شود. این همان مدل ذهنی پردازش دسته‌ای است. Now that we have defined the batch job and where analytical data lives, it is time for the processing itself — and its simplest form is the Unix pipeline. Chapter 11 starts with Unix tools. You chain a log through grep, awk, sort, and uniq. Each program does one small job, and one output becomes the next input. That is the mental model of a batch job.

# How many paid orders per country yesterday?
cat orders.log \
| grep 'status=paid' \
| awk -F, '{print $3}' \
| sort \
| uniq -c

وقتی حجم داده از یک ماشین فراتر می‌رود، دیگر نمی‌توانید همه‌چیز را روی یک دیسک و با یک پردازنده انجام دهید. باید داده را بین چند ماشین پخش کنید. برای این کار، سه رویکرد اصلی وجود دارد که در جدول زیر مقایسه شده‌اند. انتخاب هر کدام به حجم داده، بودجه و نیاز شما به سرعت و قابلیت اطمینان بستگی دارد. When data no longer fits on one machine, you can no longer do everything on one disk and one CPU. You need to distribute the data across multiple machines. There are three main approaches for this, compared in the table below. The choice depends on data volume, budget, and your need for speed and reliability.

در بخش قبل دیدیم که وقتی داده از ظرفیت یک ماشین فراتر می‌رود، باید آن را میان چند ماشین پخش کنیم؛ اما روی چنین خوشه‌ای چطور برنامه بنویسیم؟ پاسخ کلاسیک، MapReduce است: مدلی برنامه‌نویسی برای پردازش داده‌های حجیم روی خوشه‌ای از ماشین‌ها. فرض کنید میلیون‌ها سفارش فروش دارید و می‌خواهید بدانید هر کشور چقدر فروش داشته است. در این مدل، کار را در سه مرحله انجام می‌دهید: In the previous section we saw that when data outgrows one machine, you spread it across many. But how do you program such a cluster? The classic answer is MapReduce: a programming model for processing massive data on a cluster of machines. Imagine you have millions of sales orders and want to know each country's total sales. In this model, you do the work in three steps:

موتورهای جریان داده (Dataflow) مانند Spark و Flink داده را میان مرحله‌ها بیشتر در حافظه نگه می‌دارند و لازم نیست بعد از هر Map فایل‌های بزرگی روی دیسک بنویسند. عملیات‌هایی مثل Join و GroupBy همچنان به Shuffle نیاز دارند، اما API تمیزتری در اختیار برنامه‌نویس می‌گذارند؛ مثلاً به‌صورت DataFrame یا زبان کوئری. Dataflow engines like Spark and Flink keep data in memory between stages more often, avoiding the need to write large files to disk after each Map. Operations like Join and GroupBy still use Shuffle, but with a cleaner API — for example, as a DataFrame or a query language.

# input: 12 paid orders
map(order) -> emit(order.Country, order.Amount)
# shuffle groups by key
IR: [120, 90, 40, 80]
DE: [80, 60, 70]
US: [200, 50, 150, 30, 110]
reduce(country, amounts) -> emit(country, sum(amounts))
# IR=330  DE=210  US=540

تا اینجا دیدیم پردازش دسته‌ای چیست، چرا کار تحلیلی به ذخیره‌سازی ستون‌محور نیاز دارد و MapReduce چطور روی یک خوشه اجرا می‌شود. حالا نوبت به یک سؤال مهم می‌رسد: این داده‌ها دقیقاً کجا ذخیره می‌شوند؟ کار دسته‌ای از یک جا می‌خواند و نتیجه را در یک جای دیگر می‌نویسد. فصل ۶ کتاب Fundamentals of Data Engineering سه مقصد اصلی را معرفی می‌کند. انتخاب هر کدام، تأثیر مستقیم بر هزینه، سرعت و نحوهٔ استفادهٔ بعدی از داده دارد. So far, we've seen what batch processing is, why analytical workloads need columnar storage, and how MapReduce runs on a cluster. Now it's time for an important question: where exactly is this data stored? A batch job reads from one place and writes results to another. Chapter 6 of Fundamentals of Data Engineering introduces three main destinations. Each choice directly impacts cost, speed, and how the data will be used later.

در بخش قبلی دیدیم دادهٔ دسته‌ای کجا ذخیره می‌شود؛ اما سؤال بعدی این است: خود داده چطور از سیستم مبدأ به آنجا می‌رسد؟ این فرایند را ورود داده یا Ingestion می‌نامند. ورود داده یعنی انتقال داده از جایی که تولید می‌شود (مثلاً دیتابیس عملیاتی) به جایی که کار دسته‌ای می‌تواند آن را بخواند (مثلاً دریاچه یا انبار). این فرایند را نباید با یکپارچه‌سازی کامل سیستم‌ها اشتباه گرفت؛ اینجا فقط داده جابه‌جا می‌شود و دو سیستم مستقل از هم می‌مانند. در این مرحله دو تصمیم کلیدی وجود دارد: In the previous section, we learned where batch data is stored. But another important question is: how does the data actually get from the source system to that destination? This process is called ingestion. Ingestion means moving data from where it's produced (e.g., an operational database) to where the batch job can read it (e.g., a lake or warehouse). This is different from full system integration; in ingestion, you're just transferring data, not connecting two systems. There are two key decisions here:

انتخاب اندازهٔ دسته‌ها هم یک بده‌بستان است: دستهٔ خیلی کوچک یعنی سربار (Overhead) زیاد برای هر بار commit به مقصد؛ دستهٔ خیلی بزرگ یعنی اگر کار نیمه‌کاره متوقف شود، باید حجم عظیمی را دوباره پردازش کنید. اندازهٔ مناسب به حجم داده و توان سیستم شما بستگی دارد. و برای تفاوت، همین‌قدر بدانید: جریان (Stream) بی‌پایان و بدون مرز است، اما دسته (Batch) همیشه مرز و حجم مشخصی دارد. Batch size is also a trade-off. A tiny batch means high commit overhead to the destination. A huge batch means that if the job dies midway, you'll have to reprocess a massive amount. Choosing the right size depends on your data volume and system capacity. For contrast only: a stream is unbounded, while a batch is always bounded.

var watermark = await control.GetLastSuccessAsync(jobName, ct);
var rows = await source.Orders
.Where(o => o.UpdatedAt > watermark)
.AsNoTracking()
.ToListAsync(ct);                 // استخراج تفاضلی
var clean = rows
.Where(o => o.Status == "Paid")
.Select(ToFactRow)
.ToList();                        // تبدیل
await warehouse.BulkInsertAsync(clean, batchSize: 5000, ct);
await control.SaveWatermarkAsync(jobName, rows.Max(o => o.UpdatedAt), ct);

تا اینجا با جزئیات فنی پردازش دسته‌ای آشنا شدیم: از تعریف و ذخیره‌سازی گرفته تا MapReduce و نحوهٔ ورود داده. حالا وقت آن است که ببینیم این مفاهیم در دنیای واقعی چگونه استفاده می‌شوند. فصل ۱۱ کتاب DDIA کاربردهای واقعی پردازش دسته‌ای را مرور می‌کند و ما آن‌ها را در چهار خانوادهٔ اصلی می‌بینیم. برای یک توسعه‌دهندهٔ بک‌اند، ETL آشناترین مورد است، اما بقیه نیز از همان الگوی کلی پیروی می‌کنند: ورودی بزرگ → خروجی مشتق‌شده. So far, we've learned the technical details of batch processing: from definition and storage to MapReduce and data ingestion. Now it's time to see how these concepts are used in the real world. Chapter 11 of DDIA reviews real-world batch use cases, which we group into four main families. For a backend developer, ETL is the most familiar, but the others follow the same general pattern: large input → derived output.

اگر پاسخی را نمی‌دانید، به همان بخش برگردید. هدف، حفظ‌کردن نام ابزارها نیست؛ باید بتوانید بگویید چرا یک کار دسته‌ای به ذخیره‌سازی و ریتم دیگری نیاز دارد.If you cannot answer one, return to that section. The goal is not tool names. You should be able to say why a batch job needs a different store and a different rhythm.