Одни сведения удобно сравнивать по одинаковым полям, другие требуют чтения и интерпретации. Объясняем различие структуры на примере обращений покупателей.
Один вопрос, три разных источника
Представим условную службу поддержки магазина. У неё есть таблица покупок, карточки обращений и свободные сообщения клиентов. Руководитель хочет понять причины возвратов. Все три источника полезны, но работать с ними одинаковым способом неудобно. В таблице можно сравнивать заранее известные признаки. В письме причина может быть выражена несколькими фразами, с уточнениями и противоречиями.
Различие касается предсказуемости содержания. В объяснении AWS структурированные данные связываются с заранее заданной моделью, например таблицей с определёнными полями. Неструктурированные материалы не укладываются в такую модель столь же непосредственно. Это характеристика представления сведений для обработки, а не оценка их полезности или достоверности.
Структура заранее задаёт вопросы к записи
В нашей условной таблице покупок для каждой строки определены номер заказа, дата и сумма. Можно заранее договориться, какой смысл имеет каждый столбец и какие значения допустимы. Тогда общий вопрос о сумме покупок за месяц сводится к работе с известными признаками. Не приходится каждый раз угадывать, где в записи спрятана нужная дата.
Однако одинаковая форма ещё не гарантирует одинакового смысла. Один источник может показывать сумму до возврата, другой — после него. Поэтому рядом со структурой нужны определения полей и правила проверки. Аккуратная таблица с неверным толкованием суммы способна дать столь же ошибочный вывод, как неразобранная папка писем. Формальная упорядоченность и качество данных требуют отдельных проверок.
Документ может содержать часть готовой структуры
Карточка обращения в нашем примере содержит автора, дату, категорию и дополнительные сведения, которые зависят от ситуации. У одного обращения указан способ доставки, у другого приложена фотография. Такие документы часто называют полуструктурированными: элементы организации уже есть, но состав и вложенность сведений могут различаться. Google Cloud относит к этой группе документы с внутренними обозначениями полей и гибкой организацией.
Слово «документ» само по себе ничего не решает. Строго заполненная анкета и свободное письмо могут лежать в похожих файлах, но требуют разной подготовки к анализу. Полезнее спросить, какие сведения гарантированно присутствуют в каждом объекте, какие необязательны и как обнаружить их отсутствие. Расширение файла не заменяет такой проверки.
Свободный текст сохраняет оттенки смысла
Покупатель может написать: товар понравился, но доставка опоздала, поэтому подарок больше не нужен. В одном сообщении одновременно присутствуют оценка товара, описание доставки и причина возврата. Отнести письмо к одной категории — уже интерпретация. Для нашего условного разбора предложим заранее определить, можно ли назначать несколько причин и кто проверяет спорные случаи.
Сохранять исходное сообщение полезно отдельно от извлечённых признаков. Тогда при изменении категорий можно проверить первоначальный смысл. Краткая отметка «доставка» не передаёт всего содержания письма. Автоматическое извлечение тоже следует проверять на понятных примерах: наличие аккуратного столбца с категорией не доказывает, что смысл обращения распознан правильно.
Способ хранения и структура — разные решения
Не следует считать каждую таблицу маленькой, а каждый документ большим. Также нельзя выбирать систему только по слову «неструктурированные». Структура объясняет, какие операции удобно выполнять и что придётся предварительно извлечь. Отдельный вопрос — где хранить исходники и подготовленные результаты; его разбирает материал об озере и хранилище данных.
Даже после подготовки таблицы остаётся выбор её физической организации. О нём рассказывает статья про строчное и колоночное хранение. Для нашей службы поддержки начнём с перечня вопросов: что можно сравнить сразу, что нужно извлечь из текста, какие исходники сохраняем и как проверяем полученные категории. Такой разбор помогает обсуждать архитектуру предметно.
Как перейти к практике
Если хотите научиться связывать устройство данных с задачами пользователей, изучите программу «Архитектор данных». Для начала возьмите один знакомый источник и опишите обязательные поля, свободные сведения и ограничения интерпретации. Это основа для разговора о подготовке данных, без выбора технологии по одному названию формата.
