جریان در مقابل داده‌های درون حافظه

مشکل واقعی با مقیاس بندی DataWeave

MuleSoft برای مدیریت یکپارچه‌سازی‌های سازمانی ساخته شده است – اما بیشتر توسعه‌دهندگان با بارهای کوچک آزمایش می‌کنند. همه چیز در Dev خوب به نظر می رسد تا اینکه یک روز یک فایل واقعی با 1 میلیون رکورد در جریان شما قرار می گیرد. ناگهان کارگر شما از بین می رود OutOfMemoryErrorو کار به نصف شکست می خورد.

حقیقت این است که DataWeave به طور پیش فرض در حافظه اجرا می شود. این برای مجموعه داده های کوچک قابل قبول است، اما در تولید اغلب با:

• بانکداری: صادرات روزانه تراکنش های ACH، گاهی صدها مگابایت.
• مراقبت های بهداشتی: اطلاعاتی را با میلیون ها ردیف و فیلدهای عمیق تو در تو ادعا می کند.
• تجارت خرده فروشی: کاتالوگ محصولات یا سیاهههای مربوط از هزاران فروشگاه.

اگر برای استریم طراحی نکنید، جریان شما در نهایت به دیوار برخورد می کند.

In Memory vs. Streaming – واقعاً چه اتفاقی می افتد؟

در حافظه (رفتار پیش فرض)

• Mule کل محموله را قبل از تبدیل در حافظه بارگذاری می کند.
• سریع وقتی که محموله کوچک است (
• پس از افزایش حجم فایل ها به صدها مگابایت یا گیگابایت، خراب می شود.

مثل باز کردن یک فایل اکسل بزرگ فکر کنید. با چند هزار ردیف خوب کار می کند، اما سعی کنید 2 میلیون را باز کنید و اکسل فریز می شود.

اگر فایلی 1 گیگابایت باشد، Mule سعی می کند آن 1 گیگابایت را به اضافه کپی تبدیل شده در حافظه نگه دارد. این یک دستور العمل برای فاجعه است.

جریان (روش مناسب برای داده های بزرگ)

• Mule رکورد فایل را به صورت رکورد (یا در تکه های کوچک) می خواند.
• هر رکورد قبل از رفتن به رکورد بعدی، تغییر شکل داده و کنار گذاشته می شود.
• استفاده از حافظه یکنواخت و قابل پیش بینی باقی می ماند.

به آن به عنوان یک خط لوله فکر کنید – سوابق وارد می شوند، پردازش می شوند و خارج می شوند. شما هرگز کل مجموعه داده را یکجا نگه نمی دارید.

%dw 2.0
output application/json
var file = readUrl("classpath://data.json", "application/json", {streaming:true})
---
file pluck ((value, key) -> {
  id: value.id,
  amount: value.amount
})

این رویکرد با خیال راحت به میلیون ها رکورد می رسد.

چرا به جای نقشه از Pluck استفاده کنیم؟

هر دو مجموعه‌های تبدیل را تبدیل و بازیابی می‌کنند، اما در نحوه مدیریت حافظه متفاوت هستند.

• نقشه – یک آرایه جدید با تمام نتایج در حافظه ایجاد می کند. اگر رکوردهای 1M دارید، Mule حاوی 1M شی تبدیل شده است.
• بیرون بکش – از طریق جفت های کلید-مقدار تکرار کنید و نتایج را با کارایی بیشتری ارسال کنید.

در عمل، Pluck برای مجموعه داده‌های عظیم CSV یا JSON گزینه امن‌تری است.

مقایسه عملکرد: 1.2 میلیون نوشتن در 0.2 vCore Worker

در حافظه

• استفاده از حافظه: مقیاس با اندازه فایل، اوج در نزدیکی مرزهای پشته.
• سرعت پردازش: ~ 8-10 دقیقه.
• نکات: مستعد تصادف با محموله های بزرگ.

پخش جریانی (جریان: درست)

• میزان استفاده از حافظه: مسطح، ~ 300 مگابایت پایدار.
• سرعت پردازش: 10-12 دقیقه.
• نکات: پایدار، بدون خرابی.

غذای آماده

حافظه داخلی در مقیاس کوچک سریعتر به نظر می رسد، اما پخش جریانی در تولید واقعی برنده است، زیرا پایداری همیشه بر دستاوردهای عملکرد کوچک برتری دارد.

مورد واقعی: پردازش تراکنش های ACH

در یک اتحادیه اعتباری، ما روزانه 1.2 میلیون تراکنش ACH را از یک سیستم اصلی Symitar پردازش کردیم.

• در حافظه: 0.2 vCore worker (500MB heap) در وسط خراب شد.
• پخش جریانی: همان کارگر کل مجموعه داده را بدون مشکل پردازش کرد.

%dw 2.0
output application/json
var file = readUrl("classpath://ACH_Transactions.csv", "application/csv", {streaming:true})
---
file pluck ((txn, i) -> {
    transactionId: txn.txnId,
    amount: txn.amount,
    date: (txn.date as Date {format: "MM/dd/yyyy"}) as String
})

این به راحتی در تولید اجرا شد – بدون خطای پشته، بدون راه اندازی مجدد فایل کاری.

خطاهای رایجی که جریان را خراب می کند

حتی توسعه دهندگان باتجربه گاهی اوقات پخش جریانی را ناخواسته غیرفعال می کنند:

• تخصیص بار به یک متغیر (var bigData = payload) به ذخیره سازی در حافظه نیاز دارد.
• استفاده از نقشه به جای چیدن برای مجموعه های بزرگ.
• ما فراموش می کنیم که با داده های مقیاس تولید آزمایش کنیم و فقط به نمونه های ردیفی 1k تکیه می کنیم.
• تودرتو عمیق را در تبدیل‌ها بدون فیلترهای اولیه اضافه کنید، که استفاده از حافظه را چند برابر می‌کند.

اجتناب از این اشتباهات می تواند ساعت ها در رفع اشکال صرفه جویی کند و از توقف پرهزینه تولید جلوگیری کند.

چرا برای مشاغل مهم است

در مقیاس سازمانی، خطاهای حافظه فقط یک سردرد فنی نیستند، بلکه به خطرات تجاری تبدیل می شوند.

در بانکداری، یک دسته شکست خورده ACH می تواند پرداخت حقوق و دستمزد هزاران کارمند را به تاخیر بیندازد. در مراقبت های بهداشتی، پرونده ادعاهای رد شده می تواند بازپرداخت هزینه ها را برای بیمارستان ها متوقف کند. هر بار تلاش مجدد نه تنها زمان را می سوزاند، بلکه منابع محاسباتی را نیز هدر می دهد و هزینه های CloudHub را افزایش می دهد.

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

نکات تنظیم عملکرد برای مجموعه داده های بزرگ

استریمینگ به تنهایی یک گلوله نقره ای نیست. برای استفاده حداکثری از آن:

• کارگران با اندازه مناسب: 0.2 vCore می‌تواند میلیون‌ها ردیف را با جریان پردازش کند، اما پیوستن‌های پیچیده ممکن است به 1 هسته مجازی نیاز داشته باشند.
• زودتر فیلتر کنید: قبل از تبدیل های گران قیمت، مجموعه داده ها را از قبل کوچک کنید.
• در صورت امکان گروه کنید: فایل های بسیار بزرگ را برای موازی سازی به قسمت های کوچکتر تقسیم کنید.
• از چک‌این هوشمند استفاده کنید: برای جلوگیری از نفخ دیسک، نمونه ها را ضبط کنید، نه هر رکورد.
• تنظیمات مبتنی بر ویژگی: برای جلوگیری از لغو تصادفی، {streaming: true} را پارامتر کنید.
• تست خودکار: آزمایش‌های عملکرد با بارهای بزرگ را در خطوط لوله CI/CD اضافه کنید تا مشکلات مقیاس‌پذیری را زود تشخیص دهید.

محافظت از آینده با معماری های رویداد محور

پخش جریانی کاملاً با مدل‌های رویداد محور مدرن مطابقت دارد. چه MuleSoft از Kafka، Azure Event Hub یا AWS Kinesis مصرف کند، اصل یکسان است: همه چیز را در حافظه بارگذاری نکنید.

از آنجایی که سازمان‌ها از تجزیه و تحلیل بلادرنگ و فیدهای داده استقبال می‌کنند، قابلیت‌های استریم MuleSoft در حال تبدیل شدن به پلی بین فایل‌های تخت دسته‌گرا و سیستم‌های رویداد محور است. ساخت و ساز با پخش جریانی امروز زمینه را برای ادغام سازمانی بلادرنگ فردا فراهم می کند.

تکمیل

DataWeave MuleSoft قدرتمند است، اما حالت پیش‌فرض درون حافظه آن برای آرایه‌های رکورد 1M+ طراحی نشده است. برای ایجاد جریان های پایدار و آماده برای تولید:

• فعال سازی جریان برای فایل های حجیم
• من ترجیح می دهم بیرون بکش تمام نقشه.
• از نگه داشتن محموله ها در متغیرها خودداری کنید.
• با مجموعه داده های دنیای واقعی تست کنید، نه فقط با نمونه های توسعه.

این یک انتخاب طراحی کوچک است که بین جریانی که در تولید ناموفق است و جریانی که بدون زحمت به میلیون ها رکورد در هر روز می رسد، تفاوت ایجاد می کند.