Привет! ☀️

Меня зовут Юля, и я маленький системный аналитик в мире больших данных.

Здесь я делюсь своими практическими советами и наблюдениями по системному анализу и Big Data, основанными на личном опыте.

Мои статьи не претендуют на истину и нацелены в первую очередь на систематизацию моих знаний (поэтому и публикуемая здесь информация будет крутиться около моего стека).

Буду рада любому фидбеку, комментариям или ссылкам на интересную информацию.

Подписывайтесь и улучшайте свои знания вместе со мной!

Хэштеги для быстрого поиска по разделам:

#дайджест

#clickhouse
#data_governance
#databasedesign
#dwh
#etl
#greenplum
#null
#snowflake
#soft_skills
#sql
#документация
#оконные_функции
#проектирование
#системный_анализ

Системный аналитик DWH — кто это? Как объяснить так, чтобы поняла даже бабушка?

На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт бизнесу возможность принимать основанные на данных, то есть имеющие под собой опору, решения.

Получая от бизнеса задачу, системный аналитик погружается в пучину информационных потоков, изучает имеющиеся, ищет новые и подключает их к хранилищу данных (что такое хранилище обсудим чуть позже). В процессе работы активно взаимодействует не только с бизнесом, но и с архитекторами, дата инженерами, девопсами и ещё огромным количеством людей. Он легко находит общий язык с каждым.

Ежедневно мир обрастает петабайтами новой информации (полезной и не очень). Системный аналитик помогает не сойти с ума и не даёт заблудиться в озёрах данных. Даёт возможность найти нужное и использовать найденное максимально эффективно, превращая качественные данные в основу для принятия бизнес-решений.

#системный_анализ

Насколько большая эта ваша Big data? 

”Размер” больших данных — постоянно меняющаяся величина, растущая нелинейно. По прогнозам к 2025 году объем собираемых, генерируемых, копируемых и потребляемых данных достигнет 180 зеттабайт. Предполагаю, исходя из того, что исследование проводилось в 2020-2021 годах, реальные цифры будут выше.

Если же говорить в рамках одной компании, то сегодня это триллионы и квадриллионы строк данных. Информации создаётся столько, что при недостаточно развитой культуре работе с данными (чуть позже ещё затронем тему Data Governance) компании просто не успевают обрабатывать и оперативно реагировать и принимать решения на их основе. В это же время, у других Big Data помогает бизнесу становиться эффективнее и своевременно трансформироваться.

Информация — это безграничная сила в 21 веке. Важно уметь эту силу использовать и применять во благо, а не только рисовать красивые графики в отчётах.

#dwh

NULL != NULL — это True?

NULL в базах данных означает “ничего”, отсутствие данных, вместо которых "неизвестно что". Казалось бы звучит просто, но в то же время коварное NULL постоянно хочет обвести вокруг пальца. Поэтому важно помнить об его особенностях.

NULL не равен ничему, в том числе другому NULL (как одна неизвестность может быть равна другой?). При этом и выражение NULL != NULL не будет истинным, так как нельзя сравнить неизвестность с неизвестностью.

Распространённая ошибка поиск по условию WHERE column_name = NULL. Результатом такого условия будет FALSE. Вместо этого для сравнения используется оператор IS NULL (или IS NOT NULL, если нужно найти все не NULL значения).

Ну и, конечно, не стоит забывать, что NULL ни в коем случае не эквивалентен 0. 

Во время работы с запросами к БД важно понимать логику работы с NULL, так как без этого результаты могут быть далеки от реальности. Другие особенности работы с NULL рассмотрим в следующих заметках.

#sql #null

Data Warehouse (DWH) — это система (здесь акцент на слове "система") хранения и анализа больших данных, которая поддерживает процессы принятия решений в компании. Для поддержания её работоспособности нужны серьёзные технические и человекческие ресурсы.

Уильям Инмон объясняет, что такое DWH, на примере 4 ключевых характеристик этой системы:

— Предметно-ориентированность. DWH следуют отраслевой логике, и оперирует данными, относящимися только к темам, представляющим интерес для компании. 
— Интегрированность. Хранилище содержит информацию из различных источников, поэтому необходимо позаботиться о согласованности между ними.
— Привязка ко времени. DWH служит своего рода историческим архивом. Поэтому все изменения в информации, касающиеся каждого отдельного элемента, записываются, создавая новые экземпляры без перезаписи старых данных.
— Неизменяемость. Доступ к хранимой информации осуществляется "только для чтения".

Стоит отметить, что не всё из описанного выше является универсальным решением для любого DWH. В противовес Биллу Инмону ставится подход Ральфа Кимбалла. Подробнее о каждом из них буду рассказывать далее.

#dwh

Коротко о ClickHouse:

— OLAP-СУБД
— Колоночное хранение
— Эффективное сжатие данных
— Многопоточная, распределённая, специализированные векторные алгоритмы
— Высокая производительность
— Горизонтальное масштабирование
— Обновление данных большими батчами
— Время обработки 10 строк примерно такое же, как 10 000 строк
— SQL с особенностями
— Отсутствие транзакций
— Не любит джойны
— Ограниченность оконных функций

#clickhouse

ACID: atomicity, consistency, isolation and durability

Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так как все дата аналитики или инженеры будут ежедневно сталкиваться с этим в работе.

А — Атомарность. Гарантирует, что в рамках транзакции будут выполнены либо все запросы, либо ни одного.
С — Согласованность. Отвечает за то, что в рамках транзакции фиксируются только допустимые результаты.
И — Изолированность. Отвечает за то, что при одновременном выполнении нескольких транзакций, они не должны оказывать влияния друг на друга.
У — Устойчивость. Гарантирует, что если транзакция будет выполнена, то её результаты уже не отменит никакой сбой системы (выключенный сервер, сетевой сбой и так далее).

Хочу отметить, что свойства ACID спроектированы для transaction-ориентированных баз данных.

#sql #acid

Коротко о Greenplum:

— MPP-СУБД на основе PostgreSQL
— Быстро обрабатывает тяжелые аналитические запросы на больших данных
— Параллельная обработка данных
— Концепция Shared-nothing (каждый узел является независимым, самодостаточным и не существует единой точки отказа)
— Линейная масштабируемость
— ACID
— Отказоустойчивость
— Полиморфное хранение данных
— Open source
— Не для OLTP нагрузки

#greenplum

Почему UUID лучше, чем автоинкрементные идентификаторы. И лучше ли?

На хабре вышла интересная статья, почему UUID (универсальный уникальный идентификатор) является лучшим выбором в качестве идентификаторах в базах данных.

Автор описывает следующие плюсы:
1. Глобальная уникальность, в отличие от автоинкремента с уникальностью в рамках 1 таблицы.
2. Децентрализация — UUID могут генерироваться независимо друг от друга без необходимости координации.
3. Безопасность за счёт отсутствия предсказуемости.
4. Отсутствие необходимости в повторном обращении к базе данных для получения следующего доступного значения.
5. UUID в распределённых системах (благодаря уникальности) позволяет избежать риска возникновения коллизий при объединении и синхронизации данных.
6. UUID могут генерироваться в автономном режиме без связи с сервером.
7. UUID не привязаны к конкретной технологии баз данных и могут использоваться в различных системах баз данных.

Прочитать всю статью можно по ссылке: https://habr.com/ru/articles/760272/

А я отдельно рекомендую заглянуть в комментарии, где обсуждаются также недостатки UUID. В частности возможное дублирование, низкая скорость работы, стоимость хранения, индексы плохо работают и т.д.). Отдельно хочется отметить ситуацию с JOIN. Стоит помнить, что джойн по полям с целыми числами сильно эффективнее, чем джойн по строкам.

Так что, как и всегда. Сначала заходим с постановки задачи, понимания что и зачем мы делаем и как будем использовать, а потом уже выбираем лучшие решения.

#проектирование

Шардирование данных в ClickHouse

Шардирование — стратегия горизонтального масштабирования кластера (набора серверов), при которой части одной базы данных размещаются (и обрабатываются) параллельно на разных узлах кластера. Узел — 1 сервер кластера. Каждый сервер хранит свой набор данных.

Для шардирования используется движок Distributed. Он не хранит данные самостоятельно, а позволяет обрабатывать запросы распределённо, на нескольких серверах. Чтение автоматически распараллеливается.

Данные между шардами распределяются либо по какому-то ключу, например по идентификатору пользователя, либо равномерно. В качестве ключа шардирования рекомендуется брать значение хеш-функции от поля (not-Nullable) в таблице, которое обеспечит достаточно ровное распределение наборов данных по разным шардам в кластере. Либо же поле должно быть наполненно уникальными INTEGER значениями. Это важно для равномерного распределения данных между шардами.

Каждая шардированная таблица в ClickHouse состоит из:
— распределенной таблицы на движке Distributed, которая маршрутизирует запросы;
— нижележащих таблиц с данными, расположенных на нескольких шардах кластера.

С шардированной таблицей можно работать с данными, обращаясь:
— к нижележащим таблицам напрямую: вставлять данные на нужные шарды или читать данные, содержащиеся в таблице на конкретном шарде (сложнее, но эффективнее);
— через распределенную таблицу, которая будет представлять данные всех распределнных таблиц в виде единой таблицы.

Подробнее про создание Distributed-table можно прочитать в доке: https://clickhouse.com/docs/en/engines/table-engines/special/distributed

#clickhouse

Хранение данных в таблицах в Greenplum

— heap storage (без кластеризованных индексов) – обеспечивает только строковое хранение данных. Подходит для малого объёма данных (например, для справочников) и частого обновления операциями INSERT, UPDATE и DELETE. Тип хранения по умолчанию.

— append-optimized storage (AOT, оптимизированное для добавления) – обеспечивают строковое и колоночное хранение. Подходит для аналитической обработки больших массивов данных, когда данные загружаются большими пакетами и над ними производятся в основном операции чтения. Колоночное хранение значительно снижает затраты на чтение и запись, а также колоночные таблицы лучше поддаются сжатию. Для больших данных рекомендуется использовать колоночное хранение с сжатием 1-3 уровня.

Для AOT таблиц доступна строковая (row) и колоночная (column) ориентация данных.

Пример создания AOT-таблицы с колоночной ориентацией:

create table [schema_name].<table_name> 
             (<columns_list>)
with (appendoptimized = true,
      orientation = column);

#greenplum

Atomicity — Атомарность

Выше мы разговаривали о требованиях ACID (хэштег #acid). Рассмотрим каждое требование подробнее.

Атомарность гарантирует, что каждая транзакция выполнится целиком или не будет выполнена вовсе. Третьего не дано. Если в любой операции транзакции случился сбой, то все операции транзакции будут отменены и данные вернутся в исходное состояние.

Само понятие транзакции включает себя это требование. Транзакция — неделимый набор операций.

Простейший пример транзакции:

BEGIN;
UPDATE accounts SET balance = balance - 5000.00
       WHERE name = 'Olga';
UPDATE accounts SET balance = balance + 5000.00
       WHERE name = 'Bob';
COMMIT;
ROLLBACK;

Ольга перевела 5000 у.е. Ивану, в результате со счёта Ольги списались 5000, а Ивану зачислились 5000. Если, к примеру, во время зачисления средств на счёт Ивана произошёл сбой (н-р, счёт Ивана не был найден), то и списание средств со счёта Ольги не произошло. Аналогично сработает, если на счету у Ольги не окажется нужной суммы для перевода, то и Ивану тогда ничего не зачислится.

Чтобы обеспечить атомарность, СУБД используют механизмы логирования и отката. Логирование позволяет записывать все изменения, внесенные в базу данных, в журнал транзакций. В случае сбоя или ошибок СУБД использует журнал для отмены изменений, внесенных этой транзакцией.

#sql #acid

ALTER и UPDATE в SQL. В чём разница?

Когда только начинаешь свой путь в SQL то легко запутаться во всех этих многочисленных командах. Но, на самом деле всё не так сложно, как может показаться.

ALTER — для манипуляции с объектами базы данных (таблицами, колонками, партициями и т.д.).

UPDATE — для работы с данными.

Используя ALTER мы можем поменять имя таблицы, добавить или удалить столбец, изменить тип данных в столбце, добавить/удалить ограничения или изменить ключи, и т.д. Например, в таблицу orders нужно добавить столбец processed_dttm, содержащий время добавления записи в БД.

ALTER TABLE orders
ADD COLUMN processed_dttm TIMESTAMPZ;

Применяя UPDATE мы меняем данные в таблице. Например, можем изменить статусы всех заказов, не оплаченных в течение 3 дней после оформления:

UPDATE orders
SET status_id=5
WHERE status=1 AND created < NOW() - INTERVAL '3 days' ;

#sql

Работа системного аналитика заключается не только в понимании данных и архитектуры хранилища или умении писать и оптимизировать sql-запросы. Важную часть работы занимает общение со всеми сторонами процессов и написание грамотной документации. 

Техническое задание (ТЗ) — важнейший документ в работе системного аналитика. В реальном мире заказчики редко приходят с чётким пониманием что и как они хотят получить, часто их требования звучат как "найди чёрную кошку в чёрной комнате", и будет хорошо, если известно, что нужно найти именно кошку 😄 

Поэтому очень важно ещё на старте выяснить, описать, зафиксировать и согласовать все пожелания заказчика. Это ответственный момент в работе, так как некорректно собранные требования приведут к потери времени команды, срыву сроков и сорванным планам заказчика, в лучшем случае. Для команды же плюсом будет чёткое понимание задачи и возможность избежать ситуаций "мы так не договаривались".

Согласованная документация — всегда win-win история.

Поэтому я всегда топлю за структурированную, понятную всем сторонам, однозначную, согласованную и непротиворечивую, полную документацию. Да, этот процесс занимает время и иногда кажется, что он бессмысленен ("тут задача на пару часов, просто напишу инженеру в личку"). Но в любых процессах всплывают подводные камни и всегда лучше "подстелить соломку". Плюс в большой компании в любой момент времени может уйти один из сотрудников, участвующих в процессе. И вот уже не сыскать концов почему именно так был реализован тот или иной процесс, для какой бизнес-цели и кто является заинтересованной стороной.

Хорошая документация — не просто обязанность, а инвестиция в будущее проектов.

#документация

Распределение (distribution) в Greenplum

В GP данные физически хранятся на разных сегментах, поэтому указывать распределение при создании таблицы обязательно.

Правила выбора хорошего ключа дистрибьюции
— Поле не должно иметь null-значений.
— Тип поля – integer.
— Не использовать в качестве ключа поля с типами: date, timestamp, boolean, decimal, большие строки.
— Значения поля должны быть уникальными.
— Поле чаще всего используется для соединения с большими таблицами.
— Максимум 2 поля, но лучше использовать 1.
— Поле не должно использоваться в качестве поля для партиционирования.
— Не нужно использовать поля, которые используются при фильтрации запросов в where, так как нагрузка при выполнении запроса будет распределена неравномерно.

Можно использовать случайное распределение, если не получается подобрать подходящие поля, но необходимо учитывать, что такое распределение хорошо работает только при вставке данных большими пакетами, так как GP распределяет данные по циклическому алгоритму, который запускается заново для каждой операции вставки, начиная с первого сегмента. Мелкие вставки приведут к неравномерному распределению данных по сегментам (перекосу).

#greenplum

Data Lakehouse

Это открытая архитектура, объединяющая лучшие стороны озер данных (unstructured data) и хранилищ данных (structured data). Эта концепция предлагает ускорение обработки данных, улучшение качества и гибкость анализа, а также упрощение инфраструктуры хранения данных.

Преимущества Data Lakehouse:
— Хранит все виды данных в одном месте.
— Интеграция данных различных типов упрощается.
— Работа с неструктурированными данными, такими как текст, аудио или видео, с использованием методов машинного обучения и нейронных сетей.
— Исходные данные сохраняются в оригинальном виде.
— Есть поддержка ACID-транзакций.
— Анализ данных можно проводить в любое время и повторять по мере необходимости.
— Одни и те же данные можно использовать для разных целей.
— Стоит меньше и проще масштабируется по сравнению с традиционными хранилищами.

Однако, есть и недостатки. Это достаточно новый и не обкатанный подход, который скорее всего содержит в себе множество подводных камней. Без структурной организации неструктурированные данные могут превратиться в “болото данных”, где поиск полезной информации будет затруднен.

В настоящее время гибридная архитектура LakeHouse находится на уровне концепции и формирования инструментария. 

#dwh

Зачем нам нужен ETL?

ETL (Extract, Transform, Load) — это наиболее распространенный подход к интеграции данных из различных источников в хранилище данных.

ETL:
— Позволяет объединить и стандартизировать данные из различных источников, чтобы иметь целостное представление о данных.
— Подготавливает данные к анализу.
— Улучшает производительность запросов, благодаря подготовке или агрегации, оптимизации данных.
— Повышает качество данных, благодаря дополнительным проверкам на корректность.
— Позволяет автоматизировать и планировать процессы загрузки данных для обеспечения актуальности, убирая ручную обработку.

ETL (и ELT, но об этом дальше) процессы играют ключевую роль в подготовке данных к хранению и использованию в хранилище.

#dwh #etl