lecture_01

1.

Технологии хранения
данных
Занятие 1 · Big Data, DWH, Data Lake и
Lakehouse
Никита Воробьев

2.

Курс: 12 занятий от основ до комплексного ETLрешения
1 · Что такое BigData?
2 · Распределённые вычисления
4 · Колоночное хранение
DWH, DalaLake, DataLakeHouse
3 · Apache Spark
5 · Обработка данных в RT/NRT
10 · Мониторинг/алертинг/BI
6 · Data-концепции
8 · Spark
7 · Современный подход к
разделению Compute и Storage
9 · Оркестрация и
трансформации
11 · Проектирование
реализация комплексных ETL
решений
12 · Экзамен
ДЗ - Две большие
работы, разбитые на 3
подблока в каждой.
Каждый из подблоков по 5 баллов БРС
2 теста во время
лекций - по 10 баллов,
большой тест - 15
баллов
Итоговый проект - 20
баллов. Экзамен - 10
баллов.
Отл - от 85
Хор - от 70
Уд - от 51

3.

Сегодня на занятии…
Увидеть, почему данные
Разложить систему хранения
становятся сложными для системы
по нескольким независимым вопросам
Понять, чем отличаются
Связать архитектурный выбор
DWH, Data Lake и Lakehouse
с требованиями и компромиссами

4.

Раздел 1. Big
Data: смотрим на
данные через 6V

5.

Организация производит разные данные
Транзакции
События
заказы, платежи, регистрации
клики, просмотры, телеметрия
Документы и медиа
Внешние данные
тексты, изображения, аудио
партнёры, открытые источники, API

6.

Структура данных — это спектр
Структурированные
Полуструктурированные
таблицы, типы, ограничения
JSON, XML, события со схемой
Неструктурированные
Схема всё равно существует
текст, изображения, видео
явно, неявно или в коде потребителя

7.

Big Data — предел привычного подхода
Не обязательно:
Обычно есть сочетание:
• петабайты данных
• масштаба или быстрого роста
• Hadoop или Spark
• высокой скорости поступления
• полностью новая платформа
• разнообразия форматов
• данные только из интернета
• требований к качеству и ценности

8.

Первоначальные 3V описывают давление на
систему
1
Volume · объём
сколько данных и как быстро
растёт история
2
Velocity · скорость
как быстро данные приходят и
когда нужен ответ
3
Variety · разнообразие
сколько форматов, схем и
смыслов нужно согласовать
4
Вместе
3V появились как практическая
модель управления данными, а
не как строгий стандарт

9.

Volume меняет не только ёмкость,
но и способ работы
1
Объём
Сколько данных нужно хранить и
сканировать
2
Рост
Как быстро увеличивается
исторический слой
3
Стоимость
Хранение, передача,
резервирование, вычисления
4
Локальность
Данные приходится
обрабатывать рядом с
хранением

10.

Velocity связывает поступление данных
со временем решения
1
Поток
Сколько событий приходит в
секунду
2
Свежесть
Насколько новые данные нужны
потребителю
3
Окно реакции
Когда результат уже теряет
ценность
4
Режим
Batch, micro-batch, NRT,
streaming

11.

Variety увеличивает стоимость согласования
1
Форматы
таблицы, JSON, файлы, медиа
2
Семантика
одно поле может означать
разное
3
Изменения
схемы и контракты
эволюционируют
4
Интеграция
нужно сопоставить ключи, время
и качество

12.

Следующие V расширяют разговор от системы
к пользе и доверию
1
Value · значимость
какую ценность получаем из
данных
2
Visualization · визуализация
можно ли представить результат
понятно
3
Veracity · подлинность
насколько данные достоверны и
качественны
4
Оговорка
единого канонического списка V
нет: эти характеристики
добавлялись позже разными
авторами и практиками

13.

Value связывает данные с решением
Вопрос
Потребитель
Какое решение или действие изменится?
Кому и когда нужен результат?
Метрика
Компромисс
Как понять, что польза получена?
Не все данные стоит хранить вечно

14.

Visualization делает результат понятным
Форма
Аудитория
таблица, график, карта, алерт
инженеру и руководителю нужны разные детали
Контекст
Риск
единицы измерения, период, база сравнения
неудачная визуализация искажает вывод

15.

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

16.

6V — не тест, а список вопросов
Volume
Velocity
Variety
Сколько и как растёт?
Как быстро приходит и когда нужен ответ?
Какие форматы и смыслы согласовать?
Value
Visualization
Veracity
Какое решение изменится?
Как потребитель поймёт результат?
Насколько данным можно доверять?

17.

Раздел 2.
Системы
хранения:
четыре
независимые
оси

18.

Один продукт описывается сразу
по нескольким осям
1
Модель и интерфейс
SQL, NoSQL, файлы и объекты
2
Нагрузка
OLTP — короткие транзакции;
OLAP — большие аналитические
чтения
3
Физическое хранение
строки, колонки, файлы, индексы
4
Масштаб
один узел, репликация,
распределение

19.

SQL, NoSQL и файлы часто сосуществуют
Реляционные / SQL
NoSQL
PostgreSQL, MySQL, Oracle; таблицы, связи, ограничения
Redis, MongoDB, Cassandra, Neo4j; разные модели доступа
Файлы и объекты
Выбор
S3, HDFS, MinIO; CSV, JSON, Parquet, медиа
контракт, запросы, изменения, стоимость и масштаб

20.

OLTP · оперативная обработка транзакций
1
Online Transaction Processing
много параллельных коротких
операций
2
Точечный доступ
конкретная запись по ключу
3
Частые изменения
insert, update, delete
4
Транзакции
предсказуемая целостность
данных

21.

ACID формулирует базовые гарантии транзакции
Atomicity · атомарность
все изменения транзакции выполняются или
откатываются вместе
Isolation · изоляция
параллельные транзакции не видят опасных
промежуточных состояний
Consistency · согласованность
транзакция сохраняет заданные правила целостности
Durability · долговечность
зафиксированный результат переживает сбой

22.

CAP / теорема Брюера: разделение сети
1
Consistency · согласованность
каждое чтение видит единое
актуальное состояние
2
Availability · доступность
каждый запрос к работающему
узлу получает ответ
3
Partition tolerance · устойчивость
к разделению
система продолжает работать
при потере сообщений между
группами узлов
4
Практический смысл
при сетевом разделении нельзя
одновременно гарантировать C и
A

23.

OLAP · оперативная аналитическая обработка
1
Online Analytical Processing
меньше запросов, но каждый
читает много данных
2
История
срезы по периодам и
измерениям
3
Агрегации
join, group by, окна, сложные
расчёты
4
Чтение преобладает
обновления часто пакетные

24.

MPP SQL делит аналитический запрос
между узлами
1
MPP · Massively Parallel Processing
массово-параллельная
обработка
2
Распределение данных
таблицы разделены между
compute-узлами
3
Параллельный план
сканы, join и агрегации
выполняются одновременно
4
Data movement
пересылка строк между узлами
может стать главным узким
местом

25.

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

26.

На диске строки и колонки меняют объём чтения
• Строковое хранение
• Колоночное хранение
• страница: [id, дата, сумма, статус] [id, дата, сумма,
статус] …
• row group: chunk(id) | chunk(дата) | chunk(сумма) |
chunk(статус)
• Одна запись лежит рядом: точечное чтение и update
требуют мало случайных обращений.
• Запрос читает только нужные column chunks, но
сборка целой строки дороже.

27.

Однотипные значения лучше сжимаются
и считаются пакетами
1
Локальность типа
рядом лежат значения одного
типа и близкого распределения
2
Кодирование
dictionary, RLE, bit packing и delta
заменяют повторы компактными
кодами
3
Меньше I/O
projection читает нужные
колонки; статистики позволяют
пропускать страницы
4
Векторизация
CPU обрабатывает массив
однотипных значений плотными
циклами

28.

Распределённость покупает масштаб
ценой координации
1
Разделение
данные и вычисления
распределены по узлам
2
Параллелизм
части запроса выполняются
одновременно
3
Отказоустойчивость
реплики и восстановление после
сбоев
4
Цена
сеть, согласованность, skew и
эксплуатация

29.

Архитектура — комбинация осей, а не ярлык
Операционная SQL-БД
Аналитическая SQL-БД
Документная БД
SQL · OLTP · чаще строки · один
узел/реплики
SQL · OLAP · колонки · MPP
NoSQL · OLTP/смешанная · документы
Объектное хранилище
DWH
Lake / Lakehouse
файлы · дешёвый масштаб · compute
отдельно
аналитическая платформа и согласованная
модель
объектный слой + каталог + движки +
управление

30.

Требование должно менять решение
Потребители
Свежесть
Данные
BI, аналитики, приложения, ML
сутки, час, минута, секунды
структура, история, объём, рост
Качество
Нагрузка
Ограничения
правила, аудит, происхождение
число пользователей и профиль запросов
стоимость, команда, безопасность, сроки

31.

Восемь вопросов превращают идею в проект
1
Кто потребитель
и какое решение принимает?
5
Какие запросы
и сколько пользователей?
2
Какие источники
и кто ими владеет?
6
Какие гарантии качества,
аудита и безопасности?
3
Какой объём, рост
и срок хранения?
7
Какие навыки, бюджет
и операционная зрелость?
4
Какая свежесть
и допустимая задержка?
8
Как измерим успех
и цену компромисса?

32.

Раздел 3. От
операционных
источников к
аналитической
модели

33.

DWH интегрирует историю для аналитики
Предметность
Интеграция
данные организованы вокруг бизнеса
термины и ключи источников согласованы
Историчность
Стабильность
изменения сохраняются во времени
аналитический слой управляемо обновляется

34.

Уровни DWH: от источников к презентации
Источники → Staging → Центральные слои хранилища → Витрины → Презентационный уровень (BI);
ETL/ELT переносит и преобразует данные между слоями
Операционные
базы
Staging
Внешние
справочники
(и подобные
источники)
Staging
Метаданные и
технические
данные
Staging
Центральные
слои хранилища
Витрины

35.

Признаки DWH: очищенные данные легко
просматривать
SQL и отчёты
Очищенные данные
данные доступны обычными запросами и BIинструментами
проверки и согласование выполнены до публикации
Единая семантика
Управление
факты, измерения и показатели имеют общий смысл
доступ, аудит, происхождение и жизненный цикл

36.

Цена DWH – моделирование до публикации
Schema-on-write
Новые источники
правила нужны до публикации
требуют интеграции и изменений модели
Данные вне таблиц
Стоимость
медиа и меняющиеся события неудобны
платформа, команда, эксплуатация

37.

Перерыв
15 минут
Продолжим с Data Lake, Lakehouse и
сравнением архитектур

38.

Data Lake хранит данные «близко» к источнику
Разные форматы
Масштабное хранение
таблицы, события, документы, медиа
часто файловое или объектное
Много движков
Schema-on-read
интерпретация уточняется при использовании

39.

Стартовая модель Data Lake
События
?
Таблицы
Файлы
Raw
Каталог,
правила,
метаинформация
ML

40.

Lake или Swamp: всё решает управление
Data Lake
Data swamp
• Данные легко найти
• Непонятные файлы и версии
• Есть владельцы и описания
• Неизвестная семантика
• Доступ контролируется
• Дубли и устаревшие копии
• Качество измеряется
• Нет доверия к результатам
• Происхождение прослеживается
• Удалять страшно

41.

Lakehouse соединяет Lake и DWH
От Lake
От DWH
• объектное хранение
• табличная семантика
• разные типы данных
• транзакционные изменения
• отделение storage и compute
• контроль схемы и качества
• работа нескольких движков
• производительная SQL-аналитика

42.

Lakehouse: таблица поверх файлов
Файлы остаются в объектном слое; формат таблицы и каталог координируют снепшоты, схему и
изменения

43.

Lakehouse: управляемые таблицы
Транзакционные коммиты
Schema evolution
Time travel
читатель видит согласованный снимок
контролируемые изменения структуры
чтение предыдущих снимков
Много движков
Разделение storage/compute
Governance
SQL, batch, streaming, ML
независимое масштабирование
каталог, права, происхождение, качество

44.

Lakehouse не отменяет инженерную дисциплину
Сложность метаданных
Физический дизайн
каталог, снимки, совместимость движков
партиции, размеры файлов, компактация
Семантика
Зрелость команды
формат не определит бизнес-показатель
наблюдаемость, governance и FinOps

45.

Три подхода – три точки контроля
DWH
Data Lake
контроль до публикации; BI и единые показатели
разнообразное сырьё; контроль по зонам
Lakehouse
Не обязательно заменяют друг друга
управляемые таблицы поверх открытого storage
архитектуры могут сосуществовать

46.

Гибрид разводит роли слоёв
Источники → доставка → raw Lake → Lakehouse-таблицы → DWH/витрины → потребители
OLTP
ELT
События
Data Lake (Raw)
Файлы
Lakehouse
DWH / витрины
(Отдельный
контур или часть
LakeHouse)
BI

47.

Раздел 4
Дополнительные
архитектурные
паттерны

48.

Lambda: batch + stream
Два пути дают один результат: batch по полной истории + speed по свежим событиям

49.

Цена Lambda – две реализации логики
Плюс
Цена
• низкая задержка
• две кодовые базы или два режима
• полный исторический пересчёт
• расхождение результатов
• устойчивость к поздним данным
• сложная эксплуатация
• понятное разделение путей
• больше тестов и мониторинга

50.

Data Mesh держится на четырёх принципах
Доменные владельцы
Данные как продукт
команды предметной области отвечают за данные
обнаружимость, качество, SLA, документация
Self-service платформа
Федеративное управление
типовые возможности без ручных заявок
общие правила + локальная автономия

51.

Data Mesh меняет владение, не storage
Платформа хранения отвечает:
Data Mesh отвечает:
• где лежат данные
• кто владелец продукта
• как они читаются и изменяются
• какой контракт у потребителя
• какие гарантии даёт таблица
• что даёт self-service платформа
• как масштабируются вычисления
• какие правила общие для доменов

52.

Пять выводов первого занятия
1
Big Data — сочетание
характеристик и
требований, а не порог
объёма
2
SQL/NoSQL, OLTP/OLAP,
строки/колонки и
масштаб — разные оси
3
DWH делает ставку на
согласованную
аналитическую историю
4
Lake хранит сырьё;
Lakehouse добавляет
управляемые таблицы
5
Lambda — про пути
обработки; Mesh — про
ответственность

53.

Литература и первичные источники
Основное
Архитектурные тексты
• DAMA-DMBOK 2
• Laney, 3D Data Management (2001)
• Kleppmann, Designing Data-Intensive Applications
• Marz & Warren, Big Data
• Kimball & Ross, The Data Warehouse Toolkit
• Dehghani, Data Mesh Principles
• Armbrust et al., Lakehouse (CIDR 2021)
• Apache Iceberg Table Spec

54.

Раздел 5
Практика

55.

Практика: выберите кейс и архитектуру
A · Университет
Отчётность по обучению и ресурсам; много
систем, единые показатели, обновление
ежедневно
Результат
5 требований; операционные хранилища;
DWH/Lake/Lakehouse/гибрид; схема; 3
аргумента; 1 риск
B · Цифровой продукт
C · Финансы
События, логи и эксперименты; быстрый
рост, ad hoc аналитика и ML
Регламентная отчётность, хранение сырья и
near-real-time антифрод
Схема
источники → доставка→ хранение →
потребители
Самопроверка
Не смешаны оси? Учтены свежесть,
качество и стоимость? Решение следует из
требований?

56.

Фидбэк
Поделитесь обратной связью по
занятию на портале

57.

Спасибо
за внимание!