جداسازی بار کاری چند مستاجر در آپاچی دوریس: تعادل بهتر بین جداسازی و استفاده

این مقدمه ای عمیق برای قابلیت های جداسازی حجم کاری آپاچی دوریس است. اما اول از همه، چرا و چه زمانی به جداسازی حجم کاری نیاز دارید؟ اگر با هر یک از موقعیت های زیر ارتباط دارید، ادامه مطلب را بخوانید و در نهایت راه حلی خواهید داشت:

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

• شما وظایف پرس و جو در سطوح مختلف اولویت دارید و می خواهید از نظر منابع و اجرا به وظایف حیاتی خود (مانند تجزیه و تحلیل داده های لحظه ای و تراکنش های آنلاین) اولویت بدهید.

• شما نیاز به جداسازی حجم کاری دارید، اما همچنین می خواهید مقرون به صرفه بودن و نرخ استفاده از منابع بالا باشد.

آپاچی دوریس از جداسازی حجم کار بر اساس Resource Tag و Workload Group پشتیبانی می کند. Resource Tag منابع CPU و حافظه را برای بارهای کاری مختلف در سطح گره های Backend جدا می کند، در حالی که مکانیسم Workload Group می تواند منابع را در یک گره باطن برای استفاده بیشتر از منابع تقسیم کند.

https://www.youtube.com/watch?v=Wd3l5C4k8Ok

جداسازی منابع بر اساس برچسب منبع

بیایید با معماری آپاچی دوریس شروع کنیم. Doris دو نوع گره دارد: frontends (FEs) و backends (BEs). گره های FE ابرداده ها را ذخیره می کنند، خوشه ها را مدیریت می کنند، درخواست های کاربر را پردازش می کنند و طرح های پرس و جو را تجزیه می کنند، در حالی که گره های BE مسئول محاسبات و ذخیره سازی داده ها هستند. بنابراین، گره های BE مصرف کنندگان اصلی منابع هستند.

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

برای مثال، اگر می‌خواهید بارهای کاری خواندن و نوشتن را در یک کلاستر 3-BE جدا کنید، می‌توانید این مراحل را دنبال کنید:

1. تگ های منبع را به گره های BE اختصاص دهید: 2 BE را به تگ “Read” و 1 BE را به تگ “Write” متصل کنید.
2. تگ های منبع را به کپی های داده اختصاص دهید: با فرض اینکه جدول 1 دارای 3 کپی است، 2 مورد از آنها را به تگ “Read” و 1 را به تگ “Write” متصل کنید. داده های نوشته شده در Replica 3 با Replica 1 و Replica 2 همگام می شوند و فرآیند همگام سازی داده ها منابع کمی از BE 1 و BE2 را مصرف می کند.
3. گروه های بار کاری را به برچسب های منابع اختصاص دهید: پرس و جوهایی که شامل تگ “Read” در SQL های خود هستند، به طور خودکار به گره هایی با برچسب “Read” (در این مورد BE 1 و BE 2) هدایت می شوند. برای کارهای نوشتن داده، همچنین باید آنها را با تگ “Write” اختصاص دهید تا بتوان آنها را به گره مربوطه (BE 3) هدایت کرد. به این ترتیب، هیچ اختلاف منبعی بین بارهای کاری خواندن و نوشتن وجود نخواهد داشت به جز سربار همگام سازی داده ها از replica 3 به replica 1 و 2.

Resource Tag همچنین امکان اجاره چندگانه را در Apache Doris فراهم می کند. به عنوان مثال، منابع محاسباتی و ذخیره‌سازی برچسب‌گذاری شده با “کاربر A” فقط برای کاربر A هستند، در حالی که آنهایی که با “کاربر B” برچسب‌گذاری شده‌اند منحصر به کاربر B هستند. اینگونه است که Doris جداسازی منابع چند مستاجر را با برچسب‌های منبع در سمت BE پیاده‌سازی می‌کند. .

تقسیم گره های BE به گروه ها تضمین می کند سطح بالایی از انزوا:

• CPU، حافظه و ورودی/خروجی مستاجرین مختلف از نظر فیزیکی ایزوله هستند.
• یک مستأجر هرگز تحت تأثیر شکست (مانند خرابی فرآیند) مستاجر دیگر قرار نمی گیرد.

اما چند نقطه ضعف دارد:

• در جداسازی خواندن و نوشتن، هنگامی که نوشتن داده متوقف می شود، گره های BE که با “Write” برچسب گذاری شده اند، بیکار می شوند. این باعث کاهش استفاده کلی از خوشه می شود.
• در شرایط چند اجاره ای، اگر می خواهید بارهای کاری مختلف از یک مستاجر را با اختصاص گره های BE جداگانه به هر یک از آنها جداسازی کنید، باید هزینه های قابل توجه و استفاده کم از منابع را متحمل شوید.
• تعداد مستاجران به تعداد کپی های داده گره خورده است. بنابراین اگر 5 مستاجر دارید، به 5 ماکت داده نیاز خواهید داشت. این افزونگی فضای ذخیره سازی بزرگ است.

برای بهبود این موضوع، ما یک راه حل جداسازی حجم کار بر اساس Workload Group در Apache Doris 2.0.0 ارائه کرده ایم و آن را در Apache Doris 2.1.0 بهبود بخشیده ایم..

جداسازی حجم کار بر اساس Workload Group

راه حل مبتنی بر گروه حجم کاری، تقسیم دقیق تری از منابع را محقق می کند. این بیشتر منابع CPU و حافظه را در فرآیندهای گره های BE تقسیم می کند، به این معنی که پرس و جوها در یک گره BE می توانند تا حدی از یکدیگر جدا شوند. این امر از رقابت منابع در فرآیندهای BE جلوگیری می کند و استفاده از منابع را بهینه می کند.

کاربران می توانند پرس و جوها را به Workload Groups مرتبط کنند و بنابراین درصد منابع CPU و حافظه را که یک کوئری می تواند استفاده کند محدود کنند. تحت بارهای خوشه‌ای بالا، Doris می‌تواند به‌طور خودکار بیشترین جستجوی منابع را در یک Workload Group از بین ببرد. تحت بارهای کلاستر کم، Doris می تواند به چندین گروه Workload اجازه دهد منابع بیکار را به اشتراک بگذارند.

Doris از هر دو محدودیت نرم افزاری CPU و محدودیت سخت CPU پشتیبانی می کند. محدودیت نرم به گروه‌های بار کاری اجازه می‌دهد تا محدودیت را بشکنند و از منابع بی‌حرکت استفاده کنند و امکان استفاده کارآمدتر را فراهم کنند. محدودیت سخت تضمینی سخت برای عملکرد پایدار است زیرا از تأثیر متقابل Workload Groups جلوگیری می کند.

(محدودیت نرم CPU و محدودیت سخت CPU با یکدیگر متناقض هستند. شما می توانید بر اساس موارد استفاده خود از بین آنها یکی را انتخاب کنید.)

تفاوت های آن با راه حل مبتنی بر برچسب منبع عبارتند از:

• گروه های بار کاری در فرآیندها تشکیل می شوند. چندین گروه بار کاری برای منابع در همان گره BE رقابت می کنند.
• توجه به توزیع ماکت داده خارج از تصویر است زیرا Workload Group تنها راهی برای مدیریت منابع است.

محدودیت نرم CPU

محدودیت نرم CPU توسط cpu_share پارامتری که از نظر مفهومی شبیه وزن ها است. گروه های بار کاری با بالاتر cpu_share در طول یک شکاف زمانی، زمان بیشتری به CPU اختصاص خواهد یافت.

برای مثال، اگر گروه A با a پیکربندی شده باشد cpu_share از 1، و گروه B، 9. در بازه زمانی 10 ثانیه ای، زمانی که هر دو گروه A و گروه B به طور کامل بارگذاری شوند، گروه A و گروه B به ترتیب قادر خواهند بود 1 ثانیه و 9 ثانیه از زمان CPU را مصرف کنند.

آنچه در موارد واقعی اتفاق می افتد این است که همه بارهای کاری در کلاستر با ظرفیت کامل اجرا نمی شوند. تحت محدودیت نرم، اگر گروه B حجم کاری کم یا صفر داشته باشد، گروه A می تواند از تمام 10 ثانیه زمان CPU استفاده کند، بنابراین استفاده کلی از CPU در خوشه افزایش می یابد.

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

محدودیت سخت پردازنده

محدودیت سخت پردازنده در Apache Doris 2.1.0 برای کاربرانی طراحی شده است که به عملکرد پایدار نیاز دارند. به عبارت ساده، محدودیت سخت CPU تعریف می کند که یک Workload Group نمی تواند از منابع CPU بیشتر از حد خود استفاده کند، چه منابع CPU بیکار وجود داشته باشد یا نه.

اینجوری کار میکند:

فرض کنید که گروه A با cpu_hard_limit=10% و گروه B با cpu_hard_limit=90%. اگر هر دو گروه A و گروه B با بار کامل اجرا شوند، گروه A و گروه B به ترتیب از 10٪ و 90٪ از زمان کلی CPU استفاده می کنند. تفاوت در زمانی است که حجم کار گروه B کاهش می یابد. در چنین مواردی، صرف نظر از اینکه بار پرس و جو گروه A چقدر است، نباید بیش از 10% منابع CPU اختصاص داده شده به آن استفاده کند.

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

محدودیت منابع حافظه

حافظه یک گره BE شامل بخش های زیر است:

• حافظه ذخیره شده برای سیستم عامل
• حافظه مصرف شده توسط غیر کوئری ها که در آمار حافظه گروه کار در نظر گرفته نمی شود.
• حافظه مصرف شده توسط پرس و جوها، از جمله نوشتن داده ها. این می تواند توسط Workload Group ردیابی و کنترل شود.

این memory_limit پارامتر حداکثر (٪) حافظه موجود برای یک گروه بار در فرآیند BE را تعریف می کند. همچنین بر اولویت گروه های منابع تأثیر می گذارد.

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

صف پرس و جو

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

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

مکانیسم صف پرس و جو شامل سه پارامتر است: max_concurrency، max_queue_size، و queue_timeout.

تست ها

برای نشان دادن اثربخشی محدودیت نرم CPU و محدودیت سخت، چند آزمایش انجام دادیم.

• محیط: تک دستگاه، 16 هسته، 64 گیگابایت
• استقرار: 1 FE + 1 BE
• مجموعه داده: ClickBench، TPC-H
• ابزار تست بار: Apache JMeter

تست محدودیت نرم CPU

دو کلاینت را راه اندازی کنید و به ترتیب با و بدون استفاده از Workload Groups به طور مداوم درخواست ارسال کنید (ClickBench Q23). توجه داشته باشید که کش صفحه باید غیرفعال شود تا از تأثیر آن بر نتایج آزمایش جلوگیری شود.

با مقایسه توان عملیاتی دو مشتری در هر دو آزمون، می توان نتیجه گرفت که:

• بدون پیکربندی Workload Groups، دو مشتری منابع CPU را به طور مساوی مصرف می کنند.
• پیکربندی گروه های بار کاری و تنظیم cpu_share به 2:1، نسبت توان عملیاتی دو مشتری 2:1 است. با بالاتر cpu_share، Client 1 با بخش بیشتری از منابع CPU ارائه می شود و توان عملیاتی بالاتری را ارائه می دهد.

تست محدودیت سخت پردازنده

یک مشتری راه اندازی کنید، تنظیم کنید cpu_hard_limit=50% برای Workload Group، و ClickBench Q23 را به مدت 5 دقیقه در سطح همزمانی 1، 2، و 4 اجرا کنید.

با افزایش همزمانی پرس و جو، نرخ استفاده از CPU در حدود 800٪ باقی می ماند، به این معنی که از 8 هسته استفاده می شود. در دستگاه 16 هسته ای، اینطور است بهره برداری 50 درصد، که مطابق انتظار است. علاوه بر این، از آنجایی که محدودیت های سخت CPU اعمال می شود، افزایش تاخیر TP99 با افزایش همزمانی نیز یک نتیجه مورد انتظار است.

تست در محیط تولید شبیه سازی شده

در استفاده در دنیای واقعی، کاربران به‌ویژه نگران تأخیر پرس‌وجو هستند و نه صرفاً عملیات پرس و جو، زیرا تأخیر در تجربه کاربر به راحتی قابل درک است. به همین دلیل تصمیم گرفتیم اثربخشی Workload Group را در یک محیط تولید شبیه سازی شده تایید کنیم.

ما یک مجموعه SQL متشکل از جستارهایی را انتخاب کردیم که باید در 1 ثانیه تکمیل شوند (ClickBench Q15، Q17، Q23 و TPC-H Q3، Q7، Q19)، از جمله تجمیع‌های تک جدولی و جستارهای پیوستن. اندازه مجموعه داده TPC-H 100 گیگابایت است.

به طور مشابه، ما تست هایی را با و بدون پیکربندی Workload Groups انجام می دهیم.

همانطور که نتایج نشان می دهد:

• بدون گروه بار کاری (مقایسه تست 1 و 2): هنگام شماره گیری همزمانی Client 2، هر دو مشتری افزایش 2 تا 3 برابری تاخیر درخواست را تجربه می کنند.
• پیکربندی گروه بار کاری (مقایسه تست 3 و 4): با افزایش همزمانی Client 2، نوسان عملکرد در Client 1 بسیار کوچکتر است، که گواه این است که چگونه به طور موثر با جداسازی حجم کار محافظت می شود.

توصیه ها و طرح ها

راه حل مبتنی بر برچسب منبع یک طرح جداسازی حجم کار کامل است. راه حل مبتنی بر Workload Group تعادل بهتری بین جداسازی منابع و استفاده را ایجاد می کند و با مکانیسم صف پرس و جو برای تضمین ثبات تکمیل می شود.

بنابراین کدام یک را برای مورد استفاده خود انتخاب کنید؟ در اینجا توصیه ما است:

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

در نسخه‌های آینده، ما به بهبود تجربه کاربر از Workload Group و ویژگی‌های صف درخواست ادامه خواهیم داد:

• آزاد کردن فضای حافظه با لغو کوئری ها روشی بی رحمانه است. ما قصد داریم آن را با ریختن دیسک پیاده سازی کنیم، که ثبات بالاتری را در عملکرد پرس و جو به ارمغان می آورد.
• از آنجایی که حافظه مصرف‌شده توسط غیرپرسش‌ها در BE در آمار حافظه Workload Group گنجانده نشده است، کاربران ممکن است تفاوتی بین استفاده از حافظه پردازش BE و استفاده از حافظه گروه Workload مشاهده کنند. برای جلوگیری از سردرگمی به این موضوع خواهیم پرداخت.
• در مکانیسم صف پرس و جو، بار کلاستر با تنظیم حداکثر همزمانی پرس و جو کنترل می شود. ما قصد داریم حداکثر همزمانی پرس و جو پویا را بر اساس در دسترس بودن منابع در BE فعال کنیم. این برای ایجاد فشار برگشتی در سمت مشتری و در نتیجه بهبود در دسترس بودن Doris زمانی است که مشتریان بارهای بالا را ارسال می کنند.
• ایده اصلی Resource Tag گروه بندی گره های BE است، در حالی که ایده Workload Group این است که منابع یک گره BE را بیشتر تقسیم کند. برای اینکه کاربران بتوانند این ایده ها را درک کنند، ابتدا باید با مفهوم گره های BE در Doris آشنا شوند. با این حال، از منظر عملیاتی، کاربران فقط باید درصد مصرف منابع هر یک از بارهای کاری خود را درک کنند و در هنگام اشباع شدن بار کلاستر چه اولویتی را باید داشته باشند. بنابراین، ما سعی خواهیم کرد راهی برای صاف کردن منحنی یادگیری برای کاربران پیدا کنیم، مانند حفظ مفهوم گره های BE در جعبه سیاه.

برای کمک بیشتر در مورد جداسازی حجم کار در آپاچی دوریس، به انجمن آپاچی دوریس بپیوندید.