استدلال در مورد استریم در مقابل دسته با مطالعه موردی از GitHub

اگر فیلم‌ها را ترجیح می‌دهید، سخنرانی Zander در شورای داده 2023 را ببینید «چه زمانی باید از دسته‌ای به پخش جریانی رفت و چگونه آن را بدون استخدام یک تیم کاملاً جدید انجام داد».

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

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

درک زمان واقعی و پردازش جریان

Real-Time چیست؟ “زمان واقعی” به هر چیزی که توسط انسان تصور می شود در زمان واقعی اتفاق می افتد – یک تعریف کاملاً مبهم است. از نظر کمی، این معمولاً به فرآیندهایی اشاره دارد که در قلمرو فرعی اتفاق می‌افتند. جالب توجه است، بر اساس این تعریف، پردازش داده‌های بلادرنگ می‌تواند در واقع با فناوری‌های پردازش دسته‌ای و جریانی بسته به تأخیر انتها به انتها رخ دهد.

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

اکنون که تعاریفی از راه نداریم، بیایید به پردازش بلادرنگ و انواع مختلف بارهای کاری بلادرنگ بپردازیم.

ارتباط پردازش داده های زمان واقعی

در زندگی روزمره خود، ما دائماً اطلاعات را در زمان واقعی دریافت و پردازش می کنیم. رانندگی ماشین را در نظر بگیرید – فعالیتی که نیازمند پردازش ورودی های متعدد و تصمیم گیری در زمان واقعی است. اگر بخواهیم به شیوه ای پردازش دسته ای به رانندگی نزدیک شویم، منتظر جمع آوری اطلاعات برای مدتی باشیم و سپس سعی کنیم 15 ثانیه آینده را پیش بینی کنیم، احتمالاً به فاجعه ختم می شود. به عنوان مثال دیگر می توانید ورزشی مانند بسکتبال را تصور کنید. برای هر لحظه از زمان، بازیکنان ده ها یا صدها ورودی دریافت می کنند و در زمان واقعی به آنها واکنش نشان می دهند. اگر ما یک نسخه غیر واقعی از این را نیز تصور می‌کردیم، ممکن بود تماشا کردن یا بازی چندان هیجان‌انگیز نباشد زیرا هر بازیکن در حین دریافت ورودی به مدت معینی چند ثانیه منتظر ماند و سپس سعی کرد به آن ورودی‌ها واکنش نشان دهد.

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

انواع بارهای کاری بلادرنگ

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

حجم کار تحلیلی

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

نمونه دیگری از حجم کار تحلیلی بلادرنگ، سفارش Instacart است. هنگامی که سفارشی را در Instacart ثبت می کنید، می توانید به سفارش خود بروید و زمان تخمینی ورود (ETA) به روز شده را مشاهده کنید. این نمونه دیگری از حجم کاری بلادرنگ تحلیلی است که در آن کاربر در حال تعامل با داده های تحلیلی در زمان واقعی است.

حجم کار عملیاتی

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

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

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

تحلیلی در مقابل عملیاتی

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

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

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

مخازن پرطرفدار و توسعه دهندگان: یک رویکرد پردازش دسته ای

تیمی که من در GitHub عضوی از آن بودم، مسئول چندین محصول داده‌ای بود که در github.com نشان داده شد، از جمله مخازن پرطرفدار و توسعه‌دهندگان پرطرفدار. این ویژگی‌ها در صفحه GitHub Explore قرار داشتند و هدفشان شناسایی مخازن و توسعه‌دهندگان پرطرفدار بر اساس معیارهای مختلف، مانند ستاره‌ها، فورک‌ها و بازدیدها بود. ما از طریق یک پلتفرم استریم (کافکا) که توسط تیم دیگری مدیریت می‌شود، به صورت بلادرنگ به این داده‌ها دسترسی داشتیم.

اگرچه ما ظرفیت اجرای این ویژگی‌ها را به‌عنوان ویژگی‌های بلادرنگ داشتیم، اما در مقابل آن تصمیم گرفتیم. تیم ما عمدتاً متشکل از دانشمندان داده و مهندسان یادگیری ماشینی بود که قبلاً با پلتفرم‌های استریم یا پردازنده‌های استریم کار نکرده بودند. علاوه بر این، این ویژگی‌ها محصولات جدیدی بودند و ما نمی‌دانستیم که چقدر تأثیرگذار خواهند بود یا اینکه آیا کاربران آن‌ها را ارزشمند می‌دانند و مکرراً با آنها درگیر می‌شوند.

به جای پیاده سازی این ویژگی ها برای استفاده از داده های بلادرنگ، تصمیم گرفتیم این داده ها را در قالب دسته ای پردازش کنیم. ما درخواست‌های شبانه را علیه Presto اجرا می‌کردیم، جایی که داده‌ها از کافکا می‌آمدند، سپس داده‌های پردازش شده را در پایگاه داده MySQL برای بازیابی از github.com ذخیره می‌کردیم. این ویژگی ها بار کاری بلادرنگ نبودند، اما می توانستند باشند. اگر مشخص شود که آنها به عنوان محصولات داده بلادرنگ مفید خواهند بود، به عنوان نمونه های عالی از موارد استفاده تحلیلی عمل می کنند.

تشخیص هرزنامه ستاره: یک راه حل پردازش در زمان واقعی

کار دیگری که ما به عهده گرفتیم، شناسایی هرزنامه ستاره بود. مفهوم “ستاره” در مخازن GitHub به عنوان یک پروکسی برای سنجش سلامت و سودمندی پروژه استفاده می شود. اگر ما قادر به شناسایی هرزنامه‌های ستاره‌ای نباشیم، ارزش پلتفرم را برای کاربران کاهش می‌دهد و به طور بالقوه منجر به کاهش ارزش کلی پلتفرم می‌شود.

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

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

ارزش داده اغلب در طول زمان کاهش می‌یابد، و در حالی که معمولاً به صورت کاهش شدید نشان داده می‌شود (نمودار سمت چپ را ببینید)، بیشتر پروژه‌ها یا داده‌ها بیشتر از منحنی S (در سمت راست) پیروی می‌کنند. پس از یک نقطه خاص، بازده یا مقدار داده ها با توجه به تاخیر کاهش می یابد. در این مطالعات موردی، هیچ یک از پروژه‌ها با کاهش تأخیر، افزایش تصاعدی در بازده سرمایه‌گذاری نداشتند، و ما قادر بودیم با ارسال‌کنندگان هرزنامه ستاره‌ای به جای میلی‌ثانیه در یک بازه زمانی ساعتی مقابله کنیم. این نشان می دهد که همه پروژه های داده برای ارائه ارزش قابل توجه نیازی به حرکت به سمت تاخیر صفر ندارند.

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