جداسازی خواندن/نوشتن کم‌هزینه: جری یک معماری ماکت اصلی کلیک خانه می‌سازد

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

با افزایش اندازه داده ها، ما با چالش های عملکرد و هزینه با AWS Redshift مواجه شدیم. تغییر به ClickHouse عملکرد پرس و جو ما را 20 برابر بهبود بخشید و هزینه ها را تا حد زیادی کاهش داد. اما این نیز چالش‌های ذخیره‌سازی مانند خرابی دیسک و بازیابی اطلاعات را به همراه داشت.

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

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

معماری داده: از Redshift تا ClickHouse

در ابتدا، ما Redshift را برای پرس و جوهای تحلیلی انتخاب کردیم. اما با افزایش حجم داده‌ها، با چالش‌های عملکردی و هزینه‌ای شدید مواجه شدیم. به عنوان مثال، هنگام تولید گزارش‌های آزمایشی قیف و A/B، با زمان بارگذاری تا ده‌ها دقیقه مواجه بودیم. حتی در یک خوشه Redshift با اندازه معقول، این عملیات بسیار کند بود. این باعث شد سرویس داده ما در دسترس نباشد.

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

• زمان بارگذاری گزارش از ده ها دقیقه به ثانیه کاهش یافت. این کار راندمان پردازش داده ما را تا حد زیادی بهبود بخشید.
• هزینه های کلی به یک چهارم یا کمتر از مقدار قبلی کاهش یافت.

ClickHouse به هسته معماری ما تبدیل شد و با Snowflake برای مدیریت 1% باقی مانده از وظایف داده ای كه ClickHouse قادر به مدیریت آنها نبود، تکمیل شد. این تنظیمات تبادل داده ها را بین ClickHouse و Snowflake تضمین می کند.

استقرار کلیک هاوس و چالش ها

ما در ابتدا به چند دلیل یک استقرار مستقل را حفظ کردیم:

• کارایی: استقرارهای مستقل از سربار خوشه ها جلوگیری می کنند و تحت منابع محاسباتی برابر عملکرد خوبی دارند.
• هزینه های تعمیر و نگهداری: استقرارهای مستقل کمترین هزینه نگهداری را دارند. این نه تنها هزینه های تعمیر و نگهداری یکپارچه را پوشش می دهد، بلکه تنظیمات داده های برنامه و هزینه های نگهداری در معرض لایه برنامه را نیز پوشش می دهد.
• قابلیت های سخت افزاری: سخت افزار فعلی می تواند از استقرار ClickHouse مستقل در مقیاس بزرگ پشتیبانی کند. به عنوان مثال، اکنون می توانیم نمونه های EC2 را در AWS با 24 ترابایت حافظه و 488 vCPU دریافت کنیم. این در مقیاس از بسیاری از خوشه های ClickHouse مستقر شده پیشی می گیرد. این نمونه ها همچنین پهنای باند دیسک را برای برآوردن ظرفیت برنامه ریزی شده ما ارائه می دهند.

بنابراین با توجه به حافظه، CPU و پهنای باند ذخیره سازی، ClickHouse مستقل راه حل قابل قبولی است که برای آینده قابل پیش بینی موثر خواهد بود.

با این حال، راه حل ClickHouse نیز مشکلات ذاتی دارد:

• خرابی های سخت افزاری: هنگامی که خرابی های سخت افزاری رخ می دهد، ClickHouse خرابی طولانی مدت را تجربه می کند. این یک تهدید برای تداوم و پایداری برنامه است.
• انتقال داده ها و پشتیبان گیری: انتقال داده ها و پشتیبان گیری در ClickHouse همچنان وظایف چالش برانگیزی هستند و دستیابی به یک راه حل قوی هنوز دشوار است.

پس از استقرار ClickHouse، با مشکلات زیر مواجه شدیم:

• مقیاس بندی و نگهداری ذخیره سازی: رشد سریع داده ها، حفظ نرخ استفاده معقول از دیسک را چالش برانگیز کرده است.
• خرابی دیسک: ClickHouse برای استفاده تهاجمی از منابع سخت افزاری برای ارائه عملکرد بهینه پرس و جو طراحی شده است. این منجر به عملیات خواندن و نوشتن مکرر می شود که اغلب پهنای باند دیسک را به حد خود می رساند. این احتمال خرابی سخت افزار دیسک را افزایش می دهد. هنگامی که چنین خرابی هایی رخ می دهد، بسته به حجم داده، بازیابی می تواند از چند ساعت تا بیش از ده ساعت طول بکشد. ما تجربیات مشابهی را از کاربران دیگر شنیده ایم. اگرچه سیستم های تجزیه و تحلیل داده ها معمولاً کپی داده های سایر سیستم ها در نظر گرفته می شوند، تأثیر این خرابی ها هنوز قابل توجه است. بنابراین، ما باید به خوبی برای خرابی های سخت افزاری احتمالی آماده باشیم. پشتیبان‌گیری، بازیابی و انتقال داده‌ها وظایف چالش برانگیزی هستند که برای مدیریت مؤثر به تلاش و منابع بیشتری نیاز دارند.

چرا ما JuiceFS را انتخاب کردیم

برای حل نقاط درد خود، JuiceFS را به دلایل زیر انتخاب کردیم:

• JuiceFS بود فقط سیستم فایل POSIX موجود است که می تواند در ذخیره سازی اشیاء اجرا شود.
• ظرفیت نامحدود: از زمانی که ما شروع به استفاده از آن کردیم، دیگر لازم نیست نگران ظرفیت ذخیره سازی باشیم.
• مزیت هزینه قابل توجه: در مقایسه با راه حل های دیگر، JuiceFS هزینه های ما را به شدت کاهش می دهد.
• قابلیت عکس فوری قدرتمند: JuiceFS به طور هوشمندانه مدل شاخه‌بندی Git را در سطح سیستم فایل اعمال می‌کند و آن را به درستی و کارآمد پیاده‌سازی می‌کند.. وقتی دو مفهوم مختلف به طور یکپارچه با هم ادغام می شوند، اغلب راه حل های بسیار خلاقانه ای تولید می کنند. – این امر حل مسائل چالش برانگیز قبلی را بسیار ساده تر می کند.

اجرای ClickHouse در JuiceFS

ما به ایده مهاجرت ClickHouse به یک محیط ذخیره سازی مشترک بر اساس JuiceFS رسیدیم. مقاله Exploring Storage and Computing Separation for ClickHouse بینش هایی را برای ما ارائه کرد.

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

اگرچه عملکرد نوشتن به 10٪ تا 50٪ سرعت نوشتن دیسک کاهش یافت، این برای ما قابل قبول بود:

در اینجا تنظیمات تنظیمی که برای نصب JuiceFS انجام دادیم آمده است:

• برای دستیابی به نوشتن ناهمزمان و جلوگیری از مشکلات احتمالی مسدود کردن، ویژگی نوشتن بازگشت را فعال کردیم.
• در تنظیمات کش، ما تنظیم کردیم attrcacheto تا 3600.0 ثانیه، cache-size به 2,300,000 رسید و ویژگی متا کش را فعال کرد.
• با توجه به اینکه زمان اجرای I/O در JuiceFS ممکن است طولانی تر از دیسک های محلی باشد، ما استراتژی خود را با معرفی ویژگی block-interrupt تنظیم کردیم.

هدف بهینه سازی ما بهبود نرخ بازدید حافظه پنهان بود. با استفاده از سرویس ابری JuiceFS، ما با موفقیت نرخ ضربه کش را به 95% افزایش دادیم. اگر به بهبود بیشتر نیاز داشته باشیم، اضافه کردن منابع دیسک بیشتری را در نظر خواهیم گرفت.

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

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

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

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

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

چرا ما یک معماری مشابه اولیه راه اندازی کردیم

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

• بحث منابع باعث کاهش عملکرد شد. در راه‌اندازی ما، همه وظایف بر روی یک نمونه ClickHouse اجرا می‌شدند. این منجر به تضادهای مکرر بین وظایف استخراج، تبدیل و بارگذاری (ETL) و وظایف گزارش شد که بر عملکرد کلی تأثیر گذاشت.
• خرابی های سخت افزاری باعث خرابی شد. شرکت ما باید همیشه به داده ها دسترسی داشته باشد، بنابراین توقف طولانی مدت غیرقابل قبول بود. بنابراین، ما به دنبال راه حلی بودیم که ما را به راه حل یک معماری اولیه- replica رساند.

JuiceFS از چندین نقطه نصب در مکان های مختلف پشتیبانی می کند. ما سعی کردیم فایل سیستم JuiceFS را در جای دیگری نصب کنیم و ClickHouse را در همان مکان اجرا کنیم. اما در حین اجرا با مشکلاتی مواجه شدیم:

• ClickHouse یک فایل را محدود کرد تا تنها توسط یک نمونه از طریق مکانیسم‌های قفل فایل اجرا شود، که چالشی را ایجاد کرد. خوشبختانه، با تغییر کد منبع ClickHouse برای کنترل قفل، این مشکل به راحتی قابل حل بود.
• حتی در طول عملیات فقط خواندنی، ClickHouse برخی از اطلاعات وضعیت، مانند حافظه پنهان زمان نوشتن را حفظ می کرد.
• همگام سازی متادیتا نیز مشکل ساز بود. هنگام اجرای چندین نمونه ClickHouse در JuiceFS، برخی از داده های نوشته شده توسط یک نمونه ممکن است توسط دیگران شناسایی نشود. این مورد نیاز به راه اندازی مجدد نمونه برای حل مشکل دارد.

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

چگونه یک نمونه مشابه برای ClickHouse ایجاد کردیم

1. ایجاد یک عکس فوری: ما از دستور JuiceFS snapshot برای ایجاد دایرکتوری عکس فوری از دایرکتوری داده ClickHouse در نمونه اولیه و استقرار یک سرویس ClickHouse در این دایرکتوری استفاده کردیم.
2. توقف صف های مصرف کننده کافکا: قبل از شروع نمونه ClickHouse، باید مصرف محتوای حالت دار از سایر منابع داده را متوقف کنیم. برای ما، این به معنای توقف صف پیام کافکا برای اجتناب از رقابت برای داده های کافکا با نمونه اولیه بود.
3. ClickHouse را در پوشه snapshot اجرا کنید: پس از راه اندازی سرویس ClickHouse، مقداری فراداده را برای ارائه اطلاعاتی در مورد زمان ایجاد ClickHouse به کاربران تزریق کردیم.
4. جهش داده های ClickHouse را حذف کنید: در نمونه replica، ما تمام جهش های داده را برای بهبود عملکرد سیستم حذف کردیم.
5. انجام تکثیر مداوم: عکس های فوری فقط در زمان ایجاد حالت خود را حفظ می کنند. برای اطمینان از اینکه نمونه replica آخرین داده ها را می خواند، ما به صورت دوره ای نمونه replica را دوباره ایجاد می کنیم و نمونه اصلی را جایگزین می کنیم. این روش بصری و کارآمد است، با هر نمونه ماکت از دو ماکت شروع می شود و یک اشاره گر به یک ماکت اشاره می کند. ما می‌توانیم بر اساس بازه‌های زمانی یا شرایط خاص، ماکت دیگری را دوباره بسازیم و نشانگر را به سمت ماکت تازه ایجاد شده بدون خرابی نشان دهیم. حداقل فاصله زمانی ما 10 دقیقه است، اما معمولا یک بار در ساعت دویدن می تواند نیاز ما را برآورده کند.

معماری شبیه سازی اولیه ClickHouse ما بیش از یک سال است که به طور پایدار اجرا می شود. بیش از 20000 عملیات تکرار را بدون شکست انجام داده است که قابلیت اطمینان بالایی را نشان می دهد. جداسازی حجم کار و پایداری کپی داده ها کلید بهبود عملکرد هستند. ما با موفقیت در دسترس بودن گزارش کلی را از کمتر از 95٪ به 99٪، بدون هیچ گونه بهینه سازی لایه برنامه افزایش دادیم. علاوه بر این، این معماری از پوسته پوسته شدن الاستیک پشتیبانی می کند و انعطاف پذیری را تا حد زیادی افزایش می دهد. این به ما این امکان را می دهد تا خدمات جدید ClickHouse را در صورت نیاز بدون عملیات پیچیده توسعه و استقرار دهیم.

سناریوهای کاربردی JuiceFS

تبادل اطلاعات

ما بر روی کاربرد ClickHouse تمرکز می کنیم. با استفاده از توانایی آن برای دسترسی به فضای ذخیره‌سازی مشترک، ما بسیاری از سناریوهای جالب را باز کرده‌ایم. قابل ذکر است که نصب JuiceFS در JupyterHub بسیار چشمگیر بوده است.

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

خطوط لوله یادگیری ماشین

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

Kafka+JuiceFS

ما داده های کافکا را در JuiceFS ذخیره می کنیم. اگرچه ما اغلب به طور مستقیم به کافکا دسترسی نداریم، اما برای ذخیره بلندمدت دارایی داده ارزش قائل هستیم. در مقایسه با استفاده از محصولات معادل AWS، این رویکرد به طور محافظه کارانه ای حدود 10 تا 20 برابر در هزینه صرفه جویی می کند..

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

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

بعدش چی

برنامه های ما برای آینده:

• ما یک رابط کنترلی بهینه برای خودکارسازی مدیریت چرخه عمر نمونه، عملیات ایجاد و مدیریت حافظه پنهان ایجاد خواهیم کرد.
• در طول عملیات معماری اولیه، ما مشاهده کردیم که نمونه اولیه در مقایسه با دیسک های محلی بیشتر مستعد خرابی در JuiceFS بود. اگرچه داده‌ها معمولاً می‌توانند همگام‌سازی شوند و داده‌های همگام‌سازی شده معمولاً توسط نسخه‌های مشابه دیگر قابل دسترسی هستند، ما باید این موضوع را هنگام رسیدگی به خرابی‌ها در نظر بگیریم. اگرچه ما درک مفهومی و نظری از علل تصادفات داریم، اما موضوع را به طور کامل حل نکرده ایم. به طور خلاصه، از آنجایی که سیستم I/O در سیستم فایل بیشتر از دیسک های محلی طول می کشد، این ناهنجاری ها می توانند به اجزای دیگر منتشر شوند و به طور بالقوه باعث از کار افتادن نمونه اولیه شوند.
• همچنین قصد داریم عملکرد نوشتن را بهینه کنیم. از لایه برنامه، با توجه به پشتیبانی قوی از فرمت باز پارکت، می‌توانیم برای دسترسی آسان‌تر، بیشتر بارها را مستقیماً در JuiceFS خارج از ClickHouse بنویسیم. این به ما امکان می دهد از روش های سنتی برای دستیابی به نوشتن موازی استفاده کنیم و در نتیجه عملکرد نوشتن را بهبود ببخشیم.
• ما متوجه پروژه جدیدی به نام chDB شدیم که به کاربران اجازه می دهد تا عملکرد ClickHouse را مستقیماً در محیط پایتون بدون نیاز به سرور ClickHouse جاسازی کنند. با ترکیب CHDB با JuiceFS، می توانیم به یک ClickHouse کاملاً بدون سرور دست یابیم. این مسیری است که ما در حال حاضر در حال بررسی آن هستیم.

اگر سؤالی در مورد این مقاله دارید، می توانید به بحث های JuiceFS در GitHub و انجمن آنها در Slack بپیوندید.