Три типа данных по структуре

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

В DE принято делить данные на три типа: структурированные, полуструктурированные и неструктурированные. Каждый тип требует своих инструментов для хранения и обработки.

Три типа: обзор

Цифры процентов приблизительны и зависят от источника. Главная мысль: большая часть данных в мире — неструктурированные, но DE-команды чаще работают со структурированными и полу — потому что они аналитически удобны.

1. Структурированные данные

Что это

Данные, организованные в таблицы с фиксированной схемой. Каждая колонка имеет тип (INT, VARCHAR, DATE, BOOLEAN), каждая строка имеет одинаковую структуру.

Пример:

| order_id | customer_id | amount  | status    | created_at          |
|----------|-------------|---------|-----------|---------------------|
| 1001     | 42          | 99.50   | completed | 2026-05-17 10:23:00 |
| 1002     | 13          | 250.00  | pending   | 2026-05-17 10:25:00 |
| 1003     | 42          | 45.00   | completed | 2026-05-17 10:30:00 |

Где живут

• Relational DBs (OLTP): Postgres, MySQL, SQL Server, Oracle.
• DWH: Snowflake, BigQuery, Redshift, Databricks SQL.
• Файлы: CSV (грубо структурированный), Excel, Parquet/ORC (типизированные).

Плюсы

• SQL работает идеально.
• Лёгкая валидация схемы и типов.
• Хорошее сжатие в колоночных форматах (Parquet).
• BI-инструменты заточены под структуру.

Минусы

• Schema-on-write — нужно решить схему до записи.
• Schema evolution — добавить колонку = вся таблица обновляется (в плохой реализации).
• Не годится для иерархических данных без неоднократных JOIN’ов.

Где встречается в DE

• Production-БД (источник).
• Финальные mart-таблицы в DWH.
• CSV-экспорты от партнёров.

2. Полуструктурированные данные

Что это

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

Пример JSON:

{
  "user_id": 42,
  "name": "Alice",
  "email": "[email protected]",
  "preferences": {
    "newsletter": true,
    "language": "en"
  },
  "tags": ["premium", "early-adopter"],
  "address": {
    "city": "Moscow",
    "country": "Russia"
  }
}

Здесь preferences — вложенный объект, tags — массив, address — может быть, а может и не быть.

Форматы

Где живут

• REST API responses — почти всегда JSON.
• NoSQL БД: MongoDB, DynamoDB, CouchDB.
• Логи приложения — JSON-структурированные.
• Kafka — Avro или JSON.
• Cloud storage — JSON-файлы в S3.

Плюсы

• Гибкость — новое поле не ломает старые данные.
• Иерархия — нативно поддерживает вложенность.
• Schema evolution безболезненна (особенно Avro).

Минусы

• Без схемы — нет гарантий типов.
• Парсинг при чтении — медленнее структурированных.
• SQL-операции сложнее: SELECT preferences.newsletter вместо простой колонки.

Как DE с ними работает

Современные DWH умеют JSON:

-- Snowflake: VARIANT column
SELECT
  user_id,
  user_data:preferences.newsletter::BOOLEAN AS newsletter,
  user_data:tags::ARRAY AS tags
FROM raw.users;

Стратегии:

1. Хранить JSON как есть в VARIANT-колонке, извлекать поля на лету.
2. Извлекать ключевые поля в staging (flatten), оставив JSON как backup.
3. Avro / Parquet с nested types для эффективного хранения.

3. Неструктурированные данные

Что это

Данные без формальной схемы:

• Текст: email, документы, чат-сообщения, статьи.
• Изображения: фото товаров, медицинские снимки.
• Аудио: звонки в саппорт, подкасты.
• Видео: записи камер, обучающий контент.
• PDF / Word — сложно парсимые документы.

Где живут

• Object storage: S3, GCS, Azure Blob.
• Специализированные БД: ElasticSearch (полнотекстовый поиск), Pinecone / Weaviate (vector DB для LLM).

Как DE с ними работает

Раньше: просто хранили как «балласт» в S3, аналитики не трогали.

Сейчас с приходом LLM и vector search:

DE-pipeline для неструктурированных:

1. Файлы пишутся в S3.
2. Метаданные (что за файл, владелец, размер) — в DWH.
3. Содержимое (текст из PDF, embeddings) обрабатывается ML pipeline’ом.
4. Результаты — vector DB (для поиска) или DWH (для аналитики).

Плюсы

• 80% реальных данных в мире — такие.
• Информация богаче (контекст, эмоции).

Минусы

• Дорого обрабатывать (OCR, ASR, embeddings).
• Не SQL-friendly напрямую.
• Performance — текстовый поиск медленнее SQL.

Сравнительная таблица

Что важно для DE

Реальный пример

Стартап — облачный сервис для поддержки клиентов.

DE-команда: загружает все типы, обрабатывает каждый под свою задачу. Результат:

• BI-дашборды — на structured.
• Поиск по тикетам через LLM — на unstructured + vector DB.
• Анализ настроения по звонкам — на ML-обработке аудио.

Попробуй сам

1. Открой любой REST API (например, https://jsonplaceholder.typicode.com/posts). Это полуструктурированный JSON. Подумай: какие поля ты бы вытащил в колонки таблицы в DWH? А какие оставил бы в VARIANT?

2. Возьми любой PDF из своих почтовых вложений. Какие структурированные метаданные ты можешь из него извлечь (sender, date, size, page count)? Что нужно ML для контента (текст, embeddings)?