داده سازمان ثابت نمی‌ماند

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

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

تغییر فنی به هماهنگی نیاز دارد

برای تیم سازمانی، این امکانات پایان مسئله نیستند. اگر معنای یک ستون تغییر کند، داشبورد و مصرف‌کنندگان پایین‌دست باید از آن باخبر شوند. پیشنهاد می‌شود هر تغییر همراه با توضیح کسب‌وکاری، مالک تأییدکننده و فهرست گزارش‌های وابسته ثبت شود. تغییر نام فنی نباید تعریف شاخص را پنهانی عوض کند.

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

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

نمونه تغییر پارتیشن در Apache Iceberg

اگر جدول و ستون‌های مثال از قبل وجود داشته باشند، API جاوا می‌تواند مشخصات پارتیشن نوشتن داده‌های بعدی را تغییر دهد. فایل‌های قدیمی فوراً بازنویسی نمی‌شوند.

افزودن پارتیشن سطلی و حذف پارتیشن قدیمی
orders.updateSpec()
    .addField(bucket("customer_id", 16))
    .removeField("region")
    .commit();

این قطعه فرض می‌کند orders یک شیء Table آماده و region فیلد پارتیشن فعلی است؛ نام‌ها و تعداد سطل‌ها باید با داده واقعی تنظیم شوند.

یک جدول را تا انتها آزمایش کنید

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

توضیح‌ها و پیشنهادهای اجرایی این مطلب، تحلیل تحریریه دانشنامه لیان هستند.منابع: Apache Iceberg — Evolution · AWS — Apache Iceberg in a Data Lake

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