Оптимизация рабочего процесса от разработки до производства для обработки более 38 миллионов строк с помощью DuckDB и Po ⇐ Python

[Anonymous]

Я разрабатываю конвейер данных Python для обработки и обогащения набора данных Федерального дохода Бразилии (CNPJ), который состоит из ежемесячных сегментированных файлов CSV общим объемом более 38 миллионов строк (около 100 ГБ+ в необработанном виде).
Текущий стек:

• Механизм: Гибридное использование Polars (для сложных регулярных выражений) фильтрация по второстепенным действиям) и DuckDB (для объединений и объединений на базе SQL с географическими справочными таблицами).
• Хранилище: Окончательный результат в сжатом Parquet.
• Инфраструктура: Локальная разработка с 8 ГБ ОЗУ для тестирования образцов с последующим развертыванием в Экземпляры AWS EC2 r7g.xlarge (Graviton3) для полных запусков.

Текущий рабочий процесс:

• Извлеките небольшой образец локально.
• Проверьте логику преобразования и фильтры регулярных выражений.
• Вручную разверните сценарий на AWS и запустите его на полном наборе данных за 12 месяцев.

Задача: цикл «выборка локально -> развертывание в облако» кажется медленным. Хотя мои локальные тесты проходят успешно, при полномасштабном запуске иногда возникают проблемы с нехваткой памяти или узкими местами ввода-вывода при передаче данных на диск на AWS. Я ищу способы повышения производительности и снижения затрат.
Вопросы:

• Есть ли лучший способ локально имитировать ограничения памяти «в облачном масштабе» без выборки вручную?
• Как я могу дополнительно оптимизировать DuckDB TEMP_DIRECTORY на локальном NVMe по сравнению с EBS, чтобы гарантировать, что Соединение 38 M строк не останавливает процессор?
• Было бы переключение на подход Zero-ETL или использование такого инструмента, как MotherDuck, для финального уровня обогащения, лучшее соотношение затрат и производительности, чем развертывание экземпляров r7g для каждого запуска?