Есть ли лучшая практика для запроса огромного CSV в контексте весенней загрузки?

Question

Я работаю на известную компанию в проекте, который должен обеспечить интеграцию с другими системами, которые производят один csv в час 27Gb. Цель состоит в том, чтобы запросить эти файлы без импорта em (основная проблема - бюрократия, никто не хочет, чтобы в случае изменения данных никто не требовал повторной загрузки).

Основные фильтры в этих файлах можно выполнять по датам, конечный пользователь должен вставить диапазон даты начала и окончания. После этого можно фильтровать по нескольким строкам.

• Контекст: пружинные загрузочные микросервисы
• Сервер: Процессор xeon 24 ядра 256 Гбайт Ram
• Файловая система: NFS, смонтированная с внешнего сервера
• Тестовые данные: 1000 файлов, каждый 1Gb

Для производительности улучшение Я индексирую файлы по дате, записывая в каждое имя файла диапазон, который содержит, и создавая структуру папок, например гггг / мм / дд . Для каждого из следующих тестов первым шагом было создание необработанного списка путей к файлам, который будет читаться.

исследование прочитает все файлы

1. Spring batch - с буферизацией считыватель и анализ на объект: 12,097 se c
2. Обычный java - пул потоков, буферизованный считыватель и анализ на объект: 10,882 se c
3. Linux egrep с регулярным выражением и параллелью побежал от java и разобрал в объект: 7,701 se c

Самый грязный тоже пост. Я хочу избежать этого, потому что отдел безопасности предупредил меня обо всех проверках входных данных, чтобы предотвратить инъекцию оболочки.

Поиск в Google Я нашел mariadb CONNECT движок, который может также указывать на огромные csvs, так что теперь я продолжаю таким образом, создавая временную таблицу с файлами, которые представляют интерес для исследования, плохая часть заключается в том, что мне приходится делать одну таблицу для каждого запроса, поскольку даты могут быть разными.

Для первого года Мы ожидаем не более 5 параллельных исследований в то же время, в среднем 3 недели диапазона. Эти запросы будут выполняться асинхронно.

Знаете ли вы что-нибудь, что может помочь мне в этом? Не только для скорости, но и для хорошей практики. Большое спасибо, ребята.

Answer 1

Чтобы ответить на ваш вопрос:

Нет. Нет лучших практик . И, AFAIK, нет общепринятых «хороших» практик.

Но у меня есть несколько общих советов. Если вы позволите таким соображениям, как бюрократия и (в меньшей степени) указы в области безопасности, диктовать свои технические решения, то вы в конечном итоге получите некачественные решения; то есть решения, которые работают медленно или дорого, и продолжают работать. (Если «они» хотят, чтобы это было быстро, то «они» не должны мешать вам.)

Я не думаю, что мы можем дать вам простое решение вашей проблемы, но я могу скажи кое-что о своем анализе.

---

Вы сказали о решении grep.

"Я хочу избежать этого, потому что отдел безопасности предупредил меня обо всех проверках, которые нужно выполнить входные данные для предотвращения внедрения оболочки. "

Решение этой проблемы простое: не используйте промежуточную оболочку. Опасные инъекционные атаки будут осуществляться с помощью обмана, а не grep. Java ProcessBuilder не использует оболочку, если вы явно не используете ее. Сама программа grep может только читать файлы, указанные в ее аргументах, и записывать в стандартный вывод и стандартную ошибку.

---

Вы говорили об общей архитектуре:

"Цель - запросить эти файлы без их импорта (основная проблема - бюрократия, никто не хочет ответственности за изменение данных)."

Я не понимаю здесь возражений. Мы знаем, что файлы CSV будут меняться. Вы получаете новый файл CSV 27 ГБ каждый час!

Если возражение заключается в том, что формат файлов CSV изменится, что отрицательно сказывается на вашей способности эффективно запрашивать их. Но, проявив немного изобретательности, вы можете обнаружить изменение формата и настроить процесс приема на лету.

---

"Мы ожидаем не более 5 параллельные исследования в одно и то же время со средним интервалом в 3 недели. "

Если вы еще этого не сделали, вам необходимо провести некоторый анализ, чтобы увидеть, будет ли предложенное вами решение жизнеспособный. Оцените, сколько CSV-данных необходимо отсканировать, чтобы удовлетворить типичный запрос. Умножьте это на количество запросов, которые будут выполнены (скажем) за 24 часа. Затем сравните это со способностью вашего NFS-сервера выполнять массовые чтения. Затем повторите расчет, предполагая, что данное количество запросов выполняется параллельно.

Подумайте, что произойдет, если ваши (выше) ожидания неверны. Вам нужна только пара "идиотских" пользователей, которые делают неразумные вещи ...

Наличие 24-ядерного сервера для выполнения запросов - это одно, но NFS-сервер также должен иметь возможность достаточно быстро предоставлять данные. , Вы можете улучшить ситуацию с настройкой NFS (например, путем настройки размеров блоков, количества демонов NFS, используя FS-Cache), но самым узким местом будет получение данных с дисков сервера NFS и через сеть на ваш сервер. Имейте в виду, что другие серверы могут «забивать» NFS-сервер, пока ваше приложение работает.