سیستم های تجزیه و تحلیل سرور

این قسمت دوم از مجموعه مقالات در مورد سیستم های تحلیلی است (لینک قسمت 1).

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

تحلیلگران مشتری

تجزیه و تحلیل مشتری سرویسی است که یک شرکت از طریق SDK رسمی به وب سایت یا برنامه خود متصل می شود، در پایگاه کد خود ادغام می شود و محرک های رویداد را انتخاب می کند. یک نقطه ضعف آشکار در این رویکرد وجود دارد: همه داده های جمع آوری شده ممکن است دقیقاً همانطور که می خواهید پردازش نشوند به دلیل محدودیت های هر سرویسی که انتخاب می کنید. به عنوان مثال، در یک سیستم، اجرای وظایف MapReduce آسان نخواهد بود، در سیستم دیگر نمی توانید مدل خود را اجرا کنید. یکی دیگر از معایب، صورتحساب منظم (چشمگیر) خدمات خواهد بود.
راه حل های تجزیه و تحلیل مشتری زیادی در بازار وجود دارد، اما دیر یا زود تحلیلگران با این واقعیت مواجه می شوند که هیچ سرویس جهانی مناسب برای هر کاری وجود ندارد (در حالی که قیمت تمام این خدمات همیشه در حال افزایش است). در چنین شرایطی، شرکت ها اغلب تصمیم می گیرند که سیستم تجزیه و تحلیل خود را با تمام تنظیمات و قابلیت های سفارشی لازم ایجاد کنند.

تحلیلگران سرور

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

مزایا
منفی

شما می توانید هر چیزی را که می خواهید سفارشی کنید
این اغلب بسیار دشوار است و نیاز به توسعه دهندگان جداگانه دارد

دوم: خدمات SaaS (Amazon، Google، Azure) را به جای اینکه خودتان آن را مستقر کنید، استفاده کنید. در قسمت سوم در مورد SaaS با جزئیات بیشتر صحبت خواهیم کرد.

مزایا
منفی

ممکن است در حجم های متوسط ​​ارزان تر باشد، اما با رشد زیاد همچنان بسیار گران می شود
کنترل همه پارامترها ممکن نخواهد بود

مدیریت به طور کامل به شانه های ارائه دهنده خدمات منتقل می شود
همیشه معلوم نیست داخل سرویس چیست (ممکن است نیازی نباشد)

نحوه جمع آوری تجزیه و تحلیل سرور

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

1. دریافت داده ها

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

طبق پست در Quora در سال 2014، خالق آپاچی کافکا تصمیم گرفت نام این نرم افزار را به نام فرانتس کافکا بگذارد زیرا «سیستمی است که برای نوشتن بهینه شده است» و به این دلیل که آثار کافکا را دوست داشت. - ویکیپدیا

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

(تصویر از این رو)

در عین حال، کافکا به شما اجازه می‌دهد تا به صورت تکه‌ای بخوانید و جریانی از رویدادها را به صورت دسته‌ای کوچک پردازش کنید. کافکا ابزار بسیار مناسبی است که با نیازهای رو به رشد به خوبی مقیاس می شود (مثلاً با مکان یابی رویدادها).
معمولاً یک خرده کافی است، اما هنگام مقیاس بندی (مثل همیشه) همه چیز پیچیده تر می شود. احتمالاً هیچ کس مایل به استفاده از تنها یک خرده فیزیکی در تولید نخواهد بود، زیرا معماری باید مقاوم به خطا باشد. علاوه بر کافکا، راه حل معروف دیگری نیز وجود دارد - RabbitMQ. ما از آن در تولید به عنوان صف تجزیه و تحلیل رویداد استفاده نکردیم (اگر چنین تجربه ای دارید، در نظرات در مورد آن به ما بگویید!). با این حال، ما از AWS Kinesis استفاده کردیم.

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

2. پردازش جریان رویداد

بعد از اینکه همه رویدادها را آماده کردیم و در صف های مناسب قرار دادیم، به مرحله پردازش می رویم. در اینجا من در مورد دو گزینه رایج پردازش به شما خواهم گفت.
اولین گزینه فعال کردن Spark Streaming در سیستم آپاچی است. همه محصولات آپاچی روی HDFS، یک سیستم فایل امن با کپی فایل ها، زندگی می کنند. Spark Streaming ابزاری با کاربری آسان است که داده های جریانی را مدیریت می کند و به خوبی مقیاس می شود. با این حال، ممکن است حفظ آن دشوار باشد.
گزینه دیگر این است که مدیریت رویداد خود را بسازید. برای انجام این کار، به عنوان مثال، باید یک برنامه پایتون بنویسید، آن را در داکر بسازید و در صف کافکا مشترک شوید. هنگامی که محرک ها به کنترل کننده های docker رسید، پردازش شروع می شود. با استفاده از این روش، باید برنامه ها را همیشه در حال اجرا نگه دارید.
بیایید فرض کنیم که یکی از گزینه های توضیح داده شده در بالا را انتخاب کرده ایم و به خود پردازش می رویم. پردازنده ها باید با بررسی اعتبار داده ها، فیلتر کردن زباله ها و رویدادهای "شکسته" شروع کنند. برای اعتبار سنجی ما معمولا استفاده می کنیم Cerberus. پس از این، می توانید نگاشت داده ها را انجام دهید: داده ها از منابع مختلف عادی و استاندارد می شوند تا به یک جدول مشترک اضافه شوند.

3. پایگاه داده

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

4. تجمعات

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

5. Frontend

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

1. کاربر یک پرس و جوی SQL ایجاد می کند.
2. در پاسخ او یک علامت دریافت می کند.
3. یک "تجسم جدید" برای آن ایجاد می کند و یک نمودار زیبا دریافت می کند که می توانید برای خود ذخیره کنید.

تجسم های موجود در این سرویس به طور خودکار به روز می شوند، می توانید نظارت خود را سفارشی کرده و ردیابی کنید. Redash در صورت میزبانی خود رایگان است، اما به عنوان SaaS هزینه آن 50 دلار در ماه خواهد بود.

نتیجه

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

با تشکر برای خواندن! من خوشحال خواهم شد که در نظرات سؤالات خود را بپرسم.

منبع: www.habr.com