Сегодня столкнулся с интересным кейсом по Azure Databricks. Что дано: • 3 Azure Subscriptions Dev/Test/Prod • 3 Azure Databricks Workspaces Все четко и понятно. Databricks уже давно использует Unity Catalog вместо обычного Hive. Кстати он есть open source. Unity Catalog — это централизованный каталог и система управления данными от Databricks. Представь, что в компании есть десятки таблиц, файлов, ML-моделей, разбросанных по разным облакам и воркспейсам. Unity Catalog — это единое место, где всё это зарегистрировано, где видно кто к чему имеет доступ, откуда пришли данные и куда они идут. Он решает три главных вопроса: Кто может видеть данные? — можно задавать права вплоть до отдельных строк и столбцов таблицы. Откуда эти данные и можно ли им доверять? — автоматически строится граф происхождения данных (lineage): от источника до дашборда. Как найти нужные данные? — есть поисковый интерфейс с описаниями, тегами и метаданными. Всё это работает единообразно для любого воркспейса в аккаунте Databricks, что и делает его «единым» (Unity). Оказалось спустя почти года разработки, оказалось, что Metastore находится в Dev подписке. Metastore — это хранилище метаданных, то есть место, где Unity Catalog держит всю информацию о данных, но не сами данные. Проще говоря, metastore знает: какие таблицы существуют, где физически лежат их файлы в облаке, какая у них схема (столбцы и типы), кто имеет к ним доступ и т.д. Это как оглавление книги — само содержимое страниц хранится отдельно, но оглавление говорит тебе, где что искать. В контексте Unity Catalog metastore — это верхний уровень иерархии. Внутри него живут каталоги (catalogs), внутри каталогов — схемы (schemas), а внутри схем уже таблицы и прочие объекты. На один аккаунт Databricks в одном регионе обычно один metastore, и все воркспейсы в этом регионе к нему подключаются и видят одни и те же метаданные. У metastore есть особенность, о которой мы узнали только сегодня - можно только иметь один на целый Azure регион. А как вы знаете, очень важно, чтобы все ресурсы были всегда в одном регионе (в одном дата центре). Из-за этого исторически так получилось, что все 3 workspaces привязаны к одному metastore и все ресурсы Azure завязаны на один и тот же регион. Это прям ахиллесова пята Databricks. Оказалось, что спустя почти год внедрения нашли этот косяк и решили мигрировать. Хранить все метаданные в dev совсем не комильфо. Databricks стал очень metadata driven, то есть все его Declarative Jobs, Autoloader и тп - все находится в каталоге. И весь ваш прогресс тоже завязан на каталог. Сегодня мы пытались создать новый каталог в prod подписке. А из-за того, чтобы один metastore на регион, у нас ничего не получилось. При этом подготовка к этому перформансу заняла больше месяца у подрядчика. И это они же запили сердце databricks в dev. И теперь они готовились 2 месяца, чтобы узнать об ограничении региона. Я как мог их поддерживал шутками и прибаутками, даже взял на себя ответственность расшарить экран и мышкой кликать. PS проблему пока не решили в лоб. Вот так, век живи, век учись!