پاسخ دادن به میلیاردها پرسش گزارش هر روز با تأخیر کم – وبلاگ تحقیقاتی Google

ارسال شده توسط Jagan Sankaranarayanan، مهندس نرم افزار ارشد کارکنان، و Indrajit Roy، رئیس محصول Napa، Google

زیرساخت Google Ads بر روی یک انبار داده داخلی به نام Napa اجرا می شود. میلیاردها پرسش گزارش، که داشبوردهای مهمی را که توسط مشتریان تبلیغاتی برای اندازه‌گیری عملکرد کمپین استفاده می‌شوند، بر روی جداول ذخیره شده در Napa اجرا می‌کنند. این جداول حاوی سوابقی از عملکرد تبلیغات است که با استفاده از مشتریان خاص و شناسه‌های کمپین مرتبط با آنها کلید می‌خورد. کلیدها نشانه هایی هستند که هم برای مرتبط کردن رکورد تبلیغات با یک مشتری و کمپین خاص (مثلاً customer_id، camp_id) و برای بازیابی کارآمد استفاده می شوند. یک رکورد حاوی ده‌ها کلید است، بنابراین مشتریان از عبارت‌های گزارش‌دهی برای تعیین کلیدهای مورد نیاز برای فیلتر کردن داده‌ها برای درک عملکرد تبلیغات (مثلاً بر اساس منطقه، دستگاه و معیارهایی مانند کلیک‌ها و غیره) استفاده می‌کنند. چیزی که این مشکل را به چالش می کشد این است که داده ها هستند کج شده از آنجایی که پرس و جوها برای پاسخگویی به سطوح مختلفی از تلاش نیاز دارند و انتظارات تأخیر دقیقی دارند. به طور خاص، برخی از پرس و جوها نیاز به استفاده از میلیون ها رکورد دارند در حالی که برخی دیگر تنها با تعداد کمی پاسخ داده می شوند.

برای این منظور، در «پارتیشن بندی پیشرو برای اجرای پرس و جوی موازی در Napa» که در VLDB 2023 ارائه شد، توضیح می دهیم که چگونه انبار داده Napa مقدار منابع ماشینی مورد نیاز برای پاسخ به سؤالات گزارش را در حین برآورده کردن اهداف تأخیر دقیق تعیین می کند. ما یک الگوریتم پارتیشن بندی پرس و جو پیش رونده جدید را معرفی می کنیم که می تواند اجرای پرس و جو را در حضور انحراف داده های پیچیده موازی کند تا در چند میلی ثانیه به خوبی انجام شود. در نهایت، نشان می‌دهیم که چگونه Napa به زیرساخت Google Ads اجازه می‌دهد تا هر روز میلیاردها پرسش را ارائه دهد.

چالش های پردازش پرس و جو

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

مثال پرس و جو گزارش زیر رکوردهای مشخص شده با کلیدها را استخراج می کند (به عنوان مثال، customer_id و campaign_id) و سپس یک مجموع را محاسبه می کند (یعنی SUM(cost)) از جدول آگهی دهنده. در این مثال، تعداد رکوردها برای پردازش روی یک ماشین خیلی زیاد است، بنابراین Napa باید از یک کلید بعدی استفاده کند (به عنوان مثال، adgroup_id) برای تجزیه بیشتر مجموعه رکوردها به طوری که توزیع یکسان کار حاصل شود. توجه به این نکته ضروری است که در مقیاس پتابایت، اندازه آمار داده های مورد نیاز برای موازی سازی ممکن است چندین ترابایت باشد. این بدان معنی است که مشکل فقط در مورد جمع آوری مقادیر بسیار زیاد ابرداده نیست، بلکه نحوه مدیریت آن نیز است.

        SELECT customer_id, campaign_id, SUM(cost)
             FROM advertiser_table
             WHERE customer_id in (1, 7, ..., x )
             AND campaign_id in (10, 20, ..., y)
             GROUP BY customer_id, campaign_id;

این مثال پرس و جو گزارش، رکوردهایی را که با کلیدها مشخص شده اند استخراج می کند (به عنوان مثال، customer_id و campaign_id) و سپس یک مجموع را محاسبه می کند (یعنی SUM(cost)) از جدول آگهی دهنده. تلاش پرس و جو با کلیدهای موجود در پرس و جو تعیین می شود. کلیدهای متعلق به مشتریان با کمپین‌های بزرگتر ممکن است میلیون‌ها رکورد را لمس کنند زیرا حجم داده مستقیماً با اندازه کمپین تبلیغاتی مرتبط است. این نابرابری رکوردهای تطبیق بر اساس کلیدها نشان دهنده این است چولگی در داده ها، که پردازش پرس و جو را به یک مشکل چالش برانگیز تبدیل می کند.

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

مدیریت سیل داده ها

جداول در Napa دائماً به‌روزرسانی می‌شوند، بنابراین ما از جنگل‌های ادغام‌شده با ساختار گزارش (درخت LSM) برای سازماندهی سیل به‌روزرسانی‌های جدول استفاده می‌کنیم. LSM جنگلی از داده های مرتب شده است که به طور موقت با یک شاخص درخت B سازماندهی شده است تا از جست و جوهای کلیدی کارآمد پشتیبانی کند. B-trees اطلاعات خلاصه درختان فرعی را به صورت سلسله مراتبی ذخیره می کند. هر گره B-tree تعداد ورودی های موجود در هر زیردرخت را ثبت می کند که به موازی سازی پرس و جوها کمک می کند. LSM به ما این امکان را می دهد که فرآیند به روز رسانی جداول را از مکانیک ارائه پرس و جو جدا کنیم، به این معنا که پرس و جوهای زنده با نسخه متفاوتی از داده ها مخالف هستند، که پس از آماده شدن کامل دسته بعدی دریافت (به نام دلتا) به صورت اتمی به روز می شوند. برای پرس و جو

مشکل پارتیشن بندی

مشکل پارتیشن بندی داده ها در زمینه ما این است که ما یک جدول بسیار بزرگ داریم که به عنوان یک درخت LSM نشان داده می شود. در شکل زیر دلتا 1 و 2 هر کدام درخت B مخصوص به خود را دارند و با هم 70 رکورد را نشان می دهند. ناپا رکوردها را به دو قسمت می شکند و هر قطعه را به دستگاه دیگری اختصاص می دهد. این مشکل به یک مسئله تقسیم‌بندی جنگلی از درختان تبدیل می‌شود و به یک الگوریتم پیمایش درخت نیاز دارد که بتواند به سرعت درختان را به دو قسمت مساوی تقسیم کند.

برای جلوگیری از بازدید از تمام گره های درخت، مفهوم پارتیشن بندی “به اندازه کافی خوب” را معرفی می کنیم. همانطور که شروع به بریدن و تقسیم درخت به دو قسمت می کنیم، تخمین می زنیم که اگر فرآیند پارتیشن بندی را در آن لحظه خاتمه دهیم، پاسخ فعلی ما چقدر بد خواهد بود. این معیار نزدیک بودن ما به پاسخ است و در زیر با حاشیه خطای کل 40 نشان داده می شود (در این مرحله از اجرا، انتظار می رود اندازه دو قطعه بین 15 تا 35 رکورد باشد، عدم قطعیت به این مقدار می رسد. 40). هر مرحله پیمایش بعدی تخمین خطا را کاهش می دهد و اگر دو قطعه تقریباً برابر باشند، فرآیند پارتیشن بندی را متوقف می کند. این روند تا رسیدن به حاشیه خطای مورد نظر ادامه می یابد و در این زمان تضمین می شود که دو قطعه کم و بیش برابر باشند.

الگوریتم پارتیشن بندی پیشرونده

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

کار قبلی در این فضا از یک جدول نمونه برای هدایت فرآیند پارتیشن بندی استفاده می کند، در حالی که رویکرد Napa از درخت B استفاده می کند. همانطور که قبلا ذکر شد، حتی یک نمونه از یک جدول پتابایتی نیز می تواند عظیم باشد. یک روش پارتیشن بندی مبتنی بر درخت می تواند به پارتیشن بندی بسیار کارآمدتر از رویکرد مبتنی بر نمونه، که از سازماندهی درختی رکوردهای نمونه برداری شده استفاده نمی کند، دست یابد. ما پارتیشن بندی پیشرونده را با یک رویکرد جایگزین مقایسه می کنیم، که در آن نمونه برداری از جدول با وضوح های مختلف (به عنوان مثال، 1 نمونه رکورد در هر 250 مگابایت و غیره) به پارتیشن بندی پرس و جو کمک می کند. نتایج تجربی سرعت نسبی پارتیشن بندی پیشرونده را برای پرس و جوهایی که به تعداد ماشین های متفاوتی نیاز دارند را نشان می دهد. این نتایج نشان می‌دهد که پارتیشن‌بندی پیشرونده بسیار سریع‌تر از رویکردهای موجود است و با افزایش اندازه پرس و جو، سرعت آن افزایش می‌یابد.

نتیجه

الگوریتم پارتیشن بندی پیشرونده Napa به طور موثر پرس و جوهای پایگاه داده را بهینه می کند و Google Ads را قادر می سازد هر روز میلیاردها بار به درخواست های گزارش مشتری ارائه دهد. متذکر می شویم که پیمایش درخت تکنیک رایجی است که دانش آموزان در دوره های مقدماتی علوم کامپیوتر از آن استفاده می کنند، با این حال در Google نیز یک مورد استفاده حیاتی است. ما امیدواریم که این مقاله الهام بخش خوانندگان ما باشد، زیرا نشان می دهد که چگونه تکنیک های ساده و ساختارهای داده با دقت طراحی شده می توانند در صورت استفاده خوب، بسیار قوی باشند. برای کسب اطلاعات بیشتر، مقاله و سخنرانی اخیری را که ناپا را توصیف می کند، بررسی کنید.

سپاسگزاریها

این پست وبلاگ تلاش مشترکی را بین جونیچی تاتمورا، تائو زو، جاگان سانکارارایانان، یانلای هوانگ، جیم چن، یوپو ژانگ، کوین لای، هائو ژانگ، گوکول نات بابو منوهاران، گوتز گراف، دیویاکانت آگراوال، براد آدلبرگ، ایندراج کولهار و شیلپایت تشریح می‌کند. روی.