Хотите погрузиться во внутренности распределенных СУБД?
Подпишитесь на канал Carnegie Mellon University Database Group со свежими лекциями Энди Павло:
• Intro to Database Systems: все про устройство СУБД, в том числе распределенных - работа с диском и памятью, структуры данных и алгоритмы
• Advanced Database Systems: сжатие данных, сложные алгоритмы join'ов и устройство оптимизатора в СУБД. После теории автор разбирает современные распределенные движки: Databricks Photon / Spark SQL, Google BigQuery / Dremel, Snowflake
Понимание устройства распределенных СУБД поможет вам писать более эффективные запросы к существующим хранилищам данных и научит проектировать новые.
Энди Павло - профессор CMU и один из немногих учеников Майкла Стоунбрейкера, отца Postgres и Vertica. Ученики Энди Павло, в свою очередь, сегодня разрабатывают топовые движки: Databricks, BigQuery, Snowflake и другие.
#Databases
Подпишитесь на канал Carnegie Mellon University Database Group со свежими лекциями Энди Павло:
• Intro to Database Systems: все про устройство СУБД, в том числе распределенных - работа с диском и памятью, структуры данных и алгоритмы
• Advanced Database Systems: сжатие данных, сложные алгоритмы join'ов и устройство оптимизатора в СУБД. После теории автор разбирает современные распределенные движки: Databricks Photon / Spark SQL, Google BigQuery / Dremel, Snowflake
Понимание устройства распределенных СУБД поможет вам писать более эффективные запросы к существующим хранилищам данных и научит проектировать новые.
Энди Павло - профессор CMU и один из немногих учеников Майкла Стоунбрейкера, отца Postgres и Vertica. Ученики Энди Павло, в свою очередь, сегодня разрабатывают топовые движки: Databricks, BigQuery, Snowflake и другие.
#Databases
CMU 15-445/645
Schedule - CMU 15-445/645 :: Intro to Database Systems (Fall 2023)
Course schedule with slides, lecture notes, and videos.
🚀 Переосмысливаем BI в большой компании: наш путь к open source с Redash
В 2022 году мы столкнулись с задачей замены Tableau, лидера в области BI, на open source решение. Нам предстояло не только выбрать новый инструмент, но и изменить подход к аналитике данных.
🔍 Выбор инструмента: аналитический метод
Переход начался с анализа. Мы изучили лидеров рынка и open source альтернативы, оценивая их по ключевым параметрам:
- функциональность
- удобство использования
- масштабируемость
- стоимость.
Импортные BI решения сразу были убраны со стола, из-за сложностей с покупкой и наличием вендорлока. А российские BI системы еще не были развиты на приемлемом уровне. Поэтому у нас выбор был между SuperSet, Redash и Metabase.
Далее мы проанализировали логи использования Tableau и подготовили список функций, которые применялись нашими пользователями, а дальше оценили open source BI тройку на соответствие этим функциям. К сожалению любой open source далек от Tableau и мы начали оценивать стоимость и сложность доработок.
Среди всех кандидатов Redash выделился, показав наилучшее соответствие нашим требованиям, т.к. он полностью соответствовал нашему стеку, в отличии от metabase и в нем не пришлось бы сильно ломать пользовательские сценарии, как SuperSet.
🛠 Усиление функционала
Приняв решение в пользу Redash, мы начали активно развивать функциональность, уже за первые пол года были сделаны разные фичи, например такие как: Row Level Security, Workbooks, Projects, Presets, переделаны типы визуализаций, “экстракты как в Табло” и т.д.
🚀 Технические улучшения
Переход на TypeScript и усиленное покрытие unit-тестами значительно улучшили стабильность и производительность нашего решения. Мы сократили технический долг и повысили эффективность разработки и поддержки.
💡 Результаты
Переход на Redash не только открыл для нас новые возможности по масштабированию и адаптации под нужды бизнеса, но и позволил существенно расширить функциональность BI-инструментария, сделав его более быстрым и надежным для конечных пользователей.
А в будущих постах про BI мы будем больше рассказывать про фичи которые уже были разработаны и продолжают разрабатываться в Avito Redash.
#BI #Redash
В 2022 году мы столкнулись с задачей замены Tableau, лидера в области BI, на open source решение. Нам предстояло не только выбрать новый инструмент, но и изменить подход к аналитике данных.
🔍 Выбор инструмента: аналитический метод
Переход начался с анализа. Мы изучили лидеров рынка и open source альтернативы, оценивая их по ключевым параметрам:
- функциональность
- удобство использования
- масштабируемость
- стоимость.
Импортные BI решения сразу были убраны со стола, из-за сложностей с покупкой и наличием вендорлока. А российские BI системы еще не были развиты на приемлемом уровне. Поэтому у нас выбор был между SuperSet, Redash и Metabase.
Далее мы проанализировали логи использования Tableau и подготовили список функций, которые применялись нашими пользователями, а дальше оценили open source BI тройку на соответствие этим функциям. К сожалению любой open source далек от Tableau и мы начали оценивать стоимость и сложность доработок.
Среди всех кандидатов Redash выделился, показав наилучшее соответствие нашим требованиям, т.к. он полностью соответствовал нашему стеку, в отличии от metabase и в нем не пришлось бы сильно ломать пользовательские сценарии, как SuperSet.
🛠 Усиление функционала
Приняв решение в пользу Redash, мы начали активно развивать функциональность, уже за первые пол года были сделаны разные фичи, например такие как: Row Level Security, Workbooks, Projects, Presets, переделаны типы визуализаций, “экстракты как в Табло” и т.д.
🚀 Технические улучшения
Переход на TypeScript и усиленное покрытие unit-тестами значительно улучшили стабильность и производительность нашего решения. Мы сократили технический долг и повысили эффективность разработки и поддержки.
💡 Результаты
Переход на Redash не только открыл для нас новые возможности по масштабированию и адаптации под нужды бизнеса, но и позволил существенно расширить функциональность BI-инструментария, сделав его более быстрым и надежным для конечных пользователей.
А в будущих постах про BI мы будем больше рассказывать про фичи которые уже были разработаны и продолжают разрабатываться в Avito Redash.
#BI #Redash
Airflow Declarative - как не дать себя опутать
Те кто давно разрабатывают пайплайны для Airflow не понаслышке знают насколько легко в код проектов прорастают специфичные для самого Airflow API и функционал.
Для того, чтобы оградить разработчиков, от необходимости собирать пайплайн внутри питон-кода и вендор лока на airflow и была создана библиотечка airflow-declarative.
Делимся историей о предпосылках создания библиотеки и ее возможностях -
https://telegra.ph/Airflow-Declarative---kak-ne-dat-sebya-oputat-04-05
#Airflow
Те кто давно разрабатывают пайплайны для Airflow не понаслышке знают насколько легко в код проектов прорастают специфичные для самого Airflow API и функционал.
Для того, чтобы оградить разработчиков, от необходимости собирать пайплайн внутри питон-кода и вендор лока на airflow и была создана библиотечка airflow-declarative.
Делимся историей о предпосылках создания библиотеки и ее возможностях -
https://telegra.ph/Airflow-Declarative---kak-ne-dat-sebya-oputat-04-05
#Airflow
Telegraph
Airflow Declarative - как не дать себя опутать
История создания airflow-declarative восходит к 2017 году (кажется airflow был тогда версии 1.6-1.7), когда я работал в Рамблере (RIP) - мой старший инфраструктурный инженер и куратор Саша Шорин aka kxepal, к тому моменту уже успевший год как отмигрировать…
Сегодня мы заглянем под капот Vertica и расскажем о некоторых проблемах из практики ее обслуживания. Мы активно мигрируем ежедневные расчеты данных в Trino, но большая их часть по-прежнему крутится в Vertica. Недавно с ней приключилась интересная история.
https://telegra.ph/Kak-OOM-killer-Vertica-ubival-04-08
#Vertica
https://telegra.ph/Kak-OOM-killer-Vertica-ubival-04-08
#Vertica
Telegraph
Как OOM киллер Vertica убивал
Недавно мы обнаружили, что OOM киллер вдруг стал убивать процессы Vertica. Заглянув в atop, мы увидели, что она использовала меньше 300ГБ памяти, а остальные процессы набирали еще максимум 100ГБ при пределе в 500ГБ на сервер. Вроде мы еще далеки от лимита…
Наш аналитик, Артём Дронов, рассказал, как мы в Авито масштабируем AB-эксперименты. На платформе Trisigma проходит порядка 3000 экспериментов в год и это количество растет 40% YoY (конечно, у нас data-driven подход).
Теперь мы готовы выводить платформу на внешний рынок и уже ведем пилотные проекты с некоторыми компаниями.
Рекомендуем к просмотру!
#AB
Теперь мы готовы выводить платформу на внешний рынок и уже ведем пилотные проекты с некоторыми компаниями.
Рекомендуем к просмотру!
#AB
YouTube
Как масштабировать AB эксперименты | Артем Дронов | A/B Platform 2024 | SberMarket Tech
Поговорим, как в Авито бизнес формулируют свои цели основываясь на глобальных метриках. И как при этом команды оценивают свои результаты по результатам A/B, направленным на различные сегменты аудитории. Расскажем про методологию приведения результатов экспериментов…
Всем привет! Мы уже рассказывали про повышение качества данных с использованием Zero Bug Policy.
Прошло полгода и сегодня мы хотим поделиться рассказом про риск-ориентированный подход и метрики качества данных.
https://telegra.ph/Risk-orientirovannyj-podhod-k-DQ-04-17
#DQ
Прошло полгода и сегодня мы хотим поделиться рассказом про риск-ориентированный подход и метрики качества данных.
https://telegra.ph/Risk-orientirovannyj-podhod-k-DQ-04-17
#DQ
Telegraph
Риск-ориентированный подход к DQ
Мы, как команда Data Quality, стремимся, чтобы о нас забыли: если никто не говорит про качество данных, значит, все хорошо. Можно провести аналогию с безопасностью - о нас вспоминают, когда творится что-то неладное. В мире безопасности давно главенствует…
Привет! Сегодня расскажем, как можно быть эффективнее аналитической СУБД на примере джойна на коленке. Погнали:
https://telegra.ph/Kak-baza-mozhet-proigrat-algoritmu-na-kolenke-04-23
#Databases
https://telegra.ph/Kak-baza-mozhet-proigrat-algoritmu-na-kolenke-04-23
#Databases
Telegraph
Как база может проиграть алгоритму на коленке
С начала времен мы строим хранилище данных в Авито на основе методологии Anchor Modeling. Принято считать, что такая методология хорошо работает за счет локальных и мердж джойнов. И даже более того, что нет ничего лучше для настолько нормализованных данных. …
Привет всем! Сегодня мы продолжаем тему качества данных рассказом об анализе критических инцидентов с пользовательскими событиями.
https://telegra.ph/CHto-mozhno-uznat-iz-analiza-kriticheskih-incidentov-svyazannyh-s-logirovaniem-analiticheskih-sobytij-04-26
#DQ
https://telegra.ph/CHto-mozhno-uznat-iz-analiza-kriticheskih-incidentov-svyazannyh-s-logirovaniem-analiticheskih-sobytij-04-26
#DQ
Telegraph
Что можно узнать из анализа критических инцидентов, связанных с логированием аналитических событий?
Сегодня мы начинаем большой цикл статей о системе логирования пользовательских действий в Авито. Многосерийный рассказ о том, как действия пользователей порождают аналитические события, которые в процессе множества трансформаций в пайплайне данных превращаются…
Самый важный SQL-запрос в моей карьере.
Сегодняшний пост про анализ аб-тестов. Будет полезен всем аналитикам и bi-девелоперам.
Создатель in-house платформы для A/B-тестирования в Авито Данила Леньков делится лайфаком: как свести задачу расчета Minimum Detectable Effect к простому SQL-запросу.
Читайте и делитесь в комметриях своими лайфхаками про анализ #аб!
Сегодняшний пост про анализ аб-тестов. Будет полезен всем аналитикам и bi-девелоперам.
Создатель in-house платформы для A/B-тестирования в Авито Данила Леньков делится лайфаком: как свести задачу расчета Minimum Detectable Effect к простому SQL-запросу.
Читайте и делитесь в комметриях своими лайфхаками про анализ #аб!
Telegraph
Самый важный SQL-запрос в моей карьере или как посчитать MDE правильно
Больше 6 лет я занимаюсь вопросами культуры и автоматизации A/B-тестирования. Сотни часов я провел, консультируя аналитиков внутри и за пределами Авито по вопросам дизайна экспериментов. Тема A/B не всегда дается легко, несмотря на большое количество материалов…
Привет, на связи команда Datamart аналитической платформы Авито.
В этой статье я расскажу о том, как мы нашли одну из причин деградации наших аналитических расчетов. Конкурентная работа с памятью или загадка потерянного времени
#Vertica #Databases
В этой статье я расскажу о том, как мы нашли одну из причин деградации наших аналитических расчетов. Конкурентная работа с памятью или загадка потерянного времени
#Vertica #Databases
Telegraph
Конкурентная работа с памятью или загадка потерянного времени
В этой статье я расскажу о том, как мы нашли одну из причин деградации наших расчетов. Спойлер - решение оказалось довольно простым. Контекст С каждым днем бизнес Авито развивается, растет количество данных, и растет общая длительность всех аналитических…
Всем привет! Сегодня, в продолжение предыдущего поста, разберем, как можно анализировать внутреннний продукт и какие инсайты из этого мы получили.
#Clickstream
#Clickstream
Telegraph
Внутренняя аналитика: логирование действий во внутренних инструментах для улучшения ux продуктов
В предыдущей статье Никита рассказал про техническое устройство системы логирования пользовательских событий в Авито - Clickstream. Сегодня я расскажу, как мы используем эту систему для логирования действий аналитиков на внутренних продуктах Авито. Подобный…
Наш Senior SRE, Виктор Еремченко, рассказал, как мы повышали стабильность аналитической платформы. В докладе вы узнаете про, то на каких метриках мы сфокусировались, какие инструменты для мониторинга выбрали и каких результатов добились.
Выступление будет полезно SRE и всем заинтересованным в повышении стабильности хранилищ данных.
Выступление будет полезно SRE и всем заинтересованным в повышении стабильности хранилищ данных.
YouTube
Виктор Ерёмченко. Ключевые метрики стабильности,или Как мы мониторим аналитическую платформу в Авито
DUMP SPb 2025 - 14 февраля, dump-spb.ru
DUMP Ekb 2025 - 25 апреля, dump-ekb.ru
Ключевые метрики стабильности, или Как мы мониторим аналитическую платформу в Авито
Виктор Ерёмченко
Senior Site Reliability Engineer, Авито
В докладе расскажу опыт подхода…
DUMP Ekb 2025 - 25 апреля, dump-ekb.ru
Ключевые метрики стабильности, или Как мы мониторим аналитическую платформу в Авито
Виктор Ерёмченко
Senior Site Reliability Engineer, Авито
В докладе расскажу опыт подхода…
При переходе на open source BI в 2022 году мы столкнулись с целой кучей трудностей, сегодня я расскажу, как мы допиливали open source Redash под себя.
Статья будет полезна тем, кто уже работает с Redash или смотрит в сторону open source
#BI #Redash
Статья будет полезна тем, кто уже работает с Redash или смотрит в сторону open source
#BI #Redash
Telegraph
Допиливание Open Source BI или что нам не хватало в Redash (part 1)
Привет, мы в компании avito перешли на redash летом 2022 года и это был не простой выбор. Данное BI решение покрывало наши требования по фичам примерно на 35% и впереди был интересный путь, который нам нужно было пройти, чтобы упростить работу по созданию…
Всем привет! Со старта канала прошло 2 месяца и с нами уже больше 800 подписчиков, спасибо вам!❤️
Делимся подборкой лучших публикаций:
📊 #BI #Redash
- Переосмысливаем BI в большой компании
- Сложности перехода из Tableau в Redash (part 1)
🆎 #AB #Trisigma
- Как масштабировать A/B-эксперименты
- Самый важный SQL-запрос в моей карьере или как посчитать MDE правильно
💾 #Databases #Vertica
- Что посмотреть про внутренности распределенных СУБД
- Как OOM киллер Vertica убивал
- Как база может проиграть алгоритму на коленке
- Конкурентная работа с памятью или загадка потерянного времени
🔎 #DQ
- Риск-ориентированный подход к DQ
- Что можно узнать из анализа инцидентов логирования критических событий
🌊 #Clickstream
- Платформа логирования аналитических событий
- Как можно анализировать внутренний продукт с использованием логирования
🕸 #Airflow
- Airflow Declarative: как не дать себя опутать
🤝 Общее
- О чем этот канал
- Записи подкаста про аналитическую платформу
- Как мы мониторим аналитическую платформу
Поделитесь, какие темы были бы интересны вам?
Делимся подборкой лучших публикаций:
📊 #BI #Redash
- Переосмысливаем BI в большой компании
- Сложности перехода из Tableau в Redash (part 1)
🆎 #AB #Trisigma
- Как масштабировать A/B-эксперименты
- Самый важный SQL-запрос в моей карьере или как посчитать MDE правильно
💾 #Databases #Vertica
- Что посмотреть про внутренности распределенных СУБД
- Как OOM киллер Vertica убивал
- Как база может проиграть алгоритму на коленке
- Конкурентная работа с памятью или загадка потерянного времени
🔎 #DQ
- Риск-ориентированный подход к DQ
- Что можно узнать из анализа инцидентов логирования критических событий
🌊 #Clickstream
- Платформа логирования аналитических событий
- Как можно анализировать внутренний продукт с использованием логирования
🕸 #Airflow
- Airflow Declarative: как не дать себя опутать
🤝 Общее
- О чем этот канал
- Записи подкаста про аналитическую платформу
- Как мы мониторим аналитическую платформу
Поделитесь, какие темы были бы интересны вам?
Всем привет!
Сегодня расскажем о том, как мы обновляли версию ОС на кластере вертики, и почему это стало целым приключением.
Зачем мы это делали? Мы хотели полечить баг с падением из-за старой версии glibc, и у нас есть требования к минимальной поддерживаемой версии софта в компании. Погнали!
#Vertica
Сегодня расскажем о том, как мы обновляли версию ОС на кластере вертики, и почему это стало целым приключением.
Зачем мы это делали? Мы хотели полечить баг с падением из-за старой версии glibc, и у нас есть требования к минимальной поддерживаемой версии софта в компании. Погнали!
#Vertica
Telegraph
Вертика и сетевые драйверы
Недавно мы обновляли debian на серверах с 10 до 11 версии (да, мы знаем, что вертика официально не поддерживает свежие версии дистрибутивов, но мы все равно это делаем). И поначалу все шло хорошо. Собирая статистику ретроспективно, падения в самом деле прекратились.…
Привет, меня зовут Илья, я тимлид команды, которая разрабатывает BI в Авито!
Мы каждый спринт выкатываем новые фичи для наших пользователей, и сегодня хочу продолжить рассказ про большие фичи, что мы реализовали.
#BI #Redash
Мы каждый спринт выкатываем новые фичи для наших пользователей, и сегодня хочу продолжить рассказ про большие фичи, что мы реализовали.
#BI #Redash
Telegraph
Допиливание Open Source BI или что нам не хватало в Redash (part 2)
Cегодня я продолжу статью, которую начал месяц назад: про то, как мы допиливали open source BI. Фичи, о которых пойдет речь, хоть и занимают мало места по описанию в этой статье, но при проработке решения забрали у нас достаточно много времени. При создании…
Всем привет!
Как думаете, какой должна быть скорость загрузки дашборда? Мне кажется, что максимальной 🙂 Но быстро извлекать данные из источников получается не всегда: иногда БД находятся под нагрузкой, а иногда ваш запрос громоздкий и сложный. Лидеры рынка предлагают функционал по извлечению данных в собственное быстрое хранилище, например, в Tableau есть функционал Exctract.
В нашей BI-системе мы сделали свои extract'ы, а для наглядности записали короткое видео, как они работают и как наши пользователи могут их создавать. Ставь лайк, если хочешь больше лайф демо наших систем 😉
#Redash
Как думаете, какой должна быть скорость загрузки дашборда? Мне кажется, что максимальной 🙂 Но быстро извлекать данные из источников получается не всегда: иногда БД находятся под нагрузкой, а иногда ваш запрос громоздкий и сложный. Лидеры рынка предлагают функционал по извлечению данных в собственное быстрое хранилище, например, в Tableau есть функционал Exctract.
В нашей BI-системе мы сделали свои extract'ы, а для наглядности записали короткое видео, как они работают и как наши пользователи могут их создавать. Ставь лайк, если хочешь больше лайф демо наших систем 😉
#Redash
YouTube
Extract'ы в Redash
Всем привет! Сегодня мы побольше расскажем о себе: поделимся нашей ролью в компании, вызовами и попробуем найти новых коллег 😊
Организационная структура Авито состоит из множества кросс-функциональных команд (юнитов), которые соединяются в кластеры. Analytics Platform — это кластер из сотни человек, который разрабатывает платформу для упрощения решения аналитических задач в компании.
Аналитическая платформа — ядро развития бизнеса Авито с 2013 года. Тогда в компанию пришел Иван Гуз и внедрил data-центричный подход*. С тех пор на аналитическую платформу завязаны многие процессы компании: от А/Б тестов и принятия решений на метриках до процессов маркетинга и продаж, а Иван стал управляющим партнером компании.
Ядровые пользователи платформы — более 300 аналитиков, которые ежедневно 80% рабочего времени проводят в ней. При этом «на чтение» с платформой работают все сотрудники: от управляющих директоров до специалистов операционных подразделений (технической поддержки, модерации). Таких пользователей уже тысячи.
Мы выделяем у платформы 3 ключевых направления развития до 2026 года:
🕘 Стабильность.
Аналитика в Авито зарождалась в централизованном DWH, на котором строились как критичные для бизнеса процессы, так и исследовательская работа. Это позволило сделать быстрый старт и было эффективно на первых этапах, но теперь мы хотим перейти на следующий уровень. Мы внедряем распределенный Data LakeHouse с хранением данных в Ceph и вычислении в Trino. Образ результата — платформа для платформ с прозрачными SLA для бизнес-потребителей, изолированными контурами и владельцами. Главная метрика на текущий момент — суммарное отставание по готовности данных отчета с ключевыми метриками компании от 09:00. Суммарное отставание в квартал мы хотим сократить с дней до часов.
😄 Упрощение аналитических задач.
Долгое время нашей целью было развитие подхода self-service, когда каждый аналитик способен пройти весь процесс от сбора данных, проведения анализа и до создания финального регулярно обновляемого отчета без дополнительного привлечения дата инженеров. И мы добились этого, сейчас доля решаемых самостоятельно задач выше 90%! Теперь мы фокусируемся на снижении доли времени работы аналитика, которое он тратит на технические задачи: написание и оптимизация кода, поиск и валидация данных, создание отчетов и документирование исследований. В платформе зародилось более 30 инструментов, заточенных под конкретные задачи, мы делаем ставки на продуктовизацию и демократизацию - хотим прийти к ограниченному набору продуктов, решающих сквозные пользовательские сценарии. Главная метричная цель - менее 20% времени аналитика на технические задачи.
🚀 Вывод продукта на внешний рынок.
С 2013 года мы накопили в компании серьезную экспертизу по развитию инструментов для аналитики. Мы видим, что многие компании решают похожие проблемы, но не готовы инвестировать в большую in-house разработку (это долго и сложно), при этом хорошие вендорские решения дорогие и ушли из РФ. Мы уже начали пилоты с компаниями по интеграции платформы Trisigma. Цель — подключить 50 клиентов и выйти на окупаемость B2B value-стрима.
Для достижения этих больших целей мы ищем инженеров разных уровней (от Junior до Senior) и профилей (Data Engineer, SRE, Backend, Frontend, QA), а также технических руководителей (команды от 5 до 25 чел).
💌 Смотрите вакансии по ссылке, откликайтесь или пишите мне @nikolaevgenii и нашему рекрутеру @aerfulix!
*пожалуйста, воспользуйтесь VPN, чтобы открыть статью
Организационная структура Авито состоит из множества кросс-функциональных команд (юнитов), которые соединяются в кластеры. Analytics Platform — это кластер из сотни человек, который разрабатывает платформу для упрощения решения аналитических задач в компании.
Аналитическая платформа — ядро развития бизнеса Авито с 2013 года. Тогда в компанию пришел Иван Гуз и внедрил data-центричный подход*. С тех пор на аналитическую платформу завязаны многие процессы компании: от А/Б тестов и принятия решений на метриках до процессов маркетинга и продаж, а Иван стал управляющим партнером компании.
Ядровые пользователи платформы — более 300 аналитиков, которые ежедневно 80% рабочего времени проводят в ней. При этом «на чтение» с платформой работают все сотрудники: от управляющих директоров до специалистов операционных подразделений (технической поддержки, модерации). Таких пользователей уже тысячи.
Мы выделяем у платформы 3 ключевых направления развития до 2026 года:
🕘 Стабильность.
Аналитика в Авито зарождалась в централизованном DWH, на котором строились как критичные для бизнеса процессы, так и исследовательская работа. Это позволило сделать быстрый старт и было эффективно на первых этапах, но теперь мы хотим перейти на следующий уровень. Мы внедряем распределенный Data LakeHouse с хранением данных в Ceph и вычислении в Trino. Образ результата — платформа для платформ с прозрачными SLA для бизнес-потребителей, изолированными контурами и владельцами. Главная метрика на текущий момент — суммарное отставание по готовности данных отчета с ключевыми метриками компании от 09:00. Суммарное отставание в квартал мы хотим сократить с дней до часов.
😄 Упрощение аналитических задач.
Долгое время нашей целью было развитие подхода self-service, когда каждый аналитик способен пройти весь процесс от сбора данных, проведения анализа и до создания финального регулярно обновляемого отчета без дополнительного привлечения дата инженеров. И мы добились этого, сейчас доля решаемых самостоятельно задач выше 90%! Теперь мы фокусируемся на снижении доли времени работы аналитика, которое он тратит на технические задачи: написание и оптимизация кода, поиск и валидация данных, создание отчетов и документирование исследований. В платформе зародилось более 30 инструментов, заточенных под конкретные задачи, мы делаем ставки на продуктовизацию и демократизацию - хотим прийти к ограниченному набору продуктов, решающих сквозные пользовательские сценарии. Главная метричная цель - менее 20% времени аналитика на технические задачи.
🚀 Вывод продукта на внешний рынок.
С 2013 года мы накопили в компании серьезную экспертизу по развитию инструментов для аналитики. Мы видим, что многие компании решают похожие проблемы, но не готовы инвестировать в большую in-house разработку (это долго и сложно), при этом хорошие вендорские решения дорогие и ушли из РФ. Мы уже начали пилоты с компаниями по интеграции платформы Trisigma. Цель — подключить 50 клиентов и выйти на окупаемость B2B value-стрима.
Для достижения этих больших целей мы ищем инженеров разных уровней (от Junior до Senior) и профилей (Data Engineer, SRE, Backend, Frontend, QA), а также технических руководителей (команды от 5 до 25 чел).
💌 Смотрите вакансии по ссылке, откликайтесь или пишите мне @nikolaevgenii и нашему рекрутеру @aerfulix!
*
Сегодняшний пост снова на волнующую многих тему A/B-тестов.
Пару месяцев назад мы поделились лайфхаком: как посчитать MDE без python на чистом SQL. В этот раз Данила Леньков развивает тему: как в SQL проанализировать результаты эксперимента и посчитать t-test.
#AB
Пару месяцев назад мы поделились лайфхаком: как посчитать MDE без python на чистом SQL. В этот раз Данила Леньков развивает тему: как в SQL проанализировать результаты эксперимента и посчитать t-test.
#AB
Telegraph
t-test без боли на чистом SQL
В прошлый раз я поделился лайфхаком для дата-аналитика — как посчитать MDE для A/B-теста простым SQL-запросом. Пост нашел свою аудиторию: судя по статистике telegram его добавили в закладки более 500 раз. Сегодня хочу развить тему и рассказать, как использовать…
Почему мы идем в Data Lakehouse?
В этом посте мы рассмотрим варианты построения аналитического хранилища данных и представим концепцию Data Lakehouse.
Хранилище данных — это ядро аналитической платформы, которое состоит из 6 компонентов:
- Storage — собственно, где хранятся данные.
- Storage Engine — движок, отвечающий за физическую оптимизацию хранения данных.
- Compute Engine — движок, отвечающий за выполнение запросов и обработку данных.
- Catalog — система хранения метаданных (таблицы, схемы).
- Table Format — система, обеспечивающая SQL-like синтаксис работы с табличными данными.
- File Format — формат хранения данных (колоночные, строковые, ...).
Первая концепция Data Warehouse (DWH) появилась еще в 1980-х годах. В концепции описанные выше компоненты содержатся в одной коробке и максимально заточены друг под друга. Такой вариант удобен для аналитика: единая точка входа, хорошо работают аналитические запросы, просто управлять данными, схема валидируется при записи. При этом DWH редко приспособлен для решения data science задач: не приспособлен к ML-нагрузке и хранит только структурированные данные. С точки зрения администратора такое хранилище легко конфигурировать, при этом оно лишено гибкости. Один из главных недостатков — на больших объемах хранилище слишком дорого масштабировать (Compute и Storage движки соединены), подменить Compute — нельзя, всё закрыто через вендор-лок.
В 2011 году компания Pentaho представила подход Data Lake. Это парадоксально, но в таком подходе в хранилище отсутствует Storage Engine. Как преимущество — данные хранятся в открытых форматах и на дешевом железе, в хранилище может быть несколько Compute Engine (решается проблема масштабирования). Также Data Lake отлично заточен на решение data science задач: он хранит неструктурированные данные и приспособлен к ML-нагрузке. При этом такое хранилище существенно сложнее поддерживать: нужно выбирать, собирать и затачивать друг под друга компоненты. Аналитику приходится работать с неструктурированными данными и мириться с плохим перформансом запросов по сравнению с DWH.
Следующей революцией в мире аналитических хранилищ данных стала парадигма Data Lakehouse. В эту сторону двигались некоторые Big Tech компании, а термин ввели Jellyvision в 2017 году. Из названия мы понимаем, что этот подход призван совместить плюсы двух предыдущих концепций. Lakehouse предоставляет DWH-like интерфейс, предоставляет сопоставимую скорость выполнения запросов. При этом интерфейс построен на открытых технологиях, дешевом железе и приспособлен для ML-задач, как Data Lake. Разумеется, такой подход сложнее с точки зрения администрирования, но это стоит того, в особенности на больших объемах.
Хотите узнать подробнее про наш Data Lakehouse? Ставьте 👍
#Databases
В этом посте мы рассмотрим варианты построения аналитического хранилища данных и представим концепцию Data Lakehouse.
Хранилище данных — это ядро аналитической платформы, которое состоит из 6 компонентов:
- Storage — собственно, где хранятся данные.
- Storage Engine — движок, отвечающий за физическую оптимизацию хранения данных.
- Compute Engine — движок, отвечающий за выполнение запросов и обработку данных.
- Catalog — система хранения метаданных (таблицы, схемы).
- Table Format — система, обеспечивающая SQL-like синтаксис работы с табличными данными.
- File Format — формат хранения данных (колоночные, строковые, ...).
Первая концепция Data Warehouse (DWH) появилась еще в 1980-х годах. В концепции описанные выше компоненты содержатся в одной коробке и максимально заточены друг под друга. Такой вариант удобен для аналитика: единая точка входа, хорошо работают аналитические запросы, просто управлять данными, схема валидируется при записи. При этом DWH редко приспособлен для решения data science задач: не приспособлен к ML-нагрузке и хранит только структурированные данные. С точки зрения администратора такое хранилище легко конфигурировать, при этом оно лишено гибкости. Один из главных недостатков — на больших объемах хранилище слишком дорого масштабировать (Compute и Storage движки соединены), подменить Compute — нельзя, всё закрыто через вендор-лок.
В 2011 году компания Pentaho представила подход Data Lake. Это парадоксально, но в таком подходе в хранилище отсутствует Storage Engine. Как преимущество — данные хранятся в открытых форматах и на дешевом железе, в хранилище может быть несколько Compute Engine (решается проблема масштабирования). Также Data Lake отлично заточен на решение data science задач: он хранит неструктурированные данные и приспособлен к ML-нагрузке. При этом такое хранилище существенно сложнее поддерживать: нужно выбирать, собирать и затачивать друг под друга компоненты. Аналитику приходится работать с неструктурированными данными и мириться с плохим перформансом запросов по сравнению с DWH.
Следующей революцией в мире аналитических хранилищ данных стала парадигма Data Lakehouse. В эту сторону двигались некоторые Big Tech компании, а термин ввели Jellyvision в 2017 году. Из названия мы понимаем, что этот подход призван совместить плюсы двух предыдущих концепций. Lakehouse предоставляет DWH-like интерфейс, предоставляет сопоставимую скорость выполнения запросов. При этом интерфейс построен на открытых технологиях, дешевом железе и приспособлен для ML-задач, как Data Lake. Разумеется, такой подход сложнее с точки зрения администрирования, но это стоит того, в особенности на больших объемах.
Хотите узнать подробнее про наш Data Lakehouse? Ставьте 👍
#Databases