بررسی معماری داده شرکت اوبر

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

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

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

ابتدای راه

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

نسل اول : شروع کلان‌داده در اوبر

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

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

نسل دوم : هدوپ به کمک می‌آید

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

برای دسترسی و کار با داده‌ها به صورت تعاملی از Presto‌ استفاده شد (ر.ک به این مقاله) تا تیم‌های مختلف بتوانند با زبان SQL نیازهای موردی (Ad-Hoc) خود را برطرف کنند. برای افزایش سرعت پاسخگویی در پرس‌وجوها، از Apache Hive‌ هم در کنار پِرِستو استفاده شد. (اگر با هایو کار کرده باشید، امکان تعریف جداول خارجی بر روی فایل‌های موجود و کوئری گرفتن از آنها را می‌دهد). برای پردازش انبوه و تولید گزارشات روزانه و گزارشات تحلیلی هم به جای روش قدیمی توزیع و تجمیع (Map/Reduce)، آپاچی اسپارک به کار گرفته شد.

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

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

مزیت دیگر پارکوئت امکان ذخیره ساختار داده‌ها در کنار خود داده‌ها و بنابراین استاندارد کردن تولید و ذخیره داده‌ها توسط منابع مختلف است. با کمک این قابلیت، یک سرویس مرکزی با نام سرویس تعیین ساختار (Schema Service) هم به معماری داده اوبر اضافه شد که ساختار تمامی داده‌ها باید به کمک آن تعیین و به روز رسانی شود.

در این زمان هنوز بخشی از داده‌های تحلیلی و زمان‌مند بر روی ورتیکا قرار داشت. به کمک این معماری جدید، روزانه ده‌ها ترابایت به دریاچه داده اوبر اضافه می‌شد و حدود صدهزار پرس و جو هم پاسخ داده می‌شد. این حجم از عملیات  ذخیره و بازیابی داده‌ها باعث شد HDFS و به طور خاص Name Node که وظیفه پاسخگویی به درخواست‌های جایابی فایلها را برعهده داشت و به‌خاطر معماری کلاینت/سروری خود، پاشنه آشیلی برای هدوپ محسوب می‌شد (در نسخه ۳ هدوپ این معضل تا حدود زیادی رفع شده است) ، به یک گلوگاه در شرکت تبدیل شود و از طرفی تاخیر ۲۴ ساعته در پردازش داده‌های روزانه و تولید جداول جدید آماری، نارضایتی‌هایی را با خود به همراه داشت.

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

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

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

تا ابتدای سال ۲۰۱۷ بستر پردازش داده اوبر از طریق هایو، Presto،‌ اسپارک، ورتیکا و کتابچه‌ها در اختیار کابران مختلف بود. بیش از ۱۰۰ پتابایت داده در HDFS ذخیره شده بود و صدهزار هسته پردازشگر در شبکه‌ای بزرگ، روزانه ۱۰۰ هزار پرس‌و‌جوی پِرِستو، ۱۰ هزار کار اسپارک و ۲۰ هزار پرس‌وجوی هایو را پاسخ می‌دادند اما به تدریج افزایش تاخیر در محاسبات روزانه، حجم نارضایتی‌ها را افزایش داد.

همانطور که قبلاً اشاره شد، مشکل اصلی در ایجاد این تاخیر، عدم امکان به روزرسانی در پارکوئت و HDFS بود.  برای رفع این نقیصه مهم، کتابخانه جدیدی به نام Hudi (مخفف Hadoop Upserts anD Incremental) برای اسپارک ایجاد شد که امکان حذف و به روز رسانی را برای پارکوئت و HDFS به ارمغان آورد. این کتابخانه که در قلب نسل جدید معماری داده اوبر قرار گرفت، باعث شد که به روزرسانی‌ها تنها محدود به داده‌های روزانه گردد و نیاز به پردازش داده‌ها از اول مرتفع شود

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

دو موضوع «مدلسازی تدریجی جداول تحلیلی همزمان با دریافت داده‌ها» و «وجود یک مدل مرجع تعیین ساختار داده‌ها» هم در نسخه سوم معماری اوبر، لحاظ شد تا نهایتاً به دیاگرام زیر رسیدند :

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