Databricks - унифицированная Lakehouse платформа для ETL, ML и BI нагрузок / Иван Трусов

[@ДмитрийЖучков-щ8н]

Сначала про историю дата-платформ - в начале 2000-х начала активно расти отрасль BI и из OLTP-систем начали выделяться OLAP-системы. Горячие данные выделяются на отдельный DWH-сервер и уже там происходит их аналитическая обработка. Потом DS/ML-нагрузка, в основном состоящая из full-scan’ов, начала нагружать хранилища и их тоже стало не хватать. А заодно и фронтовые монолиты начали разваливаться на микросервисы, и вместо одной core-базы стало много разных backend-баз. В результате обмен данными перешёл на использованием очередей сообщений, которые обмениваются слабоструктурированной информацией. В результате появилось сочетание DataLake + DWH, которое оказалось wrong way, и Data Lake стали слишком часто превращаться в Data Swamp. Предлагаемый выход из ситуации «LakeHouse» - комбинация фич DataLake и DWH, но без дублирования данных. Черты хорошей платформы данных: 1. Поддержка BI, ETL, Streaming/Batch ETL. 2. Спокойное отношение к любым запросам данных от одной ячейки до full-scan 3. Централизованная RBAC. 4. Минимальная дупликация данных. Общие черты Databricks Platform - в самом низу лежит DataLake, т.е. данные любого уровня структурированности, поверх него формируется Delta Lake на основе открытого формата хранения структурированных данных и на самом верху DeltaEngine - кастомизированный и ускоренный Spark на стероидах. Основная идея Databricks Platform - в публичном облаке на серверах Databricks хранится сама платформа, которая работает с пользовательскими данным, лежащим где-то в том же облаке. Контрольная панель (плоскость) Control Plane - также лежит в облаке и находится под контролем поставщика платформы. Клиенты платформы заходят в свой личный кабинет в Control Plane и указывают IP-адреса своих машин, которые будут фактически работать с данными. Платформа поднимает на указанных адресах внутри пользовательского аккаунта свои «воркеры» - виртуальные машины по «золотым» образам. Runtime-воркеров оплачивается платформе по установленным тарифам. Все задачи воркерам ставятся через Control Plane. Безопасность - RBAC, row/column level security. Политики разделения ресурсов кластеров. Для ETL есть нативная интеграция с Airflow и облачными ETL-механизмами. Данные Delta Lake делятся по степени готовности на три слоя: бронзовый, серебряный, золотой. Delta Engine - сильно более быстр, по сравнению с открытым Spark’ом. Ускорение достигается за счет компиляции байт-кода в С++ код, а также за счет умного кеша. Присутствует обратная совместимость со Spark-кодом. Для ML-щиков в комплект включены заранее подготовленные инструменты типа pandas, pyTorch и т.д.. Плюс встроенное версионирование для ML-ноутбуков и поддержка парного программирования, с разделением доступа к коду. Плюс еще много всего для эффективной разработки ML. BI-часть: на основе open-source Re-dash с нативной интеграцией с популярными BI-системами. Дешборды на базе SQL-запросов. Встроенный алертинг. История запросов. Прямой доступ через интерфейсы OBDC/JDBC. Нативные клиенты для Delta Lake уже доступны на Python Java, Scala, Rust (по крайней мере чтение уже точно есть). Роутинг запросов позволяет пропускать вперёд запросы, которые потребуют мало ресурсов. Photon - быстрый движок для исполнения запросов. Свой построитель DAG’ов на Python-коде. При сравнении фич с конкурентами подчеркивается крутость заноса ML в хранилище - если вам нужен ML в продакшене, но других вариантов просто нет.

[@ivantrusov5995]

@Дмитрий, доброе утро! Спасибо большое за такое подробное summary :) Все написано правильно, но буквально пара моментов которые возможно я не совсем явно осветил: > Клиенты платформы заходят в свой личный кабинет в Control Plane и указывают IP-адреса своих машин, которые будут фактически работать с данными. Платформа поднимает на указанных адресах внутри пользовательского аккаунта свои «воркеры» - виртуальные машины по «золотым» образам. Runtime-воркеров оплачивается платформе по установленным тарифам. Все задачи воркерам ставятся через Control Plane. Это не совсем верно. В своем облачном аккаунте вы определяете ресурсные группы в которых Databricks имеет право запускать VM. Явного указания IP адресов нет (хотя можно ограничить запуски VM конкретными подсетями). > Свой построитель DAG’ов на Python-коде. Видимо это ощущение исходя из демо, но вообще говоря Delta Live Tables могут работать и на Python, и на Scala, и на SQL. > При сравнении фич с конкурентами подчеркивается крутость заноса ML в хранилище - если вам нужен ML в продакшене, но других вариантов просто нет. Как раз таки наоборот - я говорил о том что в Lakehouse архитектуре можно эффективно (=масштабируемо, дешево и быстро) доставать данные из хранилища и делать над ними ML. В типичной DWH архитектуре доставать данные для ML из хранилища не-эффективно (либо дорого, либо требует много ресурсов, либо и то и другое). Из за этого часто в DWH пытаются занести ML "внутрь", но я не видел успешных попыток это сделать, и я не припомню ни одной архитектуры где это бы считалось "best practice" - вот что я имел в виду.

[@dmitryg4781]

@@ivantrusov5995 хороший обзор вышел, мы мигрируем с on-perm hadoop, я уже глубоко уже капнул, но и мне было интересно. повсюду есть тонкие намеки, тут наконец услышал прямо, что databricks runtime это не java. не знал про feature store, хотя целенаправленно вроде искал на замену нашему. видел видос от датабрикс, но почему то про hopsworks. у меня вопрос по датабриксу, у нас типичный эентерпрайз, сотни oltp систем доставляют данные в data lake, в том числе и в open source delta записываем. нам пришлось суровый шедуллер изобрести, он блокирует джобы которые могут друг другу помешать, смотрит на приоритет, не дает джобу одного типа слишком часто запускаться и т.п. у датабрикса подобные задачи на нечто типа airflow возлагаются ?

[@ДмитрийЖучков-щ8н]

@@ivantrusov5995 спасибо за доклад, замечания по summary, разумеется, могу только принять :)

[@ivantrusov5995]

@@dmitryg4781 я думаю что если у вас уже есть сложный шедулинг который интегрирует много разных систем - стоит либо переиспользовать его (можно вызывать Databricks Jobs API прямо из шедулера), либо посмотреть в сторону Airflow (либо self-hosted, либо MWAA, либо Prefect), либо Azure Data Factory (если вы на Azure). Наш Feature Store - новая компонента, ее мы анонсировали на последнем DAIS 2021. Можете написать вашему архитектору в Databricks (или мне в LinkedIn, если не знаете кто ваш архитектор) - мы с удовольствием проведем демо и расскажем как им пользоваться.

[@serhiikholodniuk4894]

@@ivantrusov5995 Спасибо за доклад, смог посмотреть его только сегодня. Я работаю в компании которая занимается разработкой софтверных решений для клиентов со всего мира. В середине компании есть компетенции по Spark-у, также удалось реализовать проекты на Apache Hudi и Snowflake. Хотим розширить компетенцию в направлении LakeHouse и других компонент Databricks, что порекомендуете в этом направлении? Пройти сертификации или может порекомендуете дополнительные материалы, кроме документации. Также в видео вы упомянули о своем телеграм-канале, можете ли им поделиться?

[@ПавелРевин-о6о]

Огромное спасибо за доклад! Слушал с удовольствием. Очень не хватает таких материалов на русском языке...

[@pismarevvitaly3257]

Спасибо за видео, было интересно. Отдельный респект Дмитрию про вопрос датабрикс vs snowflake. Прям в яблочко вопрос ибо рассм эти решения )

[@zafardjunaydullaev9539]

Дима, интересная архитектура. А Датафактори на эйрфлоу заменить не думали?

[@darkside1995free]

Постоянно появляется сообщение "Databricks products and services are currently not authorized for use in this region." при авторизации в community edition Есть возможность обойти?

[@egorsviridenko1161]

из Беларуси работает

[@vyacheslavs5642]

Таймкоды бы не помешали

[@timurakhalaya6289]

много ненужной информации

[@pavlos_pk]

Не слушай