Качества документации: ТЗ должно быть полным, но кратким
Всем известна фраза "краткость — сестра таланта" и она отлично ложится на написание документации. Сплошную стену текста одним абзацем с пространными рассуждениями никто читать не будет или будет, но по диагонали и крайне невнимательно. Что обязательно скажется на скорости и качестве разработки, либо её поддержке.
Всегда цените своё время и время коллег.
ТЗ должно содержать минимум воды, только технические факты. Но шутка в том, что писать кратко =/= писать мало. В ТЗ не должно быть моментов "а вот это итак очевидно, указывать не буду". То, что очевидно сегодня, будет никому неизвестно завтра, когда придёт другой сотрудник или что-то просто забудется.
Поэтому важно соблюдать баланс между многабукаф и "ничего не понятно".
Лайфхаки:
— Проработайте шаблоны под типичные для компании типы ТЗ.
— Логику процессов прописывайте пошаговым списком.
— Вместо текста, там где это возможно, используйте таблицы, графики, майнд-карты.
— При написании ТЗ ставьте себя на место разработчика. Всё ли вам понятно?
— Используйте заголовки и оглавление.
— Выделяйте важный текст и не бойтесь подчеркиваний. Но без фанатизма. Система выделений и цветов не должна пестрить и должна быть понятной.
— Дописав, сделайте паузу на чай и/или другую задачу. Вернитесь и перечитайте.
#документация
Всем известна фраза "краткость — сестра таланта" и она отлично ложится на написание документации. Сплошную стену текста одним абзацем с пространными рассуждениями никто читать не будет или будет, но по диагонали и крайне невнимательно. Что обязательно скажется на скорости и качестве разработки, либо её поддержке.
Всегда цените своё время и время коллег.
ТЗ должно содержать минимум воды, только технические факты. Но шутка в том, что писать кратко =/= писать мало. В ТЗ не должно быть моментов "а вот это итак очевидно, указывать не буду". То, что очевидно сегодня, будет никому неизвестно завтра, когда придёт другой сотрудник или что-то просто забудется.
Поэтому важно соблюдать баланс между многабукаф и "ничего не понятно".
Лайфхаки:
— Проработайте шаблоны под типичные для компании типы ТЗ.
— Логику процессов прописывайте пошаговым списком.
— Вместо текста, там где это возможно, используйте таблицы, графики, майнд-карты.
— При написании ТЗ ставьте себя на место разработчика. Всё ли вам понятно?
— Используйте заголовки и оглавление.
— Выделяйте важный текст и не бойтесь подчеркиваний. Но без фанатизма. Система выделений и цветов не должна пестрить и должна быть понятной.
— Дописав, сделайте паузу на чай и/или другую задачу. Вернитесь и перечитайте.
#документация
Партиционирование (partitioning) в Greenplum
Партиционирование (или секционирование) помогает повысить производительность запросов за счет разбиения больших таблиц на небольшие части, называемые партициями (partitions). Это позволяет оптимизаторам запросов сканировать ограниченное число строк в таблице (на основе условий) вместо чтения всего содержимого таблицы.
Партицировать маленькие таблицы не имеет смысла!
Партиционирование может быть указано только при создании таблицы, однако удалять/добавлять/изменять партиции в дальнейшем можно. Чтобы сделать добавить партиционирование в таблицу, нужно сделать новую таблицу с партициями и перенести данные из непартиционированной.
Пример создания партиционированной таблицы:
#greenplum
Партиционирование (или секционирование) помогает повысить производительность запросов за счет разбиения больших таблиц на небольшие части, называемые партициями (partitions). Это позволяет оптимизаторам запросов сканировать ограниченное число строк в таблице (на основе условий) вместо чтения всего содержимого таблицы.
Партицировать маленькие таблицы не имеет смысла!
Партиционирование может быть указано только при создании таблицы, однако удалять/добавлять/изменять партиции в дальнейшем можно. Чтобы сделать добавить партиционирование в таблицу, нужно сделать новую таблицу с партициями и перенести данные из непартиционированной.
Пример создания партиционированной таблицы:
create table [schema_name].<table_name>Важно! Загрузка данных в партиционированные таблицы крайне неэффективна. Поэтому рекомендуется загружать данные в промежуточную (staging) таблицу и затем применять к партиционированной таблице команду EXCHANGE PARTITION.
(<columns_list>)
[with (<storage_options>)]
distributed <distribution_policy>
partition by <partition_spec>;
#greenplum
Isolation — Изолированность
Изолированность отвечает за то, что транзакции не должны оказывать влияния на другие параллельные транзакции.
Большинство БД поддерживает 4 уровня изоляции:
1. Read Uncommitted
2. Read Committed
3. Repeatable Read
4. Serializable
Чем ниже уровень, тем слабее изоляция, но тем меньше тратится ресурсов.
Подробнее о возникающих проблемах при работе параллельных транзакция и об уровнях изоляции поговорим позже.
#sql #acid
Изолированность отвечает за то, что транзакции не должны оказывать влияния на другие параллельные транзакции.
Большинство БД поддерживает 4 уровня изоляции:
1. Read Uncommitted
2. Read Committed
3. Repeatable Read
4. Serializable
Чем ниже уровень, тем слабее изоляция, но тем меньше тратится ресурсов.
Подробнее о возникающих проблемах при работе параллельных транзакция и об уровнях изоляции поговорим позже.
#sql #acid
Шпаргалка: NULL и логические операции
Я уже рассказывала про сравнение с Null, но это не все особенности работы с ним, которые важно знать при анализе данных.
Null — третье логическое значение (кроме True и False), оно обозначает неизвестность. Исходя из этого определения легко вывести следующее:
Null AND True = Null
Null AND False = False
Null AND Null = Null
Null OR True = True
Null OR False = Null
Null OR Null = Null
NOT (Null) = Null
NOT (NOT(Null)) = Null
Во всех случаях стоит помнить, что Null в результатах не равен Null в условии. Это несравнимая неизвестность.
#sql #null
Я уже рассказывала про сравнение с Null, но это не все особенности работы с ним, которые важно знать при анализе данных.
Null — третье логическое значение (кроме True и False), оно обозначает неизвестность. Исходя из этого определения легко вывести следующее:
Null AND True = Null
Null AND False = False
Null AND Null = Null
Null OR True = True
Null OR False = Null
Null OR Null = Null
NOT (Null) = Null
NOT (NOT(Null)) = Null
Во всех случаях стоит помнить, что Null в результатах не равен Null в условии. Это несравнимая неизвестность.
#sql #null
Data Governance или забота о данных
Data Governance — это процесс управления данными, включающий определение структуры и правил, обеспечивающий их качество, целостность, доступность, безопасность и эффективное использование.
Data Governance — это как следить за порядком в своей комнате, только в мире данных.
Почему это важно?
— Это помогает сохранить данные в порядке. Хаос в данных может привести к неверным выводам. Data Governance говорит нам, как следить за чистотой данных.
— Это помогает нам соблюдать законы. Мы должны защищать данные и соблюдать законодательство той страны, в которой работаем. Data Governance учит нас, как это делать.
— Это способствует лучшей управляемости. Когда все знают, где и какие данные есть, бизнес может принимать лучшие решения.
Data Governance — это организационный фундамент, на котором строится надёжная, безопасная и эффективная работа с данными.
#data_governance
Data Governance — это процесс управления данными, включающий определение структуры и правил, обеспечивающий их качество, целостность, доступность, безопасность и эффективное использование.
Data Governance — это как следить за порядком в своей комнате, только в мире данных.
Почему это важно?
— Это помогает сохранить данные в порядке. Хаос в данных может привести к неверным выводам. Data Governance говорит нам, как следить за чистотой данных.
— Это помогает нам соблюдать законы. Мы должны защищать данные и соблюдать законодательство той страны, в которой работаем. Data Governance учит нас, как это делать.
— Это способствует лучшей управляемости. Когда все знают, где и какие данные есть, бизнес может принимать лучшие решения.
Data Governance — это организационный фундамент, на котором строится надёжная, безопасная и эффективная работа с данными.
#data_governance
Не бойтесь "глупых" вопросов
IT, как и сфера любых технологий, стремительно развивается. И абсолютно невозможно знать всё обо всём, и это нормально. Но как часто кто-то из нас считает себя крутым специалистом и стыдится приходить с "глупыми" вопросами к коллегам?
Задавать любые вопросы — нормально. И это тоже очень важный навык. Во-первых, во время формулирования вопроса вы уже можете прийти к нужному ответу (писала про это в отдельном посте). Во-вторых, часто получить ответ от коллеги будет быстрее и эффективнее, чем идти самому через тернии к звёздам.
Конечно, это не значит, что нужно бегать за каждым забытым хоткеем по чатам. Сначала всё-таки сходите в старый добрый гугл и приложите хотя бы минимальные усилия на поиск ответа.
Сначала думаем, потом формулируем, гуглим, затем спрашиваем.
#soft_skills
IT, как и сфера любых технологий, стремительно развивается. И абсолютно невозможно знать всё обо всём, и это нормально. Но как часто кто-то из нас считает себя крутым специалистом и стыдится приходить с "глупыми" вопросами к коллегам?
Задавать любые вопросы — нормально. И это тоже очень важный навык. Во-первых, во время формулирования вопроса вы уже можете прийти к нужному ответу (писала про это в отдельном посте). Во-вторых, часто получить ответ от коллеги будет быстрее и эффективнее, чем идти самому через тернии к звёздам.
Конечно, это не значит, что нужно бегать за каждым забытым хоткеем по чатам. Сначала всё-таки сходите в старый добрый гугл и приложите хотя бы минимальные усилия на поиск ответа.
Сначала думаем, потом формулируем, гуглим, затем спрашиваем.
#soft_skills
Группировка данных в SQL: суть и применение
Группировка данных — это инструмент анализа в SQL, который позволяет агрегировать данные для получения ценных инсайтов. Давайте разберемся, как это работает.
GROUP BY — основной метод группировки данных. Он позволяет сгруппировать строки в результатах запроса по значениям в одном или нескольких столбцах. Например, вы можете группировать продажи по датам и/или по категориям товаров. Это особенно полезно для создания агрегированных отчетов.
COUNT() — используется для подсчета количества строк в каждой группе. Например, вы можете узнать, сколько заказов было сделано каждым клиентом.
SUM() — для суммирования числовых значений в группе, таких как общая сумма продаж по категории товаров.
AVG() — для вычисления среднего значения числовых данных в группе. Например, средний размер заказа.
MAX() и MIN() — определяют максимальное и минимальное значение в группе. Это может быть полезно, например, для определения самой дорогой или дешевой покупки в каждой категории товаров.
HAVING — эта уже не функция, а отдельная часть запроса, которая позволяет применять условия к группам. Например, вы можете выбрать только те группы, в которых средняя цена товаров больше определенного значения.
Пример группировки, который выводит среднюю цену товара в каждой категории с фильтрацией по среднему:
Нужно понимать, что группируя данные вы делаете именно агрегацию и не можете вывести тут же информацию и из отдельной строки.
Группировка данных полезна для создания сводных таблиц, отчетов и анализа больших объемов информации. Она помогает выделить общие закономерности и тренды, что делает ее неотъемлемой частью работы с данными в DWH.
#sql
Группировка данных — это инструмент анализа в SQL, который позволяет агрегировать данные для получения ценных инсайтов. Давайте разберемся, как это работает.
GROUP BY — основной метод группировки данных. Он позволяет сгруппировать строки в результатах запроса по значениям в одном или нескольких столбцах. Например, вы можете группировать продажи по датам и/или по категориям товаров. Это особенно полезно для создания агрегированных отчетов.
COUNT() — используется для подсчета количества строк в каждой группе. Например, вы можете узнать, сколько заказов было сделано каждым клиентом.
SUM() — для суммирования числовых значений в группе, таких как общая сумма продаж по категории товаров.
AVG() — для вычисления среднего значения числовых данных в группе. Например, средний размер заказа.
MAX() и MIN() — определяют максимальное и минимальное значение в группе. Это может быть полезно, например, для определения самой дорогой или дешевой покупки в каждой категории товаров.
HAVING — эта уже не функция, а отдельная часть запроса, которая позволяет применять условия к группам. Например, вы можете выбрать только те группы, в которых средняя цена товаров больше определенного значения.
Пример группировки, который выводит среднюю цену товара в каждой категории с фильтрацией по среднему:
SELECT category, AVG(price) as average_price
FROM products
GROUP BY category
HAVING AVG(price) > 100;
Нужно понимать, что группируя данные вы делаете именно агрегацию и не можете вывести тут же информацию и из отдельной строки.
Группировка данных полезна для создания сводных таблиц, отчетов и анализа больших объемов информации. Она помогает выделить общие закономерности и тренды, что делает ее неотъемлемой частью работы с данными в DWH.
#sql
Виды партиций в Greenplum
— partition by range – осуществляет разделение данных на основе числовых или временных (date/timestamp) диапазонов. Интервалы для партиций указываются используя ключевые слова START и END. Выражения INCLUSIVE и EXCLUSIVE используются в связке с START и END для указания того, должны ли попадать в соответствующий диапазон граничные значения. По умолчанию значения, указанные с помощью START, включаются в диапазон; значения, определенные с помощью END — нет. Партиции можно указывать как автоматически, так и вручную.
Автоматически:
Вручную:
— partition by list – на основе списков значений.
#greenplum
— partition by range – осуществляет разделение данных на основе числовых или временных (date/timestamp) диапазонов. Интервалы для партиций указываются используя ключевые слова START и END. Выражения INCLUSIVE и EXCLUSIVE используются в связке с START и END для указания того, должны ли попадать в соответствующий диапазон граничные значения. По умолчанию значения, указанные с помощью START, включаются в диапазон; значения, определенные с помощью END — нет. Партиции можно указывать как автоматически, так и вручную.
Автоматически:
create table [schema_name].<table_name>
(<columns_list>)
[with (<storage_options>)]
distributed <distribution_policy>
partition by range(<column name>)
(partition monthly start (date 'ХХХХ-ХХ-ХХ') inclusive end (date 'ХХХХ-ХХ-ХХ') exclusive every (interval '1 month'));
Вручную:
create table [schema_name].<table_name>
(<columns_list>)
[with (<storage_options>)]
distributed <distribution_policy>
partition by range(<column name>)
(partition Nov23 start(date '2023-11-01') inclusive,
partition Dec23 start(date '2023-12-01') inclusive end(date '2024-01-01') exclusive);
— partition by list – на основе списков значений.
create table [schema_name].<table_name>
(<columns_list>)
[with (<storage_options>)]
distributed <distribution_policy>
partition by list (pet)
(partition cats values ('Cat'),
partition dogs values ('Dog'),
default partition other);
#greenplum
DWH и анализ данных
Можно сколь угодно качественно раскладывать данные по хранилищу, но без понимания зачем эти данные нужны и какой профит бизнесу они могут принести, всё это — пустой слив бюджетов и времени.
Анализ данных должен стать ключевым элементом в процессе принятия обоснованных бизнес-решений и построении DWH. В хранилище хранится огромное количество информации, а анализ позволяет выявить на её основе ценные инсайты, увидеть тренды, выявить аномалии и/или понять причины просадок.
Некоторые составляющие анализа:
1. Понимание данных и их структуры (здесь поможет data-каталог или иная качественная документация к хранилищу).
2. Формулирование вопросов к бизнесу, процессам и данным. Например, "Какие продукты наиболее популярны у клиентов и есть ли зависимости от дня недели и времени суток?" или "Какие маркетинговые кампании приводят к наибольшим продажам и что между ними общего?".
3. SQL. Без этого инструмента (пока что) никуда.
4. Визуализация данных. Графики и диаграммы помогают наглядно представить результаты анализа и лучше понять данные.
5. Обнаружение паттернов, тенденции и аномалии может помочь в принятии решений, определении стратегии и оптимизации процессов.
6. Прогнозирование на основе данных из хранилища и разработка прогностических моделей.
Анализ данных добавляет существованию DWH смысл. В то же время грамотно (зависит от целей) спроектированное хранилище поможет облегчить, ускорить и качественно улучшить анализ.
#dwh
Можно сколь угодно качественно раскладывать данные по хранилищу, но без понимания зачем эти данные нужны и какой профит бизнесу они могут принести, всё это — пустой слив бюджетов и времени.
Анализ данных должен стать ключевым элементом в процессе принятия обоснованных бизнес-решений и построении DWH. В хранилище хранится огромное количество информации, а анализ позволяет выявить на её основе ценные инсайты, увидеть тренды, выявить аномалии и/или понять причины просадок.
Некоторые составляющие анализа:
1. Понимание данных и их структуры (здесь поможет data-каталог или иная качественная документация к хранилищу).
2. Формулирование вопросов к бизнесу, процессам и данным. Например, "Какие продукты наиболее популярны у клиентов и есть ли зависимости от дня недели и времени суток?" или "Какие маркетинговые кампании приводят к наибольшим продажам и что между ними общего?".
3. SQL. Без этого инструмента (пока что) никуда.
4. Визуализация данных. Графики и диаграммы помогают наглядно представить результаты анализа и лучше понять данные.
5. Обнаружение паттернов, тенденции и аномалии может помочь в принятии решений, определении стратегии и оптимизации процессов.
6. Прогнозирование на основе данных из хранилища и разработка прогностических моделей.
Анализ данных добавляет существованию DWH смысл. В то же время грамотно (зависит от целей) спроектированное хранилище поможет облегчить, ускорить и качественно улучшить анализ.
#dwh
Дайджест статей за сентябрь
Лучше поздно, чем никогда :)
Общее о профессии и DWH:
Системный аналитик — кто он?
Насколько большая эта ваша Big data?
Коротко о DWH
Data Lakehouse
Зачем нам нужен ETL?
БД:
ACID: atomicity, consistency, isolation and durability
Atomicity — Атомарность
Consistency — Согласованность
CHAR и VARCHAR — что будем использовать? Или всё-таки TEXT?
Почему UUID лучше, чем автоинкрементные идентификаторы. И лучше ли?
Немного о доках:
Без внятного ТЗ и результат ХЗ
ClickHouse:
Коротко о ClickHouse
Основные отличия ClickHouse от других MPP-систем
Шардирование данных в ClickHouse
Greenplum:
Коротко о Greenplum
Хранение данных в таблицах в Greenplum
Распределение (distribution) в Greenplum
Разное из SQL:
NULL != NULL — это True?
ALTER и UPDATE в SQL. В чём разница?
#дайджест
Лучше поздно, чем никогда :)
Общее о профессии и DWH:
Системный аналитик — кто он?
Насколько большая эта ваша Big data?
Коротко о DWH
Data Lakehouse
Зачем нам нужен ETL?
БД:
ACID: atomicity, consistency, isolation and durability
Atomicity — Атомарность
Consistency — Согласованность
CHAR и VARCHAR — что будем использовать? Или всё-таки TEXT?
Почему UUID лучше, чем автоинкрементные идентификаторы. И лучше ли?
Немного о доках:
Без внятного ТЗ и результат ХЗ
ClickHouse:
Коротко о ClickHouse
Основные отличия ClickHouse от других MPP-систем
Шардирование данных в ClickHouse
Greenplum:
Коротко о Greenplum
Хранение данных в таблицах в Greenplum
Распределение (distribution) в Greenplum
Разное из SQL:
NULL != NULL — это True?
ALTER и UPDATE в SQL. В чём разница?
#дайджест
Telegram
В мире больших данных
Системный аналитик DWH — кто это? Как объяснить так, чтобы поняла даже бабушка?
На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт…
На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт…
Хороший тон партиционирования в Greenplum
— Делить на партиции нужно только большие AOT-таблицы.
— Не нужно разбивать таблицы на очень маленькие партиции.
— Ключ партиционирования должен использоваться в запросах в условии where.
— Ключ должен позволять разбить таблицу на примерно одинаковые части.
— Таблицы, созданные с использованием политики распределения данных DISTRIBUTED REPLICATED, не могут быть партиционированы.
#greenplum
— Делить на партиции нужно только большие AOT-таблицы.
— Не нужно разбивать таблицы на очень маленькие партиции.
— Ключ партиционирования должен использоваться в запросах в условии where.
— Ключ должен позволять разбить таблицу на примерно одинаковые части.
— Таблицы, созданные с использованием политики распределения данных DISTRIBUTED REPLICATED, не могут быть партиционированы.
#greenplum
Метод '5 почему' поможет раскрыть истинные потребности бизнеса
Поговорим о том, как понять, что именно нужно бизнесу, когда он приходит с вопросом "хочу того — не знаю чего".
Рассмотрим сценарий: продуктовый аналитик требуют какие-то метрики, основанные на данных, которые вроде бы есть, а вроде и нет в хранилище. Как удовлетворить потребности максимально точно? Есть метод, который помогает раскрывать настоящие потребности заказчика. Этот метод — "5 почему".
Суть метода заключается в том, чтобы понять, что именно бизнес хочет получить задавая вопросы. Конечно, не обязательно спрашивать именно "Почему". Вместо этого, перефразируем вопросы в соответствии с запросом заказчика.
Возможные шаги:
— Определяем запрос бизнеса. Просим заказчика ясно сформулировать, что именно ему нужно.
— Задаем вопросы, которые позволят выявить детали запроса. Подходим к делу креативно.
— Создаём цепочку из вопросов (не ставим строгую планку "пять", как в оригинале метода). Постепенно детализируем каждый аспект запроса, записывая ответы, чтобы лучше видеть картину. При сложных запросах здесь классно поможет использование майнд-карт.
— Проверяем формулировку вопросов на точность. Если вдруг застреваем на каком-то этапе, перефразируем вопросы.
— При необходимости привлекаем других заинтересованных лиц. Разнообразные точки зрения и мнения — это сила.
Так благодаря системному анализу и методу "5 почему," построение DWH становится более точным и эффективным, помогая бизнесу получить от данных то, что действительно нужно.
#soft_skills #системный_анализ
Поговорим о том, как понять, что именно нужно бизнесу, когда он приходит с вопросом "хочу того — не знаю чего".
Рассмотрим сценарий: продуктовый аналитик требуют какие-то метрики, основанные на данных, которые вроде бы есть, а вроде и нет в хранилище. Как удовлетворить потребности максимально точно? Есть метод, который помогает раскрывать настоящие потребности заказчика. Этот метод — "5 почему".
Суть метода заключается в том, чтобы понять, что именно бизнес хочет получить задавая вопросы. Конечно, не обязательно спрашивать именно "Почему". Вместо этого, перефразируем вопросы в соответствии с запросом заказчика.
Возможные шаги:
— Определяем запрос бизнеса. Просим заказчика ясно сформулировать, что именно ему нужно.
— Задаем вопросы, которые позволят выявить детали запроса. Подходим к делу креативно.
— Создаём цепочку из вопросов (не ставим строгую планку "пять", как в оригинале метода). Постепенно детализируем каждый аспект запроса, записывая ответы, чтобы лучше видеть картину. При сложных запросах здесь классно поможет использование майнд-карт.
— Проверяем формулировку вопросов на точность. Если вдруг застреваем на каком-то этапе, перефразируем вопросы.
— При необходимости привлекаем других заинтересованных лиц. Разнообразные точки зрения и мнения — это сила.
Так благодаря системному анализу и методу "5 почему," построение DWH становится более точным и эффективным, помогая бизнесу получить от данных то, что действительно нужно.
#soft_skills #системный_анализ
❤1
Дайджест статей за октябрь
DWH и BigData:
OLTP vs OLAP
Data Governance или забота о данных
DWH и анализ данных
ClickHouse:
Целочисленные типы в Clickhouse
Greenplum:
Сжатие данных в Greenplum
Партиционирование (partitioning) в Greenplum
Виды партиций в Greenplum
Хороший тон партиционирования в Greenplum
SQL и БД:
Как запросом убрать дублирующиеся данные?
Я есть CRUD
Isolation — Изолированность
Шпаргалка: NULL и логические операции
Группировка данных в SQL: суть и применение
Документация:
Доки должны быть качественными
ТЗ должно быть полным, но кратким
Soft skills:
Быть или не быть. Важность формулирования вопросов
Не бойтесь "глупых" вопросов
Метод '5 почему' поможет раскрыть истинные потребности бизнеса
#дайджест
DWH и BigData:
OLTP vs OLAP
Data Governance или забота о данных
DWH и анализ данных
ClickHouse:
Целочисленные типы в Clickhouse
Greenplum:
Сжатие данных в Greenplum
Партиционирование (partitioning) в Greenplum
Виды партиций в Greenplum
Хороший тон партиционирования в Greenplum
SQL и БД:
Как запросом убрать дублирующиеся данные?
Я есть CRUD
Isolation — Изолированность
Шпаргалка: NULL и логические операции
Группировка данных в SQL: суть и применение
Документация:
Доки должны быть качественными
ТЗ должно быть полным, но кратким
Soft skills:
Быть или не быть. Важность формулирования вопросов
Не бойтесь "глупых" вопросов
Метод '5 почему' поможет раскрыть истинные потребности бизнеса
#дайджест
❤1🔥1
Множественные комбинации: перекрёстное соединение в SQL
Мы ещё не затрагивали тему соединений, которая является очень важной и обширной. И начну я, пожалуй, с одного из наиболее редких соединений. Это CROSS JOIN. Несмотря на его не частое использование, важно понимать как он работает.
По своей сути cross join — это декартово произведение. Каждая строка таблицы A объединяется с каждой строкой таблицы B. Число строк набора результатов будет равно произведению количества строк таблиц, которые будут объединены. Это отличный инструмент для создания всевозможных комбинаций.
Синтаксис:
Аналогично сработает:
Давайте рассмотрим как будет выглядеть результат перекрёстного объединения двух таблиц:
table_a
table_b
Результат:
Обратите внимание на то, как произошло объединение по NULL — это полноценное значение поля и забывать о нём не нужно.
При использовании cross join на больших таблицах не забывайте, что это дорогостоящая операция, возвращающая огромные наборы данных (ведь мы умножаем одну таблицу на другую).
#sql #join
Мы ещё не затрагивали тему соединений, которая является очень важной и обширной. И начну я, пожалуй, с одного из наиболее редких соединений. Это CROSS JOIN. Несмотря на его не частое использование, важно понимать как он работает.
По своей сути cross join — это декартово произведение. Каждая строка таблицы A объединяется с каждой строкой таблицы B. Число строк набора результатов будет равно произведению количества строк таблиц, которые будут объединены. Это отличный инструмент для создания всевозможных комбинаций.
Синтаксис:
SELECT id_a, id_b
FROM table_a
CROSS JOIN table_b;Аналогично сработает:
SELECT id_a, id_b
FROM table_a, table_bДавайте рассмотрим как будет выглядеть результат перекрёстного объединения двух таблиц:
table_a
1
3
NULLtable_b
1
2
NULLРезультат:
1 1
1 2
1 NULL
3 1
3 2
3 NULL
NULL 1
NULL 2
NULL NULLОбратите внимание на то, как произошло объединение по NULL — это полноценное значение поля и забывать о нём не нужно.
При использовании cross join на больших таблицах не забывайте, что это дорогостоящая операция, возвращающая огромные наборы данных (ведь мы умножаем одну таблицу на другую).
#sql #join
❤1
DROP, DELETE, TRUNCATE — погружение в мир удаления данных
В SQL есть несколько способов избавиться от данных и хорошо бы в них не путаться. Так что давайте вспоминать азы.
DROP — когда нужно грохнуть всё и сразу
Эта DDL-операция используется для удаления объектов базы данных (таблицы, представления, индексы и т.д., включая саму базу). Важно понимать, что удаляются не только данные, но и сама структура, определяющая их хранение.
DELETE — выборочное удаление
DML-операция DELETE удаляет записи из таблиц, при этом есть возможность удаления данных по условию. Если условие не указано, то удаляются все данные (но не структура объекта). При этом при удалении DELETE возвращает количество удалённых строк. Также стоит помнить, что DELETE сохраняет значения авто-инкрементального ID, т.е. если вы удалили последнюю запись в таблице и у неё был ID 37, новая строка добавится с ID 38.
Транзакцию с DELETE можно откатить. Удаление "построчное", поэтому медленное.
TRUNCATE — быстрая очистка
DDL-операция TRUNCATE позволяет быстро очистить таблицу ото всех записей, так как в лог-транзакций не записывается построчное удаление (быстрота особенно ощущается на больших таблицах, но не экспериментируйте на проде). При удалении TRUNCATE сбрасывает все авто-инкрементальные счётчики и статистику.
Удаляйте осознано и, главное, с пониманием что и где вы делаете 😄
#sql
В SQL есть несколько способов избавиться от данных и хорошо бы в них не путаться. Так что давайте вспоминать азы.
DROP — когда нужно грохнуть всё и сразу
Эта DDL-операция используется для удаления объектов базы данных (таблицы, представления, индексы и т.д., включая саму базу). Важно понимать, что удаляются не только данные, но и сама структура, определяющая их хранение.
DROP TABLE table_name;
DELETE — выборочное удаление
DML-операция DELETE удаляет записи из таблиц, при этом есть возможность удаления данных по условию. Если условие не указано, то удаляются все данные (но не структура объекта). При этом при удалении DELETE возвращает количество удалённых строк. Также стоит помнить, что DELETE сохраняет значения авто-инкрементального ID, т.е. если вы удалили последнюю запись в таблице и у неё был ID 37, новая строка добавится с ID 38.
Транзакцию с DELETE можно откатить. Удаление "построчное", поэтому медленное.
DELETE FROM table_name WHERE column_name=value;
TRUNCATE — быстрая очистка
DDL-операция TRUNCATE позволяет быстро очистить таблицу ото всех записей, так как в лог-транзакций не записывается построчное удаление (быстрота особенно ощущается на больших таблицах, но не экспериментируйте на проде). При удалении TRUNCATE сбрасывает все авто-инкрементальные счётчики и статистику.
TRUNCATE TABLE table_name;
Удаляйте осознано и, главное, с пониманием что и где вы делаете 😄
#sql
❤1
Сказка о потерянном времени или проблемы с датами при репликации
На хабре вышла полезная статья про то, почему стоит отказаться от timestamp в PostgreSQL. Рекомендую к прочтению, так как на самом деле тема актуальна не только для постгри.
При построении хранилища очень важно понимать какие даты лежат в источниках, какой часовой пояс на сервере и что именно приходит в нужные нам поля таблиц. Иначе мы можем получить несогласованность в данных: если в источник данные приходят без указания часового пояса, но "по умолчанию" считается, что это Москва, а само хранилище работает в UTC, при репликации даты могут сдвинуться на несколько часов (и, например, перейти в следующий день), что приведёт к недопониманию временных интервалов и ошибкам при анализе временных периодов. Это может повлиять на оценку эффективности стратегий или бизнес-процессов.
В финансовой отчетности критически важна точность дат. Несогласованные даты при расчетах прибыли и убытков могут привести к ошибкам в финансовых планах и стратегиях.
Что же делать?
— Необходим анализ всех полей с датами в источниках. Важно понимать, что неразбериха с часовыми поясами может быть даже в рамках одной таблицы, например, даты в тех.полях могут поступать в UTC, а в самих фактах в Московском времени.
— Нужна явная обработка часовых поясов при репликации, чтобы избежать несогласованных данных.
— Использование UTC в общем случае упростит согласование дат и предотвратит временную путаницу.
— Чаще всего лучше использовать тип timestamptz (with time zone), если данный тип поддерживается.
— Проверке времён нужно уделить особо внимание при тестировании и приёмке данных.
Управление часовыми поясами при репликации — ключевой аспект поддержания целостности данных в хранилище. Системный подход к этому вопросу поможет избежать временной путаницы и обеспечить точность аналитических отчётов.
#sql
На хабре вышла полезная статья про то, почему стоит отказаться от timestamp в PostgreSQL. Рекомендую к прочтению, так как на самом деле тема актуальна не только для постгри.
При построении хранилища очень важно понимать какие даты лежат в источниках, какой часовой пояс на сервере и что именно приходит в нужные нам поля таблиц. Иначе мы можем получить несогласованность в данных: если в источник данные приходят без указания часового пояса, но "по умолчанию" считается, что это Москва, а само хранилище работает в UTC, при репликации даты могут сдвинуться на несколько часов (и, например, перейти в следующий день), что приведёт к недопониманию временных интервалов и ошибкам при анализе временных периодов. Это может повлиять на оценку эффективности стратегий или бизнес-процессов.
В финансовой отчетности критически важна точность дат. Несогласованные даты при расчетах прибыли и убытков могут привести к ошибкам в финансовых планах и стратегиях.
Что же делать?
— Необходим анализ всех полей с датами в источниках. Важно понимать, что неразбериха с часовыми поясами может быть даже в рамках одной таблицы, например, даты в тех.полях могут поступать в UTC, а в самих фактах в Московском времени.
— Нужна явная обработка часовых поясов при репликации, чтобы избежать несогласованных данных.
— Использование UTC в общем случае упростит согласование дат и предотвратит временную путаницу.
— Чаще всего лучше использовать тип timestamptz (with time zone), если данный тип поддерживается.
— Проверке времён нужно уделить особо внимание при тестировании и приёмке данных.
Управление часовыми поясами при репликации — ключевой аспект поддержания целостности данных в хранилище. Системный подход к этому вопросу поможет избежать временной путаницы и обеспечить точность аналитических отчётов.
#sql
Хабр
Почему вам стоит отказаться от использования timestamp в PostgreSQL
Не секрет, что работа с часовыми поясами — боль, и многие разработчики объяснимо стараются ее избегать. Тем более что в каждом языке программирования / СУБД работа с часовыми поясами реализована...
❤1
Коротко о Snowflake
— Облачное хранилище данных и аналитическая платформа
— Трёхслойная архитектура: хранение, вычисление и сервисы
— Масштабируемость и производительность
— Лёгкая управляемость
— Высокая доступность и отказоустойчивость
— Автоматическая организация и сжатие данных
— Экономическая эффективность
— Колоночное хранение
— Snowflake SQL соответствует ANSI SQL и в целом очень похож на PostgreSQL
#snowflake
— Облачное хранилище данных и аналитическая платформа
— Трёхслойная архитектура: хранение, вычисление и сервисы
— Масштабируемость и производительность
— Лёгкая управляемость
— Высокая доступность и отказоустойчивость
— Автоматическая организация и сжатие данных
— Экономическая эффективность
— Колоночное хранение
— Snowflake SQL соответствует ANSI SQL и в целом очень похож на PostgreSQL
#snowflake
❤1
Вставка данных в таблицу Greenplum через INSERT INTO
Базовый синтаксис
Важно! тип вставляемых данных должен соответствовать типу столбцов.
Особенности
Для вставки данных в партиционироанную таблицу указывается корневая таблица (созданная командой CREATE TABLE), либо отдельная партиция для вставки. Если данные для указанной дочерней таблицы не соответствуют условию партиционирования, возвращается ошибка.
Для вставки больших объемов данных следует использовать внешние таблицы (external table) или команду COPY. Эти механизмы загрузки более эффективны для вставки большого количества строк.
Не рекомендуется использовать оператор INSERT INTO для вставки одной строки в append-optimized таблицу (AOT). Greenplum Database поддерживает не более 127 одновременных транзакций INSERT в одну AOT.
#greenplum
Базовый синтаксис
insert into sandbox.table_name ({column}, {column}, ...) values
(123456, Ivan, '2023-11-17 19:45:00'),
(123457, Olga, '2023-11-17 19:46:00');Важно! тип вставляемых данных должен соответствовать типу столбцов.
insert into sandbox.table_name select * from another_table where column_with_date > '2023-09-07';
Особенности
Для вставки данных в партиционироанную таблицу указывается корневая таблица (созданная командой CREATE TABLE), либо отдельная партиция для вставки. Если данные для указанной дочерней таблицы не соответствуют условию партиционирования, возвращается ошибка.
Для вставки больших объемов данных следует использовать внешние таблицы (external table) или команду COPY. Эти механизмы загрузки более эффективны для вставки большого количества строк.
Не рекомендуется использовать оператор INSERT INTO для вставки одной строки в append-optimized таблицу (AOT). Greenplum Database поддерживает не более 127 одновременных транзакций INSERT в одну AOT.
#greenplum
❤1
EXCEPT в SQL: ищем уникальные значения
Оператор разности EXCEPT служит для сравнения двух наборов данных. Он извлекает уникальные значения из первого, отсутствующие во втором наборе.
EXCEPT — инструмент для фильтрации данных и поиска различий между таблицами. Он позволяет выполнять сравнение в одном или нескольких столбцах, в этом случае сравнение идёт кортежами.
Важно помнить, что при выполнении операции EXCEPT автоматически устраняются дубликаты строк. Если строка существует во втором наборе данных, она не появится в окончательном результате, даже если в первом наборе присутствует несколько раз.
Для использования оператора необходимо, чтобы в обоих наборах данных было указано одинаковое количество столбцов, а их порядок и типы данных должны быть сопоставимыми.
Синтаксис:
Если результирующий набор данных нужно отсортировать, то после второго набора данных указывается
Также EXCEPT можно заменить на JOIN (и чаще всего это может дать прирост производительности):
Однако использование EXCEPT делает запрос более читабельным. Что касается эффективности — её лучше тестировать (и по возможности смотреть планы запросов) на реальных данных с учётом индексов и прочих особенностей в конкретных СУБД.
Но не только EXCEPT и LEFT JOIN помогают выявлять уникальные значения в данных. В одном из следующих постов вспомним с вами о таких методах вычитания как NOT IN и NOT EXISTS.
#sql
Оператор разности EXCEPT служит для сравнения двух наборов данных. Он извлекает уникальные значения из первого, отсутствующие во втором наборе.
EXCEPT — инструмент для фильтрации данных и поиска различий между таблицами. Он позволяет выполнять сравнение в одном или нескольких столбцах, в этом случае сравнение идёт кортежами.
Важно помнить, что при выполнении операции EXCEPT автоматически устраняются дубликаты строк. Если строка существует во втором наборе данных, она не появится в окончательном результате, даже если в первом наборе присутствует несколько раз.
Для использования оператора необходимо, чтобы в обоих наборах данных было указано одинаковое количество столбцов, а их порядок и типы данных должны быть сопоставимыми.
Синтаксис:
select column_1
from table_name_1
[where condition]
except
select column_1
from table_name_2
[where condition]
order by column_1
Если результирующий набор данных нужно отсортировать, то после второго набора данных указывается
order by.Также EXCEPT можно заменить на JOIN (и чаще всего это может дать прирост производительности):
select t1.column_1
from table_name_1 t1
left join table_name_2 t2
on t1.column_1 = t2.column_1
where t2.column_1 is NULL
order by t1.column_1
Однако использование EXCEPT делает запрос более читабельным. Что касается эффективности — её лучше тестировать (и по возможности смотреть планы запросов) на реальных данных с учётом индексов и прочих особенностей в конкретных СУБД.
Но не только EXCEPT и LEFT JOIN помогают выявлять уникальные значения в данных. В одном из следующих постов вспомним с вами о таких методах вычитания как NOT IN и NOT EXISTS.
#sql
❤1
Качества документации: непротиворечивость
Продолжим говорить о качествах документации. До этого мы рассмотрели краткость и полноту, сегодня поговорим о непротиворечивости.
ТЗ и Соглашения не должны противоречить ни другим требованиям внутри проекта, ни самим себе. Если в начале документа мы говорим "сделай так", а в конце "сделай эдак", или в одном документе указываем что поле содержит данные Х (например, дату возврата товара), а в другом это же поле содержит данные У (н-р, дату возврата денег клиенту) — ничего хорошего от данных мы в итоге не получим.
Ещё один простой пример: в ТЗ указано время обновления витрины раз в сутки, в jira требование — "обновление раз в 15 минут", какой результат ожидать от инженера? Будет круто, если он придёт за уточнением, но это бывает не всегда. Плюс время потраченное на разбирательства явно можно использовать более эффективно.
Второй пример, в компании "Рога и копыта" было решено все даты в хранилище хранить в UTC, это было зафиксировано в соглашении "Обработка часовых поясов". По прошествии лет, после некоторой ротации сотрудников об этом регламенте было забыто. И новый аналитик реализует загрузку данных в хранилище в местном времени, затем на основе старых и новых данных строятся аналитические отчёты. О каком качестве полученной информации мы можем говорить?
Конечно, проект — живой организм и в реальности часто получается так, что соглашения изменились, но исправились только в одном месте (или вообще нет), затем пришёл новый сотрудник, который не смог разобраться где правда, и решил мести новой метлой. Но в будущем такой подход приведёт к потере доверия к данным, что в свою очередь сделает хранилище малопригодным для принятия важных бизнес-решений.
Что делать? Ревью, ревью и ещё раз ревью. Как самостоятельные, так и проводимые другими аналитиками.
Второй момент — поддержание документации (как минимум основных соглашений) в актуальном и консистентном состоянии. Да, это требует усилий, времени и внимания, но они окупятся в будущем.
Важно подчеркнуть, что даже наличие качественной документации не гарантирует отсутствия тех или иных ошибок. Если документация слишком объемная, сложная для понимания или спрятана в недрах проекта так, что о ней никто не знает, то толку от неё будет мало🥂
#документация
Продолжим говорить о качествах документации. До этого мы рассмотрели краткость и полноту, сегодня поговорим о непротиворечивости.
ТЗ и Соглашения не должны противоречить ни другим требованиям внутри проекта, ни самим себе. Если в начале документа мы говорим "сделай так", а в конце "сделай эдак", или в одном документе указываем что поле содержит данные Х (например, дату возврата товара), а в другом это же поле содержит данные У (н-р, дату возврата денег клиенту) — ничего хорошего от данных мы в итоге не получим.
Ещё один простой пример: в ТЗ указано время обновления витрины раз в сутки, в jira требование — "обновление раз в 15 минут", какой результат ожидать от инженера? Будет круто, если он придёт за уточнением, но это бывает не всегда. Плюс время потраченное на разбирательства явно можно использовать более эффективно.
Второй пример, в компании "Рога и копыта" было решено все даты в хранилище хранить в UTC, это было зафиксировано в соглашении "Обработка часовых поясов". По прошествии лет, после некоторой ротации сотрудников об этом регламенте было забыто. И новый аналитик реализует загрузку данных в хранилище в местном времени, затем на основе старых и новых данных строятся аналитические отчёты. О каком качестве полученной информации мы можем говорить?
Конечно, проект — живой организм и в реальности часто получается так, что соглашения изменились, но исправились только в одном месте (или вообще нет), затем пришёл новый сотрудник, который не смог разобраться где правда, и решил мести новой метлой. Но в будущем такой подход приведёт к потере доверия к данным, что в свою очередь сделает хранилище малопригодным для принятия важных бизнес-решений.
Что делать? Ревью, ревью и ещё раз ревью. Как самостоятельные, так и проводимые другими аналитиками.
Второй момент — поддержание документации (как минимум основных соглашений) в актуальном и консистентном состоянии. Да, это требует усилий, времени и внимания, но они окупятся в будущем.
Важно подчеркнуть, что даже наличие качественной документации не гарантирует отсутствия тех или иных ошибок. Если документация слишком объемная, сложная для понимания или спрятана в недрах проекта так, что о ней никто не знает, то толку от неё будет мало
#документация
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1