Привет! ☀️
Меня зовут Юля, и я маленький системный аналитик в мире больших данных.
Здесь я делюсь своими практическими советами и наблюдениями по системному анализу и Big Data, основанными на личном опыте.
Мои статьи не претендуют на истину и нацелены в первую очередь на систематизацию моих знаний (поэтому и публикуемая здесь информация будет крутиться около моего стека).
Буду рада любому фидбеку, комментариям или ссылкам на интересную информацию.
Подписывайтесь и улучшайте свои знания вместе со мной!
Меня зовут Юля, и я маленький системный аналитик в мире больших данных.
Здесь я делюсь своими практическими советами и наблюдениями по системному анализу и Big Data, основанными на личном опыте.
Мои статьи не претендуют на истину и нацелены в первую очередь на систематизацию моих знаний (поэтому и публикуемая здесь информация будет крутиться около моего стека).
Буду рада любому фидбеку, комментариям или ссылкам на интересную информацию.
Подписывайтесь и улучшайте свои знания вместе со мной!
❤3
Системный аналитик DWH — кто это? Как объяснить так, чтобы поняла даже бабушка?
На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт бизнесу возможность принимать основанные на данных, то есть имеющие под собой опору, решения.
Получая от бизнеса задачу, системный аналитик погружается в пучину информационных потоков, изучает имеющиеся, ищет новые и подключает их к хранилищу данных (что такое хранилище обсудим чуть позже). В процессе работы активно взаимодействует не только с бизнесом, но и с архитекторами, дата инженерами, девопсами и ещё огромным количеством людей. Он легко находит общий язык с каждым.
Ежедневно мир обрастает петабайтами новой информации (полезной и не очень). Системный аналитик помогает не сойти с ума и не даёт заблудиться в озёрах данных. Даёт возможность найти нужное и использовать найденное максимально эффективно, превращая качественные данные в основу для принятия бизнес-решений.
#системный_анализ
На мой взгляд, это волшебник, который превращает хаос в нечто упорядоченное и понятное. Уменьшает энтропию в бесконечных потоках информации внутри компании и не только, даёт бизнесу возможность принимать основанные на данных, то есть имеющие под собой опору, решения.
Получая от бизнеса задачу, системный аналитик погружается в пучину информационных потоков, изучает имеющиеся, ищет новые и подключает их к хранилищу данных (что такое хранилище обсудим чуть позже). В процессе работы активно взаимодействует не только с бизнесом, но и с архитекторами, дата инженерами, девопсами и ещё огромным количеством людей. Он легко находит общий язык с каждым.
Ежедневно мир обрастает петабайтами новой информации (полезной и не очень). Системный аналитик помогает не сойти с ума и не даёт заблудиться в озёрах данных. Даёт возможность найти нужное и использовать найденное максимально эффективно, превращая качественные данные в основу для принятия бизнес-решений.
#системный_анализ
Насколько большая эта ваша Big data?
”Размер” больших данных — постоянно меняющаяся величина, растущая нелинейно. По прогнозам к 2025 году объем собираемых, генерируемых, копируемых и потребляемых данных достигнет 180 зеттабайт. Предполагаю, исходя из того, что исследование проводилось в 2020-2021 годах, реальные цифры будут выше.
Если же говорить в рамках одной компании, то сегодня это триллионы и квадриллионы строк данных. Информации создаётся столько, что при недостаточно развитой культуре работе с данными (чуть позже ещё затронем тему Data Governance) компании просто не успевают обрабатывать и оперативно реагировать и принимать решения на их основе. В это же время, у других Big Data помогает бизнесу становиться эффективнее и своевременно трансформироваться.
Информация — это безграничная сила в 21 веке. Важно уметь эту силу использовать и применять во благо, а не только рисовать красивые графики в отчётах.
#dwh
”Размер” больших данных — постоянно меняющаяся величина, растущая нелинейно. По прогнозам к 2025 году объем собираемых, генерируемых, копируемых и потребляемых данных достигнет 180 зеттабайт. Предполагаю, исходя из того, что исследование проводилось в 2020-2021 годах, реальные цифры будут выше.
Если же говорить в рамках одной компании, то сегодня это триллионы и квадриллионы строк данных. Информации создаётся столько, что при недостаточно развитой культуре работе с данными (чуть позже ещё затронем тему Data Governance) компании просто не успевают обрабатывать и оперативно реагировать и принимать решения на их основе. В это же время, у других Big Data помогает бизнесу становиться эффективнее и своевременно трансформироваться.
Информация — это безграничная сила в 21 веке. Важно уметь эту силу использовать и применять во благо, а не только рисовать красивые графики в отчётах.
#dwh
🔥1
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
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
Уильям Инмон объясняет, что такое DWH, на примере 4 ключевых характеристик этой системы:
— Предметно-ориентированность. DWH следуют отраслевой логике, и оперирует данными, относящимися только к темам, представляющим интерес для компании.
— Интегрированность. Хранилище содержит информацию из различных источников, поэтому необходимо позаботиться о согласованности между ними.
— Привязка ко времени. DWH служит своего рода историческим архивом. Поэтому все изменения в информации, касающиеся каждого отдельного элемента, записываются, создавая новые экземпляры без перезаписи старых данных.
— Неизменяемость. Доступ к хранимой информации осуществляется "только для чтения".
Стоит отметить, что не всё из описанного выше является универсальным решением для любого DWH. В противовес Биллу Инмону ставится подход Ральфа Кимбалла. Подробнее о каждом из них буду рассказывать далее.
#dwh
Коротко о ClickHouse:
— OLAP-СУБД
— Колоночное хранение
— Эффективное сжатие данных
— Многопоточная, распределённая, специализированные векторные алгоритмы
— Высокая производительность
— Горизонтальное масштабирование
— Обновление данных большими батчами
— Время обработки 10 строк примерно такое же, как 10 000 строк
— SQL с особенностями
— Отсутствие транзакций
— Не любит джойны
— Ограниченность оконных функций
#clickhouse
— OLAP-СУБД
— Колоночное хранение
— Эффективное сжатие данных
— Многопоточная, распределённая, специализированные векторные алгоритмы
— Высокая производительность
— Горизонтальное масштабирование
— Обновление данных большими батчами
— Время обработки 10 строк примерно такое же, как 10 000 строк
— SQL с особенностями
— Отсутствие транзакций
— Не любит джойны
— Ограниченность оконных функций
#clickhouse
ACID: atomicity, consistency, isolation and durability
Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так как все дата аналитики или инженеры будут ежедневно сталкиваться с этим в работе.
А — Атомарность. Гарантирует, что в рамках транзакции будут выполнены либо все запросы, либо ни одного.
С — Согласованность. Отвечает за то, что в рамках транзакции фиксируются только допустимые результаты.
И — Изолированность. Отвечает за то, что при одновременном выполнении нескольких транзакций, они не должны оказывать влияния друг на друга.
У — Устойчивость. Гарантирует, что если транзакция будет выполнена, то её результаты уже не отменит никакой сбой системы (выключенный сервер, сетевой сбой и так далее).
Хочу отметить, что свойства ACID спроектированы для transaction-ориентированных баз данных.
#sql #acid
Звучит как заклинание, но на самом деле это важнейший набор требований к работе с данными, гарантирующий надёжность транзакций.
Рассмотрим ACID обзорно, а в последствии раскроем каждое из понятий, так как все дата аналитики или инженеры будут ежедневно сталкиваться с этим в работе.
А — Атомарность. Гарантирует, что в рамках транзакции будут выполнены либо все запросы, либо ни одного.
С — Согласованность. Отвечает за то, что в рамках транзакции фиксируются только допустимые результаты.
И — Изолированность. Отвечает за то, что при одновременном выполнении нескольких транзакций, они не должны оказывать влияния друг на друга.
У — Устойчивость. Гарантирует, что если транзакция будет выполнена, то её результаты уже не отменит никакой сбой системы (выключенный сервер, сетевой сбой и так далее).
Хочу отметить, что свойства ACID спроектированы для transaction-ориентированных баз данных.
#sql #acid
🔥1
Коротко о Greenplum:
— MPP-СУБД на основе PostgreSQL
— Быстро обрабатывает тяжелые аналитические запросы на больших данных
— Параллельная обработка данных
— Концепция Shared-nothing (каждый узел является независимым, самодостаточным и не существует единой точки отказа)
— Линейная масштабируемость
— ACID
— Отказоустойчивость
— Полиморфное хранение данных
— Open source
— Не для OLTP нагрузки
#greenplum
— MPP-СУБД на основе PostgreSQL
— Быстро обрабатывает тяжелые аналитические запросы на больших данных
— Параллельная обработка данных
— Концепция Shared-nothing (каждый узел является независимым, самодостаточным и не существует единой точки отказа)
— Линейная масштабируемость
— ACID
— Отказоустойчивость
— Полиморфное хранение данных
— Open source
— Не для OLTP нагрузки
#greenplum
👍1
Почему UUID лучше, чем автоинкрементные идентификаторы. И лучше ли?
На хабре вышла интересная статья, почему UUID (универсальный уникальный идентификатор) является лучшим выбором в качестве идентификаторах в базах данных.
Автор описывает следующие плюсы:
1. Глобальная уникальность, в отличие от автоинкремента с уникальностью в рамках 1 таблицы.
2. Децентрализация — UUID могут генерироваться независимо друг от друга без необходимости координации.
3. Безопасность за счёт отсутствия предсказуемости.
4. Отсутствие необходимости в повторном обращении к базе данных для получения следующего доступного значения.
5. UUID в распределённых системах (благодаря уникальности) позволяет избежать риска возникновения коллизий при объединении и синхронизации данных.
6. UUID могут генерироваться в автономном режиме без связи с сервером.
7. UUID не привязаны к конкретной технологии баз данных и могут использоваться в различных системах баз данных.
Прочитать всю статью можно по ссылке: https://habr.com/ru/articles/760272/
А я отдельно рекомендую заглянуть в комментарии, где обсуждаются также недостатки UUID. В частности возможное дублирование, низкая скорость работы, стоимость хранения, индексы плохо работают и т.д.). Отдельно хочется отметить ситуацию с JOIN. Стоит помнить, что джойн по полям с целыми числами сильно эффективнее, чем джойн по строкам.
Так что, как и всегда. Сначала заходим с постановки задачи, понимания что и зачем мы делаем и как будем использовать, а потом уже выбираем лучшие решения.
#проектирование
На хабре вышла интересная статья, почему UUID (универсальный уникальный идентификатор) является лучшим выбором в качестве идентификаторах в базах данных.
Автор описывает следующие плюсы:
1. Глобальная уникальность, в отличие от автоинкремента с уникальностью в рамках 1 таблицы.
2. Децентрализация — UUID могут генерироваться независимо друг от друга без необходимости координации.
3. Безопасность за счёт отсутствия предсказуемости.
4. Отсутствие необходимости в повторном обращении к базе данных для получения следующего доступного значения.
5. UUID в распределённых системах (благодаря уникальности) позволяет избежать риска возникновения коллизий при объединении и синхронизации данных.
6. UUID могут генерироваться в автономном режиме без связи с сервером.
7. UUID не привязаны к конкретной технологии баз данных и могут использоваться в различных системах баз данных.
Прочитать всю статью можно по ссылке: https://habr.com/ru/articles/760272/
А я отдельно рекомендую заглянуть в комментарии, где обсуждаются также недостатки UUID. В частности возможное дублирование, низкая скорость работы, стоимость хранения, индексы плохо работают и т.д.). Отдельно хочется отметить ситуацию с JOIN. Стоит помнить, что джойн по полям с целыми числами сильно эффективнее, чем джойн по строкам.
Так что, как и всегда. Сначала заходим с постановки задачи, понимания что и зачем мы делаем и как будем использовать, а потом уже выбираем лучшие решения.
#проектирование
Хабр
7 аргументов почему UUID лучше, чем автоинкрементные идентификаторы
В мире баз данных идентификаторы имеют решающее значение для уникальной идентификации записей. Традиционно многие разработчики предпочитали автоматически увеличивающиеся целочисленные идентификаторы....
👍1
Шардирование данных в ClickHouse
Шардирование — стратегия горизонтального масштабирования кластера (набора серверов), при которой части одной базы данных размещаются (и обрабатываются) параллельно на разных узлах кластера. Узел — 1 сервер кластера. Каждый сервер хранит свой набор данных.
Для шардирования используется движок Distributed. Он не хранит данные самостоятельно, а позволяет обрабатывать запросы распределённо, на нескольких серверах. Чтение автоматически распараллеливается.
Данные между шардами распределяются либо по какому-то ключу, например по идентификатору пользователя, либо равномерно. В качестве ключа шардирования рекомендуется брать значение хеш-функции от поля (not-Nullable) в таблице, которое обеспечит достаточно ровное распределение наборов данных по разным шардам в кластере. Либо же поле должно быть наполненно уникальными INTEGER значениями. Это важно для равномерного распределения данных между шардами.
Каждая шардированная таблица в ClickHouse состоит из:
— распределенной таблицы на движке Distributed, которая маршрутизирует запросы;
— нижележащих таблиц с данными, расположенных на нескольких шардах кластера.
С шардированной таблицей можно работать с данными, обращаясь:
— к нижележащим таблицам напрямую: вставлять данные на нужные шарды или читать данные, содержащиеся в таблице на конкретном шарде (сложнее, но эффективнее);
— через распределенную таблицу, которая будет представлять данные всех распределнных таблиц в виде единой таблицы.
Подробнее про создание Distributed-table можно прочитать в доке: https://clickhouse.com/docs/en/engines/table-engines/special/distributed
#clickhouse
Шардирование — стратегия горизонтального масштабирования кластера (набора серверов), при которой части одной базы данных размещаются (и обрабатываются) параллельно на разных узлах кластера. Узел — 1 сервер кластера. Каждый сервер хранит свой набор данных.
Для шардирования используется движок Distributed. Он не хранит данные самостоятельно, а позволяет обрабатывать запросы распределённо, на нескольких серверах. Чтение автоматически распараллеливается.
Данные между шардами распределяются либо по какому-то ключу, например по идентификатору пользователя, либо равномерно. В качестве ключа шардирования рекомендуется брать значение хеш-функции от поля (not-Nullable) в таблице, которое обеспечит достаточно ровное распределение наборов данных по разным шардам в кластере. Либо же поле должно быть наполненно уникальными INTEGER значениями. Это важно для равномерного распределения данных между шардами.
Каждая шардированная таблица в ClickHouse состоит из:
— распределенной таблицы на движке Distributed, которая маршрутизирует запросы;
— нижележащих таблиц с данными, расположенных на нескольких шардах кластера.
С шардированной таблицей можно работать с данными, обращаясь:
— к нижележащим таблицам напрямую: вставлять данные на нужные шарды или читать данные, содержащиеся в таблице на конкретном шарде (сложнее, но эффективнее);
— через распределенную таблицу, которая будет представлять данные всех распределнных таблиц в виде единой таблицы.
Подробнее про создание Distributed-table можно прочитать в доке: https://clickhouse.com/docs/en/engines/table-engines/special/distributed
#clickhouse