گزارش بهینه‌سازی: پارسرهای سنتی عامل اصلی کندی خط لوله داده‌ها هستند

اگر بودجه خود را صرف افزایش تعداد کلاستره تا رفع کندی خط‌لوله (Pipeline) داده‌ها می‌کنید، احتمالاً در حال حل مشکل اشتباهی هستید. در ۱۷ ژوئن ۲۰۲۶، وینیسیوس فگوندرس، مهندس ارشد داده، افشا کرد که چگونه زمان اجرای یک عملیات دسته‌ای شبانه را بدون تغییر در حتی یک الگوریتم، از ۸ ساعت به ۴۷ دقیقه کاهش داد.

به گزارش dev.to، این گلوگاه در بخش «هوشمند» سیستم نبود، بلکه در اولین مرحلهٔ خسته‌کننده قرار داشت: تجزیه (Parsing). تجزیه — که شبیه به باز کردن یک بستهٔ پیچیده برای بیرون کشیدن چند تکه ابزار است — فرآیند تبدیل متن‌های خام مثل JSON به اشیایی در حافظه است. در بسیاری از محیط‌های عملیاتی، این مرحله گران‌ترین بخش است و هر مرحلهٔ بعدی، «مالیات» این ناکارآمدی را پرداخت می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی زیرساخت‌های داده اشاره کردیم، مدیریت مرزهای ورود داده حیاتی‌تر از بهینه‌سازی کد است. این رویکرد بهینه‌سازی در لایه‌های زیرین، مشابه استراتژی‌های توزیع پردازش است که در بررسی معماری ابزارهای ToopTools و انتقال پردازش از سرور به مرورگر برای کاهش تأخیر و فشار روی زیرساخت مورد تحلیل قرار دادیم. فگوندرس پنج عامل اصلی تخریب سرعت را شناسایی کرد:

• تجزیه تکراری: خواندن چندین‌باره یک فایل در مراحل مختلف خط‌لوله.
• بیش‌از‌حد پردازش (Over-Hydration): تجزیه کل یک شیء تو در تو در حالی که تنها به سه میدان نیاز است؛ استفاده از orjson (یک تجزیه‌کننده مبتنی بر C) این مشکل را حل می‌کند.
• تورم حافظه: بارگذاری فایل‌های ۱۰ گیگابایتی در رم به‌جای استفاده از استریمینگ با ijson.
• استنتاج طرح‌واره (Schema Inference): اجازه دادن به Apache Spark برای اسکن مجدد و حدس زدن ساختار JSON به‌جای تعریف پیش‌فرض طرح‌واره.
• فرمت فایل: استفاده از JSON (سطر-محور) به‌جای فرمت‌های ستونی مثل Parquet.

تغییر فرمت از JSON به Parquet اثرگذارترین حرکت ممکن است. برخلاف JSON که برای دسترسی به یک میدان باید کل فایل تجزیه شود، Parquet داده‌ها را ستونی ذخیره می‌کند. این یعنی سیستم فقط ستون‌های مورد نیاز را می‌خواند و بخش‌های نامرتبط را نادیده می‌گیرد. این تغییر، گردش کار را از «هر خواننده باید دوباره کار را انجام دهد» به «کار یک‌بار در ورودی انجام می‌شود» تبدیل می‌کند.

برای متخصصان، اولویت باید از بهینه‌سازی الگوریتم به مدیریت مرزها تغییر کند. اگر تجزیه‌کننده اشتباه باشد، مدل شما تنها به سرعتِ داده‌های ناکارآمدی است که تغذیه می‌شود.

گام بعدی شما

• با استفاده از cProfile یا time.perf_counter() در پایتون، توابع کند خود را شناسایی کنید.
• بررسی کنید آیا در حال پرداخت «مالیات JSON» به‌صورت تکراری هستید یا خیر.
• پیش از ارتقای سخت‌افزاری کلاستره‌ها، فرمت ذخیره‌سازی داده‌های حجیم خود را به Parquet تغییر دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.