Комментарии 8
Переводите тогда и комменты к оригиналу, его там закидали какашками за unaligned loads. Так что ускорение — фигня.
Статью не читал, но одобряю. Наверняка хорошая и полезная - оптимизация, алгоритмы - я только за.
Есть только одно замечание - большие объемы данных лучше хранить в БД, которые для этого и созданы, а небольшие файлы .csv Python и R обрабатывают практически моментально.
честно говоря не понял, чего и ради чего ускоряется. CSV хорош тем, что простой как репа и читабельный как текст в любом текстовом редакторе. Автор, как я понял, в качестве полей хочет вставлять главы из романа "Война и мир" с абзацами, переносами, умляутами и текстом на русском и французском языках, а также комментарии для читателей из Китая.
Выше вон напомнили про существование БД ;-)
Лично у меня проблема со скоростью обработки cvs возникала при попытке прочитать и построить графики в Экселе или в Calc'е из Open/Libre оффисе при хорошем количестве строк в CSV... Проблема была решена на голом Це с рисованием в файл-картинку при посредстве библиотеки gd.
честно говоря не понял, чего и ради чего ускоряется
CSV -- популярный формат для самых разных данных. Если 50 гигабайт CSV приходится перелопачивать много раз за день, то хорошо чтобы бы это происходило быстро.
если это приходится делать сного раз в день, то есть повод задуматься о более эффективном способе передачи данных и не изобретать велосипеды на ровном месте.. CSV не из воздуха же берется, а скороей всего из базы данных. А в результате перелопачивания что получается? Другая база данных? Таблица? Так на то, чтоб родить CSV много раз в день и записать куда-нибудь результат перелопачивания тоже много раз в день тоже тратится какое-то время, так нафига тогда промежуточный этап, чего б не использовать "штатные средства" баз данных, если уж речь зашла об оптимизации
В дейта инжиниринге бывают любые странные сочетания форматов и их преобразований и разные странные кейсы. Например, огромные CSV могут прилетать через какую-то интеграцию извне и конвертировать их в какой-нибудь Parquet, поддерживать преобразованные файлы в актуальном состоянии и т.п. -- лишний геморой, усложнение пайплайна и занятие времени инженеров. Нужны веские причины это делать. А этот SIMD-код нужно написать и поддерживать тольо внутри условного Spark, дальше его все просто используют (даже не зная об этом).
в задаче стоит "много раз в день"... если бы это надо было делать один раз, то и никакой оптимизации нафиг не надо делать, а если много раз - значит изначально заложена неоптимальность, и бороться за оптимальность части, не принимая во внимание неоптимальность общего... ну да, "я его слепила из того, что было, а потом четыре года сопли в тазу мыла" ;-)
И не надо называть операцию по удалению гланд через ... дейта инжинирингом
Вот согласен с Вами, но "обзываться" не надо. Если бы задача по организационной линии была решаема, то наверное так бы и поступили. Но всегда приходиться иметь дело с тем, что имеем. Например, в базу доступ не дают, даже на чтение (регламент безопасности такой), а данные получить необходимо, очень часто делают выгрузки необходимых данных именно в "транспортные" файлы (не раз такое встречал в крупных компаниях).
Быстрая обработка CSV с помощью ОКМД (SIMD)