Методология Инмона — классика в области хранилищ данных
Билл Инмон впервые предложил идею корпоративного хранилища в 1990 году. Представьте себе "большой архив", где все данные компании аккуратно упорядочены. Хранилище по Инмону является централизованным репозиторием, объединяющим в себе информацию из разных источников.
Проектирование начинается сверху вниз: сначала анализируется весь бизнес, определяются ключевые бизнес-области, затем сущности. На основе этого строится логическая модель с атрибутами каждого объекта. Затем разрабатывается физическая модель с нормализованной структурой (при этом лог.модель можно не завершать полностью, а начинать построение отдельными сущностями). Однако, из-за множества таблиц и ссылок, такую схему может быть сложно использовать для запросов (да-да, очень много JOIN)🙃
Основные принципы методологии Инмона
Все данные должны быть согласованы и нормализованы (минимум 3NF), чтобы избежать избыточности и обеспечить высокий уровень целостности. По сути, это ваша "единая версия истины".
Каждая запись обязательно должна быть снабжена временной меткой. Это позволяет анализировать историю изменений данных.
Методология также подчеркивает необходимость поддержки разных уровней детализации данных для различных аналитических задач. По простому — строить различные витрины под разные бизнес-цели на основе централизованных данных.
Кроме того, методология Инмона требует, чтобы система была гибкой к изменениям. Технологии и требования бизнеса могут меняться, и система должна быть способна адаптироваться к этим изменениям без полной перестройки. Представьте, что вы делаете косметический ремонт квартиры — меняя отделку, но не затрагивая несущие стены.
Применение методологии Инмона позволяет получить полное представление о данных бизнеса, что способствует обоснованному принятию решений.
Преимущества и недостатки:
+ Создание единого хранилища для всех корпоративных данных.
+ Логическая модель отражает бизнес-процессы в компании.
+ Построение хранилища не сразу, а по частям.
+ Высокая целостность и надежность данных
+ Неизменность исторических данных.
+ Полное понимание данных для эффективного анализа и принятия решений.
- Высокие затраты на реализацию.
- Сложность внедрения и управления.
- Время на реализацию.
- Большое количество соединений в запросах.
Важно отметить, что методология Инмона особенно подходит для крупных организаций, где требуется строгая целостность данных и сложный анализ. И она же может оказаться не лучшим выбором для стартапов или компаний, ищущих быстрые и гибкие решения из-за высоких затрат и сложности реализации.
Ну а в следующий раз поговорим о главном "противнике" Инмона — Ральфе Кимбалле.
#dwh
Билл Инмон впервые предложил идею корпоративного хранилища в 1990 году. Представьте себе "большой архив", где все данные компании аккуратно упорядочены. Хранилище по Инмону является централизованным репозиторием, объединяющим в себе информацию из разных источников.
Проектирование начинается сверху вниз: сначала анализируется весь бизнес, определяются ключевые бизнес-области, затем сущности. На основе этого строится логическая модель с атрибутами каждого объекта. Затем разрабатывается физическая модель с нормализованной структурой (при этом лог.модель можно не завершать полностью, а начинать построение отдельными сущностями). Однако, из-за множества таблиц и ссылок, такую схему может быть сложно использовать для запросов (да-да, очень много JOIN)
Основные принципы методологии Инмона
Все данные должны быть согласованы и нормализованы (минимум 3NF), чтобы избежать избыточности и обеспечить высокий уровень целостности. По сути, это ваша "единая версия истины".
Каждая запись обязательно должна быть снабжена временной меткой. Это позволяет анализировать историю изменений данных.
Методология также подчеркивает необходимость поддержки разных уровней детализации данных для различных аналитических задач. По простому — строить различные витрины под разные бизнес-цели на основе централизованных данных.
Кроме того, методология Инмона требует, чтобы система была гибкой к изменениям. Технологии и требования бизнеса могут меняться, и система должна быть способна адаптироваться к этим изменениям без полной перестройки. Представьте, что вы делаете косметический ремонт квартиры — меняя отделку, но не затрагивая несущие стены.
Применение методологии Инмона позволяет получить полное представление о данных бизнеса, что способствует обоснованному принятию решений.
Преимущества и недостатки:
+ Создание единого хранилища для всех корпоративных данных.
+ Логическая модель отражает бизнес-процессы в компании.
+ Построение хранилища не сразу, а по частям.
+ Высокая целостность и надежность данных
+ Неизменность исторических данных.
+ Полное понимание данных для эффективного анализа и принятия решений.
- Высокие затраты на реализацию.
- Сложность внедрения и управления.
- Время на реализацию.
- Большое количество соединений в запросах.
Важно отметить, что методология Инмона особенно подходит для крупных организаций, где требуется строгая целостность данных и сложный анализ. И она же может оказаться не лучшим выбором для стартапов или компаний, ищущих быстрые и гибкие решения из-за высоких затрат и сложности реализации.
Ну а в следующий раз поговорим о главном "противнике" Инмона — Ральфе Кимбалле.
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Методология Кимбалла: эволюция подходов к хранилищам данных
В отличие от подхода Билла Инмона, Ральф Кимбалл в конце 1980-х годов предложил построение хранилища данных снизу вверх. Сначала создаются маленькие, но полнофункциональные модули — звёздные схемы, которые легко масштабируются и интегрируются. Это упрощает доступ к данным и их анализ.
Ключевая идея Кимбалла — использовать денормализованные звёздные схемы для быстрого и эффективного извлечения данных. Данные изначально структурируются для запросов и анализа. Это делает методологию идеальной для бизнес-аналитики, где важен быстрый доступ к актуализированным данным. Хранилище по Кимбаллу — это по сути коллекция витрин данных.
Важные принципы методологии:
— Узнаем какие отчеты нужны, изучаем источники, на этапе подготовки преобразуем данные, затем создаем витрины.
— Денормализация данных уменьшает количество соединений (JOIN) в запросах.
— Простая и понятная архитектура ускоряет разработку и внедрение. Нет детального слоя в понимании Инмона.
— Методология способствует быстрой адаптации к изменениям в бизнес-требованиях, благодаря модульному подходу.
Однако, методология Кимбалла может привести к некоторым проблемам с управлением данными на больших объемах из-за денормализации. Здесь важен баланс между производительностью и точностью данных.
Преимущества и недостатки:
+ Быстрая реализация проектов с "нуля".
+ Гибкость в добавлении новых источников данных.
+ Простота понимания и управления.
+ Простота запросов.
- Риск возрастания избыточности данных.
- Нет единого источника истины.
- Потенциальные трудности в поддержании целостности данных на больших объемах.
Основные отличия подхода Кимбалла от Инмона:
1. Проектирование сверху вниз против снизу вверх.
2. Денормализация данных.
3. Ориентация на быстрый доступ и анализ данных.
4. Низкая целостность данных.
4. Простота и скорость внедрения (по сравнению с Инмоном).
Методология Кимбалла отлично подходит для средних и малых предприятий, где требуется быстрая доставка результатов. Гибкий и модульный подход позволяет быстро адаптироваться к изменяющимся потребностям бизнеса, что делает её предпочтительным выбором для динамичных организаций.
#dwh
В отличие от подхода Билла Инмона, Ральф Кимбалл в конце 1980-х годов предложил построение хранилища данных снизу вверх. Сначала создаются маленькие, но полнофункциональные модули — звёздные схемы, которые легко масштабируются и интегрируются. Это упрощает доступ к данным и их анализ.
Ключевая идея Кимбалла — использовать денормализованные звёздные схемы для быстрого и эффективного извлечения данных. Данные изначально структурируются для запросов и анализа. Это делает методологию идеальной для бизнес-аналитики, где важен быстрый доступ к актуализированным данным. Хранилище по Кимбаллу — это по сути коллекция витрин данных.
Важные принципы методологии:
— Узнаем какие отчеты нужны, изучаем источники, на этапе подготовки преобразуем данные, затем создаем витрины.
— Денормализация данных уменьшает количество соединений (JOIN) в запросах.
— Простая и понятная архитектура ускоряет разработку и внедрение. Нет детального слоя в понимании Инмона.
— Методология способствует быстрой адаптации к изменениям в бизнес-требованиях, благодаря модульному подходу.
Однако, методология Кимбалла может привести к некоторым проблемам с управлением данными на больших объемах из-за денормализации. Здесь важен баланс между производительностью и точностью данных.
Преимущества и недостатки:
+ Быстрая реализация проектов с "нуля".
+ Гибкость в добавлении новых источников данных.
+ Простота понимания и управления.
+ Простота запросов.
- Риск возрастания избыточности данных.
- Нет единого источника истины.
- Потенциальные трудности в поддержании целостности данных на больших объемах.
Основные отличия подхода Кимбалла от Инмона:
1. Проектирование сверху вниз против снизу вверх.
2. Денормализация данных.
3. Ориентация на быстрый доступ и анализ данных.
4. Низкая целостность данных.
4. Простота и скорость внедрения (по сравнению с Инмоном).
Методология Кимбалла отлично подходит для средних и малых предприятий, где требуется быстрая доставка результатов. Гибкий и модульный подход позволяет быстро адаптироваться к изменяющимся потребностям бизнеса, что делает её предпочтительным выбором для динамичных организаций.
#dwh
❤1
От идеи до таблицы: моделирование данных шаг за шагом
Моделирование выходит далеко за рамки таблиц и баз данных. Оно не только помогает разработчикам понять бизнес, но и помогает бизнесу понять себя.
Классически моделирование делится на три этапа:
— концептуальное
— логическое
— физическое
В этой заметке кратко раскроем каждое понятие, а затем в отдельных статьях поговорим про каждый этап подробнее.
Концептуальное моделирование
Это самый абстрактный этап. Он помогает понять, что именно нужно бизнесу. Здесь важна общая картина, а не детали. Представьте, что вы описываете свою компанию другу. Вы говорите о том, что у компании есть клиенты, товары и заказы. Но при этом не уточняете, как именно всё работает.
Концептуальное моделирование помогает всем в компании говорить на одном языке. Бизнес определяет ключевые сущности и связи между ними, архитекторы и/или аналитики создают простую диаграмму для наглядности. Это позволяет всем участникам проекта видеть общую картину.
Логическое моделирование
На этом этапе мы начинаем погружаться в детали, и уточняем все атрибуты и связи. Например, то, что у товара есть название, цена, размер и количество.
Логическое моделирование делает данные и их взаимосвязи понятными для всех участников. Бизнес подробно описывает сущности и процессы более детально, а аналитики конкретизируют эти данные и их связи.
Физическое моделирование
Наконец, заключительный этап — здесь логическая модель преобразуется в конкретное представление для выбранной СУБД. На этом этапе решаются вопросы, как именно данные будут организованы и управляться в выбранной базе данных.
Физическое моделирование включает:
— определение таблиц, столбцов и типов данных
— разработка индексов и партиционирования (при необходимости) для оптимизации производительности
— определение первичных и внешних ключей для обеспечения целостности данных
— прочие технические тонкости, включая data quality
Если коротко:
— Концептуальное моделирование: определяем ключевые сущности и их связи.
— Логическое моделирование: детализируем атрибуты и связи, уточняем типы данных.
— Физическое моделирование: подготавливаем всю техничку для создания в конкретной СУБД.
Зная об этих этапах, становится ясно, как данные проходят путь от абстрактных понятий, до конкретной реализации в базе данных. В итоге хранилище соответствует бизнесу и работает эффективно.
Но нужно понимать, что моделирование — это не событие, а процесс и он продолжается вместе с развитием компании.
#dwh
Моделирование выходит далеко за рамки таблиц и баз данных. Оно не только помогает разработчикам понять бизнес, но и помогает бизнесу понять себя.
Классически моделирование делится на три этапа:
— концептуальное
— логическое
— физическое
В этой заметке кратко раскроем каждое понятие, а затем в отдельных статьях поговорим про каждый этап подробнее.
Концептуальное моделирование
Это самый абстрактный этап. Он помогает понять, что именно нужно бизнесу. Здесь важна общая картина, а не детали. Представьте, что вы описываете свою компанию другу. Вы говорите о том, что у компании есть клиенты, товары и заказы. Но при этом не уточняете, как именно всё работает.
Концептуальное моделирование помогает всем в компании говорить на одном языке. Бизнес определяет ключевые сущности и связи между ними, архитекторы и/или аналитики создают простую диаграмму для наглядности. Это позволяет всем участникам проекта видеть общую картину.
Логическое моделирование
На этом этапе мы начинаем погружаться в детали, и уточняем все атрибуты и связи. Например, то, что у товара есть название, цена, размер и количество.
Логическое моделирование делает данные и их взаимосвязи понятными для всех участников. Бизнес подробно описывает сущности и процессы более детально, а аналитики конкретизируют эти данные и их связи.
Физическое моделирование
Наконец, заключительный этап — здесь логическая модель преобразуется в конкретное представление для выбранной СУБД. На этом этапе решаются вопросы, как именно данные будут организованы и управляться в выбранной базе данных.
Физическое моделирование включает:
— определение таблиц, столбцов и типов данных
— разработка индексов и партиционирования (при необходимости) для оптимизации производительности
— определение первичных и внешних ключей для обеспечения целостности данных
— прочие технические тонкости, включая data quality
Если коротко:
— Концептуальное моделирование: определяем ключевые сущности и их связи.
— Логическое моделирование: детализируем атрибуты и связи, уточняем типы данных.
— Физическое моделирование: подготавливаем всю техничку для создания в конкретной СУБД.
Зная об этих этапах, становится ясно, как данные проходят путь от абстрактных понятий, до конкретной реализации в базе данных. В итоге хранилище соответствует бизнесу и работает эффективно.
Но нужно понимать, что моделирование — это не событие, а процесс и он продолжается вместе с развитием компании.
#dwh
❤1
Ключевые понятия Data Vault
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики. Она помогает интегрировать данные из разных систем и анализировать их. Это фундамент на котором можно построить что угодно.
Hub — это таблица, где хранятся уникальные бизнес-ключи, например, ID клиентов. Это основа, на которой будут строиться все связи в хранилище данных.
Link связывает различные сущности в Data Vault, храня информацию о том, какие бизнес-ключи из Hubs связаны между собой. Например, Link покажет, какой клиент (из таблицы клиентов) сделал какой заказ (из таблицы заказов).
Satellite хранит описательные данные о сущности, представленной в Hub или Link. Например это может быть информация о продукте: название, цена и так далее. Здесь записываются все изменения и история этих данных.
Raw Vault — это слой после этапа интеграции данных. Здесь данные моделируются и готовятся для дальнейшей обработки и анализа.
Business Vault — это слой, где применяются бизнес-правила и выполняются различные преобразования данных. Здесь данные обрабатываются, фильтруются и агрегируются, чтобы получить полезные инсайты и отчеты. То есть это место, где сырые данные превращаются в информацию, готовую для анализа и принятия решений.
Point-in-Time (PIT) — это дополнительные структуры, которые помогают ускорить запросы к данным. Они делают доступ к историческим снимкам данных проще, что важно для анализа трендов.
Bridge Table упрощает навигацию между различными частями модели данных в Data Vault. Она позволяет быстро и эффективно выполнять повторяющиеся запросы, объединяя связанные данные из Hubs и Links. Например, Bridge Table может помочь быстро найти все заказы клиентов по разным регионам, объединяя данные из таблиц клиентов и заказов.
Business Key — уникальный идентификатор, который используется для представления бизнес-сущности. Это основной ориентир для интеграции и анализа данных.
Hash Key — хешированное представление бизнес-ключа. Оно используется для оптимизации запросов и обеспечения консистентности данных.
Surrogate Key — системные идентификаторы, которые уникально идентифицируют записи.
Hash-diff — это столбец, который содержит хешированное значение, созданное из множества других столбцов. Если хоть одно из этих значений изменилось, хеш-значение тоже изменится, что позволяет быстро обнаружить изменения в данных.
Data Vault — это инструмент для организации и анализа данных. Он объединяет лучшие практики и упрощает работу с большими объемами информации. Понимание ключевых понятий, таких как Hub, Link, Satellite, и других, поможет нам в дальнейшем подробнее рассмотреть нюансы самой методологии. До встречи в следующих постах😎
#dwh
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики. Она помогает интегрировать данные из разных систем и анализировать их. Это фундамент на котором можно построить что угодно.
Hub — это таблица, где хранятся уникальные бизнес-ключи, например, ID клиентов. Это основа, на которой будут строиться все связи в хранилище данных.
Link связывает различные сущности в Data Vault, храня информацию о том, какие бизнес-ключи из Hubs связаны между собой. Например, Link покажет, какой клиент (из таблицы клиентов) сделал какой заказ (из таблицы заказов).
Satellite хранит описательные данные о сущности, представленной в Hub или Link. Например это может быть информация о продукте: название, цена и так далее. Здесь записываются все изменения и история этих данных.
Raw Vault — это слой после этапа интеграции данных. Здесь данные моделируются и готовятся для дальнейшей обработки и анализа.
Business Vault — это слой, где применяются бизнес-правила и выполняются различные преобразования данных. Здесь данные обрабатываются, фильтруются и агрегируются, чтобы получить полезные инсайты и отчеты. То есть это место, где сырые данные превращаются в информацию, готовую для анализа и принятия решений.
Point-in-Time (PIT) — это дополнительные структуры, которые помогают ускорить запросы к данным. Они делают доступ к историческим снимкам данных проще, что важно для анализа трендов.
Bridge Table упрощает навигацию между различными частями модели данных в Data Vault. Она позволяет быстро и эффективно выполнять повторяющиеся запросы, объединяя связанные данные из Hubs и Links. Например, Bridge Table может помочь быстро найти все заказы клиентов по разным регионам, объединяя данные из таблиц клиентов и заказов.
Business Key — уникальный идентификатор, который используется для представления бизнес-сущности. Это основной ориентир для интеграции и анализа данных.
Hash Key — хешированное представление бизнес-ключа. Оно используется для оптимизации запросов и обеспечения консистентности данных.
Surrogate Key — системные идентификаторы, которые уникально идентифицируют записи.
Hash-diff — это столбец, который содержит хешированное значение, созданное из множества других столбцов. Если хоть одно из этих значений изменилось, хеш-значение тоже изменится, что позволяет быстро обнаружить изменения в данных.
Data Vault — это инструмент для организации и анализа данных. Он объединяет лучшие практики и упрощает работу с большими объемами информации. Понимание ключевых понятий, таких как Hub, Link, Satellite, и других, поможет нам в дальнейшем подробнее рассмотреть нюансы самой методологии. До встречи в следующих постах
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Эра информационного изобилия: как большие данные меняют мир
Задумывались, сколько информации мы производим каждый день? Невероятное количество. Представьте, объем данных в мире удваивается каждые два года.
Это океан информации — от лайков в соцсетях до показаний умных часов. И знаете, интересно, что около 80% всех данных неструктурированы. Но именно в этом хаосе скрывается невероятный потенциал для исследований и инноваций.
Вот несколько примеров из реальной жизни:
1. Умные города: В Лос-Анджелесе система управления трафиком, анализирующая огромные массивы данных, сократила время в пробках на 16%. А в Москве система интеллектуального управления дорожным движением, анализируя данные с более чем 2000 камер и 3700 датчиков, помогла сократить среднее время поездки на 20% с 2012 года.
2. Точные прогнозы погоды: Европейский центр ECMWF ежедневно обрабатывает более 40 миллионов наблюдений. Это делает прогнозы всё более точными, что помогает лучше планировать жизнь и бизнес.
3. Персонализированное обучение: Платформа Knewton, анализируя данные об успеваемости, подстраивается под каждого студента. В итоге результаты студентов улучшились на 18%, а процент отчислений упал на 47%.
4. Финансовые технологии: Сбербанк, используя большие данные, предотвратил мошеннические операции на сумму более 57 млрд рублей в 2020 году.
5. Сельское хозяйство: Использование данных с дронов и спутников помогает фермерам оптимизировать использование удобрений и пестицидов, что приводит к снижению затрат и увеличению урожайности на 10-15%.
Это лишь малая часть вариантов применения больших данных. Примеры выше показывают, как аналитика помогает улучшать эффективность, снижать затраты и повышать качество жизни людей по всему миру.
Хочется добавить, что несмотря на все эти технологические достижения, главными героями информационной революции пока что всё ещё остаемся мы — обычные люди. Именно наше участие и любопытство двигают прогресс вперед🚀
#dwh
Задумывались, сколько информации мы производим каждый день? Невероятное количество. Представьте, объем данных в мире удваивается каждые два года.
Это океан информации — от лайков в соцсетях до показаний умных часов. И знаете, интересно, что около 80% всех данных неструктурированы. Но именно в этом хаосе скрывается невероятный потенциал для исследований и инноваций.
Вот несколько примеров из реальной жизни:
1. Умные города: В Лос-Анджелесе система управления трафиком, анализирующая огромные массивы данных, сократила время в пробках на 16%. А в Москве система интеллектуального управления дорожным движением, анализируя данные с более чем 2000 камер и 3700 датчиков, помогла сократить среднее время поездки на 20% с 2012 года.
2. Точные прогнозы погоды: Европейский центр ECMWF ежедневно обрабатывает более 40 миллионов наблюдений. Это делает прогнозы всё более точными, что помогает лучше планировать жизнь и бизнес.
3. Персонализированное обучение: Платформа Knewton, анализируя данные об успеваемости, подстраивается под каждого студента. В итоге результаты студентов улучшились на 18%, а процент отчислений упал на 47%.
4. Финансовые технологии: Сбербанк, используя большие данные, предотвратил мошеннические операции на сумму более 57 млрд рублей в 2020 году.
5. Сельское хозяйство: Использование данных с дронов и спутников помогает фермерам оптимизировать использование удобрений и пестицидов, что приводит к снижению затрат и увеличению урожайности на 10-15%.
Это лишь малая часть вариантов применения больших данных. Примеры выше показывают, как аналитика помогает улучшать эффективность, снижать затраты и повышать качество жизни людей по всему миру.
Хочется добавить, что несмотря на все эти технологические достижения, главными героями информационной революции пока что всё ещё остаемся мы — обычные люди. Именно наше участие и любопытство двигают прогресс вперед
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Durability — Устойчивость
Кажется я задолжала вам рассказ о последнем свойстве ACID — устойчивости (durability).
Устойчивость — это гарантия того, что после завершения транзакции данные останутся в базе. Даже если система внезапно выключится или случится какой-то сбой, изменения не пропадут.
Как это работает на практике? Когда транзакция завершается успешно, СУБД физически записывает все изменения. Только после этого транзакция считается завершенной.
Для обеспечения устойчивости базы данных используют разные техники. Одна из них — логирование. Система записывает все изменения в специальный журнал до того, как внести их в основную базу. Если произойдет сбой, СУБД сможет восстановить данные из этого журнала.
Также часто применяют репликацию, т.е. данные копируются на несколько серверов. Если один выйдет из строя, другие продолжат работу.
Устойчивость особенно важна для финансовых систем. Представьте, вы перевели деньги, а потом случился сбой и ваши деньги просто исчезли. Ужасно, правда?
А еще устойчивость=надёжность важна для бизнес-аналитики. Компании полагаются на исторические данные для принятия решений. Если бы данные могли пропасть из-за сбоя, это сильно усложнило бы анализ.
Однако обеспечение устойчивости может замедлять работу системы. Запись на диск и синхронизация реплик требуют времени. Поэтому разработчики всегда ищут баланс между скоростью и надежностью.
Устойчивость — это ключевое свойство для надежных баз данных. Оно гарантирует, что ваши данные в безопасности, что бы ни случилось с системой.
#dwh #acid
Кажется я задолжала вам рассказ о последнем свойстве ACID — устойчивости (durability).
Устойчивость — это гарантия того, что после завершения транзакции данные останутся в базе. Даже если система внезапно выключится или случится какой-то сбой, изменения не пропадут.
Как это работает на практике? Когда транзакция завершается успешно, СУБД физически записывает все изменения. Только после этого транзакция считается завершенной.
Для обеспечения устойчивости базы данных используют разные техники. Одна из них — логирование. Система записывает все изменения в специальный журнал до того, как внести их в основную базу. Если произойдет сбой, СУБД сможет восстановить данные из этого журнала.
Также часто применяют репликацию, т.е. данные копируются на несколько серверов. Если один выйдет из строя, другие продолжат работу.
Устойчивость особенно важна для финансовых систем. Представьте, вы перевели деньги, а потом случился сбой и ваши деньги просто исчезли. Ужасно, правда?
А еще устойчивость=надёжность важна для бизнес-аналитики. Компании полагаются на исторические данные для принятия решений. Если бы данные могли пропасть из-за сбоя, это сильно усложнило бы анализ.
Однако обеспечение устойчивости может замедлять работу системы. Запись на диск и синхронизация реплик требуют времени. Поэтому разработчики всегда ищут баланс между скоростью и надежностью.
Устойчивость — это ключевое свойство для надежных баз данных. Оно гарантирует, что ваши данные в безопасности, что бы ни случилось с системой.
#dwh #acid
Telegram
В мире больших данных
ACID: atomicity, consistency, isolation and durability
Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так…
Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так…
❤1👍1
Наведите порядок в данных: кратко про нормальные формы
Сегодня поговорим о нормальных формах и нормализации. Это важные понятия в мире баз данных, они помогают нам правильно организовывать информацию.
Представьте базу данных в виде большого шкафа для хранения информации. Без правильной организации найти нужные данные будет сложно, как и отыскать конкретную вещь в разбросанном хаосе. Нормализация — это процесс систематизации данных, схожий с наведением порядка в шкафу, но применительно к информации.
Нормальные формы — это набор правил, помогающих структурировать данные оптимальным образом. Существует несколько уровней нормальных форм, каждый из которых улучшает организацию базы данных.
Первая нормальная форма (1NF) устанавливает базовое правило: "Одна ячейка — один факт". Это означает, что нельзя хранить множественные значения в одном поле. Например, контактные номера клиента должны храниться в отдельных записях или столбцах, а не списком в одной ячейке.
Вторая нормальная форма (2NF) развивает эту идею дальше. Она требует, чтобы все неключевые атрибуты зависели от полного первичного ключа, а не от его части. Это похоже на разделение шкафа на секции по типам одежды.
Третья нормальная форма (3NF) вводит дополнительное требование: атрибуты, не зависящие напрямую от первичного ключа, должны быть вынесены в отдельные таблицы. Это помогает избежать избыточности данных и экономит пространство.
Существуют и более высокие нормальные формы о которых стоит поговорить отдельно.
Основная цель нормализации заключается в следующем:
— Минимизация дублирования данных, что снижает риск ошибок и несоответствий.
— Упрощение процесса обновления информации. Централизованное хранение данных облегчает их модификацию.
— Повышение понятности структуры базы данных, что упрощает ее поддержку и развитие.
Исследования показывают, что корректно нормализованные базы данных могут обеспечить экономию до 30% дискового пространства. Это особенно актуально для крупномасштабных систем.
Важно отметить, что нормализация — это не одноразовое мероприятие, а непрерывный процесс. По мере роста и эволюции бизнеса структуру данных необходимо периодически пересматривать и оптимизировать.
Таким образом, при работе с базами данных всегда следует учитывать принципы нормальных форм. Это позволит создать более эффективную и удобную в использовании систему хранения и обработки информации. Чуть позже рассмотрим различные нормальные формы на примерах.
#dwh #databasedesign
Сегодня поговорим о нормальных формах и нормализации. Это важные понятия в мире баз данных, они помогают нам правильно организовывать информацию.
Представьте базу данных в виде большого шкафа для хранения информации. Без правильной организации найти нужные данные будет сложно, как и отыскать конкретную вещь в разбросанном хаосе. Нормализация — это процесс систематизации данных, схожий с наведением порядка в шкафу, но применительно к информации.
Нормальные формы — это набор правил, помогающих структурировать данные оптимальным образом. Существует несколько уровней нормальных форм, каждый из которых улучшает организацию базы данных.
Первая нормальная форма (1NF) устанавливает базовое правило: "Одна ячейка — один факт". Это означает, что нельзя хранить множественные значения в одном поле. Например, контактные номера клиента должны храниться в отдельных записях или столбцах, а не списком в одной ячейке.
Вторая нормальная форма (2NF) развивает эту идею дальше. Она требует, чтобы все неключевые атрибуты зависели от полного первичного ключа, а не от его части. Это похоже на разделение шкафа на секции по типам одежды.
Третья нормальная форма (3NF) вводит дополнительное требование: атрибуты, не зависящие напрямую от первичного ключа, должны быть вынесены в отдельные таблицы. Это помогает избежать избыточности данных и экономит пространство.
Существуют и более высокие нормальные формы о которых стоит поговорить отдельно.
Основная цель нормализации заключается в следующем:
— Минимизация дублирования данных, что снижает риск ошибок и несоответствий.
— Упрощение процесса обновления информации. Централизованное хранение данных облегчает их модификацию.
— Повышение понятности структуры базы данных, что упрощает ее поддержку и развитие.
Исследования показывают, что корректно нормализованные базы данных могут обеспечить экономию до 30% дискового пространства. Это особенно актуально для крупномасштабных систем.
Важно отметить, что нормализация — это не одноразовое мероприятие, а непрерывный процесс. По мере роста и эволюции бизнеса структуру данных необходимо периодически пересматривать и оптимизировать.
Таким образом, при работе с базами данных всегда следует учитывать принципы нормальных форм. Это позволит создать более эффективную и удобную в использовании систему хранения и обработки информации. Чуть позже рассмотрим различные нормальные формы на примерах.
#dwh #databasedesign
❤1
Как схема "звезда" упрощает работу с данными
Помните, мы обсуждали методологию Кимбалла? Так вот, ключевой элемент этого подхода — схема типа "звезда" (Star Schema). Давайте разберемся, что это такое и почему она так важна.
Схема "звезда" — это способ организации данных в хранилище. Она состоит из двух основных элементов: центральной таблицы фактов и окружающих ее таблиц измерений (но на самом деле есть ещё и справочники).
Таблица фактов (Fact Table) — это сердце схемы. В ней хранятся количественные показатели бизнеса. Например, показатели продаж или отдельные транзакции. Часто это очень большие таблицы, с миллионами строк и множеством различных столбцов.
Таблицы измерений (Dimension Tables) — "спутники" центральной таблицы. Они содержат атрибуты, которые описывают бизнес-объекты. Например, подробные данные о клиентах и товарах.
Таблица фактов связана с каждой таблицей измерений с помощью отношения первичный-внешний ключ.
Конечно же, фактов может быть множество, как и измерений.
Такая структура имеет несколько преимуществ:
+ Простота понимания. Даже неспециалист легко поймет, как устроены данные. Это упрощает работу аналитиков и менеджеров.
+ Скорость запросов. Благодаря простой структуре, запросы выполняются быстрее. Не нужно делать множество сложных соединений между таблицами.
+ Гибкость. Добавить новое измерение или факт довольно просто. Это позволяет быстро адаптироваться к изменениям в бизнесе.
Однако у этой схемы есть и недостатки:
- Избыточность данных. Денормализация приводит к дублированию информации.
- Проблемы с обновлением информации в таблицах измерений. При изменениях данных требуется обновлять множество записей.
Давайте рассмотрим простой пример.
Финансовая организация использует схему "звезда" для анализа транзакций: таблица фактов содержит данные о транзакциях, а таблицы измерений — информацию о клиентах и типах транзакций.
Таблица фактов:
Транзакции: ID транзакции, Дата, ID клиента, сумма, ID типа транзакции.
Таблицы измерений:
Клиенты: ID клиента, Имя, Дата рождения, Пол, Адрес.
Тип транзакции: ID типа транзакции, Наименование, Дата добавления.
Хочу заметить, что в современных системах хранения данных схемой "звезда" редко пользуются в чистом виде. Чаще всего она адаптируется и комбинируется с другими подходами, подстраиваясь под специфические потребности бизнеса. Например, Data Vault используется для построения оперативного хранилища данных, где данные интегрируются и историзируются. А схема "звезда" внедряется на этапе витрин данных (Data Marts) для оптимизации аналитических запросов.
#dwh
Помните, мы обсуждали методологию Кимбалла? Так вот, ключевой элемент этого подхода — схема типа "звезда" (Star Schema). Давайте разберемся, что это такое и почему она так важна.
Схема "звезда" — это способ организации данных в хранилище. Она состоит из двух основных элементов: центральной таблицы фактов и окружающих ее таблиц измерений (но на самом деле есть ещё и справочники).
Таблица фактов (Fact Table) — это сердце схемы. В ней хранятся количественные показатели бизнеса. Например, показатели продаж или отдельные транзакции. Часто это очень большие таблицы, с миллионами строк и множеством различных столбцов.
Таблицы измерений (Dimension Tables) — "спутники" центральной таблицы. Они содержат атрибуты, которые описывают бизнес-объекты. Например, подробные данные о клиентах и товарах.
Таблица фактов связана с каждой таблицей измерений с помощью отношения первичный-внешний ключ.
Конечно же, фактов может быть множество, как и измерений.
Такая структура имеет несколько преимуществ:
+ Простота понимания. Даже неспециалист легко поймет, как устроены данные. Это упрощает работу аналитиков и менеджеров.
+ Скорость запросов. Благодаря простой структуре, запросы выполняются быстрее. Не нужно делать множество сложных соединений между таблицами.
+ Гибкость. Добавить новое измерение или факт довольно просто. Это позволяет быстро адаптироваться к изменениям в бизнесе.
Однако у этой схемы есть и недостатки:
- Избыточность данных. Денормализация приводит к дублированию информации.
- Проблемы с обновлением информации в таблицах измерений. При изменениях данных требуется обновлять множество записей.
Давайте рассмотрим простой пример.
Финансовая организация использует схему "звезда" для анализа транзакций: таблица фактов содержит данные о транзакциях, а таблицы измерений — информацию о клиентах и типах транзакций.
Таблица фактов:
Транзакции: ID транзакции, Дата, ID клиента, сумма, ID типа транзакции.
Таблицы измерений:
Клиенты: ID клиента, Имя, Дата рождения, Пол, Адрес.
Тип транзакции: ID типа транзакции, Наименование, Дата добавления.
Хочу заметить, что в современных системах хранения данных схемой "звезда" редко пользуются в чистом виде. Чаще всего она адаптируется и комбинируется с другими подходами, подстраиваясь под специфические потребности бизнеса. Например, Data Vault используется для построения оперативного хранилища данных, где данные интегрируются и историзируются. А схема "звезда" внедряется на этапе витрин данных (Data Marts) для оптимизации аналитических запросов.
#dwh
❤1
Data Vault: революция в организации корпоративных хранилищ данных
Теперь, когда мы разобрались с основными терминами Data Vault, давайте рассмотрим, как эта методология работает. Она сочетает в себе уже знакомую вам "звезду" и 3-ю нормальную форму (о которой я подробно ещё здесь не написала😁 ).
Методологию разработал Дэн Линстедт в 2000 году, и это стало настоящим прорывом в организации корпоративных хранилищ. Его целью было создать метод, сочетающий гибкость Кимбалла и надежность Инмона. И у него получилось!
Сегодня существует две версии Data Vault: 1.0 и 2.0. Различия между ними мы обсудим в следующих статьях, а сейчас осветим общие моменты.
Data Vault помогает справиться с проблемами, которые часто возникают при работе с большими объемами информации из разных источников.
Когда новые данные попадают в хранилище (про ETL-ELT проговорим ещё раз позже), они распределяются по Hub, Link и Satellite таблицам. Хабах хранят только уникальные бизнес-ключи. В Линках — связи между хабами, а в Сателлитах содержатся атрибуты, описывающие хабы и линки.
Главная фишка Data Vault — его гибкость. Вы можете добавлять новые данные, не ломая то, что уже построено.
Также Data Vault отлично справляется с хранением истории изменений. Вы всегда можете "отмотать" данные назад и увидеть, как они выглядели в любой момент времени. Это особенно полезно для анализа трендов или аудита.
Для аналитиков Data Vault — настоящий подарок. Он позволяет быстро получать нужную информацию, комбинируя данные из разных источников. Например, можно легко связать данные с рекламы, посещения сайта, продажи и информацию о себестоимости для глубокого анализа.
Но у Data Vault есть и свои сложности. Его внедрение требует тщательного планирования и может занять много времени. Дело в том, что Data Vault использует концепцию "бизнес-ключей" вместо суррогатных ключей, что позволяет легко интегрировать данные из разных систем. Но при этом очень усложняет первоначальное проектирование. Поэтому очень важны специалисты, которые хорошо понимают эту методологию (иначе беды не избежать😈 ).
Методология особенно эффективна для больших компаний с множеством разнородных источников данных. Она помогает создать единую "версию правды" для всей организации.
Data Vault — сложный, но крутой инструмент для работы с информацией, который помогает бизнесу стать более гибким и основанным на данных.
#dwh
Теперь, когда мы разобрались с основными терминами Data Vault, давайте рассмотрим, как эта методология работает. Она сочетает в себе уже знакомую вам "звезду" и 3-ю нормальную форму (о которой я подробно ещё здесь не написала
Методологию разработал Дэн Линстедт в 2000 году, и это стало настоящим прорывом в организации корпоративных хранилищ. Его целью было создать метод, сочетающий гибкость Кимбалла и надежность Инмона. И у него получилось!
Сегодня существует две версии Data Vault: 1.0 и 2.0. Различия между ними мы обсудим в следующих статьях, а сейчас осветим общие моменты.
Data Vault помогает справиться с проблемами, которые часто возникают при работе с большими объемами информации из разных источников.
Когда новые данные попадают в хранилище (про ETL-ELT проговорим ещё раз позже), они распределяются по Hub, Link и Satellite таблицам. Хабах хранят только уникальные бизнес-ключи. В Линках — связи между хабами, а в Сателлитах содержатся атрибуты, описывающие хабы и линки.
Главная фишка Data Vault — его гибкость. Вы можете добавлять новые данные, не ломая то, что уже построено.
Также Data Vault отлично справляется с хранением истории изменений. Вы всегда можете "отмотать" данные назад и увидеть, как они выглядели в любой момент времени. Это особенно полезно для анализа трендов или аудита.
Для аналитиков Data Vault — настоящий подарок. Он позволяет быстро получать нужную информацию, комбинируя данные из разных источников. Например, можно легко связать данные с рекламы, посещения сайта, продажи и информацию о себестоимости для глубокого анализа.
Но у Data Vault есть и свои сложности. Его внедрение требует тщательного планирования и может занять много времени. Дело в том, что Data Vault использует концепцию "бизнес-ключей" вместо суррогатных ключей, что позволяет легко интегрировать данные из разных систем. Но при этом очень усложняет первоначальное проектирование. Поэтому очень важны специалисты, которые хорошо понимают эту методологию (иначе беды не избежать
Методология особенно эффективна для больших компаний с множеством разнородных источников данных. Она помогает создать единую "версию правды" для всей организации.
Data Vault — сложный, но крутой инструмент для работы с информацией, который помогает бизнесу стать более гибким и основанным на данных.
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
В мире больших данных
Ключевые понятия Data Vault
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики.…
Что ж, мы уже познакомились с Кимбаллом и Инмоном, теперь пора рассказать про Data Vault. Для начала разберем основные термины, которые нужно понимать.
Data Vault — это методология для работы с данными, объединяющая лучшие практики.…
❤1
1 и 2 НФ: первые шаги к упорядоченным данным
Совсем недавно я рассказывала про нормализацию, а сегодня хочу с примерами поговорить о первой (1НФ) и второй (2НФ) нормальных формах. Это базовые правила организации данных в таблицах, которые помогают избежать путаницы и дублирования информации.
Начнем с 1НФ.
Представьте, что у вас есть таблица с данными о студентах и их курсах. И в одной ячейке вы храните несколько курсов через запятую. Это нарушает 1НФ.
Пример таблицы, нарушающей 1НФ (таблицы могут некорректно отображаться на небольших телефонах🥲 смотрите в горизонтальной ориентации):
Чтобы привести таблицу к 1НФ, нужно:
— Убрать повторяющиеся группы значений из отдельных ячеек
— Создать отдельную запись для каждого значения в исходной или новой связанной таблице
— Определить уникальный первичный ключ для каждой таблицы
Пример таблиц, приведенных к 1НФ:
Теперь таблицы приведены к 1НФ, и данные структурированы таким образом, чтобы избежать дублей и обеспечить целостность данных.
2НФ строится на основе 1НФ.
Здесь главное избавиться от частичных зависимостей. Например, если у вас есть таблица "student_courses" с составным ключом из student_id и course_id, а поле "student_name" зависит только от student_id — это нарушение 2НФ.
Пример таблицы, нарушающей 2НФ:
Чтобы привести к 2НФ:
— Выделите зависимые атрибуты в отдельную таблицу
— Свяжите новую таблицу с исходной через первичный ключ
Пример таблиц, приведенных к 2НФ:
Теперь данные о студентах будут в отдельной таблице. Это уменьшит избыточность и упростит анализ информации.
Применение 1НФ и 2НФ помогает:
+ Улучшить целостность данных
+ Уменьшить избыточность
+ Упростить обновление информации
Помните, нормализация — это непрерывный процесс.
Также стоит отметить, что современные системы управления базами данных (СУБД) часто автоматизируют процесс нормализации. Например, PostgreSQL с версии 10 предлагает функции для автоматической нормализации таблиц. Но не все и не всегда ими пользуются, и не везде это работает корректно😁 так что понимать основы нужно обязательно.
В следующий раз уделим немного внимания 3НФ.
А вы применяете нормализацию в своих проектах? Какие сложности встречали?
#dwh
Совсем недавно я рассказывала про нормализацию, а сегодня хочу с примерами поговорить о первой (1НФ) и второй (2НФ) нормальных формах. Это базовые правила организации данных в таблицах, которые помогают избежать путаницы и дублирования информации.
Начнем с 1НФ.
Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.
Представьте, что у вас есть таблица с данными о студентах и их курсах. И в одной ячейке вы храните несколько курсов через запятую. Это нарушает 1НФ.
Пример таблицы, нарушающей 1НФ (таблицы могут некорректно отображаться на небольших телефонах
| student_id | student_name | courses |
|------------|--------------|---------------------|
| 1 | Иван | Математика, Физика |
| 2 | Марья | Химия, Биология |
Чтобы привести таблицу к 1НФ, нужно:
— Убрать повторяющиеся группы значений из отдельных ячеек
— Создать отдельную запись для каждого значения в исходной или новой связанной таблице
— Определить уникальный первичный ключ для каждой таблицы
Пример таблиц, приведенных к 1НФ:
| student_id | student_name |
|------------|--------------|
| 1 | Иван |
| 2 | Марья |
| student_id | course |
|------------|--------------|
| 1 | Математика |
| 1 | Физика |
| 2 | Химия |
| 2 | Биология |
Теперь таблицы приведены к 1НФ, и данные структурированы таким образом, чтобы избежать дублей и обеспечить целостность данных.
2НФ строится на основе 1НФ.
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа.
Здесь главное избавиться от частичных зависимостей. Например, если у вас есть таблица "student_courses" с составным ключом из student_id и course_id, а поле "student_name" зависит только от student_id — это нарушение 2НФ.
Пример таблицы, нарушающей 2НФ:
| student_id | course_id | student_name | grade |
|------------|-----------|--------------|-------|
| 1 | 101 | Иван | 5 |
| 1 | 102 | Иван | 4 |
| 2 | 101 | Мария | 3 |
Чтобы привести к 2НФ:
— Выделите зависимые атрибуты в отдельную таблицу
— Свяжите новую таблицу с исходной через первичный ключ
Пример таблиц, приведенных к 2НФ:
| student_id | student_name |
|------------|--------------|
| 1 | Иван |
| 2 | Мария |
| student_id | course_id | grade |
|------------|-----------|-------|
| 1 | 101 | 5 |
| 1 | 102 | 4 |
| 2 | 101 | 3 |
Теперь данные о студентах будут в отдельной таблице. Это уменьшит избыточность и упростит анализ информации.
Применение 1НФ и 2НФ помогает:
+ Улучшить целостность данных
+ Уменьшить избыточность
+ Упростить обновление информации
Помните, нормализация — это непрерывный процесс.
Также стоит отметить, что современные системы управления базами данных (СУБД) часто автоматизируют процесс нормализации. Например, PostgreSQL с версии 10 предлагает функции для автоматической нормализации таблиц. Но не все и не всегда ими пользуются, и не везде это работает корректно
В следующий раз уделим немного внимания 3НФ.
А вы применяете нормализацию в своих проектах? Какие сложности встречали?
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🤝1
Путешествие по миру современных баз данных
Хочу рассказать о современных базах данных. Мир баз данных постоянно развивается, и сейчас у нас есть целый арсенал инструментов для различных целей. Разберемся с некоторыми из них.
Реляционные базы данных (RDBMS) — это классический вид, основанный на табличной модели. Идеальны для структурированной информации с четкими связями. Н-р, для банковских систем или управления заказами в интернет-магазине.
Фишка: поддерживают сложные запросы и гарантируют целостность данных.
Согласно отчету DB-Engines Ranking на сегодня, Oracle, MySQL и MS SQL остаются самыми популярными СУБД в мире.
══════════
NoSQL — предлагает подходы, отличные от стандартного реляционного шаблона. Они появились, когда стало ясно, что не все данные удобно хранить в таблицах. Эти СУБД бывают документоориентированные (MongoDB), ключ-значение (Redis), графовые (Neo4j). Они часто используются в веб-приложениях, системах реального времени или для работы с большими данными.
Фишка: легко масштабируются и быстро обрабатывают большие объемы данных.
MongoDB — самая популярная NoSQL база среди разработчиков по данным Stack Overflow Developer Survey 2023.
══════════
Колоночные базы данных — в них данные также организованы в таблицы, но хранятся по столбцам, а не по строкам. Отлично подходят для аналитики с большими объемами данных.
Фишка: молниеносно обрабатывают аналитические запросы на терабайтах данных.
Примеры таких СУБД: ClickHouse, Google BigQuery, Apache Cassandra.
══════════
NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более современных, масштабируемых конструкций, обеспечивая высокую масштабируемость и согласованность данных.
Фишка: могут обрабатывать тысячи транзакций в секунду, сохраняя при этом ACID-свойства.
Популярные системы: CockroachDB, Google Spanner, VoltDB. Они хорошо подходят для приложений, которым нужна высокая доступность и горизонтальная масштабируемость.
══════════
Многомодельные базы данных поддерживают несколько моделей данных в рамках одной системы. Они упрощают разработку сложных приложений, где нужны разные типы данных и связей между ними.
Фишка: позволяют использовать одну базу данных вместо нескольких, упрощая архитектуру приложения.
Пример: ArangoDB (работает с документами, графами и данные в формате ключ-значение).
══════════
Базы данных на основе блокчейна используют технологию распределенного реестра. Они обеспечивают высокую безопасность и неизменяемость данных.
Фишка: гарантируют прозрачность и защиту от несанкционированных изменений.
Примеры таких баз: BigchainDB, Bluzelle. Они популярны в финтехе, управлении цепочками поставок и других областях, где важна прозрачность и безопасность.
══════════
Хранилища данных и базы данных для аналитики оптимизированы для обработки огромных объемов данных и сложных аналитических запросов.
Фишка: быстро анализируют петабайты данных и предоставляют результаты в удобном виде для бизнес-аналитики и машинного обучения.
Примеры: Snowflake, Amazon Redshift, Google BigQuery.
══════════
In-Memory базы данных хранят данные в оперативной памяти, что обеспечивает молниеносную сверхвысокую скорость работы. Часто используются как кэш или для обработки данных в реальном времени, особенно в приложениях, требующих минимальной задержки.
Фишка: обеспечивают время отклика в микро- или даже наносекундах, что критично для таких приложений, как финансовые системы, системы интернет-рекламы и игровые платформы.
Самые известные представители: Redis, Memcached, SAP HANA (для более сложных аналитических задач), Apache Ignite (для распределенных вычислений и кэширования).
══════════
Как вы можете заметить, некоторые из известных вам СУБД хочется отнести к нескольким видам. И это важно понимать: границы между типами баз данных часто размыты. Многие современные СУБД сочетают черты разных типов, адаптируясь под сложные требования своих клиентов.
Признаюсь честно, пока писала эту статью, узнала о нескольких новых для себя видах. А вы? С чем приходилось работать?😎
#databasedesign #dwh
Хочу рассказать о современных базах данных. Мир баз данных постоянно развивается, и сейчас у нас есть целый арсенал инструментов для различных целей. Разберемся с некоторыми из них.
Реляционные базы данных (RDBMS) — это классический вид, основанный на табличной модели. Идеальны для структурированной информации с четкими связями. Н-р, для банковских систем или управления заказами в интернет-магазине.
Фишка: поддерживают сложные запросы и гарантируют целостность данных.
Согласно отчету DB-Engines Ranking на сегодня, Oracle, MySQL и MS SQL остаются самыми популярными СУБД в мире.
══════════
NoSQL — предлагает подходы, отличные от стандартного реляционного шаблона. Они появились, когда стало ясно, что не все данные удобно хранить в таблицах. Эти СУБД бывают документоориентированные (MongoDB), ключ-значение (Redis), графовые (Neo4j). Они часто используются в веб-приложениях, системах реального времени или для работы с большими данными.
Фишка: легко масштабируются и быстро обрабатывают большие объемы данных.
MongoDB — самая популярная NoSQL база среди разработчиков по данным Stack Overflow Developer Survey 2023.
══════════
Колоночные базы данных — в них данные также организованы в таблицы, но хранятся по столбцам, а не по строкам. Отлично подходят для аналитики с большими объемами данных.
Фишка: молниеносно обрабатывают аналитические запросы на терабайтах данных.
Примеры таких СУБД: ClickHouse, Google BigQuery, Apache Cassandra.
══════════
NewSQL базы данных наследуют реляционную структуру и семантику, но построены с использованием более современных, масштабируемых конструкций, обеспечивая высокую масштабируемость и согласованность данных.
Фишка: могут обрабатывать тысячи транзакций в секунду, сохраняя при этом ACID-свойства.
Популярные системы: CockroachDB, Google Spanner, VoltDB. Они хорошо подходят для приложений, которым нужна высокая доступность и горизонтальная масштабируемость.
══════════
Многомодельные базы данных поддерживают несколько моделей данных в рамках одной системы. Они упрощают разработку сложных приложений, где нужны разные типы данных и связей между ними.
Фишка: позволяют использовать одну базу данных вместо нескольких, упрощая архитектуру приложения.
Пример: ArangoDB (работает с документами, графами и данные в формате ключ-значение).
══════════
Базы данных на основе блокчейна используют технологию распределенного реестра. Они обеспечивают высокую безопасность и неизменяемость данных.
Фишка: гарантируют прозрачность и защиту от несанкционированных изменений.
Примеры таких баз: BigchainDB, Bluzelle. Они популярны в финтехе, управлении цепочками поставок и других областях, где важна прозрачность и безопасность.
══════════
Хранилища данных и базы данных для аналитики оптимизированы для обработки огромных объемов данных и сложных аналитических запросов.
Фишка: быстро анализируют петабайты данных и предоставляют результаты в удобном виде для бизнес-аналитики и машинного обучения.
Примеры: Snowflake, Amazon Redshift, Google BigQuery.
══════════
In-Memory базы данных хранят данные в оперативной памяти, что обеспечивает молниеносную сверхвысокую скорость работы. Часто используются как кэш или для обработки данных в реальном времени, особенно в приложениях, требующих минимальной задержки.
Фишка: обеспечивают время отклика в микро- или даже наносекундах, что критично для таких приложений, как финансовые системы, системы интернет-рекламы и игровые платформы.
Самые известные представители: Redis, Memcached, SAP HANA (для более сложных аналитических задач), Apache Ignite (для распределенных вычислений и кэширования).
══════════
Как вы можете заметить, некоторые из известных вам СУБД хочется отнести к нескольким видам. И это важно понимать: границы между типами баз данных часто размыты. Многие современные СУБД сочетают черты разных типов, адаптируясь под сложные требования своих клиентов.
Признаюсь честно, пока писала эту статью, узнала о нескольких новых для себя видах. А вы? С чем приходилось работать?
#databasedesign #dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Batch vs Streaming: два пути к эффективной обработке данных
В мире больших данных batch и streaming — два ключевых метода загрузки и обработки, которые определяют, как информация движется и трансформируется внутри системы.
Сама суть понятий кроется в их названии: batch - пачка, streaming — поток. На этом можно было и остановиться, но всё же давайте разберемся, чем они отличаются и в каких случаях что лучше применять.
При batch загрузке мы собираем данные в большие пачки и обрабатываем их все вместе. Отлично подходит, если нам не нужны мгновенные результаты. Например, для составления ежемесячных отчетов по продажам или анализа поведения пользователей за прошедший квартал.
Плюсы batch загрузки:
+ Эффективно работает с большими объемами данных
+ Экономит ресурсы, так как обработка идет в определенное время (особенно актуально для облаков, где оплата за время использование ресурсов)
+ Подходит для сложных вычислений, которые требуют много времени
Минусы:
- Задержка между сбором данных и получением результатов
- Не подходит для задач, требующих мгновенной реакции
Streaming подход обрабатывает каждую единицу данных сразу, как только она появляется. Идеально подходит для задач, где важно получать данные мгновенно. Например, для мониторинга состояния оборудования в реальном времени.
Плюсы streaming обработки:
+ Мгновенное (ну почти) появление данных
+ Возможность быстро реагировать на события
Минусы:
- Требует больше ресурсов
- Сложнее реализовать для некоторых типов анализа
Возникает логичный вопрос что и когда использовать? Но универсального ответа нет. Выбор между пакетной и потоковой обработкой целиком зависит от ваших задач и ресурсов и в этом состоит работа системного аналитика — выбрать лучший подход для каждого конкретного случая.
Банки используют streaming загрузку в DWH для быстрого обновления данных. Информация о переводах и покупках клиентов попадает в хранилище почти мгновенно. Это дает аналитикам самую свежую картину активности клиентов. В тоже время менее критичные данные могут собираться из ERP и CRM систем раз в день.
Для batch обработки часто используют Apache Hadoop, Apache Spark или самописные репликаторы. Для streaming популярны Apache Kafka, Apache Flink и Google Cloud Dataflow. О некоторых из этих инструментов я расскажу позднее.
#dwh
В мире больших данных batch и streaming — два ключевых метода загрузки и обработки, которые определяют, как информация движется и трансформируется внутри системы.
Сама суть понятий кроется в их названии: batch - пачка, streaming — поток. На этом можно было и остановиться, но всё же давайте разберемся, чем они отличаются и в каких случаях что лучше применять.
При batch загрузке мы собираем данные в большие пачки и обрабатываем их все вместе. Отлично подходит, если нам не нужны мгновенные результаты. Например, для составления ежемесячных отчетов по продажам или анализа поведения пользователей за прошедший квартал.
Плюсы batch загрузки:
+ Эффективно работает с большими объемами данных
+ Экономит ресурсы, так как обработка идет в определенное время (особенно актуально для облаков, где оплата за время использование ресурсов)
+ Подходит для сложных вычислений, которые требуют много времени
Минусы:
- Задержка между сбором данных и получением результатов
- Не подходит для задач, требующих мгновенной реакции
Streaming подход обрабатывает каждую единицу данных сразу, как только она появляется. Идеально подходит для задач, где важно получать данные мгновенно. Например, для мониторинга состояния оборудования в реальном времени.
Плюсы streaming обработки:
+ Мгновенное (ну почти) появление данных
+ Возможность быстро реагировать на события
Минусы:
- Требует больше ресурсов
- Сложнее реализовать для некоторых типов анализа
Возникает логичный вопрос что и когда использовать? Но универсального ответа нет. Выбор между пакетной и потоковой обработкой целиком зависит от ваших задач и ресурсов и в этом состоит работа системного аналитика — выбрать лучший подход для каждого конкретного случая.
Банки используют streaming загрузку в DWH для быстрого обновления данных. Информация о переводах и покупках клиентов попадает в хранилище почти мгновенно. Это дает аналитикам самую свежую картину активности клиентов. В тоже время менее критичные данные могут собираться из ERP и CRM систем раз в день.
Для batch обработки часто используют Apache Hadoop, Apache Spark или самописные репликаторы. Для streaming популярны Apache Kafka, Apache Flink и Google Cloud Dataflow. О некоторых из этих инструментов я расскажу позднее.
#dwh
👍2❤1
Данные: структурированные и не очень
Структурированные данные имеют строгую, заранее определённую структуру и типы данных (например, числовые или текстовые), что позволяет их легко фильтровать и анализировать.
Основные характеристики:
– Фиксированная схема
– Табличный формат
– Четко определенные типы данных
– Легко анализируются
Пример структурированных данных (таблица "Клиенты"):
Структурированные данные особенно полезны, когда требуется быстрый доступ к информации и её анализ.
А вот с полуструктурированными данными не всё так просто. У них есть структура, но она более гибкая и не такая строгая. То есть параметры объектов могут меняться или отсутствовать.
Ключевые особенности:
– Гибкая схема
– Иерархическая структура
– Возможность хранения разнородных данных
– Поддержка вложенности
Пример полуструктурированных данных (JSON):
Кроме JSON, существуют и другие форматы полуструктурированных данных, такие как XML, YAML и другие. Полуструктурированные данные часто используются в современных веб-приложениях, системах управления контентом, а также в REST API для обмена информацией между различными системами.
Ну и не стоит забывать о неструктурированных данных. Это то, что не укладывается в таблицы в привычном виде — например, текстовые документы, изображения или видео. Они сложнее в обработке и анализе, но тоже могут быть полезными. Для работы с ними часто используются технологии машинного обучения, обработки естественного языка (NLP) и распознавания изображений.
В современных системах часто используется комбинация всех трех типов данных. Например, интернет-магазин может хранить информацию о клиентах в таблицах, данные о заказах — в JSON, а отзывы — как тексты или изображения. Такой подход позволяет системе быть гибкой и эффективной. Ну а нам с вами, при построении хранилищ данных, нужно уметь всё это грамотно реплицировать и приводить в порядок для последующего анализа.
#dwh
Структурированные данные имеют строгую, заранее определённую структуру и типы данных (например, числовые или текстовые), что позволяет их легко фильтровать и анализировать.
Основные характеристики:
– Фиксированная схема
– Табличный формат
– Четко определенные типы данных
– Легко анализируются
Пример структурированных данных (таблица "Клиенты"):
| customer_id | first_name | last_name | registration_date |
|-------------|------------|------------|-------------------|
| 001 | Иван | Иванов | 2023-01-15 |
| 002 | Мария | Смирнова | 2023-09-20 |
| 003 | Алексей | Петров | 2023-03-10 |
Структурированные данные особенно полезны, когда требуется быстрый доступ к информации и её анализ.
А вот с полуструктурированными данными не всё так просто. У них есть структура, но она более гибкая и не такая строгая. То есть параметры объектов могут меняться или отсутствовать.
Ключевые особенности:
– Гибкая схема
– Иерархическая структура
– Возможность хранения разнородных данных
– Поддержка вложенности
Пример полуструктурированных данных (JSON):
{
"order": {
"id": 1001,
"customer": {
"inn": "7707083893",
"name": "ООО Ромашка",
"contactPerson": "Иванов Иван Иванович"
},
"items": [
{"name": "Смартфон Yota Phone", "quantity": 1, "price": 49999.99},
{"name": "Защитное стекло", "quantity": 2, "price": 999.99}
],
"delivery": {
"address": "г. Москва, ул. Тверская, д. 1",
"method": "СДЭК",
"cost": 500.00
},
"total": 52499.97,
"status": "Отправлен"
}
}
Кроме JSON, существуют и другие форматы полуструктурированных данных, такие как XML, YAML и другие. Полуструктурированные данные часто используются в современных веб-приложениях, системах управления контентом, а также в REST API для обмена информацией между различными системами.
Ну и не стоит забывать о неструктурированных данных. Это то, что не укладывается в таблицы в привычном виде — например, текстовые документы, изображения или видео. Они сложнее в обработке и анализе, но тоже могут быть полезными. Для работы с ними часто используются технологии машинного обучения, обработки естественного языка (NLP) и распознавания изображений.
В современных системах часто используется комбинация всех трех типов данных. Например, интернет-магазин может хранить информацию о клиентах в таблицах, данные о заказах — в JSON, а отзывы — как тексты или изображения. Такой подход позволяет системе быть гибкой и эффективной. Ну а нам с вами, при построении хранилищ данных, нужно уметь всё это грамотно реплицировать и приводить в порядок для последующего анализа.
#dwh
❤1🤯1
3НФ: спасаемся от хаоса в данных
В прошлый раз мы поговорили про 1 и 2НФ, пора двигаться дальше.
Третья нормальная форма (3НФ) — один из ключевых этапов нормализации данных, который помогает избежать избыточности и аномалий при обновлении информации.
Как следует из определения, чтобы отношение находилось в 3НФ, оно должно удовлетворять двум условиям:
1. Находиться в 2НФ (то есть быть приведенным к состоянию, где все неключевые атрибуты зависят от всего первичного ключа).
2. Каждый неключевой атрибут должен зависеть только от первичного ключа и ни от чего другого.
Непонятно? Рассмотрим на примере.
Представьте, что у нас есть таблица с информацией о заказах:
Эта таблица нарушает 3НФ, потому что есть зависимость product_id -> product_name -> category. То есть название товара и его категория зависят от id продукта, а не напрямую от id заказа.
Чтобы привести таблицу к 3НФ, нужно разбить ее на несколько связанных таблиц:
В итоге структура будет выглядеть так:
Таблица orders:
Таблица products:
Внимательный читатель заметит, что таблица products всё еще не находится в 3НФ😁 . Как думаете, почему и как можно улучшить эту таблицу?
А мы пойдём дальше.
Определить нарушение 3НФ очень просто. Задайте себе несколько вопросов:
– Есть ли в таблице поля, значения которых повторяются (или могут повторяться) для разных строк?
– Можно ли определить значение одного поля через другое неключевое поле?
– При изменении одной записи, нужно ли обновлять другие записи с такими же данными?
Если хотя бы на один вопрос вы ответили "да", скорее всего, ваша таблица не соответствует 3НФ.
Применение 3НФ даёт несколько преимуществ:
– уменьшение избыточности данных: информация хранится только в одном месте, что упрощает обновление и поддержку.
– улучшение целостности данных: меньше шансов, что при обновлении информации возникнут несоответствия.
– гибкость при изменении структуры данных: если нужно добавить новые атрибуты, это не повлияет на таблицу заказов.
Однако стоит помнить, что чрезмерная нормализация может усложнить запросы и снизить производительность, особенно на больших наборах данных. Поэтому в реальных проектах часто используют денормализацию, например, при создании отдельных, часто используемых бизнесом витрин.
#dwh
В прошлый раз мы поговорили про 1 и 2НФ, пора двигаться дальше.
Третья нормальная форма (3НФ) — один из ключевых этапов нормализации данных, который помогает избежать избыточности и аномалий при обновлении информации.
Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа.
Как следует из определения, чтобы отношение находилось в 3НФ, оно должно удовлетворять двум условиям:
1. Находиться в 2НФ (то есть быть приведенным к состоянию, где все неключевые атрибуты зависят от всего первичного ключа).
2. Каждый неключевой атрибут должен зависеть только от первичного ключа и ни от чего другого.
Непонятно? Рассмотрим на примере.
Представьте, что у нас есть таблица с информацией о заказах:
| order_id | product_id | product_name | category | qty |
|----------|------------|--------------|----------|-----|
| 1 | 101 | Ноутбук | Техника | 2 |
| 2 | 102 | Смартфон | Техника | 1 |
| 3 | 103 | Футболка | Одежда | 3 |
Эта таблица нарушает 3НФ, потому что есть зависимость product_id -> product_name -> category. То есть название товара и его категория зависят от id продукта, а не напрямую от id заказа.
Чтобы привести таблицу к 3НФ, нужно разбить ее на несколько связанных таблиц:
В итоге структура будет выглядеть так:
Таблица orders:
| order_id | product_id | qty |
|----------|------------|-----|
| 1 | 101 | 2 |
| 2 | 102 | 1 |
| 3 | 103 | 3 |
Таблица products:
| product_id | product_name | category |
|------------|--------------|----------|
| 101 | Ноутбук | Техника |
| 102 | Смартфон | Техника |
| 103 | Футболка | Одежда |
Внимательный читатель заметит, что таблица products всё еще не находится в 3НФ
А мы пойдём дальше.
Определить нарушение 3НФ очень просто. Задайте себе несколько вопросов:
– Есть ли в таблице поля, значения которых повторяются (или могут повторяться) для разных строк?
– Можно ли определить значение одного поля через другое неключевое поле?
– При изменении одной записи, нужно ли обновлять другие записи с такими же данными?
Если хотя бы на один вопрос вы ответили "да", скорее всего, ваша таблица не соответствует 3НФ.
Применение 3НФ даёт несколько преимуществ:
– уменьшение избыточности данных: информация хранится только в одном месте, что упрощает обновление и поддержку.
– улучшение целостности данных: меньше шансов, что при обновлении информации возникнут несоответствия.
– гибкость при изменении структуры данных: если нужно добавить новые атрибуты, это не повлияет на таблицу заказов.
Однако стоит помнить, что чрезмерная нормализация может усложнить запросы и снизить производительность, особенно на больших наборах данных. Поэтому в реальных проектах часто используют денормализацию, например, при создании отдельных, часто используемых бизнесом витрин.
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Связи между данными: один-к-одному, один-ко-многим, многие-ко-многим
Захватим ещё немного основ (хотя, кажется, пора заканчивать с очевидным😁 ).
Когда мы работаем с базами данных, то постоянно сталкиваемся с разными типами связей между таблицами. Это база для эффективной организации данных и их анализа, обеспечивающая целостность информации.
Есть три основных типа связей: один к одному, один ко многим и многие ко многим. Давайте разберемся с каждым из них.
Cамый простой тип связи — один к одному (1:1), то есть каждая запись в одной таблице соответствует только одной записи в другой таблице.
Например, есть таблица Сотрудники и таблица Паспортные данные. Каждый сотрудник имеет только один паспорт и каждый паспорт принадлежит только одному сотруднику.
Связь один-ко-многим (1:N) используется, когда одна запись в первой таблице может быть связана с несколькими записями во второй таблице. Например, в одном отделе может работать много сотрудников, но каждый сотрудник может работать только в одном отделе.
Связь многие-ко-многим (M:N) — самый сложный тип связи. Он используется, когда несколько записей из одной таблицы могут быть связаны с несколькими записями из другой таблицы. Обычно для реализации связи M:N используется промежуточная таблица.То есть такая связь разбивается на две связи "один ко многим" через промежуточную таблицу.
Классический пример — студенты и курсы. Один студент может посещать несколько курсов, и на одном курсе учится много студентов.
Таблица students:
Таблица courses:
Таблица students_courses:
Промежуточная таблица students_courses как раз и содержит комбинации ключей из обеих связанных таблиц.
Cтоит отметить, что в хранилищах данных мы иногда отходим от строгой реляционной модели и иногда можем хранить данные в более свободном формате😎 . Но понимание этих базовых типов связей помогает нам правильно организовать данные для эффективного анализа.
#dwh
Захватим ещё немного основ (хотя, кажется, пора заканчивать с очевидным
Когда мы работаем с базами данных, то постоянно сталкиваемся с разными типами связей между таблицами. Это база для эффективной организации данных и их анализа, обеспечивающая целостность информации.
Есть три основных типа связей: один к одному, один ко многим и многие ко многим. Давайте разберемся с каждым из них.
Cамый простой тип связи — один к одному (1:1), то есть каждая запись в одной таблице соответствует только одной записи в другой таблице.
Например, есть таблица Сотрудники и таблица Паспортные данные. Каждый сотрудник имеет только один паспорт и каждый паспорт принадлежит только одному сотруднику.
Связь один-ко-многим (1:N) используется, когда одна запись в первой таблице может быть связана с несколькими записями во второй таблице. Например, в одном отделе может работать много сотрудников, но каждый сотрудник может работать только в одном отделе.
Связь многие-ко-многим (M:N) — самый сложный тип связи. Он используется, когда несколько записей из одной таблицы могут быть связаны с несколькими записями из другой таблицы. Обычно для реализации связи M:N используется промежуточная таблица.То есть такая связь разбивается на две связи "один ко многим" через промежуточную таблицу.
Классический пример — студенты и курсы. Один студент может посещать несколько курсов, и на одном курсе учится много студентов.
Таблица students:
student_id | name
------------------
1 | Анна
2 | Борис
Таблица courses:
course_id | name
----------------------
101 | Математика
102 | Физика
Таблица students_courses:
student_id | course_id
-----------------------
1 | 101
1 | 102
2 | 101
Промежуточная таблица students_courses как раз и содержит комбинации ключей из обеих связанных таблиц.
Cтоит отметить, что в хранилищах данных мы иногда отходим от строгой реляционной модели и иногда можем хранить данные в более свободном формате
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1🎄1
TABLE_DML_HISTORY: окно в мир изменений ваших данных
Вьюха TABLE_DML_HISTORY в Snowflake — инструмент, который помогает отслеживать и анализировать DML-операции (Data Manipulation Language) в таблицах. По сути он выводит агрегированную информацию о влиянии DML-операций на ваши данные.
Вот что там можно узнать:
🔵 какие таблицы изменялись
🔵 временные интервалы, в которые происходили изменения
🔵 количество добавленных, удаленных и обновленных строк
Предположим, вы хотите узнать, какие изменения были внесены в таблицу SALES за последние 24 часа. Для этого можно выполнить следующий запрос:
Если нужно проанализировать изменения во всех таблицах определенной схемы за месяц, можно использовать такой запрос:
Но не бывает крутых функций без нюансов и ограничений. TABLE_DML_HISTORY:
🔵 содержит информацию по всем DML-операциям, выполненным за последние 365 дней;
🔵 задержка обновления данных может составлять до 6 часов;
🔵 не включает DML-операции на гибридных таблицах
🔵 доступ к этому представлению зависит от привилегий пользователя, обычно требуется роль ACCOUNTADMIN или соответствующие права на чтение из схемы ACCOUNT_USAGE.
Советы по использованию:
🔵 мониторинг активности: регулярное отслеживание DML-операций помогает выявлять аномальные изменения и потенциальные проблемы с данными.
🔵 аудит изменений: можно проводить аудит изменений в важных таблицах для обеспечения соответствия внутренним политикам и внешним требованиям.
🔵 оптимизация производительности: анализ частоты и объема DML-операций может помочь в оптимизации запросов и пайплайнов.
TABLE_DML_HISTORY — хороший инструмент для мониторинга и аудита данных в Snowflake. Используйте его, чтобы лучше понимать, что происходит с вашими данными и вовремя вносить изменения в неоптимальные процессы.
Более подробную информацию вы всегда можете найти в официальной документации Snowflake.
#dwh #snowflake
Вьюха TABLE_DML_HISTORY в Snowflake — инструмент, который помогает отслеживать и анализировать DML-операции (Data Manipulation Language) в таблицах. По сути он выводит агрегированную информацию о влиянии DML-операций на ваши данные.
Вот что там можно узнать:
Предположим, вы хотите узнать, какие изменения были внесены в таблицу SALES за последние 24 часа. Для этого можно выполнить следующий запрос:
SELECT
START_TIME,
END_TIME,
ROWS_ADDED,
ROWS_UPDATED,
ROWS_REMOVED
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_DML_HISTORY
WHERE TABLE_NAME = 'SALES'
AND START_TIME >= DATEADD('day', -1, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC;
Если нужно проанализировать изменения во всех таблицах определенной схемы за месяц, можно использовать такой запрос:
SELECT
TABLE_NAME,
SUM(ROWS_ADDED) AS TOTAL_ROWS_ADDED,
SUM(ROWS_UPDATED) AS TOTAL_ROWS_UPDATED,
SUM(ROWS_REMOVED) AS TOTAL_ROWS_REMOVED
FROM SNOWFLAKE.ACCOUNT_USAGE.TABLE_DML_HISTORY
WHERE SCHEMA_NAME = 'SANDBOX'
AND START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY TABLE_NAME;
Но не бывает крутых функций без нюансов и ограничений. TABLE_DML_HISTORY:
Советы по использованию:
TABLE_DML_HISTORY — хороший инструмент для мониторинга и аудита данных в Snowflake. Используйте его, чтобы лучше понимать, что происходит с вашими данными и вовремя вносить изменения в неоптимальные процессы.
Более подробную информацию вы всегда можете найти в официальной документации Snowflake.
#dwh #snowflake
Please open Telegram to view this post
VIEW IN TELEGRAM
Денормализация данных: когда и зачем нарушать правила
Денормализация — это намеренное введение избыточности данных в таблице. Звучит как ересь, не так ли? Мы же так долго их номрализовывали! Однако, в мире больших данных и высоких нагрузок этот подход имеет место быть.
Часто нормализацию сознательно нарушают для повышения производительности системы, так как большое количество JOIN приводит к медленному выполнению запросов. Таким образом денормализация становится необходимой для ускорения доступа к данным и оптимизации запросов. Она ускоряет чтение данных, что особенно важно для построения дашбордов.
Когда применять денормализацию?
🔵 Есть часто выполняемые сложные запросы с множеством соединений — денормализация может значительно ускорить их выполнение за счёт хранения предварительно агрегированных данных в одной таблице.
🔵 Для систем бизнес-аналитики (BI) и хранилищ данных денормализация — обычная практика. Она позволяет быстрее выполнять сложные расчеты и агрегации.
🔵 В распределенных базах данных JOIN-ы между таблицами, хранящимися на разных узлах, могут быть очень дорогостоящими. Денормализация помогает избежать этих сложных операций.
Давайте рассмотрим пример. Представим, у нас есть интернет-магазин с миллионами заказов. В нормализованной схеме информация о заказе, клиенте и товарах хранится в разных таблицах:
Для получения полной информации о заказе нам приходится объединять все эти таблицы:
При высокой нагрузке это может стать узким местом. В денормализованной версии мы можем хранить все нужные нам столбцы и расчёты (н-р, order_id, customer_name, customer_email, product_name, quantity, price, total_price, order_date). Когда вся информация доступна в одной таблице, это значительно ускоряет запросы на чтение:
Важно понимать и помнить, что у этого подхода есть и свои минусы:
🔵 Избыточность данных: мы храним одну и ту же информацию в нескольких местах, что увеличивает объем хранилища.
🔵 Сложность обновления: при изменении данных (например, имени клиента) нужно обновлять информацию во всех связанных записях.
🔵 Риск несогласованности: если обновление происходит не атомарно, может возникнуть ситуация, когда данные в разных местах не соответствуют друг другу.
Чтобы минимизировать эти риски, можно использовать различные техники. Например, материализованные представления позволяют создавать денормализованные таблицы, которые автоматически обновляются при изменении исходных данных.
В конечном счете, выбор между нормализацией и денормализацией зависит от конкретных требований вашей бизнес-задачи. Главное — понимать последствия своего выбора и быть готовым вносить изменения по мере роста и изменения системы.
А вы сталкивались с необходимостью денормализации в своих проектах? Какие подходы использовали для поддержания согласованности данных?
#dwh
Денормализация — это намеренное введение избыточности данных в таблице. Звучит как ересь, не так ли? Мы же так долго их номрализовывали! Однако, в мире больших данных и высоких нагрузок этот подход имеет место быть.
Часто нормализацию сознательно нарушают для повышения производительности системы, так как большое количество JOIN приводит к медленному выполнению запросов. Таким образом денормализация становится необходимой для ускорения доступа к данным и оптимизации запросов. Она ускоряет чтение данных, что особенно важно для построения дашбордов.
Когда применять денормализацию?
Давайте рассмотрим пример. Представим, у нас есть интернет-магазин с миллионами заказов. В нормализованной схеме информация о заказе, клиенте и товарах хранится в разных таблицах:
orders:
| order_id | customer_id | order_date |
|----------|-------------|------------|
| 1 | 101 | 2024-09-01 |
customers:
| customer_id | name | email |
|-------------|-------|----------------|
| 101 | Алиса | [email protected] |
order_items:
| order_id | product_id | quantity |
|----------|------------|----------|
| 1 | 201 | 2 |
products:
| product_id | name | price |
|------------|----------|-------|
| 201 | Ноутбук | 50000 |
Для получения полной информации о заказе нам приходится объединять все эти таблицы:
SELECT
o.order_id,
c.name AS customer_name,
c.email AS customer_email,
p.name AS product_name,
oi.quantity,
p.price,
oi.quantity * p.price AS total_price,
o.order_date
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE c.name = 'Алиса';
При высокой нагрузке это может стать узким местом. В денормализованной версии мы можем хранить все нужные нам столбцы и расчёты (н-р, order_id, customer_name, customer_email, product_name, quantity, price, total_price, order_date). Когда вся информация доступна в одной таблице, это значительно ускоряет запросы на чтение:
SELECT
order_id,
customer_name,
customer_email,
product_name,
quantity,
price,
total_price,
order_date
FROM orders o
WHERE customer_name = 'Алиса';
Важно понимать и помнить, что у этого подхода есть и свои минусы:
Чтобы минимизировать эти риски, можно использовать различные техники. Например, материализованные представления позволяют создавать денормализованные таблицы, которые автоматически обновляются при изменении исходных данных.
В конечном счете, выбор между нормализацией и денормализацией зависит от конкретных требований вашей бизнес-задачи. Главное — понимать последствия своего выбора и быть готовым вносить изменения по мере роста и изменения системы.
А вы сталкивались с необходимостью денормализации в своих проектах? Какие подходы использовали для поддержания согласованности данных?
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
Загрузка данных в хранилище: полная, инкрементальная и частичная перезагрузка
Что самое главное в DWH? Конечно же, данные, которые как-то должны попасть в хранилище. Чаще мы используем современные методы загрузки, но на ранних этапах или из-за тех. ограничений, или при исследованиях, мы всё также прибегаем к классическим методам.
Есть три основных подхода: полная загрузка, инкрементальная и частичная перезагрузка. Системным аналитикам важно понимать когда какой подход лучше использовать.
При полной загрузке мы каждый раз заново забираем все данные из источника, полностью заменяя существующие данные в хранилище. Почему "полностью" курсивом? Иногда нам нужно отслеживать удалённые строки, тогда мы не просто транкейтим, а размечаем отсутствующие строки флагом DELETED.
Полная загрузка — самый простой метод со своими особенностями:
➕ простота реализации
➕ 100% актуальность данных
➖ высокая нагрузка при больших объемах данных
➖ время выполнения
➖ неэффективное использование ресурсов при небольших изменениях.
Этот метод идеален для небольших таблиц или когда нужна полная уверенность в актуальности данных. Также он хорошо подходит для справочников и других статичных данных, которые обновляются очень редко (обратите внимание, что редко определяется требованиями конкретного бизнеса).
При инкрементальном методе мы добавляем только новые или измененные данные с момента последней загрузки. Это существенно экономит время и ресурсы. Особенности:
➕ быстрее
➕ меньше нагрузка на источник и хранилище
➕ эффективное использование ресурсов
➖ сложность реализации и отслеживания изменений
➖ риск пропустить изменения
➖ нужно хранить метаданные о загрузках.
Для больших таблиц с частыми апдейтами — то, что надо. Важно❗️ если нужно отслеживать изменения, у таблиц должно быть поле, содержащее дату и время обновления строки. Убедитесь, что вы можете доверять ему. Комментарии к полям могут врать! В моей практике были случаи, когда дата содержала инфу об изменении только нескольких полей из таблицы, что не было нигде явно указано 🥲 (да, иногда нужно покапаться в коде источника)
Также важно помнить, что если в таблице удалили какую-то строку, то вы никогда об этом не узнаете, ведь вы забираете изменения только по существующим строкам.
Если мы говорим только про забор новых изменений, нам нужно инкрементное поле или поле с датой добавления строки (желательно заполняемое getdate), по которому мы будем забирать только новые строки. Метод отлично подходит для логов.
Частичная перезагрузка — гибрид предыдущих способов. Здесь мы перезагружаем только часть данных, обычно за какой-то конкретный период.
➕ баланс актуальности и эффективности
➕ обновление за определенный период без полной перезагрузки
➕ удобно для данных с "окном актуальности"
➖ сложно определить оптимальный период
➖ риск дублей при неправильной реализации
➖ нужна дополнительная логика для определения границ загрузки
Частичную перезагрузку часто применяют для данных с "окном актуальности", например, когда нужно обновить данные за последний месяц или квартал. Когда точно известно, что "более старые" данные неизменны. Здесь та же история, про которую я писала выше, у вас должно быть поле с датой, которому вы точно можете доверять.
Подытожу, выбор метода загрузки зависит от многих факторов: объема данных, частоты обновлений, требований к актуальности и доступных ресурсов. Но даже если на первый взгляд кажется, что выбрать нужный метод просто, в реальной жизни часто приходится идти на компромиссы или комбинировать подходы. Например, объект с миллионами строк без даты обновления можно днем грузить инкрементально, а раз в неделю обновлять целиком. Так себе история и, конечно, лучше использовать иные методы загрузки, но ситуации бывают разными. Будьте к ним готовы.
Благодаря тому, что источники не идеальны, работа системного аналитика всегда где-то на грани творчества и здравого смысла😇
#dwh
Что самое главное в DWH? Конечно же, данные, которые как-то должны попасть в хранилище. Чаще мы используем современные методы загрузки, но на ранних этапах или из-за тех. ограничений, или при исследованиях, мы всё также прибегаем к классическим методам.
Есть три основных подхода: полная загрузка, инкрементальная и частичная перезагрузка. Системным аналитикам важно понимать когда какой подход лучше использовать.
При полной загрузке мы каждый раз заново забираем все данные из источника, полностью заменяя существующие данные в хранилище. Почему "полностью" курсивом? Иногда нам нужно отслеживать удалённые строки, тогда мы не просто транкейтим, а размечаем отсутствующие строки флагом DELETED.
Полная загрузка — самый простой метод со своими особенностями:
Этот метод идеален для небольших таблиц или когда нужна полная уверенность в актуальности данных. Также он хорошо подходит для справочников и других статичных данных, которые обновляются очень редко (обратите внимание, что редко определяется требованиями конкретного бизнеса).
При инкрементальном методе мы добавляем только новые или измененные данные с момента последней загрузки. Это существенно экономит время и ресурсы. Особенности:
Для больших таблиц с частыми апдейтами — то, что надо. Важно
Также важно помнить, что если в таблице удалили какую-то строку, то вы никогда об этом не узнаете, ведь вы забираете изменения только по существующим строкам.
Если мы говорим только про забор новых изменений, нам нужно инкрементное поле или поле с датой добавления строки (желательно заполняемое getdate), по которому мы будем забирать только новые строки. Метод отлично подходит для логов.
Частичная перезагрузка — гибрид предыдущих способов. Здесь мы перезагружаем только часть данных, обычно за какой-то конкретный период.
Частичную перезагрузку часто применяют для данных с "окном актуальности", например, когда нужно обновить данные за последний месяц или квартал. Когда точно известно, что "более старые" данные неизменны. Здесь та же история, про которую я писала выше, у вас должно быть поле с датой, которому вы точно можете доверять.
Подытожу, выбор метода загрузки зависит от многих факторов: объема данных, частоты обновлений, требований к актуальности и доступных ресурсов. Но даже если на первый взгляд кажется, что выбрать нужный метод просто, в реальной жизни часто приходится идти на компромиссы или комбинировать подходы. Например, объект с миллионами строк без даты обновления можно днем грузить инкрементально, а раз в неделю обновлять целиком. Так себе история и, конечно, лучше использовать иные методы загрузки, но ситуации бывают разными. Будьте к ним готовы.
Благодаря тому, что источники не идеальны, работа системного аналитика всегда где-то на грани творчества и здравого смысла
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍3
Организация мониторинга и алертинга в DWH-системах
Мониторинг и алертинг — это не просто какие-то модные слова из мира IT. Это основа, на которой держится работа с данными. Давайте разберемся, как это устроено в современных хранилищах.
В DWH хранятся важные данные компании: отчеты, аналитика, истории взаимодействий с клиентами. Некорректная загрузка и обработка этих данных может обернуться большими проблемами. Мониторинг помогает вовремя выявлять аномалии в данных и процессах, а оповещения — вовремя на них реагировать.
Основные задачи мониторинга
Первая — контроль выполнения ETL/ELT процессов. Например, если скрипты, которые должны обновлять данные ежедневно, вдруг падают или выполняются слишком долго, мониторинг должен это заметить и сообщить об ошибке дежурных инженеров, чтобы они могли оперативно вмешаться.
Простой пример: у вас есть ежедневный процесс обновления данных об отгрузках со склада, и обычно он выполняется за 15 минут. Если мониторинг фиксирует, что процесс вдруг начал занимать час, он оповещает, что что-то пошло не так. Возможно, сломалась загрузка из источника или увеличился объем данных (тоже не плохо обратить на это внимание).
Еще одна задача — контроль качества данных. Иногда сами данные могут приходить с ошибками. Представьте, что ваш ETL процесс получил пустые строки об отгрузках вместо обычного объема данных. Хорошо настроенный мониторинг заметит это и оповестит команду.
Что конкретно стоит мониторить?
1. Процессы загрузки данных: время выполнения, наличие ошибок, объемы данных.
2. Качество данных: проверки на пустые значения, аномалии, отклонения от ожидаемых значений.
3. Работа сервера: утилизация CPU, память, доступное место на диске. Особенно важно в облачных решениях, где рост нагрузки приводит к дополнительным затратам.
Оповещения должны быть точными и своевременными. Если система засыпает вас уведомлениями по каждому пустяку, вы быстро перестанете на них реагировать. В итоге важные сообщения могут пройти мимо.
Ещё один пример: если ETL процесс падает три раза подряд — это явно повод для тревоги. Алертинг должен отправить сообщение дежурным инженерам по оперативным каналам (но не засыпать этот канал оповещениями нон-стоп). Для этого удобно использовать мессенджеры вроде Slack, хуже — email уведомления.
Инструменты для мониторинга и алертинга
🟠 Prometheus + Grafana: отличный вариант для отслеживания метрик и визуализации данных. Prometheus собирает метрики, а Grafana показывает их в удобных дашбордах.
🟠 dbt Cloud: инструмент для разработки и тестирования ELT процессов, который также имеет встроенные возможности для мониторинга.
🟠 Snowflake Native Alerts: позволяет создавать алерты на основе запросов. Например, если количество записей в таблице падает ниже ожидаемого уровня, система автоматически уведомит об этом.
🟠 самописные решения 🐱
С чего начать?
Например, с базовых метрик для ETL процессов, а затем добавить проверки на качество данных. Используйте оповещения с пороговыми значениями. Например, алерт сработает, если время выполнения процесса превышает обычное более чем на 10%.
Не забывайте оптимизировать количество уведомлений. Никто не хочет получать 100 уведомлений в минуту. Поэтому важно тщательно подбирать критерии для алертов, чтобы они всегда были уместны и вызвали информационную слепоту.
Используйте (или проектируйте) подходящие инструменты для мониторинга и системы оповещений, и не перегружайте свою команду лишними уведомлениями. Это сделает ваше хранилище надежным и эффективным. В конце концов, зачем нужным данные, если мы не можем положиться на их качество?
#dwh
Мониторинг и алертинг — это не просто какие-то модные слова из мира IT. Это основа, на которой держится работа с данными. Давайте разберемся, как это устроено в современных хранилищах.
В DWH хранятся важные данные компании: отчеты, аналитика, истории взаимодействий с клиентами. Некорректная загрузка и обработка этих данных может обернуться большими проблемами. Мониторинг помогает вовремя выявлять аномалии в данных и процессах, а оповещения — вовремя на них реагировать.
Основные задачи мониторинга
Первая — контроль выполнения ETL/ELT процессов. Например, если скрипты, которые должны обновлять данные ежедневно, вдруг падают или выполняются слишком долго, мониторинг должен это заметить и сообщить об ошибке дежурных инженеров, чтобы они могли оперативно вмешаться.
Простой пример: у вас есть ежедневный процесс обновления данных об отгрузках со склада, и обычно он выполняется за 15 минут. Если мониторинг фиксирует, что процесс вдруг начал занимать час, он оповещает, что что-то пошло не так. Возможно, сломалась загрузка из источника или увеличился объем данных (тоже не плохо обратить на это внимание).
Еще одна задача — контроль качества данных. Иногда сами данные могут приходить с ошибками. Представьте, что ваш ETL процесс получил пустые строки об отгрузках вместо обычного объема данных. Хорошо настроенный мониторинг заметит это и оповестит команду.
Что конкретно стоит мониторить?
1. Процессы загрузки данных: время выполнения, наличие ошибок, объемы данных.
2. Качество данных: проверки на пустые значения, аномалии, отклонения от ожидаемых значений.
3. Работа сервера: утилизация CPU, память, доступное место на диске. Особенно важно в облачных решениях, где рост нагрузки приводит к дополнительным затратам.
Оповещения должны быть точными и своевременными. Если система засыпает вас уведомлениями по каждому пустяку, вы быстро перестанете на них реагировать. В итоге важные сообщения могут пройти мимо.
Ещё один пример: если ETL процесс падает три раза подряд — это явно повод для тревоги. Алертинг должен отправить сообщение дежурным инженерам по оперативным каналам (но не засыпать этот канал оповещениями нон-стоп). Для этого удобно использовать мессенджеры вроде Slack, хуже — email уведомления.
Инструменты для мониторинга и алертинга
С чего начать?
Например, с базовых метрик для ETL процессов, а затем добавить проверки на качество данных. Используйте оповещения с пороговыми значениями. Например, алерт сработает, если время выполнения процесса превышает обычное более чем на 10%.
Не забывайте оптимизировать количество уведомлений. Никто не хочет получать 100 уведомлений в минуту. Поэтому важно тщательно подбирать критерии для алертов, чтобы они всегда были уместны и вызвали информационную слепоту.
Используйте (или проектируйте) подходящие инструменты для мониторинга и системы оповещений, и не перегружайте свою команду лишними уведомлениями. Это сделает ваше хранилище надежным и эффективным. В конце концов, зачем нужным данные, если мы не можем положиться на их качество?
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Материализованные представления: ускоряем аналитику
Чтобы понять матвью, давайте вернёмся на шаг назад и вспомним, что такое вью (view, V, представление). Представление — это виртуальные таблицы, которые хранят текст SQL-запроса и запускаются на лету. Они не сохраняют сами данные (в некоторых бд могут кешироваться в рамках сеанса до изменения источников).
Основное отличие MV от V как раз в том, что оно физически хранит результаты вычислений и позволяет использовать их повторно, вместо того чтобы пересчитывать данные каждый раз.
Пример: есть таблица с данными о продажах, которые обновляются раз в сутки. Аналитики несколько раз в день строят отчёты с расчётом суммарного дохода по регионам и категориям товаров. Создание MV позволяет агрегировать данные раз в сутки сразу после обновления источников. Это ускоряет построение отчетов и снижает нагрузку на базу данных.
Рассмотрим пример создания MV для Snowflake:
Как происходит синхронизация данных?
Чаще всего MV автоматически обновляются при изменении исходных данных. Однако частота и способ обновления зависят от СУБД:
— Snowflake: обновляются инкрементально, снижая нагрузку на хранилище.
— PostgreSQL: обновление требует явного выполнения команды REFRESH MATERIALIZED VIEW, что добавляет ручной работы.
— Oracle: поддерживаются как полные, так и инкрементальные обновления в зависимости от настроек.
— Microsoft SQL Server: MV называются индексированными представлениями и обновляются автоматически, но с ограничениями на типы запросов.
Когда использовать MV
🟢 один и тот же сложный запрос выполняется многократно на большом объёме данных;
🟢 исходные данные обновляются редко, а аналитика выполняется часто;
🟢 нужен быстрый доступ к данным с минимальной задержкой;
🟢 есть достаточно места для хранения данных.
Когда не стоит использовать MV
🟣 запросы редкие или исследовательские (ad hoc) — тогда затраты перевешивают выгоду;
🟣 ограничено место для хранения (ведь данные сохраняются физически);
🟣 данные обновляются слишком часто — материализованные представления необходимо часто обновлять, что может привести к дополнительным накладным расходам (актуально не для всех систем);
🟣 запросы содержат конструкции, не поддерживаемые MV (зависит от БД).
MV — не универсальное решение, но тем не менее есть ситуации в которых их использование помогает ускорить аналитические запросы, экономя ресурсы. Они оптимальны для сценариев, где данные обновляются реже, чем анализируются. Важно помнить о балансе: применять MV стоит только там, где выгода от ускорения превышает затраты на хранение данных и процесс вычисления.
#dwh
Материализованные представления (Materialized Views, MV, матвью) — способ ускорить выполнение аналитических запросов за счет предварительного вычисления и сохранения данных.
Чтобы понять матвью, давайте вернёмся на шаг назад и вспомним, что такое вью (view, V, представление). Представление — это виртуальные таблицы, которые хранят текст SQL-запроса и запускаются на лету. Они не сохраняют сами данные (в некоторых бд могут кешироваться в рамках сеанса до изменения источников).
Основное отличие MV от V как раз в том, что оно физически хранит результаты вычислений и позволяет использовать их повторно, вместо того чтобы пересчитывать данные каждый раз.
Пример: есть таблица с данными о продажах, которые обновляются раз в сутки. Аналитики несколько раз в день строят отчёты с расчётом суммарного дохода по регионам и категориям товаров. Создание MV позволяет агрегировать данные раз в сутки сразу после обновления источников. Это ускоряет построение отчетов и снижает нагрузку на базу данных.
Рассмотрим пример создания MV для Snowflake:
CREATE MATERIALIZED VIEW sales_summary_mv AS
SELECT
region,
category,
SUM(revenue) AS total_revenue,
COUNT(*) AS transaction_count
FROM sales
GROUP BY region, category;
Как происходит синхронизация данных?
Чаще всего MV автоматически обновляются при изменении исходных данных. Однако частота и способ обновления зависят от СУБД:
— Snowflake: обновляются инкрементально, снижая нагрузку на хранилище.
— PostgreSQL: обновление требует явного выполнения команды REFRESH MATERIALIZED VIEW, что добавляет ручной работы.
— Oracle: поддерживаются как полные, так и инкрементальные обновления в зависимости от настроек.
— Microsoft SQL Server: MV называются индексированными представлениями и обновляются автоматически, но с ограничениями на типы запросов.
Когда использовать MV
Когда не стоит использовать MV
MV — не универсальное решение, но тем не менее есть ситуации в которых их использование помогает ускорить аналитические запросы, экономя ресурсы. Они оптимальны для сценариев, где данные обновляются реже, чем анализируются. Важно помнить о балансе: применять MV стоит только там, где выгода от ускорения превышает затраты на хранение данных и процесс вычисления.
#dwh
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1🔥1