Плейлист хороших видео про Лейкхаусы
1.
Вебинар - Поднимаем Lakehouse на основе Trino.
Старался раскрыть мотивацию, зачем нужен лейкхаус и какая его ниша применения. Во второй половине - воркшоп, как сделать лейкхаус в облаке за 20 минут.
2.
Доклад от Димы Зуева на VK Data Meetup - Роль Trino в Т-Банке
Отличный рассказ о том, как изменилась практика применения движка Трино, с какими ограничениями столкнулась команда и как они их преодолели.
3.
Владимир Озеров о том как на самом деле работает Iceberg Catalog
Просто о сложном. Как оно работает.
1.
Вебинар - Поднимаем Lakehouse на основе Trino.
Старался раскрыть мотивацию, зачем нужен лейкхаус и какая его ниша применения. Во второй половине - воркшоп, как сделать лейкхаус в облаке за 20 минут.
2.
Доклад от Димы Зуева на VK Data Meetup - Роль Trino в Т-Банке
Отличный рассказ о том, как изменилась практика применения движка Трино, с какими ограничениями столкнулась команда и как они их преодолели.
3.
Владимир Озеров о том как на самом деле работает Iceberg Catalog
Просто о сложном. Как оно работает.
VK Видео
Поднимаем Data Lakehouse на основе Trino в облаке
11 февраля в 17:00 на вебинаре мы разберём, что такое Data Lakehouse и как эта архитектура объединит преимущества Data Lake и Data Warehouse, упрощая управление, хранения и анализ данных из различных источников в одном месте. Покажем, как новый облачный сервис…
👍11❤5👏3
3 сценария развития дата офиса и зачем нам DLH в каждом из них.
Все хорошо, мы развиваемся
Главный вызов - рост челенжа. Это только кажется, что при росте объема данных с 20 до 100 ТБ мы прирастаем всего в 5 раз. На самом деле у нас больше аналитиков, а это больше потоков нагрузки. Новые аналитики привносят новые датасеты, которые надо джойнить со старыми и проверять на качество.
Бизнес собрал все низковисящие фрукты и стал задавать сложные вопросы, а это рост сложности и перекрученности среднего запроса. А еще обязательно попросят обновлять данные не 1 раз в день, а максимум через 5 минут с прода они были.
Надо ли говорить, что старая MPP система может не справиться, а заливать все бюджетами может не получиться. Нужно технологическое решение, чтобы эффективно и без огромных бюджетов "съедать" все возрастающие требования.
Все плохо, мы экономим
Здесь главное - сохранить команду. Если инфраструктура не умеет сживаться в деньгах, то единственный способ сэкономить это увольнять. Не хочется стоять перед таким отсутствием выбора. Лучше если ваша система и расходы на нее умеет скалироваться вниз.
Все идет как идет
Если вы собрались на пенсию, то в целом можно ничего не делать. В другом случае риск попадания в застой существенный. И, как мы знаем, любой застой оканчивается плохо.
Все хорошо, мы развиваемся
Главный вызов - рост челенжа. Это только кажется, что при росте объема данных с 20 до 100 ТБ мы прирастаем всего в 5 раз. На самом деле у нас больше аналитиков, а это больше потоков нагрузки. Новые аналитики привносят новые датасеты, которые надо джойнить со старыми и проверять на качество.
Бизнес собрал все низковисящие фрукты и стал задавать сложные вопросы, а это рост сложности и перекрученности среднего запроса. А еще обязательно попросят обновлять данные не 1 раз в день, а максимум через 5 минут с прода они были.
Надо ли говорить, что старая MPP система может не справиться, а заливать все бюджетами может не получиться. Нужно технологическое решение, чтобы эффективно и без огромных бюджетов "съедать" все возрастающие требования.
Все плохо, мы экономим
Здесь главное - сохранить команду. Если инфраструктура не умеет сживаться в деньгах, то единственный способ сэкономить это увольнять. Не хочется стоять перед таким отсутствием выбора. Лучше если ваша система и расходы на нее умеет скалироваться вниз.
Все идет как идет
Если вы собрались на пенсию, то в целом можно ничего не делать. В другом случае риск попадания в застой существенный. И, как мы знаем, любой застой оканчивается плохо.
👍9❤3👌2
Спасибо всем, кто слушал онлайн и в зале.
Обсудим в комментах
Обсудим в комментах
❤7👍2👏1
Аптаймы
Есть байка, что где-то у кого-то есть сервер с аптаймом 32 года. То есть не выключавшийся и не перезагружавшийся ни разу с 1993 года.
Интересно, есть ли ETL пайплайн, который работает ну хотя бы с 2015-го? 10 лет.
Рекорд, который я видел своими глазами, - 1100 успешных дневных запусков подряд. 3,5 года.
С огромной вероятностью, ни сервер, ни пайплайн в реальности никому не нужны и греют воздух бесполезно.
Есть байка, что где-то у кого-то есть сервер с аптаймом 32 года. То есть не выключавшийся и не перезагружавшийся ни разу с 1993 года.
Интересно, есть ли ETL пайплайн, который работает ну хотя бы с 2015-го? 10 лет.
Рекорд, который я видел своими глазами, - 1100 успешных дневных запусков подряд. 3,5 года.
С огромной вероятностью, ни сервер, ни пайплайн в реальности никому не нужны и греют воздух бесполезно.
❤9😁7🤔2
Forwarded from Trino и CedrusData
Всем привет! 24 апреля в Москве в офисе Лемана Тех пройдет очередной митап по технологиям Trino и Apache Iceberg! Также будет доступна онлайн-трансляция.
В программе:
- Доклад от Лемана Тех про миграцию на Trino
- Доклад от Азбуки Вкуса про использование каталога Nessie
- Круглый стол про проблемы внедрения lakehouse с инженерами T-Банк, S7 Airlines, Лемана Тех и Кверифай Лабс
Регистрация по ссылке: https://cedrusdata.timepad.ru/event/3299844/
В программе:
- Доклад от Лемана Тех про миграцию на Trino
- Доклад от Азбуки Вкуса про использование каталога Nessie
- Круглый стол про проблемы внедрения lakehouse с инженерами T-Банк, S7 Airlines, Лемана Тех и Кверифай Лабс
Регистрация по ссылке: https://cedrusdata.timepad.ru/event/3299844/
cedrusdata.timepad.ru
Lakehouse Meetup #3: внедрение Trino в Лемана Тех, опыт работы с Nessie в Азбуке Вкуса, круглый стол о проблемах lakehouse / События…
Рассмотрим реальный опыт внедрения современных технологий анализа данных: реализация lakehouse на Trino в Лемана Тех, использование Nessie в Азбуке Вкуса. После этого обсудим за круглым столом насущные проблемы lakehouse с инженерами Лемана Тех, S7 Airlines…
🔥12
Отраслевые тесты для OLAP
Коллеги, поделитесь, какие вы используете тесты для изменения перформанса OLAP? Есть ли что-то кроме TPC-DS?
Есть у меня мой "авторский" на данных блокчейна Ethereum. Но к нему надо больше запросов написать как минимум и какой-то раннер прикрутить еще. Зато там данных много: Ehereum это около 6 ТБ данных транзакций, а Polygon 20 уже.
Коллеги, поделитесь, какие вы используете тесты для изменения перформанса OLAP? Есть ли что-то кроме TPC-DS?
Есть у меня мой "авторский" на данных блокчейна Ethereum. Но к нему надо больше запросов написать как минимум и какой-то раннер прикрутить еще. Зато там данных много: Ehereum это около 6 ТБ данных транзакций, а Polygon 20 уже.
🤷♂4👏4🤔3
Подлинная революция
Пока мы тут про лейкхаусы, в российском ИТ случилась настоящая революция.
1С научился хранить файлы в S3.
Пока мы тут про лейкхаусы, в российском ИТ случилась настоящая революция.
1С научился хранить файлы в S3.
Хабр
Как мы учили «1С: Предприятие» работать с объектным хранилищем S3: предпосылки, алгоритм, результат
Платформа «1С:Предприятие» де-факто является стандартом в части ПО для управления процессами и работы с данными для многих компании. Но «стоковых» интеграций, с которыми компании начинают свой путь,...
😁11👍6🥰2✍1😱1🙈1
На день космонавтики
64 года назад мы достигли многого. Мы вывели человека за пределы его колыбели и нюхнули свободы взрослого мира.
Сейчас многие вслед за Илоном нашим Маском мыслями обращаются к Марсу. И воображают что слетать туда все равно что в соседний город. Но если задуматься о масштабах, то все окажется совсем по-другому.
Упражнение с глобусом
Если взять в руки школьный глобус с диаметром 30 см, на какой высоте летал Гагарин и какая высота орбиты МКС? 1 сантиметр. Это уже для нас Космос!
А Луна? Луна на расстоянии 9 метров. Это уже соседняя квартира.
А Марс? Порядка 5 километров! 3 автобусные остановки или час пешком.
Ближайшая потенциально обитаемая планета? Очень повезло, она в ближайшей же звездной системе - это Проксима Центавра B, на ней может быть жидкая вода. Расстояние? Да забудьте - там 900 тысяч километров!
Теперь представьте поход на 23 раза обогнуть экватор в то время, как мы нормально освоили только 1 сантиметр этого пространства! Эволюционно мы на уровне инфузорий, которые и путешествуют за свою жизнь на несколько сантиметров. Теперь Илон предлагает нам приложить титанические усилия для эволюции, ну, в простейшую гидру, которая может теоретически утопать на 5 км от места своего рождения и выжить. А до звезд все еще нужен разум и реактивный самолет.
Человеку трудно представить масштабы этих расстояний и стоящих задач.
Но. Давайте в этот день праздновать. У нас есть важное отличие от инфузорий, оно в том, что мы способны осмыслить внутри себя самый дальний поход. Мы способны измерить, оценить, подсчитать, составить план. Мы даже способны вообразить задачи на сотни поколений вперед, где давно уже не будет никаких нас.
Люди на каноэ
Когда-то на берегу Тихого океана люди спустили на воду каноэ из тростника и поплыли в неизвестность. Они не знали, сколько плыть, не знали, есть ли там вообще пригодная земля. Неизвестно, сколько их сгинуло. Но известно, что все, даже самые удаленные, острова в океане на пол-Глобуса оказались заселены.
У нас огромное преимущество перед людьми на каноэ. Мы точно знаем, куда и сколько нам лететь. Мы знаем, что именно там находится. Мы в куда более лучшем положении чем люди на каноэ.
Почему мы хотим покорить Космос? Да потому что он, Космос, есть!
64 года назад мы достигли многого. Мы вывели человека за пределы его колыбели и нюхнули свободы взрослого мира.
Сейчас многие вслед за Илоном нашим Маском мыслями обращаются к Марсу. И воображают что слетать туда все равно что в соседний город. Но если задуматься о масштабах, то все окажется совсем по-другому.
Упражнение с глобусом
Если взять в руки школьный глобус с диаметром 30 см, на какой высоте летал Гагарин и какая высота орбиты МКС? 1 сантиметр. Это уже для нас Космос!
А Луна? Луна на расстоянии 9 метров. Это уже соседняя квартира.
А Марс? Порядка 5 километров! 3 автобусные остановки или час пешком.
Ближайшая потенциально обитаемая планета? Очень повезло, она в ближайшей же звездной системе - это Проксима Центавра B, на ней может быть жидкая вода. Расстояние? Да забудьте - там 900 тысяч километров!
Теперь представьте поход на 23 раза обогнуть экватор в то время, как мы нормально освоили только 1 сантиметр этого пространства! Эволюционно мы на уровне инфузорий, которые и путешествуют за свою жизнь на несколько сантиметров. Теперь Илон предлагает нам приложить титанические усилия для эволюции, ну, в простейшую гидру, которая может теоретически утопать на 5 км от места своего рождения и выжить. А до звезд все еще нужен разум и реактивный самолет.
Человеку трудно представить масштабы этих расстояний и стоящих задач.
Но. Давайте в этот день праздновать. У нас есть важное отличие от инфузорий, оно в том, что мы способны осмыслить внутри себя самый дальний поход. Мы способны измерить, оценить, подсчитать, составить план. Мы даже способны вообразить задачи на сотни поколений вперед, где давно уже не будет никаких нас.
Люди на каноэ
Когда-то на берегу Тихого океана люди спустили на воду каноэ из тростника и поплыли в неизвестность. Они не знали, сколько плыть, не знали, есть ли там вообще пригодная земля. Неизвестно, сколько их сгинуло. Но известно, что все, даже самые удаленные, острова в океане на пол-Глобуса оказались заселены.
У нас огромное преимущество перед людьми на каноэ. Мы точно знаем, куда и сколько нам лететь. Мы знаем, что именно там находится. Мы в куда более лучшем положении чем люди на каноэ.
Почему мы хотим покорить Космос? Да потому что он, Космос, есть!
❤10👍7👏4
Выступаю на Arenaday 2025
Ровно через неделю, 22 апреля состоится большая ежегодная конференция Аренадата - ArenaDay 2025.
Совместно с архитекторами Аренадаты мы подготовили доклад об эффективном обеспечении отказоустойчивости кластеров ArenaDB.
Не так сложно организовать полноценную вторую площадку данных, имея x2-x3 бюджета основной. Но мы пошли дальше и предлагаем решение, которое использует механизмы облака для сокращения бюджета на DR. Причем даже этот резерв не будет бесполезно «греть воздух», а может быть переиспользован для задач аналитики и разработки.
Какие темы раскроем
⁃ Как перестать бояться отказов и начать использовать данные в реальных бизнес-процессах. И причем тут резервная площадка.
⁃ Что может предложить облако для отказоустойчивости данных
⁃ Как организовать ADB DR без кратного роста расходов на инфраструктуру данных
⁃ Как автоматизировать переключение между площадками с помощью сервисов облака
⁃ Как составить детальный DR-план, организовать DR-учения и не бояться отказов
⁃ Как переиспользовать вторую площадку для других задач: Dev/Test окружений, песочниц для разработчиков, сервинга данных для ML и LLM.
No system is safe. Даже самые крутые ЦОДы от ведущих мировых и российских компаний иногда падают. Даже самые безопасные системы ловят вирусов-шифровальщиков.
В мою бытность Head of Analytics меня не один и не два раза выручал тот факт, что у меня есть логический бекап данных в какой-то другой системе. Иметь рабочие механизмы данных в ситуации когда вся инфраструктура вашей компании испытывает проблемы - это гигантский бонус в вашу карму. Вы надежные, вам можно доверить серьезные бизнес-процессы.
22 апреля, вторник, Секция «Гибридное хранилище», 16:30
Ровно через неделю, 22 апреля состоится большая ежегодная конференция Аренадата - ArenaDay 2025.
Совместно с архитекторами Аренадаты мы подготовили доклад об эффективном обеспечении отказоустойчивости кластеров ArenaDB.
Не так сложно организовать полноценную вторую площадку данных, имея x2-x3 бюджета основной. Но мы пошли дальше и предлагаем решение, которое использует механизмы облака для сокращения бюджета на DR. Причем даже этот резерв не будет бесполезно «греть воздух», а может быть переиспользован для задач аналитики и разработки.
Какие темы раскроем
⁃ Как перестать бояться отказов и начать использовать данные в реальных бизнес-процессах. И причем тут резервная площадка.
⁃ Что может предложить облако для отказоустойчивости данных
⁃ Как организовать ADB DR без кратного роста расходов на инфраструктуру данных
⁃ Как автоматизировать переключение между площадками с помощью сервисов облака
⁃ Как составить детальный DR-план, организовать DR-учения и не бояться отказов
⁃ Как переиспользовать вторую площадку для других задач: Dev/Test окружений, песочниц для разработчиков, сервинга данных для ML и LLM.
No system is safe. Даже самые крутые ЦОДы от ведущих мировых и российских компаний иногда падают. Даже самые безопасные системы ловят вирусов-шифровальщиков.
В мою бытность Head of Analytics меня не один и не два раза выручал тот факт, что у меня есть логический бекап данных в какой-то другой системе. Иметь рабочие механизмы данных в ситуации когда вся инфраструктура вашей компании испытывает проблемы - это гигантский бонус в вашу карму. Вы надежные, вам можно доверить серьезные бизнес-процессы.
22 апреля, вторник, Секция «Гибридное хранилище», 16:30
👍11❤4🔥2
ArenaDay 2025
22 апреля доклад прочитать не получилось из-за срочных встреч. Лучшая в мире команда архитекторов данных подхватила и доклад, и непростую технологическую идею облачного DWH DR!
Основные тезисы доклада.
📈 По мере роста дата офиса ценность данных для бизнеса неизбежно растет. Растут и потери от простоя хранилища данных.
🔬 Greenplum и ArenadataDB - отличная база данных, терпимая ко многим типам отказа оборудования. Но это все еще одна СУБД, опирающаяся на один ЦОД. КХД все еще подверженно отказам.
☁️ Облако дает несколько инструментов для отказоустойчивости.
1️⃣ Первое, это бекап в s3. В инструмент Arenadata Backup Manager можно просто прописать эндпоинты и ключи облачного s3, и это будет работать.
2️⃣ Второе интереснее - это возможность поднять в облаке горячий резерв кластер. Причем, облако обладает гибким подходом к инфраструктуре и умеет на лету по API или по Terraform менять состав инфраструктуры. Одним небольшим скриптом можно массово растить или схлопывать в размере Виртуальные Машины.
Мы можем при основном кластере в 1000 ядер гринплама поднять в облаке DR площадку на 100 ядер и применять в нее все изменения с основного кластера раз в день или раз в час.
💎 В критическом случае отказа основного кластера или ЦОД мы приходим в облачный кластер и командуем ему расшириться до 1000 ядер для принятия нагрузки.
Платим же все это время за фактически потребленные ядро-часы.
🔬 Так с помощью технологий можно значительно повысить отказоустойчивость данных без кратного раздувания бюджета.
22 апреля доклад прочитать не получилось из-за срочных встреч. Лучшая в мире команда архитекторов данных подхватила и доклад, и непростую технологическую идею облачного DWH DR!
Основные тезисы доклада.
📈 По мере роста дата офиса ценность данных для бизнеса неизбежно растет. Растут и потери от простоя хранилища данных.
🔬 Greenplum и ArenadataDB - отличная база данных, терпимая ко многим типам отказа оборудования. Но это все еще одна СУБД, опирающаяся на один ЦОД. КХД все еще подверженно отказам.
☁️ Облако дает несколько инструментов для отказоустойчивости.
1️⃣ Первое, это бекап в s3. В инструмент Arenadata Backup Manager можно просто прописать эндпоинты и ключи облачного s3, и это будет работать.
2️⃣ Второе интереснее - это возможность поднять в облаке горячий резерв кластер. Причем, облако обладает гибким подходом к инфраструктуре и умеет на лету по API или по Terraform менять состав инфраструктуры. Одним небольшим скриптом можно массово растить или схлопывать в размере Виртуальные Машины.
Мы можем при основном кластере в 1000 ядер гринплама поднять в облаке DR площадку на 100 ядер и применять в нее все изменения с основного кластера раз в день или раз в час.
Платим же все это время за фактически потребленные ядро-часы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3🔥2
Forwarded from Data Engineering Digest
✨ Пётр Гуринов и Сергей Куприков: Опыт внедрения Lakehouse в компании Лемана Тех.
Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s
Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH)
Кому будет интересно:
- Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться.
---
Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись.
---
🔍 Проблемы старой архитектуры
- Greenplum (Shared Nothing):
- Данные невозможно оторвать от compute
- Ограниченная масштабируемость
- Высокие затраты на хранение
- Pipeline до внедрения DLH:
---
🚀 Переход на Lakehouse
Требования к новой платформе:
✔️ Open Source
✔️ Разделение compute/storage
✔️ Cloud-ready/cloud agnostic
✔️ Низкий порог входа
Выбранный стек:
- Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников)
- Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake)
- Хранение: S3
- Метаданные: HMS (планы на переход к Nessie для branch-поддержки)
---
⚙️ Реализация:
- Кластеры Trino:
- Ad hoc (пользователи/BI)
- ETL (тех.учетки)
- DQ (Data Quality)
Интеграция:
- Аутентификация через Keycloak + AD
- Управление доступом: file-based ACL
---
🛠 Проблемы и решения
Ограничения технологий:
- Нет коннектора Trino → Greenplum (ходят через Master)
- Iceberg: нет мультитранзакций, сложности с типами данных
- Trino: нет временных таблиц, legacy spill-файлы
🛠 Мониторинг:
- Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana.
-Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется.
Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset
- Кастомный сбор метрик запросов через Kafka → ClickHouse
🛠 Управление инфраструктурой:
- GitOps + ArgoCD + Vault
- Автоматические откаты
---
📊 Результаты
✅ Экономия:
- Хранение дешевле в 10+ раз
- Быстрое масштабирование в Kubernetes
- Независимое масштабирование и отсутствие необходимости резервировать место заранее.
✅ Производительность:
- Ускорение расчетов витрин
- Легкий переход запросов с GP на Trino
- Аналитики получают дополнительную точку входа для доступа к данным
- Разные вычислительные движки могут использовать одни и те же данные.
---
🔮 Планы
- Замена HMS на Nessie
- Продуктивизация SCD2-таблиц
- Автоскейлинг Trino на основе метрик
- Копирование Iceberg-таблиц в Greenplum
- Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only
---
💡 Вывод:
Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.
Ссылка на выступление: https://www.youtube.com/watch?v=r70FGQWdEvc&t=950s
Сложность: 2/3 (Сложного кода в докладе нет, но требуется понимание архитектуры DWH/DLH)
Кому будет интересно:
- Вообще всем, кто как-то связан с построением хранилищ данных. DLH это новая реальность, в которую обязательно нужно погрузиться.
---
Компания с масштабной инфраструктурой (600 TB в DWH, 1.5 TB в S3) перешла на Lakehouse-архитектуру. Рассказываем, как, зачем и с какими проблемами столкнулись.
---
🔍 Проблемы старой архитектуры
- Greenplum (Shared Nothing):
- Данные невозможно оторвать от compute
- Ограниченная масштабируемость
- Высокие затраты на хранение
- Pipeline до внедрения DLH:
Источники собираются в Kafka. Flink вычитывает данные, складывает их в S3 в формате avro (слой raw). Далее Spark трансфармирует данные в parquet, складывает данные
в S3 (слой ods). Оттуда данные попадают в GP, который является единой точкой входа всех сотрудников компании (любой сотрудник магазина может запросить доступ к DWH).
---
🚀 Переход на Lakehouse
Требования к новой платформе:
✔️ Open Source
✔️ Разделение compute/storage
✔️ Cloud-ready/cloud agnostic
✔️ Низкий порог входа
Выбранный стек:
- Вычисления: Trino (поддержка ANSI SQL, активное комьюнити, лицензирование и гетерогенность источников)
- Табличный формат: Iceberg (выбирали между Iceberg/Hudi/Delta Lake)
- Хранение: S3
- Метаданные: HMS (планы на переход к Nessie для branch-поддержки)
---
⚙️ Реализация:
- Кластеры Trino:
- Ad hoc (пользователи/BI)
- ETL (тех.учетки)
- DQ (Data Quality)
Интеграция:
- Аутентификация через Keycloak + AD
- Управление доступом: file-based ACL
---
🛠 Проблемы и решения
Ограничения технологий:
- Нет коннектора Trino → Greenplum (ходят через Master)
- Iceberg: нет мультитранзакций, сложности с типами данных
- Trino: нет временных таблиц, legacy spill-файлы
🛠 Мониторинг:
- Мониторинг производительности с использованием Prometheus и Grafana. JMX Exporter снимает метрики и преобразует в формат Prometheus. Prometheus operator пушит их в VictoriaMetrics, которые визуализируются в Grafana.
-Мониторинг пользовательских запросов из коробки имеет критическое ограничение: после рестарта вся история удаляется.
Реализовали мониторинг с использованием Kafka event listener, оттуда пишем в CH и визуализируем в Grafana. Дашборды выложены в opensource: https://github.com/rugratko/grafana-trino-overview-preset
- Кастомный сбор метрик запросов через Kafka → ClickHouse
🛠 Управление инфраструктурой:
- GitOps + ArgoCD + Vault
- Автоматические откаты
---
📊 Результаты
✅ Экономия:
- Хранение дешевле в 10+ раз
- Быстрое масштабирование в Kubernetes
- Независимое масштабирование и отсутствие необходимости резервировать место заранее.
✅ Производительность:
- Ускорение расчетов витрин
- Легкий переход запросов с GP на Trino
- Аналитики получают дополнительную точку входа для доступа к данным
- Разные вычислительные движки могут использовать одни и те же данные.
---
🔮 Планы
- Замена HMS на Nessie
- Продуктивизация SCD2-таблиц
- Автоскейлинг Trino на основе метрик
- Копирование Iceberg-таблиц в Greenplum
- Обслуживание (maintenance) Iceberg таблиц. Пока не актуально, так как сейчас данные append only
---
💡 Вывод:
Lakehouse на базе Trino + Iceberg — гибкая альтернатива классическому DWH. Главные преимущества: разделение compute/storage, масштабируемость и экономия.
✍7🔥7❤3
LLM Text to SQL
Работаем над технологией конвертации аналитического запроса на естественном языке в SQL и далее в ответ. Используем демо базу авиаперелетов от Postgres PRO.
Пока по моим наблюдениям такой бот максимально напоминает стажера-аналитика. На фото типичная ошибка джуна: перепутал время заказа билета с временем перелета. Только на джуна ты наорешь, и он исправится, а LLM так и останется глупеньким. Ну и самостоятельную работу джуну поручать нельзя.
Работаем над технологией конвертации аналитического запроса на естественном языке в SQL и далее в ответ. Используем демо базу авиаперелетов от Postgres PRO.
Пока по моим наблюдениям такой бот максимально напоминает стажера-аналитика. На фото типичная ошибка джуна: перепутал время заказа билета с временем перелета. Только на джуна ты наорешь, и он исправится, а LLM так и останется глупеньким. Ну и самостоятельную работу джуну поручать нельзя.
👍7😁5❤2👏1
Архитектор Данных
LLM Text to SQL Работаем над технологией конвертации аналитического запроса на естественном языке в SQL и далее в ответ. Используем демо базу авиаперелетов от Postgres PRO. Пока по моим наблюдениям такой бот максимально напоминает стажера-аналитика. На…
Разобрался джун.
Раз на раз не приходится. Все что делает агент, надо перепроверять. А чтобы перепроверять, надо разбираться в датасете.
Раз на раз не приходится. Все что делает агент, надо перепроверять. А чтобы перепроверять, надо разбираться в датасете.
👍7😁2❤1