Codeup1054 May 15 2018 at 17:12

Парсинг 0.5Tb xml за несколько часов. Поиск организаций в открытых данных реестра субъектов МСП ФНС

9 min

13K

XML *Open data *

From sandbox

+14

Comments 21

firedragon May 15 2018 at 17:37

Почему не Perl? И почему не загнать это в базу данных, создать OLAP куб и отдать аналитикам в бухгалтерию?

domix32 May 16 2018 at 12:25

Perl не сильно приятней bash. Я бы предложил Python

Cheater May 16 2018 at 12:57

Эм, вообще-то сильно приятнее. SAX2 парсер из XML::Xerces, в комбинации с возможностями Perl по манипуляции plain text, в разы бы сократил объём кода, читаемость и скорость.

domix32 May 16 2018 at 14:24

Синтаксис perl подразумевает огромное количество спец. символов ($@#), которые сами по себе трудно обрабатывать в голове. Конечно, в нем меньше ограничений специфичных в сравнении с bash (поди напиши валидное мультиусловие с первого раза), но вцелом все ещё слишком перегружено. Особенно если код пишет адепт однострочников.
Python при сходных же реализациях и производительности выглядит на порядок чище и читаемее. Сопровождать и расширять такой код проще.

firedragon May 16 2018 at 14:36

1. Есть везде
2. Модули есть под все
3. Правильно работает с уникодом

И это специализированный инструмент для обработки текста, и только во 2-ю очередь, ЯП общего назначения

Cheater May 16 2018 at 14:40

Уж сколько раз твердили миру, что читаемость зависит от скилла разработчика, а не от языка. Специальные символы для обозначения типа переменной есть в куче языков (сам не далее как вчера создавал на c++ параметр *&int). Если «код пишет адепт однострочников», то он и на питоне будет писать кашу.

domix32 May 16 2018 at 20:59

Именно что от скилла. Вы весь такой со скилами и прокачанный, написали чудо-скрипт, а потом поменяли работу, а скрипт дали доработать свежеприбывшему програмисту рангом поменьше вас. И вот он начинает ломать глаза и мизинчик об это все.
P.S. Как-то по причине нелюбви к $varname синтаксису так не стал PHPшником

UFO just landed and posted this here

poxvuibr May 15 2018 at 17:59

Вот как приходится мучаться, когда нормального языка программирования под рукой нет.

SDKiller May 15 2018 at 19:11

А еще наши государственные opendata как будто специально задуманы, чтобы с ними мучались.
Переписывался как-то с ответственной начальницей в госкомстате по поводу файла какого-то классификатора на 50 Гб в ворде (!).
Вкратце — "нас обязали, мы выложили, а насколько это вам удобно — уже не наше дело".

domix32 May 16 2018 at 12:27

Тут где-то даже была статься про работу с этими данными. А там порой то полей нет, то xml невалидный

gibson_dev May 15 2018 at 19:59

я на php 5.6 парсил 18гб xml файл — по времени 20 минут примерно со скачиванием и распаковкой, на современных версиях у думаю побыстрее будет

xRay May 15 2018 at 22:03

А чем xml обрабатывал? SimpleXMLelement?

POPSuL May 16 2018 at 04:13

Думаю что такие объемы необходимо обрабатывать с помощью XMLReader.

gibson_dev May 16 2018 at 06:54

XMLReader умеет потоковое чтение, им выбирал блоки и их уже для удобства парсил SimpleXMLelement

peresada May 16 2018 at 08:04

это ж какая у вас скорость скачивания была?

igor_suhorukov May 16 2018 at 00:09

IMHO bash скрипты тяжело отлаживать и тяжело расширять через пару месяцев… Есть море XQuery парсеров для задачи которую вы описали, а еще если нужна тяжелая артиллерия — с подобными задачами работает Apache Drill из коробки, но в этом есть смысл если одни и те же данные вы будете многократно обрабатывать, не производя предварительно ETL.

gecube May 16 2018 at 22:45

Самое страшное в баше — это отсутствие человеческой обработки ошибок. В результате надёжный код получается обмазан кучей проверок кодов возврата и/или output от программ и это реально становится тяжело отлаживать и расширять. Плюсы тоже очевидны: bash и wget практически самые стандартные утилиты, которые есть практически в каждом дистрибутиве linux. И порог входа в них достаточно низок.

Cheater May 16 2018 at 13:02

Совет один — загляните в код xmlstarlet и проверьте, использует он libxml2 как потоковый парсер (sax) или же строит полное дерево. Для XML таких объёмов строго рекомендуется использовать потоковый парсер. XQuery здесь имхо излишен — структура входных XML-ей довольно простая. Можно вообще при желании обойтись без XML парсера и обрабатывать тупо plain text (sed/awk) регулярками — скорость сильно возрастёт.

gecube May 16 2018 at 22:39

Вопрос из зала: почему нет многопотока? Почти наверняка можно было запустить по 8 (или любое число) одновременных процессов скачивания и преобразования файлов. Ну, если, конечно, не стояло задачи делать все на самом слабом и дешёвом сервере....

sergeilem May 22 2018 at 14:38

Libxml, который использует xmlstarlet, по скорости совсем не лучший выбор. Автор pugixml (есть на гитхабе) утверждает что его произведение в разы быстрее