معرفی شاخص چند منظوره برای Lakehouse در Apache Hudi

نمایه سازی مانند بسیاری دیگر از سیستم های داده معامله ای و برخلاف انتزاع های قالب ساده جدول ، بخشی جدایی ناپذیر از Apache Hudi بوده است. در این وبلاگ ، ما بحث می کنیم که چگونه ما نمایه سازی مجدداً مورد استفاده قرار داده ایم و یک شاخص چند منظوره جدید را در نسخه آپاچی هودی 0. 11. 0 ساخته ایم ، یک زیر سیستم شاخص با کارایی بالا از نوع اول برای معماری Lakehouse ، برای بهینه سازی عملکردنمایش داده شد و معاملات را بنویسید ، به خصوص برای جداول عظیم و گسترده.

چرا شاخص چند مدلی در هودی

نمایه سازی به طور گسترده در سیستم های پایگاه داده ، مانند بانکهای اطلاعاتی رابطه ای و انبارهای داده برای کاهش هزینه I/O و بهبود کارآیی پرس و جو استفاده می شود. مشابه چگونگی یک صفحه فهرست در انتهای کتاب به شما کمک می کند تا اطلاعات را به سرعت پیدا کنید ، شاخص بانک اطلاعاتی شامل ساختار داده های کمکی برای یافتن سریع سوابق مورد نیاز ، بدون خواندن داده های غیر ضروری از ذخیره است. با توجه به اینکه طراحی هادی برای دستیابی به جریان های تغییر قابل تغییر بهینه شده است ، با الگوهای مختلف نوشتن ، هادی از ابتدای کار خود به طور منحصر به فرد پشتیبانی کرده است تا سرعت بخشیدن به Upserts را در Lakehouse کند. در حقیقت ، ده ها تکنیک نمایه سازی در ادبیات وجود دارد ، و محبوب ترین سیستم های پایگاه داده ، به عنوان مثال ، RDBMS ، PostgreSQL ، MySQL ، Spaer ، CockroachDB و غیره ، یک جعبه ابزار قدرتمند را ارائه می دهد که از بسیاری از آنها پشتیبانی می کند. در حالی که نمایه سازی هودی اکنون برای صعود سریع به صنعت اثبات شده است ، این مزایا برای پرس و جو مورد استفاده قرار نگرفته است. با توجه به مقیاس داده 10-100 برابر در دریاچه های داده در پایگاه داده ها/انبارهای سنتی ، یک زیر سیستم نمایه سازی عمومی می تواند سود عملکرد تغییر بازی را به دریاچه بیاورد. در انتشار HUDI 0. 11. 0 ، ما دوباره تصور کردیم که یک شاخص چند منظوره برای دریاچه ها چگونه باید به نظر برسد. شاخص چند منظوره هودی با تقویت جدول ابرداده با انعطاف پذیری در گسترش به انواع شاخص جدید ، همراه با مکانیسم ساخت شاخص ناهمزمان اجرا شده است. این وبلاگ به اصول اصلی طراحی و چگونگی ارائه شاخص چند منظوره در تمام مکانیسم های نمایه سازی موجود می پردازد ، در حالی که سایر مواردی که از جنبه های باقی مانده پیروی می کنند با جزئیات بیشتری پوشش می دهند.

طراحی و پیاده سازی

• ابرداده مقیاس پذیر: ابرداده جدول ، یعنی داده های کمکی در مورد جدول ، باید به اندازه بسیار بزرگ ، به عنوان مثال ، ترابایت (TB) مقیاس پذیر باشد. انواع مختلف شاخص ها باید به راحتی برای پشتیبانی از موارد مختلف استفاده بدون نیاز به نگرانی در مورد مدیریت یکسان ، یکپارچه شوند.
• به روزرسانی های معاملاتی اسید: شاخص و ابرداده جدول باید همیشه به روز و در همگام سازی با جدول داده ها باشد و نوشتن های جزئی نباید در معرض دید قرار گیرد.
• Lookup Fast: بدون نیاز به اسکن کل شاخص ، نوع جستجوهای سوزن در یک HAYSTACK باید سریع و کارآمد باشد ، زیرا اندازه شاخص می تواند TBS برای مجموعه داده های بزرگ باشد.

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

ابرداده مقیاس پذیر

تمام شاخص های حاوی ابرداده های جدول به عنوان یک جدول ادغام داخلی هادی داخلی (MOR) ، یعنی جدول ابرداده ، در جدول داده ها ذخیره می شوند. این یک روش معمول است که در آن پایگاه داده ها ابرداده را به عنوان نمای داخلی و Apache Kafka به عنوان موضوعات داخلی ذخیره می کنند. جدول ابرداده بدون سرور و مستقل از موتورهای محاسباتی و پرس و جو است. طرح جدول MOR با جلوگیری از ادغام همزمان داده ها با کاهش تقویت نوشتن ، نوشتن سریع صاعقه را ارائه می دهد. این برای مجموعه داده های بزرگ بسیار مهم است زیرا اندازه به روزرسانی های جدول ابرداده می تواند در غیر این صورت غیرقابل کنترل باشد. این به هودی کمک می کند تا ابرداده را با اندازه های دیگر مانند سایر سیستم های داده مانند BigQuery مقیاس کند.

ما در حال حاضر پرونده ها ، column_stats و شاخص های Bloom_filter برای تقویت اجراها در جبهه های مختلف داریم که بعداً در این وبلاگ مشاهده می شود. چارچوب بنیادی ساخته شده است تا برای هر شاخص جدیدی مانند Bitmap ، شاخص های مبتنی بر R-Tree ، شاخص سطح رکورد و موارد دیگر قابل توسعه و مقیاس پذیر باشد. هر شاخصی از این قبیل می تواند بدون نیاز به هماهنگی با شاخص های دیگر ، طبق ضرورت فعال و غیرفعال شود. علاوه بر این ، هودی مفتخر است که نمایه سازی ناهمزمان ، اولین بار در نوع خود را ارائه دهد ، از ساختمان شاخص در کنار نویسندگان معمولی پشتیبانی کند بدون اینکه تأثیر تأخیر در نوشتن داشته باشد (یک وبلاگ به زودی برای بحث در مورد نمایه سازی Async به تفصیل).

به روزرسانی های معاملاتی اسیدی

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

جستجوی سریع

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

ما آزمایشاتی را برای اندازه گیری تأخیر در جستجوی نقطه از ورودی های N در بین 10 میلیون (10 متر) ورودی در یک پرونده برای قالب های مختلف پرونده انجام دادیم. HFile پیشرفت های 10x تا 100x را در مقایسه با پارکت یا Avro نشان می دهد ، که هنوز هم در قالب های دیگری مانند Delta و Iceberg برای ابرداده های جدول استفاده می شود.

از آنجا که بیشترین دسترسی به جدول ابرداده ها به نظر می رسد و از نظر محدوده ای است ، فرمت HFile به عنوان قالب پرونده پایه برای جدول ابرداده داخلی انتخاب می شود. از آنجا که جدول ابرداده داده های کمکی را در سطح پارتیشن (فهرست پرونده ها) یا سطح پرونده (فهرست ستون_Stats) ذخیره می کند ، جستجوی مبتنی بر یک مسیر پارتیشن واحد و یک گروه پرونده با فرمت HFile بسیار کارآمد خواهد بود. هر دو پرونده پایه و ورود به سیستم در جدول ابرداده Hudi از قالب HFile استفاده می کنند. هر پرونده ورود به سیستم می تواند حاوی چندین بلوک ورود باشد. همانطور که از شکل زیر مشاهده می شود ، هودی از یک ایده جدید برای استفاده از سیستم فایل درون خطی برای خواندن محتوای بلوک های داده واقعی به عنوان HFile استفاده می کند ، تا بتواند از جستجوی سریعتر از قالب HFile استفاده کند. این طرح به طور دقیق انتخاب شده است تا تماس های از راه دور را در طرح های ذخیره سازی ابری کاهش دهد زیرا ممکن است جستجوی نقطه برای بارگیری کل پرونده نیازی نداشته باشد.

علاوه بر این ، این شاخص های جدول ابرداده از طریق یک سرور زمانی متمرکز که ابرداده را ذخیره می کند ، ارائه می شود و بیشتر تأخیر جستجو را از مجریان کاهش می دهد.

چگونه شاخص چند مدلی عملکرد را بهبود می بخشد

جدول ابرداده برای بهبود عملکرد برای کاربران HUDI مزایای مختلفی دارد. بیایید نگاهی بیندازیم که چگونه لیست پرونده های هادی می تواند تا 10 برابر بهبود یابد و پرش از داده ها می تواند با استفاده از شاخص چند مدلی ، تأخیر خواندن را با 10 برابر به 30 برابر یا بیشتر کاهش دهد.

لیست پرونده

استقرار بزرگ خطوط لوله تحلیلی در ذخیره های ابر معمولاً دارای 100 کیلومتر یا بیشتر پرونده در 1000 پارتیشن است. لیست مستقیم پرونده در چنین مقیاس اغلب تنگنا به دلیل عملیات پرتاب و بالا I/O است که منجر به مشکلات مقیاس پذیری می شود. برای بهبود عملکرد لیست فایل ، هودی اطلاعات را در یک پارتیشن به نام پرونده ها در جدول ابرداده ذخیره می کند تا از تماس های سیستم فایل مانند وجود ، لیستستاتوس و لیست های موجود جلوگیری کند. پارتیشن پرونده ها اطلاعات پرونده مانند نام پرونده ، اندازه و حالت فعال را برای هر پارتیشن در جدول داده ذخیره می کند.

ما بهبود عملکرد لیست فایل را با استفاده از جداول HUDI در مقیاس های مختلف حاوی تعداد مختلف پرونده ها و پارتیشن ها در آمازون S3 به نمایش می گذاریم. با استفاده از شاخص پرونده ها در جدول ابرداده ، تأخیر لیست پرونده در مقایسه با لیست مستقیم در S3 به شدت کاهش می یابد ، و سرعت 2-10 برابر را ارائه می دهد (از جمله جدول غیر پارتی با پرونده های 1M ، در شکل نشان داده نشده است). از آنجا که ذخیره سازی ابری مانند S3 محدود کننده نرخ و فشار برای تماس با سیستم فایل در مجموعه داده های بسیار بزرگ است ، لیست پرونده مستقیم با افزایش تعداد پرونده های موجود در پارتیشن به خوبی مقیاس نمی یابد و در برخی موارد ، تماس های سیستم پرونده ممکن است کامل نشود. در مقابل ، شاخص پرونده ها به حذف چنین تنگناها کمک می کند و دسترسی سریع به لیست پرونده را فراهم می کند. حتی بهتر ، با استفاده مجدد از خواننده جدول ابرداده و ذخیره شاخص در سرور Timeline ، تأخیر لیست پرونده بیشتر کاهش می یابد.

داده های پرش

یکی دیگر از مزایای مهم جدول ابرداده ، کمک به جستجوی داده ها در هنگام ارائه سؤالات خوانده شده است. Partition Column_Stats آمار ستون های علاقه مند مانند مقادیر حداقل و حداکثر ، مقادیر کل ، تعداد تهی ، اندازه و غیره را برای کلیه پرونده های داده ذخیره می کند. از این آمار در هنگام ارائه نمایش داده های خوانده شده با ستون های علاقه مند استفاده می شود. این می تواند عملکرد پرس و جو را توسط یک عامل بزرگ افزایش دهد زیرا پرونده های بی نظیر فیلتر می شوند ، بدون اینکه از سیستم فایل خوانده شوند و همچنین بار I/O را در سیستم پرونده کاهش می دهد. علاوه بر این ، اگر کاربر خوشه بندی ، سفارش z یا هر گونه بهینه سازی طرح دیگر را پیکربندی کرده باشد ، این می تواند تأخیر پرس و جو را با ترتیب بزرگی کاهش دهد ، زیرا پرونده ها از نظر الگوهای دسترسی ستون های متداول به خوبی ارائه می شوند.

در پارتیشن column_stats ، کلید ضبط با جمع آوری نام ستون ، نام پارتیشن و نام پرونده داده به ترتیب تشکیل شده است ، تا بتوانیم جستجوی نقطه و دامنه های مختلف را انجام دهیم. چنین طراحی کلید رکورد امکان انجام جستجوی پیشوند را در فهرست Column_Stats نیز باز می کند. به عنوان مثال ، همانطور که در بالا نشان داده شده است ، Query1 دارای Col1 و پارتیشن مشخص شده و Query2 Col2 را در پیش بینی ها مشخص کرده است. از پیش بینی ها برای ساخت پیشوند جستجوی به شاخص Column_Stats بدون نیاز به ارائه کلیدهای ضبط کامل استفاده می شود. این به طرز چشمگیری جستجوی شاخص برای مجموعه داده های بزرگ با 100 ثانیه یا حتی 1000 ستون را کاهش می دهد ، زیرا تعداد ورودی های شاخص برای جستجو به ترتیب O (num_ query _columns) است که معمولاً کوچک است (به عنوان مثال ، 5 تا 10) ، در عوضاز o (num_ table _columns) که می تواند عظیم باشد (به عنوان مثال ، بیش از 100 یا 1000).

ما آزمایشی را برای جستجوی مبتنی بر پیشوند با پرونده ای از ورودی های 10 متر انجام دادیم. انتظار می رود هر جستجوی ستون با ورودی های 10K مطابقت داشته باشد. HFile در مقایسه با بهترین های بعدی ، یعنی پارکت ، در همه موارد قادر است حداقل 3 برابر بیشتر تأخیر را نشان دهد. این امر همچنین به نفع عملکرد در فضای ذخیره سازی ابری است ، زیرا این امر به شدت تعداد تماس های از راه دور را کاهش می دهد. با چنین طراحی ، داده های پرش از 10 برابر تا 30 برابر در مورد تأخیر پرس و جو در مقایسه با عدم پرش از داده ها به دست می آورند. در یک وبلاگ پیگیری در مورد داده های پرش با هادی ، جزئیات بیشتری را انتظار داشته باشید.

عملکرد UPSERT

یکی از شاخص های پرکاربرد در هادی ، شاخص مبتنی بر شکوفه است. این شاخص از هرس مبتنی بر دامنه در حداقل و حداکثر مقادیر کلیدهای ضبط و جستجوی مبتنی بر شکوفه برای برچسب زدن سوابق ورودی استفاده می کند. برای جداول بزرگ ، این شامل خواندن پاورقی تمام پرونده های داده مطابق با فیلترهای Bloom است که در صورت بروزرسانی های تصادفی در کل مجموعه داده ها می تواند گران باشد. پارتیشن Bloom_filter در جدول ابرداده برای ذخیره فیلترهای بلوم کلیه پرونده های داده برای جلوگیری از اسکن کردن پاورقی ها از تمام پرونده های داده معرفی شده است. کلید ضبط در این پارتیشن از نام پارتیشن و نام پرونده داده تشکیل شده است. مشابه شاخص Column_Stats ، این نقطه از Point و Prefix Lookup استفاده می کند. بر اساس تجزیه و تحلیل ما برای یک جدول HUDI با فایلهای 100K ، خواندن فیلترهای شکوفه از پارتیشن Bloom_filter در جدول ابرداده 3 برابر سریعتر در مقایسه با خواندن از پاورقی های پرونده داده های فردی است.

کار آینده

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

نتیجه

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