تصور کنید صورتحساب ابری شما مبلغی هنگفت است و تنها برچسب «Databricks Dbt» روی آن خورده، اما نمیدانید دقیقاً کدام مدلها این هزینه را ایجاد کردهاند. برای حل این بحران، دیتابریکس (Databricks) قابلیت برچسبهای کوئری (Query Tags) را برای خط لولههای dbt در حالت پیشنمایش عمومی عرضه کرد تا برچسبهای کلی را با متادیتای دقیق در سطح مدل جایگزین کند و تیمهای داده دیگر مجبور نباشند برای یافتن عامل تخلیه بودجه خود حدس بزنند.
چالش تخصیص هزینههای dbt
مدیریت یک پروژه dbt با دهها یا حتی صدها مدل، اغلب شبیه نگاه کردن به یک قبض برق کلی است که نمیدانید چرا روشن است و کدام اتاق بیشترین مصرف را دارد. طبق گزارش دیتابریکس، پیش از این وقتی تیمهای داده dbt را روی این پلتفرم اجرا میکردند، تاریخچه کوئریها تنها برچسبهای عمومی و کلی مانند «Databricks Dbt» را نمایش میداد.
این فقدان جزئیات باعث میشد شناسایی مدلهای خاصی که بیشترین منابع را مصرف میکنند یا بیشترین سهم را در هزینههای ابری دارند، بهشدت دشوار باشد. شناسایی منبع دقیق یک جهش ناگهانی در هزینهها نیازمند بازرسیهای دستی، tedious و خستهکننده بود. این موضوع مانع بزرگی برای تیمهایی بود که میخواستند استانداردهای فیناوپس (FinOps) — یعنی مدیریت مالی هوشمند در محیط ابری — و تلاشهای بهینهسازی عملکرد را پیاده کنند.
پیادهسازی فنی و یکپارچگی
بر اساس مستندات فنی، این سامانه جدید مستقیماً با آداپتور dbt-databricks (بهطور خاص برای نسخه ۱.۱۱ و بالاتر) یکپارچه شده است. این امر تضمین میکند که کاربرانی که در حال حاضر از dbt در محیط دیتابریکس خود استفاده میکنند، تجربهای بدون وقفه و روان داشته باشند.
این سازوکار از طریق تزریق خودکار متادیتای خاص به هر کوئری SQL عمل میکند که سپس بهطور دقیق در جدول system.query.history ثبت مینماید. این قابلیت به تیمهای داده اجازه میدهد تا با استفاده از دستورات استاندارد SQL و سینتکسهای دسترسی به دادهها، بینشهای عمیقی درباره مدلهای زمانبر یا پرمصرف به دست آورند.
کنترل دقیق از طریق سطوح برچسبگذاری
کاربران میتوانند این برچسبها را در سه سطح متمایز از کاربرد مدیریت کنند:
- برچسبهای تزریقشده خودکار (Auto-injected Tags): این برچسبها بدون هیچگونه پیکربندی توسط کاربر، در کوئریها جاسازی میشوند. آنها دید فوری نسبت به جزئیات اجرای مدل و استراتژیهای متریالیزاسیون (مانند table، view یا incremental) فراهم میکنند.
- برچسبهای سطح پروفایل (Profile-Level Tags): این برچسبها در تنظیمات پروفایل dbt تعریف میشوند و بر تمام کوئریهای اجرا شده تحت آن پروفایل اعمال میگردند. این سطح برای تخصیص ابعاد کلی مانند نام تیم، مرکز هزینه (cost center)، نام پروژه و محیط اجرا ایدهآل است.
- برچسبهای سطح مدل (Model-Level Tags): این برچسبها در فایل
dbt_project.ymlیا مستقیماً در تعریف SQL مدل اختصاص داده میشوند. این سطح، دقیقترین کنترل را فراهم میکند و با برچسبهای سطح پروفایل ادغام میشود؛ در صورتی که تداخلی وجود داشته باشد، مقادیر اختصاصی مدل اولویت خواهند داشت.
پیشبرد فیناوپس و بینشهای عملکردی
دیتابریکس به یک پروژه مرجع اشاره کرد که در آن تعداد کمی از جداول Mart، بخش بزرگی از زمان محاسبات را به خود اختصاص داده بودند؛ حقیقتی که پیش از این پشت برچسبهای کلی پنهان بود. اکنون تیمها میتوانند با کوئری زدن به جدول system.query.history این نقاط داغ مصرف (usage hotspots) را دقیقاً شناسایی کنند.
این سطح از جزئیات به تیمها کمک میکند تا به سوالات حیاتی درباره افزایش صورتحسابهای انبار داده (Warehouse) پاسخ دهند و تشخیص دهند که تلاشهای بهینهسازی در کجا بیشترین اثر را خواهد داشت. فراتر از هزینهها، برچسبهای کوئری برای عیبیابی مشکلات عملکردی بسیار ارزشمند هستند و به تیمها اجازه میدهند مدلهای کند را سریعاً شناسایی کرده یا ارزیابی کنند که استراتژیهای مختلف متریالیزاسیون چگونه بر زمان اجرا تأثیر میگذارند.
برای پیشبرد این هدف، دیتابریکس یک پروژه مرجع شامل یک داشبورد AI/BI ارائه داده است. این داشبورد از جدول system.query.history بهره میبرد و توسط برچسبهای کوئری خودش فیلتر میشود؛ در واقع یک سیستم خود-مانیتورینگ ایجاد شده است که هزینهها و معیارهای عملکرد خودش را ردیابی میکند.
کاتالوگ یونیتی و قابلیتهای پیشرفته
این قابلیت به کاتالوگ یونیتی (Unity Catalog) و نماهای متری (metric views) آن نیز گسترش یافته است که مفاهیم تجاری قابل استفاده مجدد را تعریف میکنند. تیمها میتوانند با استفاده از پارامتر پیکربندی query_tags کوئریهای خاصی را که برای ایجاد یا بهروزرسانی این نماهای متری استفاده شدهاند، ردیابی کنند.
این امر زمینه عملکردی ضروری را برای تعاریف معنایی (semantic definitions) فراهم میکند و آنها را بهوضوح از databricks_tags (برچسبهای اشیاء کاتالوگ یونیتی) متمایز میسازد؛ برچسبهایی که عمدتاً برای حاکمیت داده (governance) و اکتشاف (discovery) استفاده میشوند.
بهترین شیوهها برای پیادهسازی
برای به حداکثر رساندن کاربرد برچسبهای کوئری، دیتابریکس چندین توصیه را ارائه کرده است:
- سلسلهمراتب منسجم برچسبها: یک ساختار شفاف ایجاد کنید تا از پراکندگی و هرجومرج برچسبها (tag sprawl) جلوگیری شود.
- برچسبگذاری در سطح سازمان: از برچسبهای سطح پروفایل برای ابعاد مشترک مانند
team،cost_center،project_nameوenvironmentاستفاده کنید. - تمایز محیطها: همیشه محیط اجرا (مانند
local-dev،dev،stagingوprod) را برچسبگذاری کنید تا فعالیتهای توسعه از اجراهای محیط تولید جدا شوند. - مدیریت انبار دادههای مشترک: هنگامی که چندین پروژه dbt از یک انبار داده واحد استفاده میکنند، از برچسبهای
project_nameبرای تخصیص دقیق هزینهها به هر خط لوله (pipeline) استفاده کنید. - پرهیز از برچسبگذاری بیش از حد: برچسبهای سفارشی را بر زمینههای تجاری متمرکز کنید که dbt نمیتواند بهطور خودکار استخراج کند، نه اینکه متادیتای تزریقشده خودکار را تکرار کنید.
این تغییر، رویکرد بنیادین مهندسی داده را از عیبیابی واکنشی به بهینهسازی پیشدستانه تبدیل میکند. حالا مهندسان به جای کاهش کلی اندازه انبار داده، میتوانند روی آن ۵٪ از مدلهایی تمرکز کنند که ۸۰٪ هزینه را ایجاد میکنند. گفتگو از «چرا صورتحساب بالاست؟» به «چرا این مدل افزایشی (incremental) خاص ناکارآمد است؟» تغییر میکند.
این توسعه فشار را بر رقبایی مثل اسنوفلیک (Snowflake - NASDAQ:SNOW) افزایش میدهد تا ابزارهای مشاهدهپذیری (observability) خود را بیشتر اصلاح کنند. با مقیاسپذیر شدن انبارهای داده ابری، توانایی نسبت دادن هر سنت هزینه به یک خط کد خاص، به یک ضرورت رقابتی تبدیل شده است. این ابتکار، در کنار تلاشها برای رام کردن مهاجرتهای SQL، تعهد دیتابریکس به سادهسازی عملیات پیچیده داده را نشان میدهد.
مهندسان داده اکنون میتوانند به پروژه مرجع کامل، شامل خط لوله dbt، داشبورد تحلیلی و پیکربندیهای استقرار از طریق گیتهاب دسترسی داشته باشند. همچنین اطلاعات دقیق در یک سند PDF جامع در دسترس است.
گفتگو