Data engineering
Дата-платформа: свободное припоминание
Припоминание сильнее перечитывания. Для каждого промпта восстанови полный ответ по памяти, прежде чем открыть образцовый — усилие собрать весь трек воедино и есть то, что сплавляет отдельные хранилища в одну ментальную модель.
Восстанови хребет трека, не подглядывая: почему OLTP и OLAP разделяются, где исполняется трансформация, как Parquet прунит, чем жертвует MV, почему лог — источник истины и как поиск и векторы делят релевантность — и как проектируются стыки между ними.
- 01Почему одна раскладка хранения не может обслуживать и OLTP-путь оформления, и OLAP-сканы выручки, и каков стандартный ответ из двух хранилищ?
- 02Что реально даёт выбор ELT вместо ETL и какова цена?
- 03Как Parquet пропускает данные и какая ошибка в коде тихо это ломает?
- 04Чем жертвует materialized view и как держать этот компромисс честным в продакшене?
- 05Почему append-only лог событий — источник истины в event sourcing и как текущее состояние связано с ним?
- 06Как полнотекстовый поиск и векторный поиск делят задачу релевантности и почему зрелые системы гоняют оба?
Если ты восстановил каждый ответ, ты держишь хребет трека: OLTP и OLAP разделяются, потому что ни одна раскладка не выигрывает оба паттерна доступа; ELT покупает переигрываемость, сохраняя сырое; Parquet прунит через статистику футера, пока функция не спрячет колонку; MV меняет устаревание на скорость чтения и требует объявленного freshness SLA; лог событий — источник истины, а состояние — свёртка над ним; поиск и векторы делят лексическую и семантическую релевантность. И главное — каждое хранилище корректно для своей задачи; система остаётся корректной, только когда ты проектируешь контракт, гарантию доставки, свежесть и реконсиляцию на каждом стыке между ними.