Николай Ижиков — One More Way to Make Backup in Ignite
Сложность: 3/3 (Обязательно к прослушиванию, если вам интересна работа с OLTP-нагрузкой и технические подробности снятия бэкапов)
Николай Ижиков, Platform V DataGrid Tech Lead, а также контрибьютор в Apache Kafka и участник PMC Apache ignite, рассказывает нам, как реализованы бэкапы в Platform V DataGrid, а главное — про cache dumps.
YouTube: https://www.youtube.com/watch?v=A3EkvdGK4Jg
VK Видео: https://vkvideo.ru/video-147464741_456239442
🔍 Условия:
Кластер процессинга: 32 узла, 700 ГБ RAM на узел, 40к RPS на узел.
Кластер токенизатора: 5 узлов, 550 ГБ RAM на узел, 500к RPS.
⚙️Падение СУБД
1️⃣ Однонодовая СУБД — после падения приложение не работает, Запросы не обслуживаются, данные теряются при простое.
2️⃣ Распределенная СУБД — спектр последствий разный. Может снижаться перфоманс, может теряться часть данных.
⚙️Метрики восстановления после аварии
Recovery Point Objective — целевая точка восстановления, после которой мы теряем данные. Мы оцениваем время, в течение которого мы теряем данные за этой точкой.
Recovery Time Objective — с её помощью мы оцениваем время, затраченное на восстановление системы после аварии.
🛠 Способы формирования бэкапов (рекомендуется изучить презентацию к докладу):
1️⃣ Apache Ignite: ребаланс данных, позволяет сохранить данные, если количество упавших нод меньше бэкап-фактора.
2️⃣ DataGrid: при ребалансе данных распределение партиций такое, что у стойки есть дублер. Позволяет восстановиться при падении стойки.
3️⃣ Apache Ignite: CDC обеспечивает асинхронную логическую репликацию данных. RPO ➡️ секунды, RTO ➡️ 0. Данные реплицируются в другой кластер через WAL, доступ к данным открывается после перемещения сегмента в архив. Из-за этого RPO сдвигается.
4️⃣ Data Grid: Online CDC внутри ноды есть буфер данных, который наполняется событиями и из него данные стримятся в соседний кластер. RPO ➡️ 0, RTO ➡️ 0. Растет потребление памяти, при переполнении используется классический CDC через WAL.
5️⃣ Снапшоты в Apache Ignite: системный процесс PME делает stop the world. Начатые транзакции заканчиваются, новые стоят на паузе. В этот момент происходит копирование партиций, изменения пишутся отдельно, после снятия резервной копии изменения накладываются поверх снимка. RPO ➡️ часы, RTO ➡️ 0
6️⃣ Apache Ignite: инкрементальный снапшот снимает только изменения в данных, но часто. Система не блокируется. RPO ➡️ минуты, RTO ➡️ минуты. В докладе даны ссылки на статьи по этому механизму.
🔮 Cache dump
📝Задачи и качества метода:
1️⃣ консистентный бэкап in-memory кэшей с учетом транзакций без прерывания пользовательской нагрузки;
2️⃣ Восстановление данных на любую топологию;
3️⃣ Поддержка CLI;
4️⃣ API offline обработка
⚙️⚙️ Механизм снятия дампа:
1️⃣ Stop the world
2️⃣ Данные консистентны; запуск писателей дампа
3️⃣ Для сохранения консистентности установка listener'ов на изменения кэша
4️⃣ Запуск транзакций
5️⃣ Итерация по партициям и запись row by row
6️⃣ Запись данных listener'ом
🪛 Тонкости:
1️⃣ Откатиться, если где-то ошибка — Distributed Process.
2️⃣ Не перегрузить ноды системным процессом - прежде всего операции пользователя.
3️⃣ Запоминание изменений каждого ключа — это дорого по памяти.
📝 Эффективная фильтрация:
1️⃣ Итератор по партиции не транзакционный
Listener должен сохранить entry до изменения
2️⃣ Итератор сортированный (B+дерево)
3️⃣ У каждой записи есть уникальная версия. Версия выдается на primary.
❔Ответы на вопросы:
Q: cache dump можно снимать не только для in-memory cache, но и для персистентного кэша?
A: Можно, вопрос целесообразности. Для persistent cache есть более подходящие способы.
Q: Уточнение по процессу: если версия ключа более новая, то итератор её пропускает. Как все значения ключей попадают в запись бэкапа?
A: Если версия старше версии в момент снятия, то эти данные либо пришли после запуска процесса снятия бэкапа, либо старые данные были изменены во время снятия и эти изменения записаны listener'ом.
Сложность: 3/3 (Обязательно к прослушиванию, если вам интересна работа с OLTP-нагрузкой и технические подробности снятия бэкапов)
Николай Ижиков, Platform V DataGrid Tech Lead, а также контрибьютор в Apache Kafka и участник PMC Apache ignite, рассказывает нам, как реализованы бэкапы в Platform V DataGrid, а главное — про cache dumps.
YouTube: https://www.youtube.com/watch?v=A3EkvdGK4Jg
VK Видео: https://vkvideo.ru/video-147464741_456239442
🔍 Условия:
Кластер процессинга: 32 узла, 700 ГБ RAM на узел, 40к RPS на узел.
Кластер токенизатора: 5 узлов, 550 ГБ RAM на узел, 500к RPS.
⚙️Падение СУБД
1️⃣ Однонодовая СУБД — после падения приложение не работает, Запросы не обслуживаются, данные теряются при простое.
2️⃣ Распределенная СУБД — спектр последствий разный. Может снижаться перфоманс, может теряться часть данных.
⚙️Метрики восстановления после аварии
Recovery Point Objective — целевая точка восстановления, после которой мы теряем данные. Мы оцениваем время, в течение которого мы теряем данные за этой точкой.
Recovery Time Objective — с её помощью мы оцениваем время, затраченное на восстановление системы после аварии.
🛠 Способы формирования бэкапов (рекомендуется изучить презентацию к докладу):
1️⃣ Apache Ignite: ребаланс данных, позволяет сохранить данные, если количество упавших нод меньше бэкап-фактора.
2️⃣ DataGrid: при ребалансе данных распределение партиций такое, что у стойки есть дублер. Позволяет восстановиться при падении стойки.
3️⃣ Apache Ignite: CDC обеспечивает асинхронную логическую репликацию данных. RPO ➡️ секунды, RTO ➡️ 0. Данные реплицируются в другой кластер через WAL, доступ к данным открывается после перемещения сегмента в архив. Из-за этого RPO сдвигается.
4️⃣ Data Grid: Online CDC внутри ноды есть буфер данных, который наполняется событиями и из него данные стримятся в соседний кластер. RPO ➡️ 0, RTO ➡️ 0. Растет потребление памяти, при переполнении используется классический CDC через WAL.
5️⃣ Снапшоты в Apache Ignite: системный процесс PME делает stop the world. Начатые транзакции заканчиваются, новые стоят на паузе. В этот момент происходит копирование партиций, изменения пишутся отдельно, после снятия резервной копии изменения накладываются поверх снимка. RPO ➡️ часы, RTO ➡️ 0
6️⃣ Apache Ignite: инкрементальный снапшот снимает только изменения в данных, но часто. Система не блокируется. RPO ➡️ минуты, RTO ➡️ минуты. В докладе даны ссылки на статьи по этому механизму.
🔮 Cache dump
📝Задачи и качества метода:
1️⃣ консистентный бэкап in-memory кэшей с учетом транзакций без прерывания пользовательской нагрузки;
2️⃣ Восстановление данных на любую топологию;
3️⃣ Поддержка CLI;
4️⃣ API offline обработка
⚙️⚙️ Механизм снятия дампа:
1️⃣ Stop the world
2️⃣ Данные консистентны; запуск писателей дампа
3️⃣ Для сохранения консистентности установка listener'ов на изменения кэша
4️⃣ Запуск транзакций
5️⃣ Итерация по партициям и запись row by row
6️⃣ Запись данных listener'ом
🪛 Тонкости:
1️⃣ Откатиться, если где-то ошибка — Distributed Process.
2️⃣ Не перегрузить ноды системным процессом - прежде всего операции пользователя.
3️⃣ Запоминание изменений каждого ключа — это дорого по памяти.
📝 Эффективная фильтрация:
1️⃣ Итератор по партиции не транзакционный
Listener должен сохранить entry до изменения
2️⃣ Итератор сортированный (B+дерево)
3️⃣ У каждой записи есть уникальная версия. Версия выдается на primary.
❔Ответы на вопросы:
Q: cache dump можно снимать не только для in-memory cache, но и для персистентного кэша?
A: Можно, вопрос целесообразности. Для persistent cache есть более подходящие способы.
Q: Уточнение по процессу: если версия ключа более новая, то итератор её пропускает. Как все значения ключей попадают в запись бэкапа?
A: Если версия старше версии в момент снятия, то эти данные либо пришли после запуска процесса снятия бэкапа, либо старые данные были изменены во время снятия и эти изменения записаны listener'ом.
YouTube
Николай Ижиков — One More Way to Make Backup in Ignite
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
Скачать презентацию с сайта SmartData — https://jrg.su/bYCt0V
Спикер разработал еще один способ создания резервной копии данных в Apache Ignite. Он называется cache dumps. В докладе — про API,…
— —
Скачать презентацию с сайта SmartData — https://jrg.su/bYCt0V
Спикер разработал еще один способ создания резервной копии данных в Apache Ignite. Он называется cache dumps. В докладе — про API,…
❤8🔥5👍2🏆2
Бронислав Житников — NiFi. Пишем код для codeless-системы
Сложность: 2/3 (Если NiFi не
трогали - пропускайте данный доклад. Это отличное подспорье для углубленного знакомства с NiFi)
📺: https://youtu.be/Lnta1yPIMrY?si=cuGJLbmET3cQvadf
📺 :VK
🔍 Условия:
1️⃣ В NiFi может не хватать встроенных процессоров
2️⃣ Иногда нужно избежать приземления данных на диск и для этого несколько процессоров собрать в один
3️⃣ Встроенный процессор иногда стоит доработать, либо исправить в нем ошибки
⚙️ Путь к необходимости писать код:
1️⃣ ExecuteStreamCode — позволяет запустить внешний скрипт
2️⃣ ExecuteScript — дает доступ к внутренним фишкам NiFi
3️⃣ ScriptedService — позволяет изменить часть логики
4️⃣ ScriptedProcessor — позволяет прописать всю логику процессора
🛠 Устройство NiFi:
Для написания кода в большинстве случаев придется работать с NiFi API (Processors&Service)
1️⃣ ScriptEngine: докладчик рекомендует писать скрипты сразу на Groovy, так как Jython не даст свободы использования Python и при этом даст ограничения в работе с API
2️⃣ Можно писать свои модули сразу на Java
3️⃣ В версии 2.0 ожидается написание модулей на Python
⚙️ Шаги создания Processor:
1️⃣ Чтение Developers Guide
2️⃣ Применение Maven-Archetype — быстрый старт разработки, есть только часть процессоров и сервисов
3️⃣ Заполняем аннотации — могут определять поведение процессора, наполнять документацию, определять ключевые методы
4️⃣ Заполняем OnScheduled
5️⃣ Заполняем OnTrigger
⚙️ Аннотации поведения:
1️⃣ @InputRequirement — требует ли входящей очереди (обязательна, допустима, недопустима)
2️⃣ @TriggerWhenEmpty — требуется ли FlowFile. Позволяет запускаться процессору без файлов во входящей очереди. Для процессоров без входящих очередей не имеет смысла
3️⃣ @PrimaryNodeOnly — запуск только на ведущей ноде. Пригодится для процессоров без входящих очередей
4️⃣ @SupportBatching — возможность запускать длительный Run, снимая нагрузку с планировщика
⚙️ Аннотации документирования:
1️⃣ @CapabilityDescription — описание процессора
2️⃣ @UseCase — редко встречается, но очень помогают пользователям
3️⃣ @ReadAtrribute/@WriteAttribute — описывает, какие атрибуты приходят на вход и оказываются на выходе из процессора
4️⃣ @SeeAlso — справка о дополнительных источниках
📝 Расширенное документирование:
1️⃣ в каталоге resoursces создать docs, там создать каталог с полным именем процессора
2️⃣ Создать файл additionalDetails.html
🪛 Важные элементы разработки:
1️⃣ Properties — важно определить, как параметры обрабатываются; работают ли они с сервисами и с какими; определить наличие dynamic properties; настроить валидаторы и обязательность указания параметров
2️⃣ Relationships — заполнить имя, описание, обязательно указать настройку "выключен по умолчанию"
3️⃣ Lifecycle — c @OnAdded начинается создание экземпляра процессора;
@Onscheduled — запуск процессора, при перезапуске NiFi так же вызывается
@OnUnscheduled — остановка процессора, если его запуск больше не запланирован. Часть тредов могут быть активны после вызова метода с этой аннотацией. Лучше избегать применения в логике для выключения процессора
@OnStopped — следует применять эту аннотацию к методу, срабатывающему при полной остановке процессора
@OnRemoved — удаление экземпляра процессора
@OnShutdown — избегать использования в логике, так как NiFi чаще останавливается нештатно
⚙️⚙️ OnTrigger — метод построения логики работы процессора
1️⃣ Проверить наличие файла
2️⃣ Помнить об экземплярах вызова, изменяемые данные должны быть внутри OnTrigger
3️⃣ Расчет только из атрибутов
4️⃣ Не изменять атрибуты во время изменения контента
5️⃣ Не забывать отправлять файлы в следующие отношения или удалять
6️⃣ session.penalize — позволяет определить период, когда файл не подлежит обработке, используется для обработки ошибок
7️⃣ context.yield — в случае отсутствия отклика БД процессор может не запускаться какое-то время, даже если расписание на него выставлено
8️⃣ ProcessSession — управляет обработкой файла
9️⃣ ProcessContext — определяет доступ к информации из процессора и среды
Сложность: 2/3 (Если NiFi не
трогали - пропускайте данный доклад. Это отличное подспорье для углубленного знакомства с NiFi)
📺: https://youtu.be/Lnta1yPIMrY?si=cuGJLbmET3cQvadf
📺 :VK
🔍 Условия:
1️⃣ В NiFi может не хватать встроенных процессоров
2️⃣ Иногда нужно избежать приземления данных на диск и для этого несколько процессоров собрать в один
3️⃣ Встроенный процессор иногда стоит доработать, либо исправить в нем ошибки
⚙️ Путь к необходимости писать код:
1️⃣ ExecuteStreamCode — позволяет запустить внешний скрипт
2️⃣ ExecuteScript — дает доступ к внутренним фишкам NiFi
3️⃣ ScriptedService — позволяет изменить часть логики
4️⃣ ScriptedProcessor — позволяет прописать всю логику процессора
🛠 Устройство NiFi:
Для написания кода в большинстве случаев придется работать с NiFi API (Processors&Service)
1️⃣ ScriptEngine: докладчик рекомендует писать скрипты сразу на Groovy, так как Jython не даст свободы использования Python и при этом даст ограничения в работе с API
2️⃣ Можно писать свои модули сразу на Java
3️⃣ В версии 2.0 ожидается написание модулей на Python
⚙️ Шаги создания Processor:
1️⃣ Чтение Developers Guide
2️⃣ Применение Maven-Archetype — быстрый старт разработки, есть только часть процессоров и сервисов
3️⃣ Заполняем аннотации — могут определять поведение процессора, наполнять документацию, определять ключевые методы
4️⃣ Заполняем OnScheduled
5️⃣ Заполняем OnTrigger
⚙️ Аннотации поведения:
1️⃣ @InputRequirement — требует ли входящей очереди (обязательна, допустима, недопустима)
2️⃣ @TriggerWhenEmpty — требуется ли FlowFile. Позволяет запускаться процессору без файлов во входящей очереди. Для процессоров без входящих очередей не имеет смысла
3️⃣ @PrimaryNodeOnly — запуск только на ведущей ноде. Пригодится для процессоров без входящих очередей
4️⃣ @SupportBatching — возможность запускать длительный Run, снимая нагрузку с планировщика
⚙️ Аннотации документирования:
1️⃣ @CapabilityDescription — описание процессора
2️⃣ @UseCase — редко встречается, но очень помогают пользователям
3️⃣ @ReadAtrribute/@WriteAttribute — описывает, какие атрибуты приходят на вход и оказываются на выходе из процессора
4️⃣ @SeeAlso — справка о дополнительных источниках
📝 Расширенное документирование:
1️⃣ в каталоге resoursces создать docs, там создать каталог с полным именем процессора
2️⃣ Создать файл additionalDetails.html
🪛 Важные элементы разработки:
1️⃣ Properties — важно определить, как параметры обрабатываются; работают ли они с сервисами и с какими; определить наличие dynamic properties; настроить валидаторы и обязательность указания параметров
2️⃣ Relationships — заполнить имя, описание, обязательно указать настройку "выключен по умолчанию"
3️⃣ Lifecycle — c @OnAdded начинается создание экземпляра процессора;
@Onscheduled — запуск процессора, при перезапуске NiFi так же вызывается
@OnUnscheduled — остановка процессора, если его запуск больше не запланирован. Часть тредов могут быть активны после вызова метода с этой аннотацией. Лучше избегать применения в логике для выключения процессора
@OnStopped — следует применять эту аннотацию к методу, срабатывающему при полной остановке процессора
@OnRemoved — удаление экземпляра процессора
@OnShutdown — избегать использования в логике, так как NiFi чаще останавливается нештатно
⚙️⚙️ OnTrigger — метод построения логики работы процессора
1️⃣ Проверить наличие файла
2️⃣ Помнить об экземплярах вызова, изменяемые данные должны быть внутри OnTrigger
3️⃣ Расчет только из атрибутов
4️⃣ Не изменять атрибуты во время изменения контента
5️⃣ Не забывать отправлять файлы в следующие отношения или удалять
6️⃣ session.penalize — позволяет определить период, когда файл не подлежит обработке, используется для обработки ошибок
7️⃣ context.yield — в случае отсутствия отклика БД процессор может не запускаться какое-то время, даже если расписание на него выставлено
8️⃣ ProcessSession — управляет обработкой файла
9️⃣ ProcessContext — определяет доступ к информации из процессора и среды
YouTube
Бронислав Житников — NiFi. Пишем код для codeless-системы
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
Скачать презентацию с сайта SmartData — https://jrg.su/5ZoqVb
NiFi — инструмент, в котором без написания кода можно сделать почти все благодаря широкой палитре процессоров данных. А с учетом возможностей…
— —
Скачать презентацию с сайта SmartData — https://jrg.su/5ZoqVb
NiFi — инструмент, в котором без написания кода можно сделать почти все благодаря широкой палитре процессоров данных. А с учетом возможностей…
👍12❤6🔥4
Продолжение предыдущего поста. Выводы и ответы на вопросы не влезли)
📝 Чего избегать:
1️⃣ С осторожностью соединять процессоры
2️⃣ Не усложнять процессор в погоне за оптимизацией
❔Ответы на вопросы:
Q: Где брать готовые процессоры для NiFi
A: Ожидать сервис от коммьюнити, сейчас никак
Q: Можно ли отладить процессор в IDE?
A: в NiFi есть эмуляция процессов, можно написать тест там. Возможно открыть PortDebug, поможет если уже процессор работает, но ведет себя аномально.
Q: Как часто ты рекомендуешь использовать систему логгирования?
A: Использую всегда. Трейсы пишу всегда, когда есть ошибки, ворнинги пишу, но стараюсь не перегружать ими.
Q: Как дебажить ScriptedProcessor?
A: Если его не выпилят в 2.0, я напишу функционал и выложу. для Groovy такое уже есть
📝 Чего избегать:
1️⃣ С осторожностью соединять процессоры
2️⃣ Не усложнять процессор в погоне за оптимизацией
❔Ответы на вопросы:
Q: Где брать готовые процессоры для NiFi
A: Ожидать сервис от коммьюнити, сейчас никак
Q: Можно ли отладить процессор в IDE?
A: в NiFi есть эмуляция процессов, можно написать тест там. Возможно открыть PortDebug, поможет если уже процессор работает, но ведет себя аномально.
Q: Как часто ты рекомендуешь использовать систему логгирования?
A: Использую всегда. Трейсы пишу всегда, когда есть ошибки, ворнинги пишу, но стараюсь не перегружать ими.
Q: Как дебажить ScriptedProcessor?
A: Если его не выпилят в 2.0, я напишу функционал и выложу. для Groovy такое уже есть
❤7👍6🔥4
✨ Станислав Лысиков — StarRocks как ядро современной платформы данных
Станислав Лысиков рассказал о внедрении StarRocks в продуктовом финтехе с данными до петабайта. Доклад — это честный разбор опыта перехода на новую аналитическую СУБД.
Дисклеймер: Рекомендую не читать этот пост, а посмотреть доклад самим) Смотрится легко и очень интересно)
YouTube: https://www.youtube.com/watch?v=oiPXIbX-cTw
VK Видео: https://vkvideo.ru/video-147464741_456239483
Сложность: 2/3 (Технически насыщенный доклад, требует понимания архитектуры аналитических баз данных)
Кому будет интересно:
• Дата-архитекторам и инженерам
• Всем, кто выбирает аналитическую СУБД для высокой нагрузки
🔍 Проблемы, которые привели к StarRocks
• Старый стек: Микросервисы на MySQL + Go, но аналитика не масштабировалась
• Требования к новой БД:
✔️ Дешевое внедрение и масштабируемость
✔️ Высокая скорость на потоковых данных
✔️ Open Source с активным сообществом
🏗 Архитектура и установка
Два режима работы:
1 Share Nothing (данные + вычисления на одних нодах)
2 Share Data (отдельное хранилище)
Минимальные требования:
• 3 ноды для продакшна (рекомендуется 5)
• NVMe диски, RAID не требуется
• Репликация на уровне серверов
Управление:
• Готовность к Kubernetes (есть операторы)
• Простое ручное развертывание через Helm
⚡️ Ключевые особенности StarRocks
Производительность:
• Разработан для лямбда-архитектуры
• Высокая скорость запросов (сравнима с ClickHouse, быстрее Vertica/Spark)
Поддержка форматов:
• Нативные коннекторы к HDFS, Iceberg, JSON
• Работа с Hive Metastore
Уникальные фичи:
• Data Recovery — восстановление случайно удаленных данных
• Частичные UPDATE по условию
• Хранение Kafka-оффсетов в БД (независимость от consumer groups)
🔄 Интеграция с данными
Потоковая загрузка:
• Нативная поддержка Kafka
• Проблема с порядком сообщений решена через таймштампы
Работа с Go:
• Прямая работа с Go-структурами (команда без Java/.NET специалистов)
🛠 Проблемы и решения
1️⃣ Шардирование данных:
• Двухуровневое (партиции + бакеты)
• Автоматическое распределение при добавлении нод
2️⃣ Совместимость:
• Драйвер через MySQL-протокол
• Проблемы с некоторыми системами (например, Vertica)
3️⃣ Decimal типы:
• Пришлось реализовывать кастомное решение
📊 Сравнение с аналогами
StarRocks vs ClickHouse/Trino:
• Выше скорость на аналитических запросах
• Лучшая поддержка потоковой загрузки
StarRocks vs Doris:
• Разная кодовая база
• Активное развитие отдельного сообщества
🤝 Сообщество и поддержка
• Open Source: Активное развитие, быстрое исправление регрессий
• В РФ: Доступна платная поддержка (решение Selena)
• Коммерческие внедрения: Успешные кейсы в банках и телекоме
💡 Практические выводы
✅ Плюсы:
• Простое развертывание и масштабирование
• Высокая скорость работы с потоковыми данными
• Активное сообщество
⚠️ Минусы:
• Молодая экосистема (проблемы с некоторыми драйверами)
• Требует адаптации под специфичные типы данных
Итог: StarRocks — мощный вариант для построение DWH и для аналитики в реальном времени. Подходит для компаний, которые хотят быстро развернуть производительное решение без огромных затрат.
Станислав Лысиков рассказал о внедрении StarRocks в продуктовом финтехе с данными до петабайта. Доклад — это честный разбор опыта перехода на новую аналитическую СУБД.
Дисклеймер: Рекомендую не читать этот пост, а посмотреть доклад самим) Смотрится легко и очень интересно)
YouTube: https://www.youtube.com/watch?v=oiPXIbX-cTw
VK Видео: https://vkvideo.ru/video-147464741_456239483
Сложность: 2/3 (Технически насыщенный доклад, требует понимания архитектуры аналитических баз данных)
Кому будет интересно:
• Дата-архитекторам и инженерам
• Всем, кто выбирает аналитическую СУБД для высокой нагрузки
🔍 Проблемы, которые привели к StarRocks
• Старый стек: Микросервисы на MySQL + Go, но аналитика не масштабировалась
• Требования к новой БД:
✔️ Дешевое внедрение и масштабируемость
✔️ Высокая скорость на потоковых данных
✔️ Open Source с активным сообществом
🏗 Архитектура и установка
Два режима работы:
1 Share Nothing (данные + вычисления на одних нодах)
2 Share Data (отдельное хранилище)
Минимальные требования:
• 3 ноды для продакшна (рекомендуется 5)
• NVMe диски, RAID не требуется
• Репликация на уровне серверов
Управление:
• Готовность к Kubernetes (есть операторы)
• Простое ручное развертывание через Helm
⚡️ Ключевые особенности StarRocks
Производительность:
• Разработан для лямбда-архитектуры
• Высокая скорость запросов (сравнима с ClickHouse, быстрее Vertica/Spark)
Поддержка форматов:
• Нативные коннекторы к HDFS, Iceberg, JSON
• Работа с Hive Metastore
Уникальные фичи:
• Data Recovery — восстановление случайно удаленных данных
• Частичные UPDATE по условию
• Хранение Kafka-оффсетов в БД (независимость от consumer groups)
🔄 Интеграция с данными
Потоковая загрузка:
• Нативная поддержка Kafka
• Проблема с порядком сообщений решена через таймштампы
Работа с Go:
• Прямая работа с Go-структурами (команда без Java/.NET специалистов)
🛠 Проблемы и решения
1️⃣ Шардирование данных:
• Двухуровневое (партиции + бакеты)
• Автоматическое распределение при добавлении нод
2️⃣ Совместимость:
• Драйвер через MySQL-протокол
• Проблемы с некоторыми системами (например, Vertica)
3️⃣ Decimal типы:
• Пришлось реализовывать кастомное решение
📊 Сравнение с аналогами
StarRocks vs ClickHouse/Trino:
• Выше скорость на аналитических запросах
• Лучшая поддержка потоковой загрузки
StarRocks vs Doris:
• Разная кодовая база
• Активное развитие отдельного сообщества
🤝 Сообщество и поддержка
• Open Source: Активное развитие, быстрое исправление регрессий
• В РФ: Доступна платная поддержка (решение Selena)
• Коммерческие внедрения: Успешные кейсы в банках и телекоме
💡 Практические выводы
✅ Плюсы:
• Простое развертывание и масштабирование
• Высокая скорость работы с потоковыми данными
• Активное сообщество
⚠️ Минусы:
• Молодая экосистема (проблемы с некоторыми драйверами)
• Требует адаптации под специфичные типы данных
Итог: StarRocks — мощный вариант для построение DWH и для аналитики в реальном времени. Подходит для компаний, которые хотят быстро развернуть производительное решение без огромных затрат.
YouTube
Станислав Лысиков — StarRocks — реальность современной платформы данных
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
Скачать презентацию с сайта — https://jrg.su/DHS6kY
Платформа данных в нашей компании существует уже более 5 лет, за это время она вобрала множество модных (и не очень) решений. Расскажу, как мы…
— —
Скачать презентацию с сайта — https://jrg.su/DHS6kY
Платформа данных в нашей компании существует уже более 5 лет, за это время она вобрала множество модных (и не очень) решений. Расскажу, как мы…
👍10❤9🔥8👌2👎1
Мне очень нравится вопрос: Чем Parquet отличается от Iceberg?
Если очень-очень грубо усреднить ответы, то получится что-то типа: Parquet - это файл с данными, а Iceberg - это данные + метаданные про этот файл.
Но если Iceberg «умный» и уже хранит метаданные, почему в стеке Trino + S3 до сих пор живет Metastore? Какие функции он выполняет?
На этот вопрос ответят в докладе Михаила Иванова "Что такое metastore и с чем его едят?"
YT : https://www.youtube.com/watch?v=BJnOb_BJCLQ
VK : https://vkvideo.ru/video-147464741_456239481
Привычного формата поста не будет, так как в докладе разбирают специфичный кейс компании, которой не подошли современные metastore и они пошли по пути написания своего решения. Я бы порекомендовал посмотреть первые 15 минут доклада для Junior/middle специалистов, а для Senior/Architector последние 15 минут доклада) Но доклад правда интересный)
Покидаю интересные скрины с доклада следующим постом:
Если очень-очень грубо усреднить ответы, то получится что-то типа: Parquet - это файл с данными, а Iceberg - это данные + метаданные про этот файл.
Но если Iceberg «умный» и уже хранит метаданные, почему в стеке Trino + S3 до сих пор живет Metastore? Какие функции он выполняет?
На этот вопрос ответят в докладе Михаила Иванова "Что такое metastore и с чем его едят?"
YT : https://www.youtube.com/watch?v=BJnOb_BJCLQ
VK : https://vkvideo.ru/video-147464741_456239481
Привычного формата поста не будет, так как в докладе разбирают специфичный кейс компании, которой не подошли современные metastore и они пошли по пути написания своего решения. Я бы порекомендовал посмотреть первые 15 минут доклада для Junior/middle специалистов, а для Senior/Architector последние 15 минут доклада) Но доклад правда интересный)
Покидаю интересные скрины с доклада следующим постом:
YouTube
Михаил Иванов — Что такое metastore и с чем его едят
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
Скачать презентацию с сайта — https://jrg.su/ApLkVF
Metastore — это ключевой компонент любой современной платформы данных, который отвечает за управление метаданными. Без него работа с большими…
— —
Скачать презентацию с сайта — https://jrg.su/ApLkVF
Metastore — это ключевой компонент любой современной платформы данных, который отвечает за управление метаданными. Без него работа с большими…
❤8👍5
Ещё один доклад из которого не получился пост по причине того, что админ очень не любит spark)
https://youtu.be/xhgsQIqkNYY?si=iSXHWg8Fyd-goJz4
Приложу три самых интересных для меня скринов из доклада
https://youtu.be/xhgsQIqkNYY?si=iSXHWg8Fyd-goJz4
Приложу три самых интересных для меня скринов из доклада
🔥10🥰1
5 октября начнется 19-й поток программы Data Engineer от Newprolab
Программа для junior- и middle-дата-инженеров, аналитиков, backend-разработчиков, техлидов и тех, кто работает с data-командами и хочет лучше понимать современный стек DE
📌 Что внутри:
– 10 недель обучения
– 30 занятий: онлайн + записи
– 10 практических лабораторных работ
– облачный кластер и реальные данные
– чат участников и поддержка команды программы
📌 Что получите на выходе:
1. Научитесь решать типовые задачи DE на практике
2. Систематизируете знания и закроете пробелы в современном DE-стеке
3. Поработаете с реальными данными и инфраструктурой, а не только с учебными примерами
4. Соберете практический опыт, который можно обсуждать на собеседованиях и использовать в работе
5. Все записи и материалы останутся у вас после окончания программы
Преподаватели – практикующие специалисты из ведущих технологических компаний. На занятиях можно разбирать реальные кейсы, задавать вопросы и получать обратную связь
👉 Подробности и квиз – на сайте
Квиз покажет, насколько программа подходит именно под вашу роль и задачи, даст персональные рекомендации и промокод на скидку
___
По всем вопросам пишите Алексею @snitsa
Реклама. НОЧУ ДПО «НЬЮПРОЛАБ», ИНН 7729461098, erid: CQH36pWzJqVKq9rQTHdoerUjCtLJwbma2q2Sq6DgPEKAP7
Программа для junior- и middle-дата-инженеров, аналитиков, backend-разработчиков, техлидов и тех, кто работает с data-командами и хочет лучше понимать современный стек DE
📌 Что внутри:
– 10 недель обучения
– 30 занятий: онлайн + записи
– 10 практических лабораторных работ
– облачный кластер и реальные данные
– чат участников и поддержка команды программы
📌 Что получите на выходе:
1. Научитесь решать типовые задачи DE на практике
2. Систематизируете знания и закроете пробелы в современном DE-стеке
3. Поработаете с реальными данными и инфраструктурой, а не только с учебными примерами
4. Соберете практический опыт, который можно обсуждать на собеседованиях и использовать в работе
5. Все записи и материалы останутся у вас после окончания программы
Преподаватели – практикующие специалисты из ведущих технологических компаний. На занятиях можно разбирать реальные кейсы, задавать вопросы и получать обратную связь
👉 Подробности и квиз – на сайте
Квиз покажет, насколько программа подходит именно под вашу роль и задачи, даст персональные рекомендации и промокод на скидку
___
По всем вопросам пишите Алексею @snitsa
Реклама. НОЧУ ДПО «НЬЮПРОЛАБ», ИНН 7729461098, erid: CQH36pWzJqVKq9rQTHdoerUjCtLJwbma2q2Sq6DgPEKAP7
❤3👍1👎1🔥1
Прошу простить, уже долгое время не могу выделить время на полноценный пост о интересных докладах с конференциях. Но это не значит, что доклады я перестал смотреть)
По итогам просмотра очередного доклада: https://www.youtube.com/watch?v=JeAP_L671CQ родился небольшой пост.
На курсах по Clickhouse меня спрашивали: "А если у нас только логи, которые мы хотим анализировать, нам нужен Clickhouse или можно обойтись Elasticsearch?"
Я ответил что-то вроде:
а) Полнотекстовый поиск и расследование, объём умеренный, хранить недолго - оставайтесь на Elasticsearch.
б) Отчёты, тренды, долгая история, SQL - берите ClickHouse, даже если источник только логи. Полнотекстовый поиск в CH тоже есть (индексы для полнотекстового поиска), но заставить их работать - тот ещё квест.
в) Нужны оба сценария - это два разных хранилища: Elasticsearch на короткий операционный контур, ClickHouse на аналитику и длинное хранение. Одно другим не заменяется.
А от меня хотели услышать цифры, сравнение производительности. А я их дать не смог) В этом докладе ссылочка на неплохую статью https://infostart.ru/1c/articles/1325649/
Сам доклад так же рекомендую)
По итогам просмотра очередного доклада: https://www.youtube.com/watch?v=JeAP_L671CQ родился небольшой пост.
На курсах по Clickhouse меня спрашивали: "А если у нас только логи, которые мы хотим анализировать, нам нужен Clickhouse или можно обойтись Elasticsearch?"
Я ответил что-то вроде:
а) Полнотекстовый поиск и расследование, объём умеренный, хранить недолго - оставайтесь на Elasticsearch.
б) Отчёты, тренды, долгая история, SQL - берите ClickHouse, даже если источник только логи. Полнотекстовый поиск в CH тоже есть (индексы для полнотекстового поиска), но заставить их работать - тот ещё квест.
в) Нужны оба сценария - это два разных хранилища: Elasticsearch на короткий операционный контур, ClickHouse на аналитику и длинное хранение. Одно другим не заменяется.
А от меня хотели услышать цифры, сравнение производительности. А я их дать не смог) В этом докладе ссылочка на неплохую статью https://infostart.ru/1c/articles/1325649/
Сам доклад так же рекомендую)
🔥6❤4👍3
5 октября начнется 19-й поток программы Data Engineer от Newprolab
Программа для junior- и middle-дата-инженеров, аналитиков, backend-разработчиков, техлидов и тех, кто работает с data-командами и хочет лучше понимать современный стек DE
📌 Что внутри:
– 10 недель обучения
– 30 занятий: онлайн + записи
– 10 практических лабораторных работ
– облачный кластер и реальные данные
– чат участников и поддержка команды программы
📌 Что получите на выходе:
1. Научитесь решать типовые задачи DE на практике
2. Систематизируете знания и закроете пробелы в современном DE-стеке
3. Поработаете с реальными данными и инфраструктурой, а не только с учебными примерами
4. Соберете практический опыт, который можно обсуждать на собеседованиях и использовать в работе
5. Все записи и материалы останутся у вас после окончания программы
Преподаватели – практикующие специалисты из ведущих технологических компаний. На занятиях можно разбирать реальные кейсы, задавать вопросы и получать обратную связь
👉 Подробности и квиз – на сайте
Квиз покажет, насколько программа подходит именно под вашу роль и задачи, даст персональные рекомендации и промокод на скидку
___
По всем вопросам пишите Алексею @snitsa
Программа для junior- и middle-дата-инженеров, аналитиков, backend-разработчиков, техлидов и тех, кто работает с data-командами и хочет лучше понимать современный стек DE
📌 Что внутри:
– 10 недель обучения
– 30 занятий: онлайн + записи
– 10 практических лабораторных работ
– облачный кластер и реальные данные
– чат участников и поддержка команды программы
📌 Что получите на выходе:
1. Научитесь решать типовые задачи DE на практике
2. Систематизируете знания и закроете пробелы в современном DE-стеке
3. Поработаете с реальными данными и инфраструктурой, а не только с учебными примерами
4. Соберете практический опыт, который можно обсуждать на собеседованиях и использовать в работе
5. Все записи и материалы останутся у вас после окончания программы
Преподаватели – практикующие специалисты из ведущих технологических компаний. На занятиях можно разбирать реальные кейсы, задавать вопросы и получать обратную связь
👉 Подробности и квиз – на сайте
Квиз покажет, насколько программа подходит именно под вашу роль и задачи, даст персональные рекомендации и промокод на скидку
___
По всем вопросам пишите Алексею @snitsa
❤4👎1