Когда я был еще в процессе поиска инструментов для чтения XLSB файлов, я натыкался на готовые библиотеки для конвертации XLSB -> XLSX. Все они использовали именно COM-интерфейс MS Excel, но мне этот вариант критически не подходил: во-первых, мне нужно было кроссплатформенный модуль, который можно было бы одинаково эффективно использовать и под Windows и под Linux, во-вторых я все такие решения, лично на мой взгляд, являются «костылями» - пусть и доступными, но не универсальными, написанными «чтобы много не писать». И самое главное – я не совсем представляю, как можно настолько упростить взаимодействие с файлами MS Excel, используя такую вещь, как COM интерфейс, чтобы иметь все те же возможности, что и в Polars, например. Полноценный модуль-адаптер для COM интерфейса Excel, скорее всего, окажется по итогу сложнее и медленнее, чем существующие решения.
Разумеется, для пользователей MS Excel уровня эксперта – любая задача по плечу, но не думаю, что в нем удобно проводить автоматизацию обработки отчетов и дальнейшую заливку в базу данных. Более того, сомневаюсь, что кто-либо станет для этого ставить виртуалку.
Кроме того, поистине ничтожна вероятность того, что виртуалку Windows можно поставить внутри контейнера Kubernetes с Linux, чтобы «удобно и быстро» разделать файлы Excel командами через SSH терминал :)
К слову, недавно успешно отработал с файлом MS Excel – весом 3GB (личный рекорд). 10 листов по 1048000 строк. Помнится, «даже родной» MS Excel такие файлы только открывает +/- вечность. Я сконвертировал их в Parquet, даже не прибегая, собственно, к импорту Pandas или Polars, и теперь, чтобы И открыть любой лист И найти нужное значение – понадобится менее 5 секунд, так что в данном случае RXLS уделывает MS Excel просто в ноль. На моем не особо мощном ПК на конвертацию понадобилось около 15 минут на лист, но я уверен, MS Excel не открыл бы файл вообще – ни сегодня, ни завтра, никогда.
Думаю, вы правы, насчет того, что в некоторых случаях, может быть проще прибегнуть к этому мощнейшему инструменту, чтобы объединить файлы в один. Но, мое мнение, если на PyPi есть подходящий для этой задачи инструмент (Pandas в связке с OpenPyXL/PyXLSB или Calamine), на память питониста первым придет именно он, пусть и придется крепко повозиться.
В некоторых же случаях, и в моем случае, в частности, использовать Power Query попросту невозможно.
Действительно, Pandas имеет такую возможность — считать все ячейки как строки.
Проблема в данном случае в том, что Pandas использует OpenPyXL, и, в случае с чтением больших файлов, это огромная трата времени и оперативной памяти и, плюс к этому, дополнительные затраты на конвертацию в строки. Для XLSB сохраняется проблема PyXLSB с чтением дат.
К слову, если используется Pandas старых версий (<2.1.0), он не использует для хранения строк формат PyArrow (как рекомендовано в новых версиях), что приводит к многократному перерасходу оперативной памяти в процессе формирования датафрейма. В новых версиях хорошо использовать read_excel(…, dtype=»string[pyarrow]»).
В новых версиях Pandas добавлена поддержка нового ридера файлов Excel — Calamine (с версии Pandas 2.1 — и, следовательно, как минимум для Python 3.9+, минимальной поддерживаемой версии), который именно заточен на чтение любых файлов Excel (.xlsx,.xls,.xlsb,.ods) — но, опять же, принцип всё тот же: читаем файл строками, потом раскладываем по столбцам, затем конвертируем в строковый тип данных. Тратится оперативная память (строки в любом виде забивают больше памяти, чем числа или даты), и уходит время на конвертацию и «поворот» формата. Хороший момент — что Calamine корректно читает даты в файлах Excel, и в целом работает очень и очень шустро (там Rust «под капотом»), так что, похоже, PyXLSB и OpenPyXL вместе уходят в закат (на зависть пользователям старых версий Pandas/Python и, в том числе, мне).
В целом, мое мнение, файлы XLSX и XLSB, как правило, достаточно хорошо организованы — пусть форматы ячеек не всегда совпадают в пределах столбца, но они обычно относятся к общему типу — в одном столбце даты, в другом строки, в третьем — числа и т. д. По‑настоящему приспособленный для чтения таких файлов инструмент не должен иметь каких‑то особых проблем с соединением таких участков. Но, другая глобальная проблема — наличие «подвалов» и, особенно, «шапок» случайной величины, «лишних» строк — какие‑нибудь «ИТОГ», «СУММА» и т. п. — вставленных непредсказуемым образом — реально заводит в тупик. Также, нет никакого простого способа считать многострочный заголовок, особенно, если он собран местами из «объединенных» (merged) ячеек.
Вот взять, например, десять файлов — в восьми из них шапка занимает 15 строк, и заголовок — 4 строки, в двух оставшихся шапка, внезапно, 16 строк. В одном из первых восьми файлов есть строка итогов внизу таблицы, а в одном из двух оставшихся — итоги вставлены сразу после заголовка… Даже лучшие из существующих инструментов потребуют индивидуальной подгонки параметров для чтения каждого файла, что порождает простыню «одноразового», почти непригодного для переиспользования, кода. Мой же проект предназначен для того, чтобы, по возможности, решить все эти сложности, и при этом оптимизировать траты системных ресурсов.
Тестировщики у нас к работе подключаются после завершения разработки. Тестировщики не трогают юнит-тесты, пишут только свои интеграционные. Юниты мы так и оставляем на моках, в нашем случае этого всегда достаточно .
Ранее ничего не слышал о данном фреймворке, streamlit оказался довольно занимательным инструментом. Если вариант задачника на Flask не выстрелит, то попробую сделать решение на streamlit'е.
В контексте данной задачи специализированные модели значительно лучше ведут себя, чем модели общего назначения, поскольку они обучались на данных для решения именно этой проблемы. Даже «нормальная модель» не дает гарантий, что сгенерированный ответ будет корректный. Пока что всё ещё необходимо проверять результат работы модели, поскольку LLM’s галлюцинируют и находятся не на том уровне, когда пользователь может безоговорочно доверять всему, что ему выдает AI-помощник.
Вы правы, можно настроить подключение к другой языковой модели, прописать вызов функций и работать напрямую с результатом. Но я привела примеры бесплатных моделей, при использовании которых у пользователя не возникнет ограничений или сложностей, связанных как с интерфейсом (веб-интерфейс понятен и доступен многим), так и со сложностью разработки (не нужно ничего прописывать, кроме самого запроса на естественном языке).
Вы правы. Существуют различные модели и методы, решающие данный тип задач. Пост носит обзорный характер, и я предлагаю использовать LLM на ряду с другими инструментами.
Добрый день! Конечно, данные ИИ-инструменты выступают только в роли помощников, но никак не в роли полноценной замены сотрудников, напрямую работающих с БД. Я не рекомендую полностью полагаться на запросы, сформированные AI-плагинами, но в случае затруднений можно обратить на них внимание.
Из соображений конфиденциальности мы не можем дать ссылку на датасет и на его структуру. Повторимся, что датасет содержит как численные, так и категориальные переменные, работу с которыми мы и показали. Нашей целью было показать методы PySpark работы с ними, поэтому конкретная структура таблицы и значения признаков для демонстрации необязательны.
Касаемо файнтьюнинга, то как уже было упомянуто в посте, наибольший прирост в скорости наблюдается если:
обучать на больших батчах;
использовать тяжёлую модель;
максимально занять GPU;
обучать на много эпох.
Если применить только одну рекомендацию(в вашем случае тяжелая модель с большим количеством параметров), то маловероятно, что будет наблюдаться прирост в скорости.
Нам в работе такие инструменты не встречались, возможно ИИ пока не дошёл до такой степени автоматизации, или мы просто ещё не знаем о нем. Будем благодарны, если кто-то поделиться таким инструменте.
Ананас и пылесос в заголовке тоже взялись неспроста.
Добрый день!
Когда я был еще в процессе поиска инструментов для чтения XLSB файлов, я натыкался на готовые библиотеки для конвертации XLSB -> XLSX. Все они использовали именно COM-интерфейс MS Excel, но мне этот вариант критически не подходил: во-первых, мне нужно было кроссплатформенный модуль, который можно было бы одинаково эффективно использовать и под Windows и под Linux, во-вторых я все такие решения, лично на мой взгляд, являются «костылями» - пусть и доступными, но не универсальными, написанными «чтобы много не писать». И самое главное – я не совсем представляю, как можно настолько упростить взаимодействие с файлами MS Excel, используя такую вещь, как COM интерфейс, чтобы иметь все те же возможности, что и в Polars, например. Полноценный модуль-адаптер для COM интерфейса Excel, скорее всего, окажется по итогу сложнее и медленнее, чем существующие решения.
Разумеется, для пользователей MS Excel уровня эксперта – любая задача по плечу, но не думаю, что в нем удобно проводить автоматизацию обработки отчетов и дальнейшую заливку в базу данных. Более того, сомневаюсь, что кто-либо станет для этого ставить виртуалку.
Кроме того, поистине ничтожна вероятность того, что виртуалку Windows можно поставить внутри контейнера Kubernetes с Linux, чтобы «удобно и быстро» разделать файлы Excel командами через SSH терминал :)
К слову, недавно успешно отработал с файлом MS Excel – весом 3GB (личный рекорд). 10 листов по 1048000 строк. Помнится, «даже родной» MS Excel такие файлы только открывает +/- вечность. Я сконвертировал их в Parquet, даже не прибегая, собственно, к импорту Pandas или Polars, и теперь, чтобы И открыть любой лист И найти нужное значение – понадобится менее 5 секунд, так что в данном случае RXLS уделывает MS Excel просто в ноль. На моем не особо мощном ПК на конвертацию понадобилось около 15 минут на лист, но я уверен, MS Excel не открыл бы файл вообще – ни сегодня, ни завтра, никогда.
Добрый день!
Думаю, вы правы, насчет того, что в некоторых случаях, может быть проще прибегнуть к этому мощнейшему инструменту, чтобы объединить файлы в один. Но, мое мнение, если на PyPi есть подходящий для этой задачи инструмент (Pandas в связке с OpenPyXL/PyXLSB или Calamine), на память питониста первым придет именно он, пусть и придется крепко повозиться.
В некоторых же случаях, и в моем случае, в частности, использовать Power Query попросту невозможно.
Добрый день!
Действительно, Pandas имеет такую возможность — считать все ячейки как строки.
Проблема в данном случае в том, что Pandas использует OpenPyXL, и, в случае с чтением больших файлов, это огромная трата времени и оперативной памяти и, плюс к этому, дополнительные затраты на конвертацию в строки. Для XLSB сохраняется проблема PyXLSB с чтением дат.
К слову, если используется Pandas старых версий (<2.1.0), он не использует для хранения строк формат PyArrow (как рекомендовано в новых версиях), что приводит к многократному перерасходу оперативной памяти в процессе формирования датафрейма. В новых версиях хорошо использовать read_excel(…, dtype=»string[pyarrow]»).
В новых версиях Pandas добавлена поддержка нового ридера файлов Excel — Calamine (с версии Pandas 2.1 — и, следовательно, как минимум для Python 3.9+, минимальной поддерживаемой версии), который именно заточен на чтение любых файлов Excel (.xlsx,.xls,.xlsb,.ods) — но, опять же, принцип всё тот же: читаем файл строками, потом раскладываем по столбцам, затем конвертируем в строковый тип данных. Тратится оперативная память (строки в любом виде забивают больше памяти, чем числа или даты), и уходит время на конвертацию и «поворот» формата. Хороший момент — что Calamine корректно читает даты в файлах Excel, и в целом работает очень и очень шустро (там Rust «под капотом»), так что, похоже, PyXLSB и OpenPyXL вместе уходят в закат (на зависть пользователям старых версий Pandas/Python и, в том числе, мне).
В целом, мое мнение, файлы XLSX и XLSB, как правило, достаточно хорошо организованы — пусть форматы ячеек не всегда совпадают в пределах столбца, но они обычно относятся к общему типу — в одном столбце даты, в другом строки, в третьем — числа и т. д. По‑настоящему приспособленный для чтения таких файлов инструмент не должен иметь каких‑то особых проблем с соединением таких участков. Но, другая глобальная проблема — наличие «подвалов» и, особенно, «шапок» случайной величины, «лишних» строк — какие‑нибудь «ИТОГ», «СУММА» и т. п. — вставленных непредсказуемым образом — реально заводит в тупик. Также, нет никакого простого способа считать многострочный заголовок, особенно, если он собран местами из «объединенных» (merged) ячеек.
Вот взять, например, десять файлов — в восьми из них шапка занимает 15 строк, и заголовок — 4 строки, в двух оставшихся шапка, внезапно, 16 строк. В одном из первых восьми файлов есть строка итогов внизу таблицы, а в одном из двух оставшихся — итоги вставлены сразу после заголовка… Даже лучшие из существующих инструментов потребуют индивидуальной подгонки параметров для чтения каждого файла, что порождает простыню «одноразового», почти непригодного для переиспользования, кода. Мой же проект предназначен для того, чтобы, по возможности, решить все эти сложности, и при этом оптимизировать траты системных ресурсов.
Добрый день!
На сайте Pypl с документацией к данной библиотеке указаны актуальные ссылки на onnx-файлы, необходимые для работы модели.
Добрый день!
Тестировщики у нас к работе подключаются после завершения разработки. Тестировщики не трогают юнит-тесты, пишут только свои интеграционные.
Юниты мы так и оставляем на моках, в нашем случае этого всегда достаточно .
Добрый день!
Вы правы, идея использовать global была не самой лучшей.
Сейчас собираю обратную связь и буду проводить code review, чтобы такие моменты исправлять.
Добрый день, спасибо за комментарий!
Ранее ничего не слышал о данном фреймворке, streamlit оказался довольно занимательным инструментом. Если вариант задачника на Flask не выстрелит, то попробую сделать решение на streamlit'е.
Добрый день, если дадут добро на размещение, то проект в немного изменённом виде появится на github.
Добрый день, спасибо за вопрос!
Вы правы, лучше всего использовать примеры из документации.
Если проект продолжит развиваться, то я обязательно переработаю формат запросов, дополнительно разобрав защиту от sql инъекций.
На данном момент использовать такой формат запросов считаю уместным только в качестве примера для демонстрации логики.
Добрый день!
В контексте данной задачи специализированные модели значительно лучше ведут себя, чем модели общего назначения, поскольку они обучались на данных для решения именно этой проблемы. Даже «нормальная модель» не дает гарантий, что сгенерированный ответ будет корректный. Пока что всё ещё необходимо проверять результат работы модели, поскольку LLM’s галлюцинируют и находятся не на том уровне, когда пользователь может безоговорочно доверять всему, что ему выдает AI-помощник.
Вы правы, можно настроить подключение к другой языковой модели, прописать вызов функций и работать напрямую с результатом. Но я привела примеры бесплатных моделей, при использовании которых у пользователя не возникнет ограничений или сложностей, связанных как с интерфейсом (веб-интерфейс понятен и доступен многим), так и со сложностью разработки (не нужно ничего прописывать, кроме самого запроса на естественном языке).
Добрый день!
Вопрос интересный, автор взял время чтобы разобраться в нём.
Вы правы. Существуют различные модели и методы, решающие данный тип задач. Пост носит обзорный характер, и я предлагаю использовать LLM на ряду с другими инструментами.
Добрый день! Конечно, данные ИИ-инструменты выступают только в роли помощников, но никак не в роли полноценной замены сотрудников, напрямую работающих с БД. Я не рекомендую полностью полагаться на запросы, сформированные AI-плагинами, но в случае затруднений можно обратить на них внимание.
Добрый день!
Спасибо за замечание про pkl - учту при работе с данными.
Про pyarrow не знал - возьму на заметку.
Добрый день!
Термины на то и термины, что они подразумевают что-то под собой, но своим названием не всегда могут передать свой смысл.
Что касается перевода skip connections: пытался что-нибудь придумать, но ничего лучше не выдумал.
Добрый день! Не готов сказать наверняка. Все очень сильно зависит от масштаба и качества видео.
Добрый день!
Из соображений конфиденциальности мы не можем дать ссылку на датасет и на его структуру. Повторимся, что датасет содержит как численные, так и категориальные переменные, работу с которыми мы и показали. Нашей целью было показать методы PySpark работы с ними, поэтому конкретная структура таблицы и значения признаков для демонстрации необязательны.
Спасибо за интерес к посту!
Добрый день!
Касаемо файнтьюнинга, то как уже было упомянуто в посте, наибольший прирост в скорости наблюдается если:
обучать на больших батчах;
использовать тяжёлую модель;
максимально занять GPU;
обучать на много эпох.
Если применить только одну рекомендацию(в вашем случае тяжелая модель с большим количеством параметров), то маловероятно, что будет наблюдаться прирост в скорости.
Нам в работе такие инструменты не встречались, возможно ИИ пока не дошёл до такой степени автоматизации, или мы просто ещё не знаем о нем. Будем благодарны, если кто-то поделиться таким инструменте.