Хотите погрузиться во внутренности распределенных СУБД?
Подпишитесь на канал 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.
Привет! Сегодня расскажем, как можно быть эффективнее аналитической СУБД на примере джойна на коленке. Погнали:
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. Принято считать, что такая методология хорошо работает за счет локальных и мердж джойнов. И даже более того, что нет ничего лучше для настолько нормализованных данных. …
Привет, на связи команда Datamart аналитической платформы Авито.
В этой статье я расскажу о том, как мы нашли одну из причин деградации наших аналитических расчетов. Конкурентная работа с памятью или загадка потерянного времени
#Vertica #Databases
В этой статье я расскажу о том, как мы нашли одну из причин деградации наших аналитических расчетов. Конкурентная работа с памятью или загадка потерянного времени
#Vertica #Databases
Telegraph
Конкурентная работа с памятью или загадка потерянного времени
В этой статье я расскажу о том, как мы нашли одну из причин деградации наших расчетов. Спойлер - решение оказалось довольно простым. Контекст С каждым днем бизнес Авито развивается, растет количество данных, и растет общая длительность всех аналитических…
Всем привет! Со старта канала прошло 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: как не дать себя опутать
🤝 Общее
- О чем этот канал
- Записи подкаста про аналитическую платформу
- Как мы мониторим аналитическую платформу
Поделитесь, какие темы были бы интересны вам?
Почему мы идем в 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
Чтобы что-то в каталоге нашлось, нужно что-то в каталог добавить! ☝️
Что же мешает данным оказаться в нём? «Метаинформационное налогообложение». Это оплата усилий, необходимых для документирования и ввода метаданных. А так как эффективный дата-каталог критически важен для успеха бизнеса, платить этот «налог» придётся.
🔍 Как найти тех, кто будет его (и данные) собирать, и как оптимизировать «налог» — то есть снизить затраты? Читайте в нашей статье про киллер фичи дата-каталогов.
#Databases
Что же мешает данным оказаться в нём? «Метаинформационное налогообложение». Это оплата усилий, необходимых для документирования и ввода метаданных. А так как эффективный дата-каталог критически важен для успеха бизнеса, платить этот «налог» придётся.
#Databases
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM