در حدود سال ۲۰۱۲، شرکت LinkedIn با یک چالش اساسی در حوزه زیرساخت داده روبهرو شد. دادههای مربوط به فعالیت کاربران مانند لایکها، بازدید پروفایلها و انتشار پستها نقش حیاتی در عملکرد سایت و تجربه کاربری داشتند. با این حال، زیرساخت قدیمی لینکدین متشکل از دو خط لوله مجزا بود: یکی برای پردازش دستهای (Batch Pipeline) مبتنی بر Oracle و Hadoop، و دیگری برای پردازش آنی (Real-time Pipeline) که تنها از طریق Zenoss در دسترس بود. این معماری جداگانه و قدیمی، مشکلاتی جدی در مقیاسپذیری، پایداری و دسترسی بلادرنگ به دادهها ایجاد کرده بود، چالشی که به ساخت Kafka منجر شد.
اما مشکلات عمده بودند:
- کار دستی زیاد و نگهداری سخت
- بکلاگ بزرگ از دادههای ناقص
- نبود یکپارچگی بین سیستمها
- شکنندگی و خرابیهای مکرر
- مشکلات در مدیریت اسکیمای داده (Schema) و تغییرات آن
- تاخیر زیاد در دسترسی به دادهها (ساعات بعد از تولید داده)
- دادهها فقط در مقاصد محدود ذخیره میشدند
LinkedIn به این نتیجه رسید که نمیتواند فقط با ابزارهای کلاسیک ادامه دهد؛ زیرا: «سیستمهای پیامرسانی سنتی مقیاسپذیری لازم را ندارند» و «انبارسازیهای سنتی، در زمان واقعی کافی نبودند»
نیازهای LinkedIn چه بودند؟
برای حل این مشکلات، آنها به چیزی فراتر از دو خط لوله موجود نیاز داشتند. به طور خاص، باید زیرساختی ایجاد میشد که بتواند:
- زیرساخت پایدار و مقاوم (Robustness) باشد.
- مقیاسپذیری (Scalability) بالا داشته باشد — بتواند دادهها را همزمان زیاد پردازش کند.
- مدیریت صحیح اسکیمای داده و سازگاری با گذشته (Backward Compatibility) داشته باشد.
- پشتیبانی از Fan-out بالا (ارسال داده به چندین مقصد) داشته باشد.
- در زمان واقعی (real-time) کار کند و تأخیرها را به حداقل برساند.
- امکان ادغام آسان و خودکار (Plug & Play Integration) با سیستمهای مختلف داشته باشد.
- امکان تغییر مالکیت وظایف به تیم تولیدکننده داده (“data producer teams”) موجود باشد.
- تولیدکننده (Producer) و مصرفکننده (Consumer) دادهها از هم جدا باشند تا بکلاگ تولید، مصرف را مختل نکند.
چطور Kafka ساخته شد؟
در همین بستر، LinkedIn تیم مهندسی خود را گرد هم آورد تا یک سیستم جدید بسازد. نتیجه، پروژه Kafka بود. این سیستم توانست ۵ مورد از ۸ نیاز اصلی را مستقیماً برطرف کند:
- Robustness: سیستم توزیع شده با replication و failover.
- Scalability: پارتیشنبندی Topics و مقیاسپذیری افقی.
- High Read Fan-out: ساختار Log بدون قفل برای خواندن مقیاسپذیر.
- Real-time: پردازش تقریبا لحظهای دادهها.
- Decoupling Producers from Consumers: ذخیرهسازی داده روی دیسک و امکان پردازش کند مصرفکنندهها بدون تأثیر بر تولید.
هرچند که مدیریت اسکیمای داده (Schema Management) و ادغام کامل Plug & Play به صورت کامل حل نشده بودند، اما Kafka به عنوان هسته زیرساخت دادهها در LinkedIn قرار گرفت.
مدیریت اسکیمای داده و مالکیت داده
برای آنکه داده تولید شده به مصرفکنندهها (مصرفهای مختلف، انبار داده، سیستمهای بینابینی) به صورت استاندارد و یکنواخت برسد، LinkedIn چند گام زیر را برداشت:
- مهاجرت از XML به Apache Avro، پیامها هفت برابر کوچکتر و فشردهتر شدند.
- ساخت نسخهٔ اولیه یک Schema Registry برای مدیریت نسخهها و اطمینان از deserialize صحیح.
- مدل سازگاری برای حفظ Backwards Compatibility.
- تعریف یک اسکیمای یکنواخت برای دادهها (Schema on Write به جای Schema on Read) → دادهها تمیز و آماده مصرف در همهجا بودند.
- امکان ادغام Plug & Play با انبار داده و سایر مصرفکنندهها.
علاوه بر این، مالکیت و حاکمیت دادهها نیز تغییر کرد:
- مسئولیت اسکیمای داده و دادهها از تیم Pipeline به تیمهای تولیدکننده داده منتقل شد، هر تیم تولیدکننده بهتر میداند دادههای خودش چیست.
- بررسی کد برای تغییرات اسکیمای داده اجباری شد.
- مستندسازی هزاران فیلد و نسخه اسکیمای داده.
چرا هنوز هم برای من جای سوال دارد که «چرا Kafka اسکیمای داده ندارد؟»
شاید همین سؤال شما هم باشد: اگر LinkedIn تا این حد روی اسکیمای داده متمرکز بوده، پس چرا برخی افراد میپرسند «چرا Kafka اسکیمای داده ندارد؟» پاسخ ساده این است: Kafka به عنوان یک موتور انتقال و ذخیرهسازی پیام ساخته شده است، نه به عنوان یک سیستم کامل برای مدیریت اسکیمای داده. یعنی:
- Kafka خود یک لایه پیامرسان و دیتالُگ (commit log) است.
- اسکیمای داده، نسخهبندی پیام، تطابق مصرفکنندهها با تولیدکنندهها بخشی از لایههای بالاتر هستند — مثلاً Schema Registry یا لایههای پردازش داده.
- فرق بین «اسبکاری» Kafka و «خانهسازی» نظام دادههای کامل است: Kafka نقش حیاتی دارد ولی نمیخواهد همهچیز را خودش اداره کند.
