Tech Trends & Architecture

في بدايات LinkedIn، كان عندهم مشكلة كبيرة في تتبع نشاط المستخدمين وفهم سلوكياتهم على المنصة. كل…

في بدايات LinkedIn، كان عندهم مشكلة كبيرة في تتبع نشاط المستخدمين وفهم سلوكياتهم على المنصة. كل تفاعل - زي لايك، كومنت، أو حتى مجرد تصفح - النظام كان يجمعه باستخدام Batch Processing. العملية كانت تتم عن طريق تخزين…

في بدايات LinkedIn، كان عندهم مشكلة كبيرة في تتبع نشاط المستخدمين وفهم سلوكياتهم على المنصة. كل تفاعل - زي لايك، كومنت، أو حتى مجرد تصفح - النظام كان يجمعه باستخدام Batch Processing. العملية كانت تتم عن طريق تخزين البيانات محليًا (Offline)، تجميعها على شكل دفعات، وبعدين إرسالها للأنظمة الثانية بشكل دوري.
في البداية، كانت الطريقة هذه فعالة نوعاً ما مع الحجم الصغير للبيانات، لكن مع نمو عدد المستخدمين بدأ النظام يواجه مشاكل كثيرة.
أول مشكلة كانت الـ Latency، لأن البيانات كانت توصل متأخرة عن وقت حدوثها. بالإضافة إلى أنه أثناء تجميع وإرسال البيانات، كان يحصل فقدان في بعض الأحداث أو أخطاء في دقتها، واللي أثر بشكل مباشر على تحليل سلوك المستخدمين.
النظام وقتها كان يعتمد على ملفات XML لنقل البيانات بين الأنظمة، وملفات XML معروفة بثقلها وصعوبة التعامل معها لما تكبر البيانات. الشيء ذا جعل الأداء يبدأ ينهار مع الوقت، وصار من المستحيل تقديم تجربة مستخدم سلسة ومميزة، واللي هو كان الهدف الأساسي من كل العملية.
حاول فريق LinkedIn يستخدم حلول زي ActiveMQ، لكنها ما كانت مصممة للتعامل مع التدفق الضخم للبيانات اللي كانت تصير في LinkedIn. الأنظمة كانت ببساطة تنهار تحت الضغط، والنتيجة: وقت كثير ضايع ومحاولات ما توصل للحل المطلوب.
في هذه النقطة، كان واضح إن الحلول الجاهزة ما رح تفي بالغرض، وكان لازم يبنوا نظام جديد بالكامل.
الفريق الهندسي بقيادة Jay Kreps، Neha Narkhede، وJun Rao قرروا تصميم نظام يشتغل على الزمن الحقيقي (Real-Time Processing)، بحيث أنه يحافظ على دقة البيانات، ويقدر يتوسع بسهولة مع نمو المنصة. وهنا انولد Kafka.
الفكرة الرئيسية لـ Kafka كانت تصميم نظام يعتمد على Commit Log بسيط وفعّال. البيانات تتحرك فيه بشكل مباشر من ال producer (المسؤول عن عملية إرسال البيانات) إلى ال kafka اللي بدوره يقوم بعملية assign للبيانات لل consumer (المسؤول عن عملية استهلاك البيانات).
اللي ميز Kafka عن غيره إنه كان Distributed. بمعنى إنه يشتغل على أكثر من سيرفر، ويتوسع بسهولة حسب الحاجة. كل Partition في الـ Topics موزع على عدة سيرفرات، مما أعطى مرونة وسرعة غير مسبوقة في التعامل مع البيانات. والأهم إنه استبدل ملفات XML المعقدة بـ تنسيقات أخف زي JSON وAvro لتحسين الأداء.
بعد نجاح النظام داخل LinkedIn، قرر الفريق فتح مصدره في 2011 تحت مظلة Apache Software Foundation. وأصبح حجر الأساس للشركات الكبيرة اللي تحتاج بيانات الزمن الحقيقي. اليوم، شركات زي Netflix، Uber، وTwitter تعتمد على Kafka لتشغيل أنظمتها.
في 2014، فريق Kafka قرر ياخذ المشروع خطوة أبعد وأسّسوا شركة Confluent. الهدف كان تقديم خدمات مبنية على Kafka للشركات اللي تحتاج تطبقه بسرعة وكفاءة. Confluent أضافت أدوات مثل Kafka Connect لتسهيل التكامل مع الأنظمة الثانية، وksqlDB لتحليل البيانات باستخدام لغة SQL مباشرة.

LinkedIn

Original source

This content was originally published as a LinkedIn post. Open it in a new tab.

Open on LinkedIn