تست عملکرد بیگ دیتا؛ Batch، Streaming و Spark

دو Pipeline هرکدام یک میلیارد رکورد را در ۴۰ دقیقه پردازش می‌کنند؛ آیا عملکردشان برابر است؟ شاید اولی ۹۹ درصد داده را در پنج دقیقه و یک Partition پرت را در ۳۵ دقیقهٔ بعد تمام کند، دومی پس از خرابی نتواند Backlog را جبران کند، یا هر دو نتیجه را سریع اما با رکوردهای تکراری منتشر کنند. عدد «مدت Job» بدون شکل داده، Freshness، صحت، هزینه و رفتار شکست، پاسخ قابل اتکایی نیست.

تست عملکرد بیگ دیتا یعنی اندازه‌گیری رفتار یک سامانهٔ توزیع‌شده زیر Workload تعریف‌شده و نسبت‌دادن نتیجه به نسخهٔ کد، داده، تنظیمات و زیرساخت مشخص. در این راهنما برای سه خانوادهٔ Batch، Streaming و Interactive Query، مدل بار، SLO، دادهٔ نماینده، متریک‌های Spark/Flink/Kafka، آزمون Skew و Backpressure، بازیابی از شکست، تحلیل هزینه و یک نمونهٔ تسویهٔ پرداخت ایرانی را قدم‌به‌قدم طراحی می‌کنیم.

تست عملکرد بیگ دیتا چه چیزی را می‌سنجد؟

هدف، پیدا کردن «حداکثر رکورد» یا گرفتن یک نمودار سبز نیست. باید بدانیم تحت چه حجم، نرخ، شکل داده، Query mix و Failure profile، سامانه هنوز خروجی درست را در Deadline یا Freshness هدف و با بودجهٔ پذیرفتنی تولید می‌کند. نتیجهٔ خوب یک Capacity envelope و Bottleneck evidence است، نه یک صفت مانند «سریع».

مرز این مقاله با سه موضوع نزدیک

• برای تعریف Load، Stress، Spike، Soak، p95/p99 و Open/Closed workload از راهنمای مبانی تست عملکرد شروع کنید.
• برای سند رسمی Scope، Entry/Exit، ایمنی و زمان‌بندی، مقالهٔ برنامه تست عملکرد را ببینید.
• برای Grain، Reconciliation، CDC، SCD و صحت Transform، راهنمای تست انبار داده و ETL مرجع داخلی مکمل است.

اینجا Intent تخصصی عملکرد Pipeline و موتور توزیع‌شده است. صحت همچنان Guardrail آزمون است، اما جای برنامهٔ کامل Data Quality را نمی‌گیرد.

بیگ دیتا فقط حجم زیاد نیست

رفتار سیستم به Record count تنها وابسته نیست. یک ترابایت در ده فایل بزرگ با همان یک ترابایت در ده میلیون فایل کوچک Workload یکسانی ندارد. Cardinality کلید Join، درصد Null، فشرده‌سازی، Schema width، Key skew، Window، Late data، Mutation، Partition layout و Locality می‌توانند هزینهٔ CPU، Memory، Network، Shuffle و Metadata را عوض کنند.

مرز End-to-End را رسم کنید

یک Pipeline معمولاً از Producer/Source، Broker یا Object storage، Ingest، Transform، State/Checkpoint، Sink/Table، Semantic layer و مصرف‌کنندهٔ Dashboard/API تشکیل شده است. Benchmark یک Operator فقط پاسخ عملکرد کل Journey را نمی‌دهد. برای هر آزمون روشن کنید Stopwatch از کجا شروع و کجا تمام می‌شود: تولید Event، پذیرش Broker، پردازش، Commit جدول یا قابل مشاهده‌شدن نتیجه برای تصمیم کسب‌وکار.

سه ضلع جدانشدنی

• Performance: Latency، Freshness، Throughput، Deadline، Recovery و Scalability؛
• Correctness: Completeness، Duplicate، Order، Window result، مبلغ/نوع و Atomic publish؛
• Cost: Compute، Memory، Storage، Network egress، API call و زمان اشغال Cluster.

اگر Pipeline با حذف Late event سریع‌تر شود یا با دوبرابرکردن منابع فقط ۵ درصد Throughput بیشتر دهد، «Pass عملکرد» بدون دو ضلع دیگر گمراه‌کننده است.

سه خانوادهٔ Workload: Batch، Streaming و Query

Batch: Deadline و توزیع مدت Stageها

برای Batch، ورودی محدود است و پایان Job معنا دارد. SLIها می‌توانند Makespan، زمان Queue/Schedule، مدت Stage/Task، Throughput منطقی، Shuffle/Spill، نرخ Retry، Straggler و Completion deadline باشند. فقط میانگین Task را نبینید؛ یک Partition پرت می‌تواند کل Job را نگه دارد. Cold cache و Warm cache را جدا گزارش کنید.

Streaming: Event time، Freshness و پایداری State

Streaming ورودی پایان‌ناپذیر دارد. سه زمان را جدا کنید:

• Event time: زمانی که رویداد در دامنه رخ داده است؛
• Ingest time: زمانی که Source/Broker آن را پذیرفته است؛
• Processing/Availability time: زمانی که پردازش یا خروجی قابل مصرف شده است.

Freshness معمولاً Availability time منهای Event time است، اما Definition باید Clock source، Replayed event و Late policy را روشن کند. راهنمای Apache Beam Window، Trigger، Watermark و Allowed lateness را جدا می‌کند؛ Watermark یک برآورد پیشرفت است، نه اثبات اینکه هرگز Event قدیمی‌تری نمی‌آید.

Interactive Query: Tail latency و Concurrency mix

Dashboard یا SQL endpoint باید با Query mix نماینده سنجیده شود: Query کوتاه/سنگین، Filter انتخابی/غیرانتخابی، Cache hit/miss، Tenant کوچک/بزرگ، Concurrency، Think time و Export. p50 تجربهٔ معمول و p95/p99 دنباله را نشان می‌دهند. خطاهای سریع را از Latency موفق جدا کنید و Goodput—نتیجهٔ صحیح درون SLO—را گزارش دهید.

سامانهٔ Hybrid را به یک عدد تقلیل ندهید

ممکن است Ingest Streaming باشد، Compaction به‌صورت Batch انجام شود و مصرف‌کننده Query تعاملی داشته باشد. هر کلاس SLO و بار خودش را دارد و بر دیگری اثر می‌گذارد. مثلاً Compaction شبانه می‌تواند I/O را اشباع و p99 Dashboard را خراب کند؛ آزمون Isolated و Concurrent هر دو لازم‌اند.

SLI و SLO قابل اجرا بسازید

راهنمای SLO گوگل SRE بر تعریف دقیق Indicator و استفاده از Percentile برای دیدن Tail تأکید دارد. عبارت «Latency کمتر از دو دقیقه» ناقص است؛ باید Population، Window، نقطهٔ اندازه‌گیری، Outcome و استثنا را مشخص کنید.

نمونه‌های دقیق

• Batch: ۹۹ درصد Runهای روزانه با Dataset تعریف‌شده تا ساعت ۰۵:۳۰ تمام شوند و هیچ Partition ناقصی Publish نشود.
• Streaming: طی Burst پانزده‌دقیقه‌ای، p95 فاصلهٔ Event time تا قابل Query شدن حداکثر ۱۲۰ ثانیه باشد؛ Eventهای مجازِ دیررس جدا سنجیده شوند.
• Query: ۹۵ درصد Queryهای کلاس A در Concurrency=۲۰ و Dataset version X زیر سه ثانیه، با Error rate کمتر از ۰٫۱ درصد پاسخ درست دهند.
• Recovery: پس از از دست‌رفتن یک Worker در بار پایدار، پردازش بدون Duplicate مالی بازیابی و Backlog در ۲۰ دقیقه تخلیه شود.
• Cost: هزینهٔ منتسب به پردازش هر ترابایت منطقی از سقف بودجه فراتر نرود، با Region و مدل قیمت ثبت‌شده.

چهار فرمول مفید

• Throughput = valid logical records processed / elapsed time
• Freshness = output-available timestamp - event timestamp
• Backlog drain rate = processing rate - arrival rate؛ اگر پایداراً مثبت نباشد، Catch-up رخ نمی‌دهد.
• Relative scaling efficiency = (throughput_n / throughput_base) / (resources_n / resources_base)

Logical و Physical bytes را مخلوط نکنید؛ Compression می‌تواند آن‌ها را بسیار متفاوت کند. Scaling efficiency نیز فقط برای Workload ثابت و بازهٔ مقایسه‌شده معنا دارد و هدف جهانی ۱۰۰ درصد نیست.

Guardrailهای هر SLO

همراه زمان، Count/Checksum/Reconciliation، Duplicate، Late/drop، Error، Retry و Cost را بگیرید. برای Approximate query، Error bound و Seed/algorithm version را ثبت کنید. Pipeline سریع با خروجی ناقص یا stale، SLO کسب‌وکار را برآورده نکرده است.

مدل Workload قبل از تولید بار

قرارداد Dataset

مدل ورود داده

Baseline، Peak، Burst، رشد فصلی و Replay را از هم جدا کنید. Generator باید Event-time و Wall-clock را کنترل و نرخ واقعیِ پذیرفته‌شده را اندازه بگیرد؛ نرخ تنظیم‌شده تضمین نمی‌کند بار به SUT رسیده است. برای Streaming، Partition/key distribution و Producer acknowledgment نیز بخشی از مدل‌اند.

Query و Job mix

درصد هر کلاس، پارامترها، Tenant، Concurrency، Think time، زمان‌بندی و هم‌پوشانی Jobها را تعریف کنید. اجرای یک Query محبوب به‌تنهایی اثر Queue، Resource pool، Cache eviction و Noisy neighbor را نشان نمی‌دهد. Production trace می‌تواند مدل بدهد، اما PII و Bias نمونه باید مدیریت شود.

دادهٔ مصنوعیِ نماینده، نه فقط حجیم

Generator را از یک Data Specification بسازید: Seed، نسخه، Invariant، Distribution و Correlation. دادهٔ یکنواخت معمولاً Hot key و Straggler واقعی را حذف می‌کند. روش‌های ساخت Dataset نسخه‌دار در راهنمای تولید داده تست آمده است. استفاده از دادهٔ Production باید حداقل‌سازی، مجوز، Mask/Anonymization معتبر، Retention و ریسک بازشناسایی داشته باشد؛ راهنمای TDM مرز این روش‌ها را توضیح می‌دهد.

Performance Run Manifest

Run: ID، زمان، مالک و هدف
Code: Git SHA، Artifact و Query/Job version
Engine: Spark/Flink/Kafka و Connector version
Config: Runtime flags، Parallelism، Partition و Autoscaling bounds
Infra: Region/zone، node/CPU/RAM/disk/network و shared services
Data: Dataset version/seed/shape/layout
Load: rates، mix، duration، warm-up و fault schedule
Observability: dashboard/trace/log IDs و clock sync
Cost: price snapshot و allocation rule

محیط آزمون و امکان تعمیم نتیجه

Fit-for-purpose مهم‌تر از «کاملاً شبیه Production» است

برای هر سؤال، Fidelity لازم را مشخص کنید. Microbenchmark محلی برای مقایسهٔ دو Serializer کافی است؛ Capacity و Network/Shuffle به Cluster نماینده نیاز دارد؛ Recovery به topology و storage durability نزدیک‌تر احتیاج دارد. Manifest محیط، Drift و Health gate را با روش مدیریت محیط تست کنترل کنید.

از Cluster کوچک خطی برون‌یابی نکنید

Cache، Scheduler، Network bisection، Metadata service، Object-store request limits، Shuffle و Autoscaling رفتار غیرخطی دارند. اگر Scale-down لازم است، نسبت‌های مهم مانند bytes per core، key skew، file count per partition، state per task و source partitions را حفظ و Limit استنتاج را صریح کنید. یک تست تأییدی در مقیاس بالاتر برای Knee ظرفیت لازم است.

نویز را ثبت و کنترل کنید

Workload همسایه، Spot interruption، background compaction، JVM warm-up، cache، autoscaling delay و Cloud throttling نتیجه را عوض می‌کنند. Runها را تکرار، ترتیب A/B را در صورت امکان جابه‌جا، Warm/Cold را جدا و Distribution را گزارش کنید. حذف Run «بد» فقط با علت از پیش تعریف‌شده مجاز باشد.

انواع تست عملکرد بیگ دیتا

Baseline و Regression

با Workload کوچک اما ثابت، نسخهٔ کد/Query/Engine را مقایسه کنید. Plan، input size و correctness باید ثابت یا Delta آن ثبت شود. Threshold مطلق کوچک در CI می‌تواند به نویز حساس باشد؛ از Repeat، Control workload و Trend استفاده کنید.

Load و Capacity curve

نرخ، داده یا Concurrency را پله‌ای زیاد کنید و برای هر پله Goodput، Tail latency، Lag، Saturation و Cost را بگیرید. Capacity فقط جایی نیست که سیستم Crash می‌کند؛ Knee جایی است که Lag/Latency سریع‌تر رشد می‌کند، Queue پایدار نمی‌شود یا Cost efficiency افت می‌کند.

Stress، Spike و Backlog recovery

Stress مرز و Degradation را می‌سنجد؛ Spike جهش ناگهانی را؛ Backlog test توان جبران پس از افت ظرفیت را. Stop condition برای Data corruption، هزینه، سرویس مشترک و مدت Recovery داشته باشید. در Streaming، کاهش Arrival پس از Spike بخشی از آزمون است؛ فقط Peak را قطع و نمودار را نبندید.

Volume، Shape و Layout

یک بعد را در هر Experiment تغییر دهید: bytes/records، File count، key cardinality، skew، compression یا partition count. این کار مشخص می‌کند مشکل از حجم است یا شکل. Volume test با User concurrency یکسان نیست.

Soak و رشد State

برای Memory leak، State-store growth، checkpoint size/duration، compaction debt، file proliferation، connection leak و GC degradation مدت کافی اجرا کنید. Duration باید از چرخهٔ مورد انتظار مسئله بیاید—مثلاً چند دور Checkpoint و Compaction—نه عدد ثابت «هشت ساعت».

Scalability و Elasticity

Scale-up/out و Scale-down را جدا کنید. Throughput، Latency، Cost و Migration/Rebalance delay را در چند اندازه بگیرید. Autoscaler ممکن است SLO را بعد از Delay بازیابی کند اما هزینه یا Duplicate بسازد. Scaling efficiency را روی Curve گزارش کنید، نه یک Percentage بازاریابی.

Failure و Recovery زیر بار

از دست‌رفتن Worker/Executor، Broker rebalance، Slow storage، network delay، checkpoint failure، Driver/JobManager restart، Sink timeout-after-commit و partial region dependency را در Scope مجاز بیازمایید. معیارها: زمان تشخیص، افت Goodput، Duplicate/loss، Restore duration، Backlog peak/drain و بازگشت به SLO. مستند Checkpointهای Flink توضیح می‌دهد Snapshot حالت و position چگونه برای Recovery استفاده می‌شود؛ وجود Checkpoint به‌تنهایی موفقیت End-to-End sink را ثابت نمی‌کند.

Benchmark و مقایسهٔ معماری

Benchmark تکرارپذیر برای مقایسهٔ Component/Configuration مفید است؛ Load test رفتار Workload خودتان را می‌سنجد. اگر نام یا نتیجهٔ TPC را منتشر می‌کنید، قواعد Disclosure و مقایسه را رعایت کنید؛ راهنمای Fair Use بنچمارک‌های TPC استفاده از Metricهای رسمی را برای نتیجهٔ غیررسمی محدود می‌کند. عبارت «TPC-like» بدون مشخص‌کردن تفاوت، اعتبار ایجاد نمی‌کند.

متریک‌های لازم برای تشخیص، نه فقط Dashboard

متریک در پنج لایه

Spark: Stage و Task distribution را بخوانید

مستند Monitoring اسپارک متریک‌هایی مانند Executor runtime/CPU، GC، Memory/Disk spill، Input/Output و Shuffle read/write/fetch wait را ارائه می‌کند. Median و Max/P95 Task duration و input bytes را مقایسه کنید تا Skew و Straggler دیده شود. Plan و SQL execution را نیز ذخیره کنید؛ راهنمای Performance Tuning اسپارک SQL نقش Statistics، Partition، Join و Adaptive Query Execution را شرح می‌دهد. Config پیشنهادی را کورکورانه به نسخه یا Workload دیگر منتقل نکنید.

Flink: Backpressure، Busy/Idle و Checkpoint

در Streaming، Source lag می‌تواند معلول Sink کند باشد. راهنمای Backpressure فلینک busy، idle و backPressured time را در سطح Subtask جدا می‌کند. Checkpoint duration، alignment/start delay، size، failure و restore را کنار End-to-End freshness ببینید؛ سریع‌ترکردن Checkpoint لزوماً علت Backpressure را رفع نمی‌کند.

Kafka: Lag را با نرخ و زمان ترکیب کنید

مستند Monitoring کافکا Message/byte rate، request time و consumer records-lag-max را از سیگنال‌های مهم می‌داند. Lag بر حسب Record بدون اندازه، نرخ و سن Partition ممکن است گمراه‌کننده باشد. Zero lag نیز Performance کل Pipeline را ثابت نمی‌کند؛ Consumer شاید سریع بخواند اما Sink یا Read model دیر Publish شود.

Run ID و Correlation

هر بار تست را در Generator، Broker header، Job tag، Output partition و Dashboard علامت بزنید. Clockها را همگام و بازهٔ Warm-up/Fault/Cool-down را Annotation کنید. بدون ارتباط نسخه و Run، هم‌زمانی CPU spike با Job فقط همبستگی است.

روش تشخیص گلوگاه

1. ابتدا SLO شکست‌خورده و Window دقیق را مشخص کنید.
2. تقاضای واقعی رسیده به SUT را با Generator intent مقایسه کنید.
3. مسیر را از Source تا Sink دنبال و اولین نقطهٔ رشد Queue/Lag را پیدا کنید.
4. توزیع Task/Partition را ببینید؛ Average می‌تواند Hot key را پنهان کند.
5. Resource saturation و زمان انتظار را با همان بازه مرتبط کنید.
6. یک Hypothesis بسازید و فقط یک عامل مهم را تغییر دهید.
7. Correctness و Cost را در Retest دوباره بسنجید؛ بهبود محلی ممکن است هزینه را جابه‌جا کند.

ابزار را بر اساس لایه انتخاب کنید

چهار خانوادهٔ ابزار

• Generator/Driver: Producer یا API load generator که Shape، Rate، Key و timestamp را کنترل می‌کند؛
• Workload/Benchmark: Query/job suite نسخه‌دار برای مقایسهٔ Engine یا Config؛
• Native diagnostics: Spark UI/History، Flink Web UI، Kafka metrics و Query plan؛
• Observability/Profile: Metrics، log، trace، profiler، cost و infrastructure telemetry.

JMeter، k6 یا Gatling برای API/ingest edge مفیدند، اما DAG، Shuffle، State یا correctness داخل Pipeline را خودکار پوشش نمی‌دهند. Prometheus/Grafana نمودار می‌سازند، نه Workload و Oracle. ابزار تخصصی بدون Run Manifest نیز نتیجهٔ قابل مقایسه تولید نمی‌کند.

PoC انتخاب ابزار

یک Golden workload کوچک با نرخ و Shape معلوم اجرا کنید. بررسی کنید Generator واقعاً نرخ هدف را می‌رساند، Backpressure خودش را SUT جا نمی‌زند، timestamp و key distribution درست‌اند، خطای ارسال گم نمی‌شود و خروجی ماشین‌خوان/قابل نسخه‌گذاری است. هزینهٔ نگهداری، Self-host، Artifact/PII، محدودیت تحریم/دسترسی و Export داده را نیز ارزیابی کنید.

ابر هزینه را حذف نمی‌کند

محیط On-demand هزینهٔ ثابت را کم می‌کند ولی Autoscaling delay، Quota، egress، shared-service throttling و price variability می‌آورد. Performance Efficiency در AWS Well-Architected رویکرد داده‌محور و Load testing را توصیه می‌کند؛ اصل قابل انتقال این است که انتخاب معماری و منبع را با Evidence Workload خودتان بسنجید، نه اینکه یک Cloud یا Instance همیشه بهتر فرض شود.

مثال: Pipeline تسویهٔ پرداخت ایرانی

این سناریو تخیلی است. فروشگاه رویدادهای Order، Payment callback، Refund و Settlement را از Kafka می‌خواند، Stream را به جدول وضعیت نزدیک‌به‌لحظه می‌نویسد، شبانه Batch تطبیق PSP را اجرا می‌کند و Dashboard مالی Query تعاملی دارد.

ریسک‌ها و Invariantها

• هر PSP reference برای هر Operation دقیقاً یک اثر مالی معتبر داشته باشد؛
• مبلغ Canonical بر حسب ریال باشد و تومان/ریال یا ارقام فارسی/عربی/لاتین باعث Split key نشود؛
• Callback دیررس و Out-of-order در Window/State تعریف‌شده جذب یا به DLQ قابل پیگیری برود؛
• تاریخ کسب‌وکار تهران با Event time UTC اشتباه Partition نشود؛
• Dashboard سریع اما Stale، «تسویه‌شده» را پیش از Ledger نشان ندهد.

Workload نسخه‌دار

• Baseline: نرخ پایدار ۳٬۰۰۰ Event/s؛ Burst: ۱۰٬۰۰۰ Event/s برای ۱۵ دقیقه؛
• ۲۰ درصد Merchantها، ۶۵ درصد Eventها را تولید می‌کنند تا Skew واقعی‌نما باشد؛
• ۲ درصد Event تا ۳۰ دقیقه دیر و ۰٫۲ درصد Duplicate با همان Event ID وارد می‌شوند؛
• Dataset تحلیلی ۹۰ روزه، ۲ ترابایت Logical و ترکیب File/Partition ثبت‌شده دارد؛
• Query mix: خلاصه روزانه ۶۰٪، جست‌وجوی Merchant ۳۰٪ و Drill-down سنگین ۱۰٪ در Concurrency=۲۰؛
• تمام اعداد نمونه و غیرتولیدی‌اند و باید با Baseline واقعی سازمان جایگزین شوند.

SLO و Guardrail

• در Burst، p95 Freshness خروجی Stream ≤ ۱۲۰ ثانیه و p99 ≤ ۵ دقیقه؛
• بعد از بازگشت نرخ به Baseline، Backlog حداکثر در ۲۰ دقیقه تخلیه شود؛
• Batch تطبیق تا ۰۵:۳۰ تمام و Partition به‌صورت Atomic Publish شود؛
• p95 Query کلاس عادی ≤ ۳ ثانیه و Error rate < ۰٫۱٪؛
• صفر Missing/Duplicate financial effect در Golden Ledger و Reconciliation؛
• Cost per logical TB در بودجهٔ مصوب، با قیمت و Region همان Run.

ترتیب Experimentها

1. Golden correctness روی Dataset کوچک و ثابت؛
2. Baseline با Warm/Cold cache جدا؛
3. Load پله‌ای برای رسم Curve نرخ، Freshness، Lag و Cost؛
4. Skew A/B با همان Volume و توزیع یکنواخت در برابر Merchant hot keys؛
5. Burst و سپس Catch-up؛
6. از دست‌رفتن Worker و Sink timeout-after-commit حین Burst؛
7. Soak شامل چند چرخهٔ Checkpoint/Compaction؛
8. Scale از N به 2N و بازگشت برای سنجش Elasticity و Rebalance.

نمونهٔ تشخیص

در Burst، Kafka lag بالا می‌رود اما CPU متوسط ۴۵ درصد است. Average CPU نتیجه نمی‌دهد. Subtask distribution نشان می‌دهد دو Partition با Merchantهای پرت ۹۵ درصد Busy و upstream Backpressured است؛ Checkpoint alignment نیز بالا رفته. A/B با Salt کنترل‌شده و همان Dataset، p95 Freshness را بهتر می‌کند ولی Shuffle bytes و Cost را افزایش می‌دهد. تصمیم باید بین SLO، correctnessِ Grouping، پیچیدگی و بودجه گرفته شود؛ «CPU آزاد بود، پس Node اضافه کنیم» تشخیص نیست.

Oracle صحت زیر بار

قبل و بعد Run، Count، Sum ریالی، مجموعهٔ Business key، Duplicate و وضعیت هر Window/Partition را با Golden Ledger و Source cut مقایسه کنید. Eventهای Late/DLQ/Quarantine باید مخرج مشخص داشته باشند. Performance result فقط وقتی معتبر است که همان Run از Guardrail صحت عبور کند.

اجرای قابل تکرار و تحلیل آماری مسئولانه

Warm-up، تکرار و Window

JIT، cache، autoscaling و connection pool Warm-up ایجاد می‌کنند. بازهٔ Warm-up را پیشاپیش تعریف و جدا کنید. هر سناریوی کوتاه را چندبار اجرا و Median/Percentile/Range را گزارش کنید؛ Run طولانی را به Windowهای معنی‌دار بشکنید. یک Run موفق Trend نیست.

مقایسهٔ A/B

Code، data، config، cluster، load و background activity را جز عامل مورد آزمایش ثابت نگه دارید. ترتیب اجرا را برای کاهش اثر زمان/Cache جابه‌جا و Control workload داشته باشید. تفاوت آماری بدون اثر عملیِ SLO یا Cost، دلیل Deployment نیست.

محدودیت و عدم قطعیت

اگر محیط کوچک‌تر، Storage مشترک یا Dataset مصنوعی است، Limit تعمیم را بنویسید. Result را با تعداد رقم بیش از دقت اندازه‌گیری ارائه نکنید. Timeout، Sampling، missing telemetry و Clock skew می‌توانند Percentile را منحرف کنند.

تست عملکرد بیگ دیتا در CI/CD

Feedback laneهای متناسب با هزینه

• Pull Request: Correctness، Plan/schema diff، Microbenchmark حساس و Budget کوتاه؛
• Nightly: Dataset متوسط، Query mix، Stage/task regression و Stream burst کوتاه؛
• Weekly/Capacity: Scale curve، Skew، Soak و Cost با محیط رزروشده؛
• Pre-release پرریسک: Workload نماینده، Failure/Recovery، full guardrails و تصمیم ظرفیت؛
• Production feedback: SLI واقعی و Drift داده برای به‌روزرسانی مدل، بدون اجرای مخرب خارج از مجوز.

همهٔ Testها را در هر Commit اجرا نکنید. نحوهٔ طراحی Lane و Gate در راهنمای Continuous Testing آمده است.

Quality Gate بدون نویز

Gate را به SLO و Guardrail وصل کنید: «p95 بیش از ۱۰ درصد نسبت به Baseline نسخه‌دار بدتر و از سقف سه ثانیه عبور کرده» از «Job پنج درصد کند شد» بهتر است. Inconclusive برای خرابی Generator/Telemetry/Environment داشته باشید؛ Failure زیرساخت را Pass نکنید. Baseline change نیازمند Review، دلیل و تاریخ است.

گزارش Performance که تصمیم می‌سازد

حداقل اجزا

1. Decision و سؤال ظرفیت/انتشار؛
2. Scope و Stopwatch boundary؛
3. Run Manifest کامل؛
4. Workload/Dataset shape و Generator validation؛
5. SLI/SLO، Window، Population و Guardrail؛
6. Timeline Warm-up/Load/Fault/Cool-down؛
7. نتایج Distribution/curve، نه فقط Average؛
8. Correctness و Cost همان Run؛
9. Bottleneck hypothesis با Evidence لایه‌ای؛
10. Limitها، ریسک باقیمانده و توصیهٔ قابل شرط.

زبان توصیه

بگویید: «برای Workload v3 و Cluster c5، تا ۷٬۵۰۰ Event/s همهٔ SLOها برقرارند؛ در ۱۰٬۰۰۰ Event/s Hot-key partitions باعث شکست p95 Freshness می‌شوند. گزینهٔ Salt، SLO را برمی‌گرداند اما Cost/TB را ۱۸ درصد افزایش می‌دهد. نتیجه به Distribution ثبت‌شده و Region آزمون محدود است.» این جمله از «سیستم تا ۱۰ هزار رکورد مقیاس‌پذیر است» قابل تصمیم‌تر است.

متریک را بازی‌ناپذیر کنید

مخرج، واحد، Clock، Aggregation window، Success criteria و Data source هر متریک را ثبت کنید. Throughput بالا با Drop، Error یا خارج‌کردن Slow record ارزش ندارد. راهنمای متریک‌های تست نرم‌افزار برای طراحی Data contract متریک و Guardrail مفید است.

چک‌لیست اجرای تست عملکرد بیگ دیتا

• Batch، Streaming، Query و Stopwatch boundary جدا تعریف شده‌اند.
• Dataset فقط حجم ندارد؛ Schema، File count، Skew، Cardinality، Time و Mutation دارد.
• Arrival/Query mix، Burst، Growth و Concurrency از Evidence آمده‌اند.
• Artifact، Engine، Connector، Config، Cluster، Region و قیمت Pin شده‌اند.
• Generator rate/shape و Clock sync مستقل اعتبارسنجی شده‌اند.
• SLO شامل Population، Percentile، Window و Guardrail صحت/هزینه است.
• Warm/Cold، Warm-up، Repeat و نویز محیط ثبت شده‌اند.
• Source، queue، operator، state/data movement و resource telemetry همبسته‌اند.
• Skew، Small files، Late/out-of-order، Retry و Failure/Recovery پوشش دارند.
• Backlog پس از Peak/Fault تا بازگشت به SLO اندازه‌گیری شده است.
• Count/Sum/Key/Duplicate و Atomic publish همان Run تأیید شده‌اند.
• گزارش Capacity curve، Cost، Limit و گزینهٔ تصمیم دارد.

دوازده ضدالگو

• تعریف بیگ دیتا فقط با Record count یا TB؛
• گزارش Average duration و پنهان‌کردن Tail/Straggler؛
• تولید دادهٔ یکنواخت و نتیجه‌گیری دربارهٔ Join/Partition واقعی؛
• برون‌یابی خطی از Laptop یا Cluster کوچک؛
• یکی‌گرفتن Kafka lag، Watermark، Freshness و End-to-End latency؛
• افزایش Node پیش از پیدا کردن Queue یا Partition محدودکننده؛
• پذیرفتن سرعت با Drop، Duplicate یا Late-data loss؛
• اجرای Benchmark عمومی و ادعای ظرفیت Workload سازمان؛
• استفاده از Production PII برای «واقع‌گرایی» بدون کنترل؛
• نادیده‌گرفتن Cost و Autoscaling delay در Cloud؛
• تغییر هم‌زمان Code، Config، Data و Cluster در A/B؛
• بستن تست در Peak بدون اندازه‌گیری Catch-up و Recovery.

برنامهٔ ۳۰روزه

هفتهٔ اول: Contract و مشاهده‌پذیری

یک Journey داده انتخاب، Boundary را رسم و سه SLO با Guardrail تعریف کنید. Run Manifest و Dashboard پنج‌لایه بسازید. Golden dataset کوچک و Reconciliation را آماده کنید.

هفتهٔ دوم: Baseline و Shape

Dataset specification، Generator validation و Baseline تکرارشونده اجرا کنید. یک A/B فقط برای Skew یا File count انجام دهید. Warm/Cold و نویز را ثبت کنید.

هفتهٔ سوم: Curve و Failure

Load پله‌ای، Burst/Catch-up و یک Failure مجاز اجرا کنید. اولین Queue، Straggler و Saturation را با Run ID مرتبط کنید. Cost همان Run را تخصیص دهید.

هفتهٔ چهارم: Gate و تصمیم

یک Lane کوتاه Regression به CI و یک Capacity lane زمان‌بندی‌شده بسازید. Baseline policy، Inconclusive state و Report template را تصویب کنید. نتیجه را Adopt/Adapt/Stop کنید، نه اینکه صرفاً ابزار دیگری اضافه شود.

سؤالات متداول

جمع‌بندی

تست عملکرد بیگ دیتا با «دادهٔ خیلی زیاد + ابزار بار» ساخته نمی‌شود. باید Journey و Stopwatch را تعریف کنید، Workload shape و Run Manifest نسخه‌دار داشته باشید، SLO را برای Batch/Streaming/Query جدا بنویسید و Performance را همراه Correctness و Cost بسنجید. سپس با متریک‌های لایه‌ای، Curve ظرفیت، Skew، Backpressure، Failure و Catch-up، گلوگاه را به Evidence تبدیل کنید. نتیجهٔ قابل دفاع همیشه می‌گوید برای کدام نسخه، داده، زیرساخت و محدوده معتبر است.