اسپاتیفای یک لایه ایندکس خارجی به‌نام Random Access Parquet (RAP) معرفی کرده تا پرس‌وجوهای نقطه‌ای با تاخیر پایین را مستقیماً روی دیتا لیک پردازشی اجرا کند و نیاز به تکثیر گسترده داده‌ها در پایگاه‌های سرویس‌دهی را کاهش دهد.

چرایی نیاز به RAP

دیتا لیک‌های مدرن مرکز پردازش تحلیلی و هوش مصنوعی شده‌اند، اما موتورهایی مانند Trino و BigQuery برای اسکن‌های تحلیلی طراحی شده‌اند نه پرس‌وجوهای مبتنی بر کلید. هرچند سرویس‌های ذخیره‌سازی اشیاء مانند Google Cloud Storage به تاخیرهای نزدیک به میلی‌ثانیه رسیده‌اند، سربار برنامه‌ریزی کوئری، پیمایش متادیتا و کشف فایل‌ها هنوز برای دسترسی‌های نقطه‌ای پرهزینه است. وقتی پتابایت‌ها از دادهٔ آنلاین در Bigtable و اگزابایت‌ها در دیتا لیک روی GCS نگهداری می‌شوند، تکثیر داده‌ها به پایگاه‌های سرویس‌دهی بار مالی و عملیاتی سنگینی ایجاد می‌کند؛ RAP برای کاهش این بار طراحی شده است.

چگونگی کار RAP

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

ساختار ایندکس و سازگاری با Iceberg

برای همگام‌شدن با فرمت‌هایِ جدول مانند Apache Iceberg، سازنده ایندکس، تکه‌های ایندکس append-only تولید می‌کند تا فایل‌های Parquet غیرقابل‌تغییر را دستکاری نکند. نتیجه اینکه همان مجموعه‌داده برای تحلیلات، یادگیری ماشین، نوت‌بوک‌ها و سرویس‌های حساس به تاخیر قابل‌استفاده باقی می‌ماند بدون نیاز به نگهداری چندین کپی از داده.

بهینه‌سازی‌های چیدمان ذخیره‌سازی

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

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

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

درهم‌تنیدن ستون‌های مقادیر برای خوانش پیوسته

شاخص‌های ثانویه و انواع ایندکس

RAP امکان اضافه‌کردن شاخص‌های ثانویه برای جستجو در چند بعد را فراهم می‌کند؛ برای مثال جستجو بر اساس شناسه خریدار یا شناسه فروشنده بدون بازنویسی فایل‌های Parquet ممکن می‌شود. انواع ایندکس‌های مورد اشاره شامل موارد زیر است:

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

مدیریت ایندکس‌های ثانویه در لایه سرویس‌دهی انجام می‌شود تا مسیرهای دسترسی جدید بدون تغییر در خطوط لوله داده اضافه شوند.

بازخورد جامعه و مقایسه با رویکردهای دیگر

اعلام RAP در جامعه مهندسی داده بحث‌برانگیز بود؛ برخی از جمله Andrew Lamb آن را نمونه‌ای از توسعه فرمت‌های باز برای بارهای کاری تعاملی دانستند. در مباحث دیگر، به این نکته اشاره شد که بهبود عملکرد ذخیره‌سازی اشیاء بخشی از تاخیر را از لایه ورودی به بخش برنامه‌ریزی کوئری و دسترسی به متادیتا منتقل کرده و RAP با ایندکس‌های پیش‌محاسبه‌شده برای کاهش این سربار طراحی شده است.

در کنار آن، ارائه‌های اخیر مانند معماری lakehouse مبتنی بر Iceberg از سوی برخی ارائه‌دهندگان ابری هدف مشابهی—کاهش تکثیر داده‌ها—را دنبال می‌کنند، اما تفاوت RAP افزوده‌شدن یک لایه ایندکس خارجی اختصاصی است که برای جستجوهای نقطه‌ای بهینه شده و با فایل‌های Parquet و جداول Iceberg سازگار باقی می‌ماند.

پیامدها برای سرویس‌های آنلاین و هوش مصنوعی

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

مزایا

  • کاهش نیاز به کپی داده‌ها و صرفه‌جویی در هزینه ذخیره‌سازی.
  • دسترسی نقطه‌ای با تاخیر پایین نزدیک به عملکرد دیتابیس‌های عملیاتی.
  • همگام‌سازی آسان‌تر با ابزارهای تحلیلی و ML که از Iceberg و Parquet استفاده می‌کنند.

محدودیت‌ها و چالش‌ها

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

نگاهی به آینده

اضافه‌کردن ایندکس‌های خارجی به فرمت‌های باز مانند Parquet ممکن است الگوی جدیدی ایجاد کند که مرز میان دیتا لیک‌های تحلیلی و پایگاه‌های داده عملیاتی را کمرنگ‌تر سازد. گام‌های بعدی احتمالاً شامل توسعه ابزارهای مدیریت ایندکس، همگام‌سازی با تراکنش‌های Iceberg و ارزیابی هزینه/فایده در محیط‌های عملیاتی خواهد بود.