Я как то уже рассуждал здесь и вслух о том что ИТ профессии часто формируют устойчивые когнитивные искажения, например, когда все окружающее воспринимается как таблицы или как данные, лично я считаю что в этом нет ничего зазорного и сам иногда впадаю в состояние автоматического построения структур данных в голове и доведение их до 3NF.

Но то что кто-то может назвать когнитивным искажением, можно назвать и способом взгляда на те или иные явления. И вот один из таких способов восприятия реальности - это смотреть на все как на список. Список дел, список строк в файле, список записей в БД и так далее. А если по списку можно проходить и что-то делать с тем что в нем находится то он является перебираемым или на английском языке iterable.

Собственно под восприятия мира данных того что большая часть структур данных, форматов дата файлов и тд - это перебираемые списки я когда-то создал, а недавно обновил библиотеку iterabledata для Python.

Изначально она создавалась для того чтобы реализовать для JSON/JSON lines файлов логику перебора содержимого по принципу csv.DictReader, стандартной библиотеки в Python в которой перебираемые объекты возвращаются как словари. Заодно добавив к этому что чаще всего эти файлы с данными сжаты чем-то Gzip, LZMA, Zstandard и тд.

А в этот раз я обновил эту библиотеку для большей универсальности и поддержки десятков новых форматов данных DBF, JSON-LD, KML, GML, CSVW, Annotated CSV, MessagePack и еще много, полный список.

Включая некоторые экзотические форматы такие как WARC для веб-архивации, которые тоже можно рассматривать как объекты со списками для перебора.

А в качестве наглядного примера, преобразование дампа Википедии из сжатого XML в Parquet.

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

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

#opensource #dateno #datatools #dataengineering

У меня есть довольно давняя отложенная нерабочая задача - это извлечь с каталога музейного фонда РФ (goskatalog.ru) материалы по армянскому культурному наследию для чего я когда-то выгружал с портала данных Минкультуры РФ битый датасет этого реестра и преобразовывал 88ГБ текстовый файл в 2.7ГБ файл Parquet с 31.7 записями о культурных объектах. А также есть примерно 100 регулярных выражений позволяющих найти записи в которых есть прямое или косвенное упоминание Армении или армянской культуры.

Задача универсальная, можно вместо поиска армянской культуры искать культуру еврейскую, чувашскую, адыгскую - вариаций много. Ключевое в том что есть большой файл с данными, много регулярных выражений и надо найти все идентификаторы записей в которых присутствует хотя бы одно совпадение. При этом искать надо не по всем полям, а буквально по 4-м: название, описание, место, авторы

А теперь о подходах как такую задачу можно решить.

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

Облачное программирование (неэкономное). То же самое только арендуешь сервер в облаке на котором запускаешь, после отработки кода сохраняешь результаты и сервер отключаешь.

Неэкономное продвинутое программирование. Обращаешь внимание что записи в данных не зависят друг от друга и находишь компьютер с большим объемом памяти и множеством ядер или арендуешь дорогой облачный сервер, разрезаешь оригинальный файл с данными на 100 по 370 тысяч записей каждый и запускаешь их обработку параллельно по числу доступных ядер

Экономное хардкорное программирование. Обращаешь внимание что регулярные выражения - это медленно почти всегда и на то что не все поля в оригинальных данных нужны. Оптимизируешь и пересобираешь оригинальный файл с данными так чтобы он содержал только id записи и поля с нужными текстами, переписываешь регулярные выражения на pyparsing или разворачиваешь их в текст для полного мэтчинга и, конечно, тоже разрезаешь файл с данными на 100 (или сколько нужно) и параллельно запускаешь обработку не обязательно на продвинутом железе. Думаешь о том не переписать ли все это на Rust

Управленческое решение. Находишь человека с нужными навыками в своей команде и предаешь ему эту задачу. Как он это сделает тебя волнует не особенно, главное чтобы результат был к ожидаемому сроку.

Поиски волонтера. Описываешь целесообразность и нужность задачи в виде мини ТЗ. Закидываешь с сообщества где могут быть потенциальные волонтеры готовые ее решить. Задача не самая сложная, не самая простая, как раз по силам.

Вайб-кодирование. Описываешь эту задачу ИИ агенту и он за тебя генерирует код (скорее всего не самый высокопроизводительный) и дальше уже по аналогии с ленивым программированием

Продвинутое вайб кодирование. Ставишь задачу нескольким ИИ агентам и сравниваешь результаты. Долго тюнишь лучший из результатов уточняющими запросами по оптимизации кода.

—
Можно придумать еще какое-то количество подходов, ИИ агенты добавили несколько опций которые оказываются полезными и ускоряют работу, но в работе с данными даже такого небольшого объёма это пока не такой оптимальный вариант как что-то другое.

#thoughts #programming #dataengineering