Comments 16
Зачем Python, если для того, чтобы подключить таблицу из БД сразу для просмотра и редактирования на Delphi не нужно писать ни одной строчки вообще? Даже если у тебя запрос в бд написан руками, то возможность редактировать данные напрямую в таблице сразу в нескольких таблицах БД всё равно остается. Вывод графиков точно так же может быть напрямую из запроса или любого датасета. А не хочешь редактировать данные напрямую в таблице, то подключение полей ввода тоже делается вообще без какого-либо кода. И всё это без сторонних библиотек.
Зачем тут вообще питон, если есть просто SQL или даже PL/SQL?
Думаю, автор описал довольно адекватный набор инструментов и практик для тех, кому не хватает экселя при анализе данных. ИМХО Delphi - странный выбор. Есть достаточно специализированного ПО для анализа данных. Связка: базовый питон с пандас и библиотекой для графиков в юпитер ноутбуке имеет сопоставимый невысокий порог входа, популярны, универсальна, легко автоматизируются и способна развиться, например, в какой-нибудь красивый корпоративный дашборд работающий в браузере. Причем этот дашборд способен в короткие сроки создать и дальше поддерживать начинающий программист уровня "копирую код из примеров". (проверено на себе) ))
Здравствуйте! Про кейс с Delphi не слышал, а что касается наличия Python, так он нам помог обработать данные в одном ноутбуке, это намного удобнее чем в excel. Также подобный пайплайн данных может включать в себя и сбор данных по API, и вообще еще круче: участие DAGs в Airflow. Но это все уже для продвинутых пользователей.
Мне кажется, что и с документацией и поддержкой именно этой схемы проблем быть не должно. Я думаю питониста средней квалификации можно найти за 5 минут в любом старбаксе, а вот дельфиста, наверное нужно долго искать.
Старался передать сам принцип сбора, обработки и анализа данных на этих инструментах, разбирая и поясняя самые азы.
вы забыли, что у менеджеров нет проблем работать с получением данных из источников. Ключевым моментом в выборе системы является её юзабилити, в консолях отсутствует форматирование,. Люди любят копировать таблички, красить цветами, выделять и тп
Да есть 2 вида работы с excel: первый - анализ данных, второй - планирование, раскрашивание, декомпозиция, составление графика дежурств на кухне. Я больше про первый тип, когда в компаниях несколько филиалов и подразделений, которые например отчеты подают в одной форме, и их нужно забирать в один фаил "прицепляя" эти таблицы и снизу и слева друг к другу. Уверен, что кейс не самый частый, но востребованный.
Итоговые отчеты и сводные таблицы, все равно будут раскрашивать)
Спасибо за замечание!
Класс, спасибо за инфу
Разумеется, автор может выбрать любой удобный ему стек, чтобы работать с данными. Это не отменяет того факта, что недостатки Excel из коробки тут описаны, прямо скажем, предвзято. Давайте по пунктам:
Какие есть серьезные проблемы при работе в Excel файлами, кроме очевидных преимуществ.
Нужно писать на языке VBA, чтобы автоматизировать рутину: например, очищать данные, или приводить их к нужному виду. Или вам приходится заказывать эти скрипты в it отделе, а они почему то не спешат вам помочь.
Трудно работать с версиями, делать бэкапы. Код макроса может внезапно перестать работать, а на наладку может уйти много времени.
Нужна лицензия на полноценную работу, есть привязка к Windows, что сейчас крайне актуально для многих компаний в РФ с переходом на Linux. А python и СУБД (Например SQLite или PostgreSQL) имеют открытый исходный код и распространяются свободно.
Код макроса может перестать работать после обновления Excel.
Ограничение excel по размеру в миллион строк, и зависание при работе на больших массивах (более 200 000 строк на средних офисных машинах)
Нет, VBA не нужно. Уже давно можно писать на любом языке, поддерживающем COM, включая кстати и питон. А так штатный язык я бы сказал на сегодня C#.
Это также верно и для любого другого стека. Если у вас поменяется структура документа - ваш код сломается. Что же до версий скрипта - то его надо делать плагином, а не держать в одной таблице с данными - и все с ним будет хорошо, включая возможность хранить его в VCS.
Ну разумеется нужна. Это платный продукт. За эти деньги вы получаете свои плюсы. А за пользование продуктом бесплатным вы тоже платите - своим временем, как правило.
Ваш код тоже может перестать работать по многим разным причинам.
Да, ограничение по размеру конечно есть. И я бы даже сказал более сильное, чем миллион строк. Если у вас датасет правда больше - вам прямой путь к СУБД. Это не проблема Excel, это ограничение, его надо было учесть при выборе технологии.
Ну то есть, я бы сказал, что три претензии - не сильно по делу, и еще две - валидные, но намекают на то, что пользоваться Excel и автоматизировать работу в нем тоже нужно уметь.
Хорошо, что вы прошлись этим пунктам, но я отвечу:
Как много фирм в РФ готовы нанять специалиста по C# для оптимизации работы с данными? И как много специалистов по C# знают хорошо доменную область, чтобы знать, как выводить те или иные агрегаты или метрики, pnl for example? Сейчас даже финансисты с удовольствием учат python, чтобы автоматизировать рутину по подготовке этой информации. Мое мнение, что финансисту проще выучить язык, чем сишарписту - финансы. Это новая грамотность.
Соглашусь.
Плюсы да, но они и платить за зарубежный софт все труднее. Красить таблицы можно и в OpenOffice, а вот чего там нет, так это аналога Power query/bi/pivot. Многие корпораты уйдут в сторону открытого ПО, яркий пример Superset вместо больой bi тройки.
Да, но эту проблему решают тесты, теоретически. Не знаю, насколько просто их организовать в vba?
Тесты в VBA пишутся точно так же, как в любом другом языке. Просто инструмент их запуска будет другой.
Что до C#, то я скорее хотел сказать, что автоматизировать работу с Excel можно практически на любом языке, который поддерживает Windows, потому что он скорее всего поддерживает COM. Скажем, я это делал примерно на четырех разных языках. И если вам так уж хочется - то ActivePython это умеет не помню уже сколько лет (больше 20-ти точно).
Python + Jupyter и прочие Панды и Нампаи стали стандартным набором для аналитиков. Много документации, дополнительный библиотек и обучалок и прочего. И Винда не обязательна (кстати, как её ныне официально купить?).
А вот использовать Эксель (да любой табличный редактор) для хранения и анализа данных - плохая идея. 200 тыс строк - и тормоза. Всё же базы данных для этого придуманы.
Если вы перечитаете ветку с начала, то я с этого начал. Выбор стека - не вопрос, автор может его выбрать какой хочет, даже просто потому, что питон знает.
Я лишь намекаю, что некоторые утверждения автора про Excel и его использование - не совсем точные. А так вы совершенно правы, я хранил в Excel (64 битовый обязателен) порядка 500 тыс строк, это ужас-ужас. Это можно сделать, чтобы куда-то данные передать, показать, ну там не знаю, графики построить (хотя на таком объеме оно еле шевелится).
Было бы гораздо интереснее, если показали динамику ща последние 3-4 месяца. Что там происходит после поднятия ставки и урезания ипотеки.
Датасет с 2013 по 2023, октябрь, покупался у фирмы торгующей подобными данными для целей анализа цен. Больше не работаю с этим проектом, и данных за февраль у меня нет. Вы можете посмотреть сайты dataflat или bnmap, там много открытых данных о ситуации на рынке. Они же продают такие датасеты.
Да, такой анализ провести можно было, и я его проводил на тот момент. Очень сильное затоваривание рынка, построили больше, чем могли продать все застройщики в России.
В статье написан SQL-путь анализа с самой быстрой SQLite (но DuckDB теперь уже быстрее).
Хорошо в статьей показано где SQL уступает Pandas-у - в "итерационной" чистке данных. SQL-запрос с длинной цепочкой CAST SUBSTR() AS будет и дольше работать, и его труднее составить. А главное - затруднено пере-использование кода. В Python вы буквально со второго раза сообразите, что часто повторяющееся действие нужно вынести в виде UDF в свой модуль (py-файл), и тогда работа с любой табл. информацией будет идти в ячейках JupyterLab логично:
df.Дата = df.Дата.apply(рус_дата_в_iso) # 28/02/24 28.02.24 28.02.2024 -> 2024-02-28
В UDF() постепенно перейдет половина кода из статьи, даже рисование графиков, и это главный путь повышения продуктивности дата-аналитика. Кстати, кириллические имена UDF в Python/SQLite работают прекрасно, и это лучший способ поделить пространство имен на две части для тех, кому английские слова напоминают что-то другое (например конструкции языка или функции библиотек). Естественно, они м.б. длинными, все равно их никто руками не набирает (в JupyterLab прекрасно работает Автодополнение для всего).
Дата-саентисты непременно будут делать весь подобный анализ целиком в Python/Pandas/JupyterLab, но только если объем таблицы менее 10-20 млн. строк. Если больше - база в RAM не поместится и надо переходить на SQLite. Но сам анализ все равно будет в Pandas, просто таблицы для анализа будут браться SQL-запросами с отбором строк/полей (не целиком). Применение Dask/Polars кратного роста скорости не даст, это скорее инструменты для сотен миллионов строк.
Прямо в Pandas легче с-JOIN-ить все таблицы в одну (это называется обогащение данных). И вот ее, в самом конце, можно записать в SQLite-файл (для тех кто умеет только в SQL).
Но в среде Pandas хранение в сжатом колоночном Feather-формате с посл. считываением в RAM - более быстрое во всех аспектах применения, оставляя далеко позади другие способы.
Документацию DuckDB прочитал в декабре, и теперь буду использовать только ее, из-за обилия аналитических функций. Про скорость https://duckdblabs.github.io/db-benchmark/
У вас очень верные и глубокие дополнения.
SQL и python для анализа цен на новостройки в СПб или ценнейший навык для маркетолога в 2024