Cheat Sheet

برای استفاده سریع و ساده از رکامندر یک راهنمای سریع درست کردیم. میتونید از اینجا دریافت کنید.

Screen Shot 2016-06-13 at 11.33.54 AM

 

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

مثال‌هایی از کاربرد متد‌ها و توضیحات هم ارائه شده. اگر کم و کسری داره بگین لطفا.

آدرس دانلود فایل: http://recommender.ir/download/recommender.ir_v2.5_cheat_sheet.pdf

پیشنهاد‌های مبتنی بر مکان

 

locations

یکی از نیازهایی که کسب‌و‌کارهای گوناگون از recommender.ir می‌طلبیدند، در نظر گرفتن مکان کاربر در محاسبات بود. این نیاز بارها در دوره‌های مختلف مطرح شده بود. ولی پیاده‌سازی نیازهای ابتدایی‌تر فرصت پرداختن به این مقوله را سلب کرده بود.

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

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

 

LBR2.5

پیرو درخواست‌های منطقی و مکرری که از مشتریان دریافت کردیم، نسخه ۲.۵ recommender.ir را به توسعه راه‌حل در جهت تولید پیشنهاد‌های مبتنی بر مکان اختصاص دادیم.

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

هم چنین بر هر آیتم می‌توان تعدادی موقعیت مکانی (طول‌ و عرض جغرافیایی) منتسب کرد.

برای استفاده از مکانیزم‌های تولید پیشنهاد مبتنی بر مکان کافیست شعاع مورد نظر کاربر (یا پیش فرض) را در واحد کیلومتر وارد کرد. برای مثال radius=5 به حداکثر فاصله ۵ کیلومتری بین مکان‌های کاربر و نزدیکترین مکان آیتم است.

تصویر زیر مثال‌هایی از فراخوانی را نمایش می‌دهد (برای مشاهده جزئیات روی تصویر کلیک کنید):radiusیکی از دیگر فیچر‌های نسخه ۲.۵، نگهداری از اولویت‌های کاربر است. برای مثال کاربری که به رویداد‌های کارآفرینی علاقمند است، می‌تواند این علاقمندی را در پروفایل خود ست کند. با کامل‌تر شدن پروفایل کاربر، سیگنچر متد‌ها کوچکتر می‌شود. این به معنی فراخوانی راحت‌تر متد‌های ‌API است.

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

در طول تابستان فیچر‌هایی بسیار جذاب معرفی خواهیم کرد…

از بهبود پنل تا تولد هایپراسپیس

حدود ۱۰ روز پیش گفتگوی دوستانه‌ای با یکی از مشتریان سرویس‌مان داشتم. گفت داره پنل گرافیکی وب می‌نویسه برای recommender.ir . گفتم آفرین! حالا چرا می‌نویسی؟ گفت آخه پنل recommender.ir ناقصه! و درست می‌گفت.

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

panel2.4

در واقع به روز آوری و تکمیل پنل توی برنامه توسعه نسخه ۲.۴ نبود. ولی در آخرین روز‌هایی که ‌API آخرین تست‌هاش رو پشت سر می‌ذاشت، پنل رو به موازات کامل کردیم. تصویر بالا بخش‌های اصلی پنل نسخه ۲.۴ رو نشون میده.

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

 

با آماده شدن پنل و دریافت فیدبک از مشتریان، نیازمندی‌های پروژه بعدی ما یعنی ‌hyperspace شکل گرفت. هایپراسپیس یعنی چندبعدی یا ابرفضا. نام پروژه‌ایست که بناست بر روی رکامندر، کامنتوم و دیگر پروژه‌های‌ما و مشتری، مصورسازی داده‌‌ (Data Visualization) فراهم کنه. قصد داریم به نحوی نوشته بشه که دست برنامه نویس‌ها رو برای توسعه گراف‌ها و چارت‌های کسب و کار خودشون باز بذاره. بتونن گراف‌های تلفیقی توسعه بدن. بر خلاف دیگر سرویس‌ها ما، میتونه روی ماشین‌ اپراتور‌ها نصب شده و امکانات خوبی در تحلیل داده‌ها در اختیارشون قرار بذاره.

هایپراسپیس از بهترین فناوری‌های نمایش داده استفاده می‌کنه. در سمت بک‌اند، میکروسرویسز و اسپرینگ‌بوت، با قالب‌های ساده ‌Freemarker و در سمت کلاینت از d3.js و svg استفاده می‌کنیم. در حالی که تنها چند روز از شروعش نمی‌گذره خوب پیش رفته و به زودی قابل ارائه خواهد بود. اولین نسخه‌ رو به همراه نسخه  recommender.ir 2.5 در اختیار مشتریان مشتاق‌ قرار می‌دیم و نظرات طلایی اون‌ها رو در اصلاح و تکامل خدمت بکار می‌گیریم.

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

کسب‌وکارهای گوناگون نگاه خاص و ویژه خود را به مقوله تحلیل داده‌ها دارند. لذا هایپراسپیس اجازه می‌ده نمودار‌ها و نمایه‌هایی که ما در اختیارشون قرار می‌دیم با توجه به نیاز‌هاشون سفارشی کنند.

راهنمای سریع

راهنمای سریع recommender.ir
نسخه ۲.۴

ارسال داده‌ها
راه‌حل ما برای جلب رضایت کاربران، و افزایش راندمان کسب‌وکار شما، به داده‌هایی نیاز دارد. این داده‌ها به سه دسته زیر تقسیم می‌شوند:

۱. ویژگی‌های آیتم‌ها – توسط فراخوانی متد termItemAdd انجام می‌گیرد.

۲. رفتار کاربر – توسط فراخوانی متد ingest صورت می‌گیرد.

۳. ویژگی‌های کاربر – توسط فراخوانی متد setUserProfile صورت می‌گیرد. بدیهیست بخش بزرگی از کاربران به صورت ناشناس به سایت شما می‌آیند. کافیست تنها پروفایل تعداد اندکی که احراز هویت شده‌اند مشخص شود.

نیازی به رعایت ترتیب خاصی برای اجرای متد‌های فوق نیست.  برای مثال میتوانید ابتدا رفتار کاربران را ارسال کنید. سپس ویژگی‌های آیتم‌ها را کامل کنید و در نهایت به تکمیل پروفایل بخشی از کاربران بپردازید. یا می‌توانید ابتدا ویژگی‌های آیتم‌ها را ارسال کنید. سپس به رصد رفتار کاربر مشغول شوید. پس از مدت کوتاهی recommender.ir قادر به پاسخگویی به پرسش‌های شماست.
مهم: از بین سه متد یاد شده، بکارگیری متد ingest (ارسال رفتار کاربر) الزامی‌ است.

پرسش‌ها
recommender.ir به طیف متنوعی از پرسش‌ها پاسخ می‌دهد. این پرسش‌ها به گروه‌های زیر تقسیم می‌شوند:
– شناسایی محبوب‌ترین آیتم‌ها
ـ پیشنهاد برای کاربر یا گروهی از کاربران
– خوشه‌بندی آیتم‌ها بر اساس میزان شباهت
– خوشه بندی ویژگی‌ها بر اساس میزان شباهت
– محاسبه علاقه / عدم‌علاقه کاربر به آیتم‌ها
– شناسایی پرسونا (پروفایل) کاربر‌ ناشناس
– شتابدهی هوشمند به عرضه آیتم
– راهنمایی کاربر تازه‌وارد
– مرتب‌سازی اقلام جدید بر اساس علاقه کاربر‌تازه وارد

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

غلبه بر چالش‌های محتوای جدید / کاربر جدید

یکی از چالش‌هایی که رکامندر‌ها با اون مواجه هستند، مواجه با کاربران و آیتم‌های جدید است که ازش به شروع سرد نام می‌برن.

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

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

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

مزایا

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

 

تصویر شماتیک زیر کارکرد متد fastStart را نمایش می‌دهد:

estimateBasedOnRecentActions

 

مثالی از فراخوانی:

  • فرض کنید ‌آیتم های زیر را تازه در سایت خود معرفی کرده اید:
  • item83
  • item89
  • item90
  • item93

کاربری برای اولین بار به سایت آمده است. او به ترتیب به آيتم‌های item10 ،  item35  و  item21 علاقمندی نشان داده است (تنها سه کلیک) :

  • item10, 200
  • item35, 100
  • item21, 50

همین توالی کوتاه سه انتخابی، برای محاسبه میزان محبوبیت آيتم‌های جدید کافیست. روش فراخوانی متد را در زیر می‌بینید:

fastStart/item83,item89,item90,item93/item10,200/item35,100/item21,50

 

و نتیجه که بر اساس دنباله سه حرکتی روی آيتم‌های قدیمی تر محاسبه شده است:

[["item83",0.0693373],["item93",0.03374617],["item89",-0.029169414],["item90",-0.04337809]]

The Next Move

 

و برای کاربری با توالی متفاوت، نتایج متمایزی تولید‌ می‌شود:

fastStart/item83,item89,item90,item93/item15,40/item45,40/item21,120

[["item90",0.03488824],["item83",-0.025891062],["item93",-0.030702673],["item89",-0.064953186]]

 

حتی یک کلیک کافیست:

fastStart/item83,item89,item90,item93/item35,40

 

[["item93",0.04895537],["item83",-0.017683292],["item90",-0.025015056],["item89",-0.026147814]]

 

شناسایی همگرایی رفتار کاربر

نسخه ۲.۴ recommender.ir آخرین تست های خود را می‌گذراند و طبق برنامه تا چند روز دیگر در اختیار سرویس گیرندگان قرار می‌گیرد. مهمترین بهبودهای نسخه ۲.۴ عبارتند از:

  • تعریف محتوای آیتم، قبل دریافت داده توسط کاربران
  • تعریف دقیقتر دامنه نتایج در متدهای درگیر محتوا
  • تولید نتایج سورپزایزیگ در تمامی متدها

همچنین علاوه بر بهبود‌های فوق که بر روی تمام متد‌ها اعمال شده است، دو متد جدید نیز معرفی می‌کنیم:

  • متد اسپاتلایت (Spotlight)
  • متد اسپکترومتر (Spectrometer)

این دو متد فصلی جدید در تعالی تعامل کاربران آنلاین و سایت‌ها/اپلینکیشن‌ها می‌گشایند. در واقع با شناسایی آغاز همگرایی(Convergence) رفتار کاربر پیرامون آیتم‌ها یا پیرامون جزئیات محتوای آیتم‌ها، انگیزه‌های کاربر را شناسایی نموده و بر اساس تجریبات موفق قبلی، وی را راهنمایی می‌کنند.

 

اسپاتلایت (Spotlight)

با فراخوانی متد spotlight قادر به شناسایی آیتم‌های محوری مورد توجه کاربر هستید. این متد از تکنیک‌های پیشنهاد استفاده نمی‌کند. بلکه نتایج بر اساس شناسایی همگرایی نظر کاربر بر آيتم(ها) معین شکل می‌گیرد.

spotlight_small

مثال ۱:

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

 

مثال ۲:

کاربری به مشاهده سریال شهرزاد علاقمند است.

 

در مثال‌های ۱ و ۲،   recommender.ir با شناسایی همگرایی فعالیت‌های کاربر پیرامون آیتم‌هایی، قادر به راهنمایی کاربر توسط ارائه تجربیات موفق پیرامون آن آیتم است.

 

اسپکترومتر (Spectrometer)

اسپکترومتر نیز بر شناسایی توجه(Attention) کاربر تاکید دارد. ولی برخلاف spotlight که بر شناسایی همگرایی بر آیتم(ها) تاکید دارد، spectrometer بر همگرایی بر جزئیات محتوا(Content) تمرکز دارد.

jam 1.8

مثال ۳:

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

 

مثال ۴:

کاربری صرف نظر از ژانر و دیگر پارامتر‌ها، وسواس‌گونه فیلم‌های کلینت‌ایستوود را دنبال می‌کند.

 

در مثال‌های  recommender.ir با شناسایی همگرایی در سطح ویژگی‌ها و محتوای آیتم، کاربر را به سمت تجربیات موفق راهنمایی ‌می‌کند. در مثال ۳ با شناسایی ویژگی مورد نظر کاربر، فهرستی از آیتم‌های نزدیک به خواست وی، آماده می‌شود.

در مثال ۴ در حالی که وی از ژانری به ژانر دیگر می‌رود همگرایی در سطح بازیگر در حال شکل گیری‌ است. پس recommender.ir او را به سمت آیتم‌های جذاب و نزدیک به خواست وی، راهنمایی می‌کند.

 

مهم:

این دو متد تنها در صورت شناسایی همگرایی توجه کاربر بر آیتم‌ها یا ویژگی‌ها، قادر به تولید نتایج هستند. لذا در شرایط زیر پاسخی تولید نمی‌کنند:

  • کاربر تازه به سایت وارد شده است.
  • کاربر علاقه خاصی به آيتم یا ویژگی معینی نشان نداده است.

چشم‌انداز ۱۳۹۵

در حالی سال ۱۳۹۵ را آغاز می‌کنیم که سالی فشرده و پر بار را پشت سر گذاشتیم. پیدایش recommender.ir به سال ۱۳۹۲ باز می‌گردد،‌ ولی در سال ۱۳۹۴ به بلوغ کافی برای ارائه خدمت به بهترین‌های وب ایران رسیدیم.

برای سال ۱۳۹۵ برنامه‌ای ساده و دقیق تنظیم کرده‌ایم. ساده نه از نظر سادگی وظایفی که قراره به انجام برسونیم. بلکه از نظر سرفصل. برنامه ما شامل ارائه خدمت بهتر و پایدار تر به کاربران فعلی، و توسعه نسل سوم recommender.ir است.

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

در کنار recommender.ir به تکمیل commentum.ir نیز خواهیم پرداخت. ارزش‌ آفرینی در حوزه متن و ارائه خدمات متنی در قالب سرویسی کارامد و پایدار، مهمترین وظیفه کامنتوم است.

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

 

Nowruz RC

ارسال دسته‌ای داده‌ها

ما recommender.ir را برای ارائه خدمت به صورت بلادرنگ و آنلاین توسعه داده‌ایم. در حالی که بلادرنگ بودن مزیت خدمت ماست، در مواردی کسب و کارها نیازمند ارسال داده‌ها به صورت آفلاین بودند. یعنی نیازداشتند که بسته‌هایی از داده را به صورت دسته‌ای به recommender.ir ارسال کنند. برای این منظور امکان ارسال داده در قالب CSV  را پیاده سازی کردیم.

اکنون می‌تونید در میان درخواست‌های بلادرنگ از تک تک رفتار‌های کاربران، جریان‌هایی از رفتار کاربر را به صورت جریان CSV به recommender.ir بفرستید (تصویر زیر).

 

Bulk Insertion

 

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

مزایای ارسال دسته‌ای داده‌ها به شرح زیر است:

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

 

بررسی کارکرد‌های ‌recommender.ir

به همت کتابخانه حسینیه ارشاد،  نشستی پیرامون بررسی کارکرد‌های recommender.ir در روز چهارشنبه ۵ اسفند از ساعت ۱۶ الی ۱۸ برگزار می‌گردد. شرکت در نشست رایگان است. برای در دست داشتن تخمینی از تعداد شرکت‌کنندگان و پیش‌بینی فضا، لطفا ثبت‌نام کنید.

ershad_small

پردازش جریان‌‌های داده – قسمت اول

پیشگفتار

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

برخی چهار‌چوب‌ها و تکنیک‌هایی که در این پست می‌خوانید در توسعه recommender.ir و helio.ir استفاده شده اند. لذا برای آشنایی با برخی مکانیزم‌های داخلی یک پیشنهاد‌دهنده یا پردازشگر‌جریان داده، آگاهی از این مطالب خالی از لطف نیست.

تاریخچه

سرآغاز بسیاری از نوآوری‌های دنیای پردازش اطلاعات به یونیکس باز‌میگردد. با مراجعه به تاریخچه پر افتخار یونیکس1، در می‌یابیم، پردازش‌جریان‌داده، اساساً یک فناوری جدید نیست. توسعه مفهوم پایپلاین2 و یوتیلیتی‌ sed3 در یونیکس به قدمت نیاز به فناوری پردازش‌جریان داده در دنیای کامپیوتر اشاره دارند. برخورد کلاسیک و انتزاعی4 سیستم‌عاملهای شبه‌یونیکس5 با جریان داده، همچنان پرکاربرد است. یونیکس به فایل و جریان‌داده نگاهی یکسان دارد. این نگاه انتزاعی در سامانه‌های پیشرفته امروزی نیز همچنان راه‌گشاست.

با فراگیر شدن اینترنت، افزایش چشمگیر تعداد کاربران شبکه‌های اجتماعی، و تنوع محتوا، هنجارهای پردازش‌داده را تغییر داد. شبکه‌های اجتماعی محبوب، همچون توئیتر6‌، لینکداین7 و اینستاگرام، بستر انتشار نظرات ساکنین این سیاره شده‌اند.

اشاره به توئیتر خالی از لطف نیست. توئیتر ۳۵۰ میلیون کاربر دارد. در صورتی که هر کاربر به طور متوسط در طول شبانه‌روز ۳ بار توئیت کند، آنگاه در هر ثانیه ۱۲۵۰۰ توئیت به سمت سرورهای توئیتر، ارسال ‌می‌شود. از سوی دیگر انعکاس تغییرات باید برای دنبال‌کنندگان8، و گیرندگان توئیت نیز ارسال شود. پس این جریان چندین برابر می‌گردد. در سال ۲۰۰۹ درپی فوت خواننده مشهور آمریکایی، مایکل‌جکسن، سرورهای توئیتر زیر فشار ۱۰۰هزار توئیت در ثانیه، از کار افتادند!9

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

تغییر هنجار‌های برنامه‌نویسی

همزمان با نیاز روز افزون به مدلهایی مقیاس‌پذیر پردازش‌داده، و محبوبیت پردازش‌ابری11، از محبوبیت شی‌گرایی12 به عنوان مدلی مناسب برای دنیای داده‌های‌بزرگ13 کاسته شد. شی‌گرایی با تمام مزایایی که به همراه آورده بود، برای پردازش حجم انبوه داده مناسب نمی‌نمود. بهای تسهیلاتی که زبانهای شی‌گرا برای برنامه نویسان فراهم‌ می‌سازند، افزون شدن پیچیدگی در لایه‌های زیرین و افزایش بار زمان‌اجرا14 است. اشیا‌ بزرگ و پیچیده‌ای، که برنامه نویسان شی‌گرا در زبانهایی مانند جاوا15، به سادگی توسعه می‌دهند، در زمان‌اجرا بر روی سرورها به عملیاتی مهلک و طاقت فرسا بدل می‌شود. از سوی دیگر هزینه حذف16 انبوه اشیاء پیچیده‌ای که به سادگی تولید می‌کنیم و برای 17GC رها‌ میکنیم، با افزون شدن بار پردازشی و تعداد اشیا‌ زنده در حافظه، به مشکلی پیچیده بدل ‌می‌شود. لذا شی‌گرایی که زمانی راهکاری‌توانا در توسعه سامانه‌های نرم‌‌افزاری می‌نمود، با ورود به عصر داده‌های‌بزرگ18، به راهکاری ناکارآمد بدل شد.
مسئله اصلی از اهمیت وضعیت اشیا در مدل‌های شی‌گرا ناشی می‌شد. هر شی در زمان اجرا در هر لحظه وضعیتی دارد. وابستگی اشیا به وضعیت یکدیگر از میزان مقیاس‌پذیری زبان‌های شی‌گرا می‌کاهد.

برای رهایی از پیچیدگی‌های شی‌گرایی، بازگشتی هوشمندانه به سوی زبانهای برنامه‌سازی تابعی19 آغاز شد20. بسیار پیشتر در سال ۱۹۵۰، جان مک‌کارتی21، با معرفی زبان پیشرفته لیسپ دنیای زبانهای تابعی را گشوده بود.

در دهه گذشته، زبانهای تابعی محبوبیت بسیار یافته‌اند. این حرکت به توسعه زبانهایی مانند کلوژر22 (مشتق شده از لیسپ23) و اسکالا24 منتهی شد. اسکالا مزایای زبانهای‌تابعی و شی‌گرا را توأماً عرضه می‌کند25. هردوی این زبانها روی ماشین‌مجازی‌جاوا26، به خوبی کار می‌کنند. بی‌شک پدید آمدن زبانهای نوین تابعی، توسعه چهارچوبهای نوین پردازش‌داده و جریان‌داده را تسهیل کرد.
در زبان‌های تابعی تمامی ملزومات داده‌ای پردازش را به شکل پارامتر‌های ورودی، هنگام فراخوانی به تابع ارسال می‌کنیم. لذا می‌توانیم بدون هیچ مشکلی پردازش را بر روی ماشین‌های متعدد گسترش دهیم. این کیفیت حاصل بدون‌وضعیت بودن توابع است.

تولد‌ چهارچوب‌های اختصاصی

در این دوره چهارچوبهایی آوانگارد و مدرن همچون آپاچی استورم27 و آپاچی سامزا28 متولد شدند. استورم توسط ناتان مرز29، بر پایه کلوژر و جاوا توسعه یافت. البته زبانهای غیر JVM30 دیگری را نیز پشتیبانی می‌کند31. ناتان مرز یکی از ایده‌پردازان و معماران فناوری‌های جریان‌داده است. وی از توسعه دهندگان معماری لامبدا32 است. توئیتر در سال ۲۰۱۱ این پروژه را به دست آورد و در توسعه آن سرمایه‌گذاری کرد. استورم به عنوان چهارچوب اصلی پردازش جریان‌داده توئیتر، تا چندی پیش به کار گرفته می‌شد. استورم از چهارچوب زیروام‌کیو33 به عنوان بستر ارتباطی داخلی خود بهره می‌گیرد. در ابتدای سال ۲۰۱۵ توئیتر استورم را به دلایلی چند34 همچون، عدم ارائه مکانیزم اضافه‌بار35، ضعف در کارایی و ناکارآمدی معماری، کنار گذاشت36 و به توسعه هرون37 روی آورد. استورم درحالی بازنشسته شد، که به بلوغ دست نیافته بود. با این حال تیمهای بسیاری به عنوان چهارچوب اصلی پردازش جریان‌داده از آن بهره می‌برند38.

در سوی دیگر، لینکداین در توسعه سامزا از زبانهای اسکالا و جاوا بهره گرفت. درحالی که ایده‌های بنیادین‌ سامزا از استورم برگرفته شده است، سامزا در حرکتی هوشمندانه سعی بر حفظ سازگاری با اکوسیستم هدوپ39 دارد. اختلافاتی دیگر نیز در معماری این دو به چشم می‌خورد. سامزا در مدیریت وضعیت40 راه‌کار بهتری41 برگزید. در حالی که استورم مکانیزم انزوا سطحفرایند42 یونیکس را عرضه می‌کند، سامزا از یارن43 برای ارائه انزوا در سطحمنبع44 بهره می‌برد. لذا پیشرفتهایی که در مکانزیمهای یارن و خدمات آن بوقوع پیوست منجر به بهبود کارکردهای داخلی سامزا شد.

لینکداین در کنار توسعه سامزا، پروژه بسیار موفق دیگری بنام آپاچی‌کافکا45 را نیز معرفی کرد. کافکا یک کارگزارپیام46 مقیاس‌پذیر است که در دنیای پردازش داده‌های‌بزرگ و جریان‌داده محبوبیت بسیار کسب نموده است.

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

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

آپاچی هدوپ با تمرکز بر به حداکثر رسانیدن توان اجرایی پردازه‌های ‌نگاشتکاهش بر روی ماشینهایی با دیسکهای مکانیکی و حافظه محدود توسعه یافته بود. طی سالهای اخیر، تیمهایی نوآور از کمپانی‌هایی همچون‌ مپ‌آر49 و دیتابریکس50 با هدف افزایش سرعت اجرای پردازه‌ها‌ی مبتنی بر نگاشتکاهش، مدل محاسباتی هدوپ را دستخوش تغییراتی وسیع نموده‌اند. این تغییرات بر استفاده بهتر از حافظه رم51، و استفاده بهینه از چرخه‌های نگاشتکاهش تمرکز دارد. نوآوری‌هایی که روی نگاشت‌کاهش انجام پذیرفت، با ارزان شدن فناوری، بر فراگیر‌شدن استفاده از SSD52، نیز تکیه دارند. بهبود مدیریت منابع53 خوشه54 توسط یارن و‌ آپاچی مزوز55 نیز در افزایش کارایی نگاشتمپ مؤثر بود.

آپاچی اسپارک56 بهترین نمونه از این دست است. اسپارک با زبان پیشرفته و تابعی اسکالا توسعه یافته است. این پروژه که در ابتدا در یکی از آزمایشگاه‌های دانشگاه برکلی57 توسط ماتی زهریا58 توسعه یافت، اکنون به عنوان بخشی از اکوسیستم هدوپ، کارایی کم نظیری در اجرای پردازه‌های نگاشتکاهش ارائه می‌کند59. اسپارک با فراهم آوردن چهارچوبی ويژه برای پردازش‌جریان‌داده بنام اسپارک‌استریمینگ60، توان پردازشی خود را در اختیار کارکردهای پردازش‌جریان قرار می‌دهد. اسپارک‌استریمینگ از هسته آپاچی‌ اسپارک بهره‌ می‌گیرد. رویکرد اسپارک‌استریمینگ اساساً با سامزا و خلف‌اش، استورم، متفاوت است. آن‌ها هر پیام دریافتی را پردازش‌ می‌کنند، حال آنکه اسپارک‌استریمینگ پیامهای دریافتی را با رویکردی دسته‌ای مورد پردازش قرار ‌می‌دهد.

نامهای‌گوناگون

از پردازش جریان‌داده با نامهای متفاوتی یاد شده است. برخی آن را پردازش‌جریان61، خوانده‌اند. برخی از آن با رویدادسپاری62 یا CQRS63 نام برده‌اند. حتی برخی آن را پردازش‌رویدادپیچیده64 نامیده‌اند. همانطور که اشاره شد، ابزارهای توزیع شده پردازش‌جریان‌داده از کمپانی‌های اینترنتی همچون لیندکداین و توئیتر سربرآورده‌اند. این اتفاقات از سال ۲۰۰۰ شروع شده بود. از سوی دیگر پردازش‌رویداد‌پیچیده در دانشگاه استانفورد طی پروژه رپید65 در سال ۱۹۹۰ متولد شد. رویدادسپاری، ریشه در نگاهی دامنهمحور66 به حل توسعه‌ نرم‌افزارهای سازمانی67 با مدلهای داده‌ای بسیار پیچیده، ولی در ابعادی کوچکتر از شرکتهای وب، دارد.

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

فناوری پردازش‌جریان‌داده

در اینجا سعی بر معرفی فناوری پردازش‌جریان‌داده داشته و سعی می‌کنیم پیرامون چگونگی استفاده از این فناوری در راستای افزایش مقیاس‌پذیری، قابلیت‌اطمینان68 و قابلیت‌نگهداری69 بحث کنیم. همانگونه که در مقدمه اشاره شد، ایده سامان‌دهی‌ داده در قالب جریانی از رویدادها‌، موضوعی جدید نیست و پیشینه آن به نگاه بدیع و نبوغ‌آمیز پدیدآورندگان یونیکس به فایل باز‌ می‌گردد. کن تامپسون70 در سال ۱۹۷۳، پایپلاین را در یونیکس نسخه ۳ پیاده‌سازی کرد. وی از ایده داگلاس مک‌ایلروی71 بهره گرفت.

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

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

پردازش و تحلیل رویدادها به منظور حصول بینش72

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

به طور کلی در پردازش جریان رویداد، دو رویکرد پایه زیر وجود دارد:

  • الف ذخیره سازی رویدادهای‌خام75

  • ب ذخیره‌سازی داده‌های سرجمع76

ds-p1

الفذخیره‌سازی رویدادهای خام

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

ب ذخیره‌سازی داده‌های سرجمع

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

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

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

معماری ترکیبی82

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

ds-p2

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

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

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

تعریف

پیش از معرفی چهارچوبها و ابزارهای پردازش جریان‌داده، به ارائه تعریفی از بن‌سازه95 پردازش جریان‌داده می‌پردازیم:

یک بن‌سازه پردازش جریان‌داده، به دو نیاز زیر پاسخ مید‌هد:

۱. یکپارچه‌سازی داده96: بن‌سازه پردازش‌جریان‌داده، با تسخیر پیوسته جریانهای رویداد و داده، سامانه‌های دیگر را تغذیه ‌می‌کند. این سامانه‌ها طیف متنوعی همچون پایگاه‌‌داده رابطه‌ای و غیر‌رابطه‌ای، مخازن کلیدمقدار97، هدوپ یا سامانه‌های انبارداده هستند.

۲. پردازش جریان98: پردازش پیوسته، بلادرنگ و اعمال تغییرات بر جریانهای داده و تولید نتیجه برای دیگر سامانه‌ها توسط پردازش‌جریان صورت می‌گیرد.

چهارچوبها و ابزارها

پایگاه‌داده

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

در ذخیره سازی داده‌های خام، یک پایگاه‌داده سازگار با هدوپ که بتواند برای تامین مقیاس‌پذیری و قابلیت اطمینان از ‌99HDFS بهره‌گیرد، انتخابی مناسب ‌خواهد بود. در طراحی اینگونه کاربردها، در بهره‌گیری از پایگاه‌های داده‌ای رابطه‌ای100، احتیاط کنید. پیچیدگی ‌‌فناوری بانکهای‌رابطه‌ای از قابلیت بهره‌برداری از آن‌ها در ذخیره‌سازی جریانهای بزرگ‌ و سریع داده کاسته است. در صورتی که بنچ‌مارک101 می‌کنید، روی‌ محاسبه کارایی در ذخیره سازی ترابایت‌های دوم و سوم حساب کنید. پایگاه‌های داده‌ای که کنترل‌ همزمانی چندنسخه‌ای102 را پیاده‌سازی نموده‌اند، برای کاربردهای ذخیره‌سازی جریانهای داده، مشکلاتی بوجود می‌آورند. به مدلهای ساده‌تر همچون، NoSQL و ساختارهای سریع و ساده مبتنی بر فایل بیاندیشید. بهتر است از راه‌حلهایی که ویژگی مطلوب، فقط‌اضافه103 را پیاده‌سازی نموده‌اند، بهره‌گیرید.

کارگزارپیام

کافکا یک خدمت تکثیرشده104، پارتیشن‌شده105 و توزیع‌شده ثبت لاگ106 است. کافکا کارکردهای یک سامانه پیام را در قالب طرحی نو و منحصر بفرد، ارائه‌ می‌کند107.

کافکا پیامهای دریافتی در قالب موضوعات108 دسته بندی می‌کند. پردازه‌ای که به ارسال پیام به کافکا می‌پردازد، منبع‌پیام‌109، نام‌ دارد. پردازه‌هایی که دریافت‌کننده پیام هستند، پیامگیر110 نام دارند. پردازه‌های کافکا در قالب خوشه‌ای از ماشین‌ها که به هریک واسط111 می‌گوییم، اجرا می‌شوند. کافکا برای پیاده‌سازی توزیع‌پذیری و افزایش راندمان خوشه، و همچنین افزایش قابلیت بازیابی از خطا، از مفهوم پارتیشن بهره‌می‌گیرد.

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

ds-p3

منابع داده، منبع‌پیام هستند. پیامگیرهای متنوعی توسط کافکا تغذیه می‌شوند.113

موتور پردازش‌جریان‌داده

همانطور که در تاریخچه اشاره شد، چهارچوبهای متنوعی برای پردازش بلادرنگ جریان‌داده توسعه یافته است. به نظر می‌رسد اسپارک‌استریمینگ و سامزا بر دیگر چهارچوبها، مزایایی غیر قابل چشم‌پوشی ارائه می‌کنند. سازگاری با چهارچوب نگاشتکاهش، پیاده‌سازی توسط زبانهای تابعی متعالی، همچون اسکالا و ایده‌های نوین را دلایلی برای این انتخاب می‌دانم. اسپارک با فراهم‌ساختن API بسیار ساده و توانمند، برنامه‌نویسان را از پیچیدگی‌های پردازش جریان دور نموده، اجازه‌ میدهد آزادانه به پیاده‌سازی رویه‌ها بپردازند. برای مقایسه این چهارچوبها میتوان با یک جستجوی ساده به مراجعی114 115 دست یافت. برای کسب نتیجه بهتر قطعاتی ساده از سناریوهای موردنیاز را پیاده‌سازی نموده و بنچ‌مارک کنید. به خاطر داشته باشید، رفتار این‌گونه سامانه‌ها در زمانهای طولانی استفاده ممکن است تغییر کند. بنابر این به منابع کافی داده دسترسی داشته باشید. برای کاربردهای بسیار سریع، در حد یک ثانیه بهتر است از راه‌حالهایی همچون سامزا بهره‌گیرید. برای پردازش انبوه ‌داده‌هایی با تاخیر در مقیاس ثانیه یا دقیقه، از اسپارک‌استریمینگ نیز‌ می‌توانید بهره‌برداری کنید. پروژه آپاچی فلینک116 نیز بسیار توانمند است. تولد این پروژه با اوج گرفتن اسپارک همزمان شده است. لذا شهرتی در خور آنچه سزاوار است، کسب ننموده. فلینک در بهره‌گیری از حافظه هوشمندانه رفتار می‌کند. بسادگی توسعه میابد و با زیست‌بوم هدوپ سازگار است. فلینک از پروژه تحقیقاتی استراتوسفر117 منشعب شده است. برای پردازش‌هایی با زمان پاسخ در حد میلی‌ثانیه یا کمتر، از زبان‌های تابعی، و مکعب‌داده به همراه پردازش داده‌های خام در قاب‌های کوچک، با پارامتر فراموشی استفاده کنید.



برخی الگورتیمها و ترفندهای پایه در پردازش جریان‌داده

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

ترفندهای کلیدی

برای سرعت‌ بخشیدن به رویه‌های پردازش جریان‌داده از دو ترفند هش‌کردن121 و طرح‌کردن122 بسیار استفاده می‌شود. در ترفند هش‌کردن، یک هویت را به کمک تابعی123 به هش124 تبدیل می‌کنیم. در ترفند ‌طرح‌کردن، اغلب مقدار زیادی از داده را به طرحی125 کوچک از داده تبدیل می‌کنیم. نکته مهم در بکاربرد این ترفندها، یافتن تابعی مناسب برای هش کردن، و طرحی مناسب برای طرح‌کردن است. تقریباً تمامی الگوریتمهای پردازش جریان‌داده که در اینجا مرور می‌کنیم، از طرح‌کردن و هش‌کردن بهره‌ می‌برند.

تکرار کمینه

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

ایده‌اولیه این است، که اگر n نمونه هش شده با فاصله‌های127 حداکثر یک واحد داشته باشیم، آنگاه آن n نمونه، n+1 فاصله می‌سازند. پس اندازه میانگین128فاصله n+1 فاصله، باید:

ds-p7

باشد. بر اساس تقارن، متوسط دوری129 تا کمینه130 مقادیر هش شده نیز باید:

ds-p7باشد.

از سوی دیگر، به واسطه مکانیزم هش‌کردن، به مقادیر تکراری، مکان جدیدی تخصیص داده نمی‌شود و بر روی مقادیر موجود نوشته می‌شوند. پس تصویر را تغییر‌ نمی‌دهند. لذا n تعداد مقادیر هش یکتا است. این بدین معنی‌ است که اگر ۱۰ نمونه داشته باشیم، مقدار کمینه حدود 1/11 خواهد بود.

ds-p4

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

طرح‌کمینه‌تعداد132

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

ds-p5

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

ds-p6

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

K-Means جریان‌داده

در بهره‌گیری از ‌‌‌K-Means در پردازش جریان‌داده، باید برای دفعات متعدد مورد نیاز برای خوشه‌بندی137 و بارگذاری‌‌های متعدد، چاره‌ای اندیشید. راهکار کارآمدی که می‌توان بهره‌جست، تولید یک طرح (نمایشی کوچک از انبوه‌ داده) و اعمال الگوریتم خوشه‌بندی بر روی طرح است. بدیهی است طرح بسیار کوچکتر از داده‌های منبع است. لذا خوشه بندی آن نیز بسیار سریع انجام می‌گیرد. انتخاب مقدار تقریب مناسب در تهیه طرح، اهمیت دارد. طرح را میتوان بسیار سریع و در یک دور پردازش تولید نمود. در‌واقع به جای اجرای خوشه‌بندی بر منبع اصلی داده به خوشه بندی طرح کوچکی که مدلی کوچک از داده است، تمرکز می‌کنیم.

امیر صدیقی مرداد ۱۳۹۴

twitter:@amirsedighi

http://www.linkedin.com/in/amirsedighi

1 Unix

2 https://en.wikipedia.org/wiki/Pipeline_(Unix)

3 https://en.wikipedia.org/wiki/Sed

4 Abstract

5 َUnix-Like

6 Twitter

7 LinkedIn

8 Followers

9 https://en.wikipedia.org/wiki/Twitter

10 Scaleability

11 Cloud Computing

12 Object Orientation

13 Big-Data

14 Runtime

15 Java

16 Garbage Collection

17 Garbage Collector

18 Big-Data

19 Functional Programming Languages

20 http://www.ibm.com/developerworks/library/j-ft20/

21 John MacCarthy

22 Clojure

23 Lisp

24 Scala

25 http://cacm.acm.org/magazines/2014/4/173220-unifying-functional-and-object-oriented-programming-with-scala/fulltext/

26 Java Virtual Machine

27 Apache Storm

28 Apache Samza

29 Nathan Marz

30 Java Virtual Machine

31 http://samza.apache.org/learn/documentation/0.7.0/comparisons/storm.html

32 http://lambda-architecture.net/

33 http://zeromq.org/

34 http://dl.acm.org/citation.cfm?id=2742788

35 Backpressure

36 http://www.infoq.com/news/2015/06/twitter-storm-heron

37 https://blog.twitter.com/2015/flying-faster-with-twitter-heron

38 http://samza.apache.org/learn/documentation/0.7.0/comparisons/storm.html

39 Hadoop Ecosystem

40 State

41 http://samza.apache.org/learn/documentation/0.7.0/comparisons/introduction.html

42 Procss-Level Isolation

43 YARN

44 Resource-Level Isolation

45 Apache Kafka

46 Message Broker

47 Map-Reduce

48 Batch Processing

49 MAPR

50 Databricks

51 RAM

52 Solid-State Disk

53 Resource Management

54 Cluster

55 Apache Mesos

56 Apache Spark

57 AMPLab

58 Matei Zaharia

59 https://spark.apache.org/news/spark-wins-daytona-gray-sort-100tb-benchmark.html

60 Spark Streaming

61 Stream Processing

62 Event Sourcing

63 Command Query Responsibility Segregation

64 Complex Event Processing

65 http://complexevents.com/stanford/rapide/

66 Domain-Driven

67 Enterprise Businesses

68 Reliability

69 Maintainability

70 Ken Thompson

71 Douglas McIlroy

72 Insight

73 Event Processing

74 Business

75 Store Raw Events

76 Store Aggregated Data

77 Data Warehouse

78 Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab

79 Cache

80 Forensic

81 Machine Learning

82 Hybrid

83 Consumers

84 DB Writes

85 DB Reads

86 Libraries

87 Extract Transfer Load

88 Business Intelligence

89 Metrics

90 Business Constraints

91 Patterns

92 Frequency

93 Length

94 Priority

95 Platform

96 Data Integration

97 Key-Value Stores

98 Stream Processing

99 Hadoop Distributed File System

100 RDBMS

101 Benchmark

102 Multivestion Concurrency Control – MVCC

103 Append-Only

104 Replicated

105 Partitioned

106 Commit Log

107 http://kafka.apache.org/documentation.html#introduction

108 Topics

109 Message Producer

110 Message Consumer

111 Broker

113 http://www.confluent.io/blog/stream-data-platform-1/

114 http://samza.apache.org/learn/documentation/0.7.0/comparisons/introduction.html

115 https://dzone.com/articles/streaming-big-data-storm-spark

116 Apache Flink

117 http://stratosphere.eu

118 Approximation

119 Frame

120 RAM

121 Hashing

122 Sketching

123 Identity Function

124 Hash

125 Sketch

126 https://en.wikipedia.org/wiki/HyperLogLog

127 Intervals

128 Avarage Size

129 Distance

130 Minimum

131 Distinct Values

132 Count-Min Sketch

133 Frequency

134 Popular Items

135 Recommender Systems

136 Realtime Monitoring

137 Clustering

138 Data Centric

139 Enterprise

140 http://rayd.ir/solutions/

141 Spark Cookbook – Fast Data Processing with Spark – Graph Processing using Spark

142 PACKT Publishing

143 Technical Reviewer

144 Http://recommender.ir

145 Log Management

146 NLAI

147 http://mvnrepository.com/artifact/org.tigris.jsapar

148 http://blog.hexican.com/2010/02/parsing-huge-text-files-using-java-and-jsapar/