IO, базы и сериализация в Python

# json не умеет datetime сам:
json.dumps(dt)              # TypeError
json.dumps(dt, default=str) # ок

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.

1. #io_serialization1 / 5
   Зачем в пайплайне используют пул соединений (connection pool) к БД?

   A)Пул нужен, чтобы каждый запрос наверняка открывал новое свежее соединение с нуля

   B)Пул соединений автоматически ускоряет выполнение самих SQL-запросов внутри базы данных

   C)Пул полностью снимает лимиты на число одновременных подключений к серверу базы данных

   D)Переиспользовать открытые соединения вместо дорогого открытия/закрытия на каждый запрос

   показать ответ и разбор

   +D)Переиспользовать открытые соединения вместо дорогого открытия/закрытия на каждый запрос

   // разбор: Открытие соединения к БД дорого: TCP-хендшейк, аутентификация, инициализация сессии. Пул держит набор готовых соединений и выдаёт их задачам, возвращая обратно после использования — цена коннекта платится раз, а не на каждый запрос. Пул также ограничивает число одновременных соединений (защита БД от исчерпания слотов). Без пула частые короткие запросы тратят время в основном на установку связи.

2. #io_serialization2 / 5
   Почему промежуточные данные пайплайна часто пишут в Parquet, а не в JSON/CSV?

   A)Колоночный сжатый бинарный формат: меньше объём, чтение нужных колонок, типы и pushdown — быстрее дальше

   B)JSON компактнее Parquet, потому что текст сжимается лучше бинарного формата хранения

   C)Parquet требует читать весь файл целиком, тогда как из JSON можно взять одну колонку

   D)Форматы равнозначны по объёму и скорости, выбор между ними — дело вкуса

   показать ответ и разбор

   +A)Колоночный сжатый бинарный формат: меньше объём, чтение нужных колонок, типы и pushdown — быстрее дальше

   // разбор: Parquet — колоночный бинарный формат со сжатием, схемой и статистикой: он в разы компактнее текстового JSON/CSV, хранит типы (не парсить строки), позволяет читать только нужные колонки и отсекать блоки по статистике (predicate pushdown). Для промежуточных слоёв и обмена между шагами это кратно дешевле по месту и I/O. JSON/CSV удобны как интерфейс с внешним миром, но не как рабочий формат больших данных.

3. #io_serialization3 / 5
   Зачем на границе пайплайна описывать записи через pydantic/dataclass со схемой?

   A)Чтобы ускорить сериализацию: модели pydantic работают быстрее обычных словарей Python

   B)Типобезопасная валидация на границе, битое отсекается рано

   C)Чтобы отказаться от тестов пайплайна: схема заменяет собой проверку логики трансформаций

   D)Чтобы данные автоматически сохранялись в базу без написания какого-либо кода загрузки

   показать ответ и разбор

   +B)Типобезопасная валидация на границе, битое отсекается рано

   // разбор: Модель pydantic (или dataclass + валидация) на входе описывает ожидаемую схему: типы, обязательность, диапазоны. Данные проверяются один раз на границе — некорректные ловятся сразу с понятной ошибкой, а дальше по коду идут уже типизированные, валидные объекты, а не сырые dict с сюрпризами. Это сдвигает обнаружение проблем к источнику (fail fast) и документирует контракт данных.

4. #io_serialization4 / 5
   Файл JSON на 50 ГБ надо обработать на машине с 16 ГБ RAM. Как читать?

   A)Просто вызвать json.load() — Python сам обработает файл размера порциями под капотом

   B)Загрузить весь файл в один список и затем итерироваться по нему в цикле for

   C)Streaming-парсинг/NDJSON — по объекту за раз, память ограничена

   D)Прочитать файл целиком в строку, а потом много раз разрезать её методом split

   показать ответ и разбор

   +C)Streaming-парсинг/NDJSON — по объекту за раз, память ограничена

   // разбор: json.load() строит всё дерево в памяти и на 50 ГБ падает. Решения: потоковый парсер (ijson) выдаёт элементы по мере разбора, не держа весь документ; или, если формат — newline-delimited JSON (по объекту на строку), читать файл построчно генератором и парсить каждую строку отдельно. В обоих случаях пик памяти ограничен одним объектом, а не файлом. NDJSON — стандарт для больших JSON-логов именно поэтому.

5. #io_serialization5 / 5
   Повторный запуск загрузки должен не задваивать строки. Что писать вместо голого INSERT?

   A)Просто добавить SELECT перед каждым INSERT и проверить наличие строки в приложении вручную

   B)Ничего: повторный INSERT тех же данных база сама молча проигнорирует без всяких дубликатов

   C)Отключить уникальные ограничения таблицы, тогда дубликаты перестанут появляться при повторе

   D)Идемпотентный UPSERT (INSERT ... ON CONFLICT DO UPDATE) по ключу — повтор обновляет, а не дублирует

   показать ответ и разбор

   +D)Идемпотентный UPSERT (INSERT ... ON CONFLICT DO UPDATE) по ключу — повтор обновляет, а не дублирует

   // разбор: Голый INSERT при повторном запуске (ретрай, backfill) создаёт дубликаты. UPSERT — INSERT ... ON CONFLICT (Postgres) / MERGE — по уникальному ключу вставляет новое и обновляет существующее, поэтому повторная загрузка тех же данных приводит систему в то же состояние (идемпотентность). Альтернатива — delete-insert по партиции/окну перед вставкой. Ключ к безопасным ретраям и переналивкам.