Складское хозяйство 101: Практическое руководство для начинающих

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

Это не должно вызывать удивления.

Специалисты по обработке данных имеют разный опыт работы, например, математики, статистики, психологии и программирования. Многие, вероятно, не вникали бы в тонкости систем баз данных во время учебы в университете.

В том числе и я, математик, ставший специалистом по данным.

Я изучал науку о данных на онлайн-курсах — необходимое условие для получения работы наука о данных, я полагаю, — но основы баз данных я изучил только на работе.

Кроме того, сейчас в моде озера данных, кому вообще нужны склады, верно? (Это шутка!)

Я написал эту статью как быстрый и грязный ускоренный курс для всех, кто приступает к работе в области аналитики, не имея особых знаний о хранилищах данных и моделировании данных.

Мы рассмотрим три темы:

  • Как выглядит рабочий процесс корпоративного хранилища данных;
  • Чего достигает нормализация базы данных;
  • Дегустационная проверка баз данных NoSQL.

Давайте погрузимся!

Новичок в Medium? Присоединяйтесь здесь и получите неограниченный доступ к лучшим статьям в Интернете.

1. Рабочий процесс хранилища данных

Конкретные детали могут различаться в зависимости от решения, но общая архитектура для корпоративной аналитики выглядит следующим образом:

  1. Данные хранятся в озере данных.
  2. Данные загружаются в хранилище данных.
  3. Создается модель данных.
  4. Аналитики потребляют данные.

Давайте посмотрим, как это выглядит более подробно.

Аналитическая обработка данных

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

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

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

Поскольку озера данных обычно относятся к области больших данных, что влечет за собой распределенные вычисления и хранение с помощью таких платформ, как Apache Hadoop, обработка ETL выполняется инженерами данных, которые настроили задания Hive или Spark для параллельной обработки больших объемов данных с использованием многоузловых кластеров. Эти конвейеры включают как пакетную обработку статических данных, так и обработку потоковых данных в реальном времени.

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

Ознакомьтесь с моей объяснительной статьей о всем ландшафте корпоративных данных, от хранилищ до озер данных и сетки данных.

Новичок в изучении данных и создании моделей машинного обучения? Ознакомьтесь с моими пошаговыми руководствами по науке о данных здесь, здесь и здесь.

Хранилища данных, таблицы, схемы и нормализация

Хорошо, идем дальше. Время обогатить наши данные, сидя в озере.

Сначала данные копируются в хранилище данных, оптимизированное для операций чтения.

Хранилище данных – это реляционная база данных, в которой данные хранятся в схеме, оптимизированной для анализа данных, а не для транзакционных рабочих нагрузок. Хранилища по своей конструкции оптимизированы для операций чтения — в первую очередь запросов для поддержки бизнес-аналитики (BI), которая включает в себя создание отчетов, информационных панелей и визуализаций, которые под крылом хороших рассказчиков данных» могут сообщать о ценности и влиять на принятие решений.

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

Именно это позволяет обогащать данные за счет объединения таблиц.

Например, на первичный ключ клиента можно ссылаться в записи заказа на продажу, чтобы указать, какой клиент разместил этот заказ:

-- Joining two tables using SQL
SELECT * FROM Customer C
JOIN Orders O
ON C.ID = O.Customer

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

Подробнее о нормализации позже.

Таблицы управляются и запрашиваются с помощью языка структурированных запросов (SQL), который основан на стандарте ANSI, поэтому он одинаков во многих системах баз данных. Выше мы видели простой запрос, соединяющий две таблицы.

Давайте поговорим подробнее о схемах базы данных.

В то время как в озерах данных используется подход Schema-on-Read, который не требует определения предварительной схемы, в хранилищах используется более ресурсоемкая, но более организованная парадигма Schema-on-Write. где схемы таблиц должны быть определены заранее.

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

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

Затем они связаны с одной или несколькими таблицами измерений, представляющими объекты, по которым вы хотите агрегировать эти числовые показатели, например product или клиент.

Каждый объект представлен строкой с уникальным значением ключа.

Остальные столбцы представляют атрибуты объекта — например, у продуктов есть названия и категории, а у клиентов — адреса и города. В большинстве аналитических моделей обычно используется измерение Время, чтобы можно было агрегировать числовые показатели, связанные с событиями во времени.

Итак, вот как все это выглядит:

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

Чтобы быть более конкретным:

Каждая строка в таблице фактов представляет собой записанное событие с прикрепленными числовыми показателями. Здесь таблица Продажи в нашей звездообразной схеме представляет транзакции продаж для отдельных товаров и включает числовые значения проданного количества и дохода.

Продажи можно агрегировать по параметрам клиент, продукт, магазин и время, что позволяет легко находить итоговую сумму за месяц. например, доход от продаж по продуктам для каждого магазина.

Именно здесь могут быть раскрыты идеи.

В итоге:

Соединение таблиц с помощью ключей обогащает данные, а агрегирование позволяет получить ценную информацию.

-- Find total sales for each customer and product in 2022
SELECT c.name, p.name, s.sum(s.Revenue) FROM Sales s
JOIN Customer s
ON c.Key = s.CustomerKey
JOIN Product p
ON p.Key = s.ProductKey
JOIN Time t
ON t.Key = s.TimeKey
GROUP BY 1, 2
WHERE t.Year = '2023'

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

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

См. мой Учебник по PowerBI на реальном примере моделирования данных.

Аналитическая модель данных

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

Они называются моделями онлайн-аналитической обработки (OLAP) или кубами.

Агрегированные данные представлены по измерениям на разных уровнях или в иерархиях, что позволяет вам детализировать вверх/вниз для просмотра агрегированных данных на нескольких иерархических уровнях — например, чтобы найти общий объем продаж по регионам, по городам или по индивидуальному адресу.

Поскольку данные OLAP предварительно агрегированы, запросы для возврата содержащихся в них сводок могут выполняться быстро.

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

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

Круто правда?!

Важно! Хотя мы обычно называем аналитическую модель кубом, трех измерений может быть больше (или меньше) — нам просто не просто визуализировать больше трех!

Готов к употреблению!

Аналитики данных используют данные из этих аналитических моделей (этап 3) — или непосредственно из хранилищ данных (этап 2) — или даже из «сырых» наборов данных, хранящихся в озере данных (этап 1), для изучения данных. и создавайте информационные панели, отчеты и визуализации для получения информации.

Неспециалисты в организации могут выполнять самостоятельный анализ данных и составлять отчеты по ним, особенно если они уже были визуализированы в инструменте бизнес-аналитики, таком как PowerBI или Tableau.

Эти визуализации, основанные на хороших аналитических моделях данных, показывают сравнения, тенденции и ключевые показатели эффективности (KPI) и могут принимать форму диаграмм, графиков, отчетов, которые часто распространяются в документах и ​​презентациях PowerPoint. », веб-панели мониторинга и интерактивные среды (например, PowerBI и Tableau), где последующие пользователи — даже руководители высшего звена — могут легко просматривать данные визуально и принимать решения на основе данных.

2. Нормализация базы данных

Давайте теперь углубимся в некоторые детали нормализации базы данных.

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

Цель нормализации — создать схему базы данных, которая будет более эффективной, гибкой и менее подверженной аномалиям данных. Мы начинаем с набора таблиц и часто заканчиваем большим набором «более чистых» таблиц.

Существует несколько уровней нормализации, каждый из которых имеет набор правил, которым необходимо следовать. Наиболее распространенными являются:

Первая нормальная форма (1NF)

Каждый столбец таблицы должен содержать атомарные (неделимые) значения. То есть ни один столбец не должен содержать список или набор значений.

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

Вторая нормальная форма (2NF)

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

Продолжая пример с заказом клиента, предположим, что у вас есть новый столбец для даты размещения заказа. Если эта дата зависит только от имени клиента, вы можете получить дубликаты в таблице. Во 2NF вы бы разбили таблицу на две части: одну для информации о клиенте, а другую для информации о заказе. Это гарантирует, что каждая часть информации сохраняется только один раз, и предотвращает частичные зависимости.

Третья нормальная форма (3NF)

Таблица находится в 3НФ, если она находится во 2НФ и все неключевые столбцы независимы друг от друга. Другими словами, не должно быть транзитивных зависимостей, когда неключевой столбец зависит от другого неключевого столбца.

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

Помимо 3NF существуют дополнительные уровни нормализации, но на практике они используются реже.

3. Нереляционные базы данных

Кроме того, давайте быстро рассмотрим не-реляционные базы данных.

Это системы управления данными, которые не применяют к данным реляционную схему. Нереляционные базы данных часто называют базами данных NoSQL, хотя некоторые из них поддерживают вариант языка SQL.

Обычно используются четыре основных типа нереляционных баз данных.

  • База данных "ключ-значение", в которой каждая запись состоит из уникального ключа и связанного значения, которое может быть в любом формате.
  • Базы данных документов, представляющие собой особую форму базы данных "ключ-значение", в которой значением является документ JSON, который система оптимизирована для синтаксического анализа и запроса.
  • Базы данных семейств столбцов, в которых хранятся табличные данные, состоящие из строк и столбцов, но вы можете разделить столбцы на группы, известные как семейства столбцов. Каждое семейство столбцов содержит набор столбцов, которые логически связаны друг с другом.
  • Графические базы данных, в которых объекты хранятся в виде узлов со ссылками для определения отношений между ними.

4. Резюме

Аналитические модели позволяют структурировать данные для проведения анализа.

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

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

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

Для дальнейшего повышения эффективности данные могут быть предварительно объединены в модель OLAP или куб. Интуитивно эти модели формируют многомерные структуры, напоминающие куб, в случае, если вы агрегируете ровно по 3 измерениям, например доход от продаж по клиенту, продукт и время.

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

Посредством убедительного повествования на основе данных аналитики и бизнес-профессионалы затем представляют свои выводы лицам, принимающим решения, которые могут действовать на основе данных.

Дайте мне знать, если вы нашли эту статью полезной!

Найдите меня на Linkedin, Twitter и YouTube.

Мои популярные статьи об искусственном интеллекте и науке о данных

  • AI Revolution: стремительное введение в машинное обучение — здесь
  • ChatGPT и GPT-4: как OpenAI выиграл войну NLU — здесь
  • Искусство генеративного искусственного интеллекта: объяснение промежуточного пути и стабильного распространения — здесь
  • Сила сторителлинга на основе данных — продавайте истории, а не данные — здесь
  • Хранилища данных, озера данных и сетка данных — здесь
  • Power BI — от моделирования данных до потрясающих отчетов — здесь
  • Хранилища данных и моделирование данных — краткий курс — здесь
  • Машинное обучение против механического моделирования — здесь
  • Объяснение популярных показателей производительности машинного обучения — здесь
  • Будущее работы: безопасна ли ваша карьера в эпоху ИИ — здесь
  • Помимо ChatGPT: поиск настоящей интеллектуальной машины — здесь
  • Регрессия: прогнозирование цен на жилье с помощью Python — здесь
  • Классификация: прогнозирование оттока сотрудников с помощью Python — здесь
  • Блокноты Python Jupyter против Dataiku DSS — здесь
  • Как использовать облачные вычисления для вашего бизнеса — здесь

Неограниченный доступ к среде

Присоединяйтесь к Medium здесь и наслаждайтесь неограниченным доступом к лучшим статьям в Интернете.

Вы будете напрямую поддерживать меня и других ведущих писателей. Ваше здоровье!