- Размер скачанного файла не превышает 4 МБ;
- Количество файлов = 48 (прогнозы на 2ое суток вперед), не более 200 мб архивированных данных за иттерацию;
- Контейнер данных - grib2;
- Степень сжатия архивов 33%, вес файлов на одну иттерацию - до 600 мб;
- Из контейнера нам нужны значения на 0-ую минуту каждого час (первая DataSeries).
- Для работы с grib файлом была выбрана библиотека xarray. С ее помощь выгружаются данные в np.array для дальнейшей обработки;
- Загрузка и распаковка исходных файлов с удаленного ресурса реализована асинхронно;
- Обработка загруженных файлов происходит в отдельных потоках;
- Из-за необходимости корректировки файла значения прошлого часа - все результаты собираются в главном процессе, который и производит запись результирующих файлов;
- Cкачанные файлы не удаляются (для возможности ретро-расчета). Устаревшие данные возможно удалять отдельным скриптом (find download/ -type f -mtime +7).
- установить в систему eccodes (brew install eccodes);
- установить все пакеты из requirements.txt;
- запуск файла - python main.py.
- Избавиться от превращения xarray в numpy (если xarray - подходящая библиотека и от явного использования numpy можно отказаться);
- Возможно, что pygrib окажется более ресурсо-эффективной (по памяти), но из-за сложности ее установки на ряд платформ был сделан выбор в пользу xarray;
- Динамический расчет множителя (multi) для обрбаатываемого файла;
- Написание юнит-тестов (проверка pack-unpack, а так же мат. операций);
- Написание интеграционных тестов (на случай смены формата/состава входных данных - критичным для нас моментом является смена множителя);
- Рассчитать требуемые ресурсы (особенно RAM) для выполнения одной иттерации (актуально при выкатке в kubernetes).
- Правильность выбора библиотеки для работы с grib2-файлами;
- В источнике лежит 49 файлов (по тз было 48). 49ый (самый свежий) не является валидным (не содержит lat/lon данных). Возможно, что этот аспект возник именно в конкретных сутках.