Приветствуем!
Вы на канале про Data Driven культуру, который бережно и старательно ведёт команда российского BI продукта Analytic Workspace.
Но мы не будем рассказывать здесь про наш продукт и нахваливать его, хотя нам есть чем хвастать 😉
Здесь мы делимся информацией из мира больших и малых данных — из мира, в который мы ежедневно окунаемся.
Про что мы здесь пишем:
— Интересные примеры визуализаций.
— Дата сторителлинг.
— ML в BI. BI без ML. ML без BI.
— Кейсы из практики внедрения (как удалось объединить необъединяемое, например).
— Культура DD в общем смысле.
— Тренды на рынке BI.
— Статистика с рынка BI: рост/падение популярности профессии, профиль специалиста и т.п.
— Что почитать.
— Где и чему учиться.
Для удобной навигации используем теги:
#новичкам – знания, точно полезные для тех, кто только погружается в тему.
#профи – информация для тех, кто уже в теме BI.
#ru_bi – информация из мира российских BI.
#визуал – пример классного (или страшного) дашборда.
#практика – примеры из практики, датасеты и прочее.
#мнение – оно и есть мнение.
#технологии – о технологиях в BI.
#статья – полезная статья из мира данных.
#книга – рекомендация книги.
#интервью – интервью с представителями отрасли.
#история – интересная история из мира данных.
#жиза – смешные и не очень зарисовки из Data Driven будней.
#дайджест – подборка ссылок на полезное, увиденное нами.
#мероприятия — анонс или запись классного мероприятия.
#знания — ценные знания из мира данных.
———————————
analyticworkspace.ru — это наш сайт.
@awcommunity — сообщество взаимопомощи специалистов, которые работают с Analytic Workspace.
Вы на канале про Data Driven культуру, который бережно и старательно ведёт команда российского BI продукта Analytic Workspace.
Но мы не будем рассказывать здесь про наш продукт и нахваливать его, хотя нам есть чем хвастать 😉
Здесь мы делимся информацией из мира больших и малых данных — из мира, в который мы ежедневно окунаемся.
Про что мы здесь пишем:
— Интересные примеры визуализаций.
— Дата сторителлинг.
— ML в BI. BI без ML. ML без BI.
— Кейсы из практики внедрения (как удалось объединить необъединяемое, например).
— Культура DD в общем смысле.
— Тренды на рынке BI.
— Статистика с рынка BI: рост/падение популярности профессии, профиль специалиста и т.п.
— Что почитать.
— Где и чему учиться.
Для удобной навигации используем теги:
#новичкам – знания, точно полезные для тех, кто только погружается в тему.
#профи – информация для тех, кто уже в теме BI.
#ru_bi – информация из мира российских BI.
#визуал – пример классного (или страшного) дашборда.
#практика – примеры из практики, датасеты и прочее.
#мнение – оно и есть мнение.
#технологии – о технологиях в BI.
#статья – полезная статья из мира данных.
#книга – рекомендация книги.
#интервью – интервью с представителями отрасли.
#история – интересная история из мира данных.
#жиза – смешные и не очень зарисовки из Data Driven будней.
#дайджест – подборка ссылок на полезное, увиденное нами.
#мероприятия — анонс или запись классного мероприятия.
#знания — ценные знания из мира данных.
———————————
analyticworkspace.ru — это наш сайт.
@awcommunity — сообщество взаимопомощи специалистов, которые работают с Analytic Workspace.
Python и аналитика данных
Спросили у нашего архитектора Александра Кварацхелия про Python: нужен ли он аналитику данных и с чего можно начать изучение (желательно бесплатно)?
Собственно ответ:
"В последние несколько лет Python стал де-факто основным языком, используемым при обработке больших данных. Это связано с тем, что Python является мощным и гибким языком программирования, который обладает множеством библиотек и инструментов для работы с данными.
Кроме того, Python признан одним из самых удобных языков для быстрой разработки прототипов и тестирования идей, что делает его особенно привлекательным для научных исследователей и аналитиков данных. Наконец, благодаря своей простоте и открытому исходному коду, Python позволяет быстро создавать и распространять программное обеспечение, что делает его идеальным выбором для командной работы над проектами по обработке и анализу больших данных.
В части анализа данных Python применяет декларативные возможности языка и это очень похоже на использование SQL: аналитик в скрипте указывает в каком виде необходимо выполнить обработку данных, а среда исполнения вызывает низкоуровневые и высокопроизводительные функции, написанные на других языках (например, на C). Это позволяет применять всю мощь современных возможностей обработки данных при сохранении простоты и удобства использования.
Хорошим местом для того, чтобы начать изучать возможности Python в анализе данных, являются бесплатные курсы на платформе Stepik. Например, курс Анализ данных (Введение в Python и обработку таблиц) (доступные и понятные уроки, преподносимые с чувством юмора)."
#новичкам
Спросили у нашего архитектора Александра Кварацхелия про Python: нужен ли он аналитику данных и с чего можно начать изучение (желательно бесплатно)?
Собственно ответ:
"В последние несколько лет Python стал де-факто основным языком, используемым при обработке больших данных. Это связано с тем, что Python является мощным и гибким языком программирования, который обладает множеством библиотек и инструментов для работы с данными.
Кроме того, Python признан одним из самых удобных языков для быстрой разработки прототипов и тестирования идей, что делает его особенно привлекательным для научных исследователей и аналитиков данных. Наконец, благодаря своей простоте и открытому исходному коду, Python позволяет быстро создавать и распространять программное обеспечение, что делает его идеальным выбором для командной работы над проектами по обработке и анализу больших данных.
В части анализа данных Python применяет декларативные возможности языка и это очень похоже на использование SQL: аналитик в скрипте указывает в каком виде необходимо выполнить обработку данных, а среда исполнения вызывает низкоуровневые и высокопроизводительные функции, написанные на других языках (например, на C). Это позволяет применять всю мощь современных возможностей обработки данных при сохранении простоты и удобства использования.
Хорошим местом для того, чтобы начать изучать возможности Python в анализе данных, являются бесплатные курсы на платформе Stepik. Например, курс Анализ данных (Введение в Python и обработку таблиц) (доступные и понятные уроки, преподносимые с чувством юмора)."
#новичкам
Про детализацию
Большая ценность BI в том, что данные живые. Живость информации сильно отличает работу с данными в BI от работы с данными в презентации.
Презентация — это один срез, Дашборд — это сотни срезов сразу.
Но закончим про банальное 😉 и перейдём к сути — к детализациям.
Живость информации получается достигнуть за счёт детализаций и фильтрации, а иногда за счёт их совместной смеси.
Сегодня про детализации.
Англоязычные BI-аналитики для детализации обычно используют два термина: Drill down и Drill through. Русскоязычные BI-аналитики оба термина часто заменяют словом детализация, потому что Drill through звучит не очень.
Суть детализации (кратко и понятно):
Drill down — мы углубляемся в информации, не меняя при этом место углубления. Например, мы делаем группировку в сводной таблице, где на первом уровне — регион, на втором — менеджер, на третьем — товары. И открывая эти уровни мы углубляемся внутрь (down).
Drill through — мы углубляемся в информации, меняя место углубления. Например, мы выводим в дашборд KPI (плашка с цифрой) с объёмом продаж, но клик по этой плашке переводит нас на совсем другой дашборд (или лист дашборда), в котором продажи разложены на конкретные показатели.
Drill through — полезная история для случаев, когда директор, глядя с прищуром на какой-то график, говорит: "А скажи мне, голубчик, почему просели продажи у Иванова?". Голубчик в таком случае жмёт на столбик с Ивановым, открывая на отдельном дашборде кучу показателей, которые касаются конкретно Иванова. В статичной презентации такое сделать невозможно.
Теперь вы знаете про два основных вида детализации в BI.
#новичкам
Большая ценность BI в том, что данные живые. Живость информации сильно отличает работу с данными в BI от работы с данными в презентации.
Презентация — это один срез, Дашборд — это сотни срезов сразу.
Но закончим про банальное 😉 и перейдём к сути — к детализациям.
Живость информации получается достигнуть за счёт детализаций и фильтрации, а иногда за счёт их совместной смеси.
Сегодня про детализации.
Англоязычные BI-аналитики для детализации обычно используют два термина: Drill down и Drill through. Русскоязычные BI-аналитики оба термина часто заменяют словом детализация, потому что Drill through звучит не очень.
Суть детализации (кратко и понятно):
Drill down — мы углубляемся в информации, не меняя при этом место углубления. Например, мы делаем группировку в сводной таблице, где на первом уровне — регион, на втором — менеджер, на третьем — товары. И открывая эти уровни мы углубляемся внутрь (down).
Drill through — мы углубляемся в информации, меняя место углубления. Например, мы выводим в дашборд KPI (плашка с цифрой) с объёмом продаж, но клик по этой плашке переводит нас на совсем другой дашборд (или лист дашборда), в котором продажи разложены на конкретные показатели.
Drill through — полезная история для случаев, когда директор, глядя с прищуром на какой-то график, говорит: "А скажи мне, голубчик, почему просели продажи у Иванова?". Голубчик в таком случае жмёт на столбик с Ивановым, открывая на отдельном дашборде кучу показателей, которые касаются конкретно Иванова. В статичной презентации такое сделать невозможно.
Теперь вы знаете про два основных вида детализации в BI.
#новичкам
Кто есть кто в мире обработки данных?
Data Analyst (Аналитик данных) - это «детектив», который заглядывает в прошлое и настоящее данных, чтобы отыскать отгадки на вопросы бизнеса. Аналитики данных обладают способностью переводить язык цифр в увлекательные бизнес-истории и играют роль консультантов для высшего руководства.
Инструменты: Business Intelligence (BI), Data Storytelling, анализ тенденций, What-If Analysis, создание визуализаций/отчетности/дашбордов, SQL/ database knowledge
Data Scientist - а вот этот персонаж больше волшебник, чем детектив. Он глубоко погружается в данные, строит аналитические модели и прогнозы для интерпретации сложной информации, применяет AI и машинное обучение, чтобы найти глубинные связи в данных.
Его инструменты: AI/ML, инструменты статистического / машинного обучения для классификации шаблонов, определения силы шаблонов и взаимосвязей, количественная оценка причинно-следственных связей, обучение и оптимизация моделей машинного обучения.
Data Engineer (Инженер данных) - и наконец, герой, который создает и поддерживает всю инфраструктуру данных. Они - строители этого цифрового мира. Data Engineer разрабатывает и оптимизирует систему для ученых и аналитиков данных, чтобы они могли выполнять свою работу эффективно.
Его инструменты: проектирование инфраструктуры больших данных и подготовка ее к анализу, построение сложных запросов для создания «конвейеров данных (data pipelines)», очистка наборов данных, трансформация данных, оптимизация производительности, Data architecture, Data Warehousing & ETL, Hadoop-based Analytics
Data Architect (Архитектор данных) - это специалист, отвечающий за проектирование и создание структуры данных в организации. Data Architect разрабатывает концептуальные и физические модели данных, определяет схемы данных и выбирает соответствующие технологии для обработки данных. Также архитектор данных определяет стратегии архивирования, восстановления данных и управляет общей архитектурой данных в организации.
Его инструменты: CASE-средства, СУБД, ETL-инструменты, инструменты для проектирования и визуализации данных
Мы кратко разобрались, кто есть кто в мире работы с данными. Каждый из них играет важную роль в этой игре. Без них - нет настоящего анализа данных! 📊🔍
#новичкам
Data Analyst (Аналитик данных) - это «детектив», который заглядывает в прошлое и настоящее данных, чтобы отыскать отгадки на вопросы бизнеса. Аналитики данных обладают способностью переводить язык цифр в увлекательные бизнес-истории и играют роль консультантов для высшего руководства.
Инструменты: Business Intelligence (BI), Data Storytelling, анализ тенденций, What-If Analysis, создание визуализаций/отчетности/дашбордов, SQL/ database knowledge
Data Scientist - а вот этот персонаж больше волшебник, чем детектив. Он глубоко погружается в данные, строит аналитические модели и прогнозы для интерпретации сложной информации, применяет AI и машинное обучение, чтобы найти глубинные связи в данных.
Его инструменты: AI/ML, инструменты статистического / машинного обучения для классификации шаблонов, определения силы шаблонов и взаимосвязей, количественная оценка причинно-следственных связей, обучение и оптимизация моделей машинного обучения.
Data Engineer (Инженер данных) - и наконец, герой, который создает и поддерживает всю инфраструктуру данных. Они - строители этого цифрового мира. Data Engineer разрабатывает и оптимизирует систему для ученых и аналитиков данных, чтобы они могли выполнять свою работу эффективно.
Его инструменты: проектирование инфраструктуры больших данных и подготовка ее к анализу, построение сложных запросов для создания «конвейеров данных (data pipelines)», очистка наборов данных, трансформация данных, оптимизация производительности, Data architecture, Data Warehousing & ETL, Hadoop-based Analytics
Data Architect (Архитектор данных) - это специалист, отвечающий за проектирование и создание структуры данных в организации. Data Architect разрабатывает концептуальные и физические модели данных, определяет схемы данных и выбирает соответствующие технологии для обработки данных. Также архитектор данных определяет стратегии архивирования, восстановления данных и управляет общей архитектурой данных в организации.
Его инструменты: CASE-средства, СУБД, ETL-инструменты, инструменты для проектирования и визуализации данных
Мы кратко разобрались, кто есть кто в мире работы с данными. Каждый из них играет важную роль в этой игре. Без них - нет настоящего анализа данных! 📊🔍
#новичкам
Паттерны для архитектуры данных
Сегодня мы рассмотрим три базовых архитектурных подхода, которые применяются дата-инженерами и архитекторами корпоративных платформ для построения хранилищ данных.
🔸 Data Warehouse (DWH, Корпоративное хранилище данных)
В рамках данной архитектуры подразумевается построение отдельного структурированного супер-хранилища, промежуточного между разнообразными источниками данных и системами и их обработки. Над всеми данными, хранящимися в DWH, существует некая общая целевая модель данных, которая указывает, как эти данные связаны между собой.
Исторически, это первая парадигма хранения данных, применяемая с 1980-ых годов. К её преимуществам относят:
· Наличие единой модели данных, которая позволяет рассматривать DWH как единый источник истины;
· DWH идеально подходит для задач BI и аналитики, поскольку данные уже хранятся в упорядоченном виде, что делает их поиск более доступным и эффективным;
· DWH позволяет повысить производительность запросов, уменьшить избыточность данных и увеличить их точность.
Недостатки применения DWH:
· Наиболее существенной проблемой является сложность работы с полуструктурированными и неструктурированными данными;
· Создание конвейеров ETL для интеграции данных из различных источников в супер-хранилище может быть длительным и сложным;
· Единый источник истины также труднодостижим из-за постоянно меняющихся процессов, систем и требований.
🔸Data Lake (DL, озеро данных)
Для хранения данных из множества различных источников для разных аналитических продуктов и рабочих нагрузок в начале 2010-ых дата-архитекторы начали применять Озера данных. Озеро данных похоже на DWH, но данные в нем никак не организованы и не структурированы. Озеро данных хранит фактические данные в необработанном виде и позволяет проводить анализ данных в гораздо больших масштабах, чем традиционные DWH. Оно также позволяет пользователям хранить значительные объемы данных из различных источников и быстро получать к ним доступ при необходимости. В Озерах данные могут храниться и обрабатываться в своем родном формате, что обеспечивает большую гибкость и масштабируемость.
Преимущества:
· Озера данных обеспечивают хранение и обработку огромных объемов данных при низких затратах;
· Озера обеспечивают быстрый ввод данных в хранилище;
· Озера могут работать с любыми типами данных: структурированными, полуструктурированными и неструктурированными;
Недостатки:
· Из-за отсутствия единой схемы данных, Озера со временем могут дезорганизоваться, что приводит к образованию так называемого болота данных;
· Запросы к данным, хранящимся в озерах данных, обычно выполняются медленнее, чем к данным в DWH, и озера данных не являются идеальным решением для задач BI.
🔸Data LakeHouse (DLH, Озерище или Хранозеро)
В начале 2020 года появилась новая модель гибридной архитектуры данных, которая стремится объединить достоинства классических DWH с гибкостью Озер данных. Эта парадигма стала возможной благодаря новому дизайну системы: реализации структур данных и функций управления данными, аналогичных тем, которые используются в DWH, непосредственно поверх недорогого облачного хранилища в открытых форматах.
Применение DLH позволяет сохранить преимущества предыдущих двух подходов:
· Поддержка многообразия различных типов данных;
· Совместимость с BI инструментами. При этом, DLH позволяет использовать эти инструменты непосредственно в исходных данных, что повышает их актуальность;
· Изоляция хранения от вычислений, что облегчает масштабирование при росте объемов и рабочих нагрузок на хранилище;
· Возможность принудительного применения и управления схемой, что улучшает целостность и полноту данных.
Недостатки предыдущих подходов тоже имеются, но выражены в наименьшей степени. Потенциально DLH дает более гибкие и широкие возможности, но из-за этого является менее управляемым по сравнению с DWH. Кроме этого, данная технология еще относительно нова, и может не обеспечивать всеобъемлющего представления имеющихся данных.
#новичкам
Сегодня мы рассмотрим три базовых архитектурных подхода, которые применяются дата-инженерами и архитекторами корпоративных платформ для построения хранилищ данных.
🔸 Data Warehouse (DWH, Корпоративное хранилище данных)
В рамках данной архитектуры подразумевается построение отдельного структурированного супер-хранилища, промежуточного между разнообразными источниками данных и системами и их обработки. Над всеми данными, хранящимися в DWH, существует некая общая целевая модель данных, которая указывает, как эти данные связаны между собой.
Исторически, это первая парадигма хранения данных, применяемая с 1980-ых годов. К её преимуществам относят:
· Наличие единой модели данных, которая позволяет рассматривать DWH как единый источник истины;
· DWH идеально подходит для задач BI и аналитики, поскольку данные уже хранятся в упорядоченном виде, что делает их поиск более доступным и эффективным;
· DWH позволяет повысить производительность запросов, уменьшить избыточность данных и увеличить их точность.
Недостатки применения DWH:
· Наиболее существенной проблемой является сложность работы с полуструктурированными и неструктурированными данными;
· Создание конвейеров ETL для интеграции данных из различных источников в супер-хранилище может быть длительным и сложным;
· Единый источник истины также труднодостижим из-за постоянно меняющихся процессов, систем и требований.
🔸Data Lake (DL, озеро данных)
Для хранения данных из множества различных источников для разных аналитических продуктов и рабочих нагрузок в начале 2010-ых дата-архитекторы начали применять Озера данных. Озеро данных похоже на DWH, но данные в нем никак не организованы и не структурированы. Озеро данных хранит фактические данные в необработанном виде и позволяет проводить анализ данных в гораздо больших масштабах, чем традиционные DWH. Оно также позволяет пользователям хранить значительные объемы данных из различных источников и быстро получать к ним доступ при необходимости. В Озерах данные могут храниться и обрабатываться в своем родном формате, что обеспечивает большую гибкость и масштабируемость.
Преимущества:
· Озера данных обеспечивают хранение и обработку огромных объемов данных при низких затратах;
· Озера обеспечивают быстрый ввод данных в хранилище;
· Озера могут работать с любыми типами данных: структурированными, полуструктурированными и неструктурированными;
Недостатки:
· Из-за отсутствия единой схемы данных, Озера со временем могут дезорганизоваться, что приводит к образованию так называемого болота данных;
· Запросы к данным, хранящимся в озерах данных, обычно выполняются медленнее, чем к данным в DWH, и озера данных не являются идеальным решением для задач BI.
🔸Data LakeHouse (DLH, Озерище или Хранозеро)
В начале 2020 года появилась новая модель гибридной архитектуры данных, которая стремится объединить достоинства классических DWH с гибкостью Озер данных. Эта парадигма стала возможной благодаря новому дизайну системы: реализации структур данных и функций управления данными, аналогичных тем, которые используются в DWH, непосредственно поверх недорогого облачного хранилища в открытых форматах.
Применение DLH позволяет сохранить преимущества предыдущих двух подходов:
· Поддержка многообразия различных типов данных;
· Совместимость с BI инструментами. При этом, DLH позволяет использовать эти инструменты непосредственно в исходных данных, что повышает их актуальность;
· Изоляция хранения от вычислений, что облегчает масштабирование при росте объемов и рабочих нагрузок на хранилище;
· Возможность принудительного применения и управления схемой, что улучшает целостность и полноту данных.
Недостатки предыдущих подходов тоже имеются, но выражены в наименьшей степени. Потенциально DLH дает более гибкие и широкие возможности, но из-за этого является менее управляемым по сравнению с DWH. Кроме этого, данная технология еще относительно нова, и может не обеспечивать всеобъемлющего представления имеющихся данных.
#новичкам
Почему Clickhouse?
Точнее вопрос будет звучать так: почему в системах аналитики часто используется Clickhouse, а не традиционные БД(Postgres, MySQL, Oracle и т.д.)?
Ответ: из-за архитектурных особенностей баз данных.
В классических реляционных базах данные хранятся построчно, приблизительно так:
[A1, B1, C1], [A2, B2, C2], [A3, B3, C3]…
где A, B и С — это поля (столбцы), а 1,2 и 3 — номер записи (строки).
Такое хранение удобно для частых операций добавления новых строк в базу данных, хранящуюся как правило на жестком диске, и используется в транзакционных приложениях(создали нового пользователя - записали в базу, отправили сообщение - записали в базу и т.п.)
В случае аналитических систем наибольшая нагрузка создается тяжелыми выборками (select) сотен тысяч и миллионов записей, часто с группировками и расчетом агрегатов. Количество операций записи при этом невысоко, нередко менее 1% общего числа.
Однако что произойдет, если выбрать, например, только 3 поля из таблицы, в которой их всего 50? В силу построчного хранения данных в традиционных СУБД будут прочитаны абсолютно все строки целиком со всеми полями, пропущены через контроллер дискового ввода-вывода и переданы процессору, который уже отберет только необходимые для запроса.
Решить эту проблему призваны колоночные СУБД, к которым и относится Clickhouse. Основная идея колоночных СУБД — это хранение данных не по строкам, а по колонкам. С точки зрения SQL-клиента данные представлены как обычно в виде таблиц, при этом физически на диске значения одного поля хранятся последовательно друг за другом — приблизительно так:
[A1, A2, A3], [B1, B2, B3], [C1, C2, C3] и т.д.
Такая организация данных приводит к тому, что при выборе в SELECT 3 полей таблицы из 50, с диска физически будут прочитаны только 3 колонки. Это означает что нагрузка на канал ввода-вывода будет приблизительно в 50/3=17 раз меньше, чем при выполнении такого же запроса в традиционной СУБД. Кроме того, при поколоночном хранении данных появляется возможность сильно компрессировать данные, так как в одной колонке таблицы данные как правило однотипные, чего не скажешь о строке.
#новичкам #технологии #знания
Точнее вопрос будет звучать так: почему в системах аналитики часто используется Clickhouse, а не традиционные БД(Postgres, MySQL, Oracle и т.д.)?
Ответ: из-за архитектурных особенностей баз данных.
В классических реляционных базах данные хранятся построчно, приблизительно так:
[A1, B1, C1], [A2, B2, C2], [A3, B3, C3]…
где A, B и С — это поля (столбцы), а 1,2 и 3 — номер записи (строки).
Такое хранение удобно для частых операций добавления новых строк в базу данных, хранящуюся как правило на жестком диске, и используется в транзакционных приложениях(создали нового пользователя - записали в базу, отправили сообщение - записали в базу и т.п.)
В случае аналитических систем наибольшая нагрузка создается тяжелыми выборками (select) сотен тысяч и миллионов записей, часто с группировками и расчетом агрегатов. Количество операций записи при этом невысоко, нередко менее 1% общего числа.
Однако что произойдет, если выбрать, например, только 3 поля из таблицы, в которой их всего 50? В силу построчного хранения данных в традиционных СУБД будут прочитаны абсолютно все строки целиком со всеми полями, пропущены через контроллер дискового ввода-вывода и переданы процессору, который уже отберет только необходимые для запроса.
Решить эту проблему призваны колоночные СУБД, к которым и относится Clickhouse. Основная идея колоночных СУБД — это хранение данных не по строкам, а по колонкам. С точки зрения SQL-клиента данные представлены как обычно в виде таблиц, при этом физически на диске значения одного поля хранятся последовательно друг за другом — приблизительно так:
[A1, A2, A3], [B1, B2, B3], [C1, C2, C3] и т.д.
Такая организация данных приводит к тому, что при выборе в SELECT 3 полей таблицы из 50, с диска физически будут прочитаны только 3 колонки. Это означает что нагрузка на канал ввода-вывода будет приблизительно в 50/3=17 раз меньше, чем при выполнении такого же запроса в традиционной СУБД. Кроме того, при поколоночном хранении данных появляется возможность сильно компрессировать данные, так как в одной колонке таблицы данные как правило однотипные, чего не скажешь о строке.
#новичкам #технологии #знания
Как писать красивые и читаемые SQL запросы :)
Думаю большинство тех, кто читает данный пост знает, что такое SQL и с чем его едят. Для новоприбывших в ряды аналитиков: в комментарии к посту найдете ссылку наопределение из Википедии хороший обучающий тренажер с теорией. Язык SQL можно выучить самостоятельно. Он прост, быстро усваивается, благодаря чему отлично подходит для погружения в науку о данных, однако самостоятельное обучение может таить в себе ряд недостатков. Ключевой из них: формирование неправильного стиля программирования. Давайте разбираться на что обратить внимание, чтобы ваши запросы можно было масштабировать и их понимали другие люди.
1. Отступы и пробелы необходимы для структурирования запросов
Старайтесь выносить операторы на новые строки, добавлять отступы и пробелы между структурными блоками. Согласитесь, легче воспринимается это:
Верхний регистр используется для ключевых слов SQL, а нижний — для таблиц и столбцов. Функции SQL также настоятельно рекомендуется писать в верхнем регистре.
3. Не используйте SELECT * при написании кода итоговых версий запросов
Перетаскивая все столбцы с собой, мы легко можем спровоцировать нарушение их работы. Потеря контроля над ними чревата получением лишних невостребованных данных и дублированных столбцов, усложняющих код. Перечисляем только нужные столбцы!
4. Используйте меньше подзапросов и больше CTE
Вложенные многоуровневые запросы усложняют чтение кода. Для тех кто в теме: проблема похожа на пирамиду вложенных вызовов в языках программирования. К примеру, в JavaScript ее решили введением promise`ов. Вывод: делайте структуру кода плоской, так код проще воспринимать.
5. Присваивайте столбцам логически обоснованные имена
При создании запроса мы можем просто переносить столбцы. Вместо этого рекомендуется называть их в соответствии с предполагаемым назначением.
#новичкам #знания
Думаю большинство тех, кто читает данный пост знает, что такое SQL и с чем его едят. Для новоприбывших в ряды аналитиков: в комментарии к посту найдете ссылку на
1. Отступы и пробелы необходимы для структурирования запросов
Старайтесь выносить операторы на новые строки, добавлять отступы и пробелы между структурными блоками. Согласитесь, легче воспринимается это:
SELECTчем это:
TA.id,
TA.client_name,
TA.client_surname,
SUM(TB.client_spent_amount) AS total_client_spent_amount,
SUM(TB.client_Discounts) AS total_clients_discounts
FROM table_A AS TA
LEFT JOIN table_B AS TB
ON TA.id = TB.id
WHERE TA.country = "France"
GROUP BY TA.id
SELECT TA.id, TA.client_name, TA.client_surname, SUM(TB.client_purchases) AS total_client_purchases, sum(TB.client_Discounts) as total_clients_discounts2. Пишите синтаксис SQL в верхнем регистре
FROM table_A AS TA LEFT JOIN table_B AS TB ON TA.id = TB.id WHERE TA.country = "France" GROUP BY TA.id
Верхний регистр используется для ключевых слов SQL, а нижний — для таблиц и столбцов. Функции SQL также настоятельно рекомендуется писать в верхнем регистре.
3. Не используйте SELECT * при написании кода итоговых версий запросов
Перетаскивая все столбцы с собой, мы легко можем спровоцировать нарушение их работы. Потеря контроля над ними чревата получением лишних невостребованных данных и дублированных столбцов, усложняющих код. Перечисляем только нужные столбцы!
4. Используйте меньше подзапросов и больше CTE
Вложенные многоуровневые запросы усложняют чтение кода. Для тех кто в теме: проблема похожа на пирамиду вложенных вызовов в языках программирования. К примеру, в JavaScript ее решили введением promise`ов. Вывод: делайте структуру кода плоской, так код проще воспринимать.
5. Присваивайте столбцам логически обоснованные имена
При создании запроса мы можем просто переносить столбцы. Вместо этого рекомендуется называть их в соответствии с предполагаемым назначением.
#новичкам #знания
Почему одни SQL-запросы выполняются быстрее других или первое знакомство с планом выполнения
Спойлер: у этого поста нет цели научить вас за 5 минут оптимизировать запросы или разбираться в работе движка той или иной БД. Это больше вектор на область знаний, понимание которой поможет вам расти профессионально, глубже разбираться в том, что вы делаете.
План запроса - это внутренняя структура, создаваемая оптимизатором SQL базы данных для выполнения определенного SQL-запроса. План запроса содержит информацию о порядке выполнения операторов в запросе, а также об используемых индексах, таблицах и других объектах базы данных.
Выполнение запроса можно разделить на следующие этапы (подробнее о каждом этапе можно прочитать в источнике):
- Установка подключения к серверу СУБД
- Трансформация SQL-запроса
- Планирование запроса
- Исполнение запроса
- Завершение соединения
На этапе планирования выполняется поиск наиболее оптимального способа выполнения нашего запроса. Для этого планировщик осуществляет перебор возможных планов выполнения, оценивает затраты на исполнение и присваивает каждому определённую стоимость.
Для просмотра выбранного плана можно использовать команду EXPLAIN. В её выводе для каждого узла дерева плана отводится строка с описанием базового типа узла, оценки стоимости выполнения (cost), ожидаемое число строк (rows), ожидаемый средний размер строк (width). Команду EXPLAIN можно использовать с параметром ANALYSE, которая выполнит запрос и выведет фактический план, дополненный информацией о времени планирования и исполнения. Команду можно использовать для оценки фактического времени выполнения запроса, однако не стоит забывать, что использование параметра ANALYSE требует реального выполнения запроса в БД. Пример реального плана выполнения можно увидеть на картинке к посту.
Итого: понимание работы плана запроса является важным аспектом для оптимизации SQL-запросов и повышения производительности базы данных. Как минимум SQL-запросы станут для вас более предсказуемыми, вы будете тратить меньше времени на возникающие проблемы и их устранение :)
Источники:
https://club.directum.ru/post/361562
https://habr.com/ru/articles/203320/
http://bit.ly/3GPYWcX
#новичкам #знания
План запроса - это внутренняя структура, создаваемая оптимизатором SQL базы данных для выполнения определенного SQL-запроса. План запроса содержит информацию о порядке выполнения операторов в запросе, а также об используемых индексах, таблицах и других объектах базы данных.
Выполнение запроса можно разделить на следующие этапы (подробнее о каждом этапе можно прочитать в источнике):
- Установка подключения к серверу СУБД
- Трансформация SQL-запроса
- Планирование запроса
- Исполнение запроса
- Завершение соединения
На этапе планирования выполняется поиск наиболее оптимального способа выполнения нашего запроса. Для этого планировщик осуществляет перебор возможных планов выполнения, оценивает затраты на исполнение и присваивает каждому определённую стоимость.
Для просмотра выбранного плана можно использовать команду EXPLAIN. В её выводе для каждого узла дерева плана отводится строка с описанием базового типа узла, оценки стоимости выполнения (cost), ожидаемое число строк (rows), ожидаемый средний размер строк (width). Команду EXPLAIN можно использовать с параметром ANALYSE, которая выполнит запрос и выведет фактический план, дополненный информацией о времени планирования и исполнения. Команду можно использовать для оценки фактического времени выполнения запроса, однако не стоит забывать, что использование параметра ANALYSE требует реального выполнения запроса в БД. Пример реального плана выполнения можно увидеть на картинке к посту.
Итого: понимание работы плана запроса является важным аспектом для оптимизации SQL-запросов и повышения производительности базы данных. Как минимум SQL-запросы станут для вас более предсказуемыми, вы будете тратить меньше времени на возникающие проблемы и их устранение :)
Источники:
https://club.directum.ru/post/361562
https://habr.com/ru/articles/203320/
http://bit.ly/3GPYWcX
#новичкам #знания
Поговорим о типах атрибутов в аналитических таблицах. Не о тех, которые “строка”, ”число”, ”дата” и ”логическое” А те, которые “числовые”, “категориальные” и “порядковые”.
Числовые атрибуты - описывают измеримые величины, задаваемыми целыми или действительными числами.
В рамках числовых атрибутов принято ещё выделять два подтипа: интервальные и относительные. Интервальные атрибуты измеряются по шкале с фиксированными, но произвольными единицами измерений и произвольным началом отсчета. Примером интервальных атрибутов являются дата и время (да-да, даты и временные метки хранятся в компьютерах в виде чисел). Или температура по шкале Цельсия. К таким атрибутам применяются операции упорядочивания (мы точно знаем какая дата не меньше другой), а также вычитание (вычитая две даты мы получаем количество дней между ними). Но мы не можем сказать, что при 20 градусов Цельсия - это в два раза теплее, чем 10 градусов.
Относительные атрибуты отличаются от интервальных тем, что для них есть истинный ноль. То есть, мы можем описать любое значение такого атрибута как кратное другому значению. Вес, рост, размер заработной платы, баллы ЕГЭ - это всё примеры таких атрибутов. Возвращаясь к градусам: по шкале Кельвина, 20 градусов действительно в два раза теплее, чем 10)
Категориальные атрибуты - принимают значения из ограниченного набора и могут восприниматься как имена для категорий, классов и обстоятельств (поэтому, их иногда ещё называют номинальными). Примеры категориальных атрибутов: семейное положение (холост, женат и разведен), виды шотландского виски (односолодовый, зерновой и купажированный) и “это-спам?” (да/нет). Также, ФИО в зарплатной ведомости - это тоже категориальный атрибут. И даже иногда значения с датами, если они указывают на первый день месяца, можно воспринимать как название (т.е., категоризацию) этого месяца.
Порядковые атрибуты - аналогичны категориальным с той разницей, что их можно ранжировать. То есть, установить между любыми двумя значениями отношение “больше-меньше”. Например, степень усталости: “легкая”, “средняя”, “тяжелая”.
Граница между категориальными и порядковыми атрибутами не всегда четкая. Кто-то может сказать, что “пасмурно” - это между “солнечно” и “дождливо”. А кто-то может считать, что это вообще нельзя упорядочивать.
Такая типизация атрибутов влияет на методы анализа и понимания данных. Даже если у вас какая-то категория физически описывается числовыми значениями (например, цифрами 1, 2, 3 - как идентификаторы в БД), то нельзя применять к ней методы нахождения среднего значения и дисперсии, как мы бы сделали с другими числовыми данными (например, размер з/п в компании).
#новичкам
Числовые атрибуты - описывают измеримые величины, задаваемыми целыми или действительными числами.
В рамках числовых атрибутов принято ещё выделять два подтипа: интервальные и относительные. Интервальные атрибуты измеряются по шкале с фиксированными, но произвольными единицами измерений и произвольным началом отсчета. Примером интервальных атрибутов являются дата и время (да-да, даты и временные метки хранятся в компьютерах в виде чисел). Или температура по шкале Цельсия. К таким атрибутам применяются операции упорядочивания (мы точно знаем какая дата не меньше другой), а также вычитание (вычитая две даты мы получаем количество дней между ними). Но мы не можем сказать, что при 20 градусов Цельсия - это в два раза теплее, чем 10 градусов.
Относительные атрибуты отличаются от интервальных тем, что для них есть истинный ноль. То есть, мы можем описать любое значение такого атрибута как кратное другому значению. Вес, рост, размер заработной платы, баллы ЕГЭ - это всё примеры таких атрибутов. Возвращаясь к градусам: по шкале Кельвина, 20 градусов действительно в два раза теплее, чем 10)
Категориальные атрибуты - принимают значения из ограниченного набора и могут восприниматься как имена для категорий, классов и обстоятельств (поэтому, их иногда ещё называют номинальными). Примеры категориальных атрибутов: семейное положение (холост, женат и разведен), виды шотландского виски (односолодовый, зерновой и купажированный) и “это-спам?” (да/нет). Также, ФИО в зарплатной ведомости - это тоже категориальный атрибут. И даже иногда значения с датами, если они указывают на первый день месяца, можно воспринимать как название (т.е., категоризацию) этого месяца.
Порядковые атрибуты - аналогичны категориальным с той разницей, что их можно ранжировать. То есть, установить между любыми двумя значениями отношение “больше-меньше”. Например, степень усталости: “легкая”, “средняя”, “тяжелая”.
Граница между категориальными и порядковыми атрибутами не всегда четкая. Кто-то может сказать, что “пасмурно” - это между “солнечно” и “дождливо”. А кто-то может считать, что это вообще нельзя упорядочивать.
Такая типизация атрибутов влияет на методы анализа и понимания данных. Даже если у вас какая-то категория физически описывается числовыми значениями (например, цифрами 1, 2, 3 - как идентификаторы в БД), то нельзя применять к ней методы нахождения среднего значения и дисперсии, как мы бы сделали с другими числовыми данными (например, размер з/п в компании).
#новичкам
Почему лучше не пользоваться 3D диаграммами
3D-диаграммы выглядят круто. Но корректно ли их использовать при визуализации данных?
В первую очередь рассмотрим явление окклюзии. Окклюзия – это синоним препятствия. На ровной поверхности, когда мы видим, что один объект закрывает другой, человеческий мозг воспринимает, что скрываемый предмет находится позади и, следовательно, дальше от объекта, который находится впереди.
Когда мы рассматриваем объекты в 3D, объекты, расположенные дальше, кажутся меньшими, но наш мозг воспринимает их как более крупные, чем на изображении, и использует прошлый визуальный опыт для внесения этих корректировок.
Посмотрим, как этот эффект проявляется при работе с графиками. Обе круговые диаграммы представляют идентичные данные. На двухмерной круговой диаграмме легко увидеть, что синий и серый цвета (яблоки и бананы) имеют одинаковый размер. С другой стороны, на трехмерной диаграмме серый цвет выглядит намного больше, чем синий. Кроме того, серый и оранжевый кажутся одинаковыми в 3D, а синий - наименьшим. Следовательно, мы неправильно воспринимаем три вещи на трехмерной круговой диаграмме. Это связано с принципом искажения перспективы.
⚠️Таким образом можно сделать вывод, что симпатичные трехмерные диаграммы на самом деле плохо справляются с передачей информации. А на примере это достаточно наглядно продемонстрировано☝️
#новичкам #знание
3D-диаграммы выглядят круто. Но корректно ли их использовать при визуализации данных?
В первую очередь рассмотрим явление окклюзии. Окклюзия – это синоним препятствия. На ровной поверхности, когда мы видим, что один объект закрывает другой, человеческий мозг воспринимает, что скрываемый предмет находится позади и, следовательно, дальше от объекта, который находится впереди.
Когда мы рассматриваем объекты в 3D, объекты, расположенные дальше, кажутся меньшими, но наш мозг воспринимает их как более крупные, чем на изображении, и использует прошлый визуальный опыт для внесения этих корректировок.
Посмотрим, как этот эффект проявляется при работе с графиками. Обе круговые диаграммы представляют идентичные данные. На двухмерной круговой диаграмме легко увидеть, что синий и серый цвета (яблоки и бананы) имеют одинаковый размер. С другой стороны, на трехмерной диаграмме серый цвет выглядит намного больше, чем синий. Кроме того, серый и оранжевый кажутся одинаковыми в 3D, а синий - наименьшим. Следовательно, мы неправильно воспринимаем три вещи на трехмерной круговой диаграмме. Это связано с принципом искажения перспективы.
⚠️Таким образом можно сделать вывод, что симпатичные трехмерные диаграммы на самом деле плохо справляются с передачей информации. А на примере это достаточно наглядно продемонстрировано☝️
#новичкам #знание