Avito Data Tech
2.78K subscribers
170 photos
1 video
1 file
122 links
Эксперты Авито делятся опытом развития аналитической платформы.

Будет полезно для инженеров, аналитиков и тимлидов в сфере Big Data.
Download Telegram
Хотите погрузиться во внутренности распределенных СУБД?

Подпишитесь на канал 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
Всем привет! Со старта канала прошло 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: как не дать себя опутать

🤝 Общее
- О чем этот канал
- Записи подкаста про аналитическую платформу
- Как мы мониторим аналитическую платформу

Поделитесь, какие темы были бы интересны вам?
Почему мы идем в 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
Чтобы что-то в каталоге нашлось, нужно что-то в каталог добавить! ☝️

Что же мешает данным оказаться в нём? «Метаинформационное налогообложение». Это оплата усилий, необходимых для документирования и ввода метаданных. А так как эффективный дата-каталог критически важен для успеха бизнеса, платить этот «налог» придётся.

🔍 Как найти тех, кто будет его (и данные) собирать, и как оптимизировать «налог» — то есть снизить затраты? Читайте в нашей статье про киллер фичи дата-каталогов.

#Databases
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM