оокей ) но конечно не плохобы научится в простую БД и туда закачивать данные, тогда появится SQL и станет все проще

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

а что за енвайромент, он позволяет вытащить данные по условию?

Из API данные вытаскиваются в датафрейм pandas, а дальше в pandas есть огромный инструментарий для того, чтобы этими данными вертеть: делать выборки, строить сводные таблицы, агрегировать и ещё кучу всего

ну возможно, просто когда я пытался сделать отчеты которые дают ответы на поставленные вопросы - там без БД и нормального кодинга не обойтись. Вытащить данные из апи это вершина айсберга. Но наверное у меня задачи другие были.

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

Тогда нет нужды запускать код чанками.

В основном, сам код пайплайна пишется кусками. Тут дело не в размере данных, а в том, что так удобно быстро валидировать что на определенном этапе пайплайна с данными всё ок. Если набрасывать весь пайплайн сразу, то можно потом сильно задолбаться с отладкой. И отладка тут не в том, что мы смотрим на стектрейс, а смотрим что происходит с данными на каждом этапе пайплайна

Так можно на любом шаге принтовать всё что хочешь. Смотреть оно ли, и идти дальше добавлять шаги в пайплайн.

Чет не понял аргумента.

Мне кажется, это скорее дело подхода. Написать весь алгоритм целиком и принтовать или последовательно отлаживать каждый этап пайплайна. Я для себя вижу плюс в том, что я могу быстрее понять что не так, когда последовательно обрабатываю. И использовать для отладки уже существующий environment, без необходимости запускать предыдущие этапы пайплана. В добавок, если на каких-то этапах нужны визуализации, то в рамках ноутбука их удобно выводить в новом output

если я правильно понял вопрос, в pycharm можно точно так же работать, как в юпитере. ноутбуки туда интегрируются.

Почему "написать весь алгоритм целиком"? По шагам конечно.

В чём плохость запускать предыдущих этапов? Просто берешь часть данных такого размера, чтобы все было быстро.

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

Я не говорю, что запускать предыдущие этапы плохо. Всё зависит от задачи. Если речь идёт про какой-нибудь разведывательный анализ данных, то лично мне удобнее работать с environment-ом без необходимости перезапускать все предыдущие вычисления

Если лично удобно, то и отлично.

Но я хотел понять, почему это удобнее. Если скорость уже отмели, то я не понял какой аргумент остаётся за repl.

Вот загрузил я датафрейм. Предположим, вообще никогда данные не видел, но есть какая-то задача с ними. Потом я пишу в одной ячейке вывод df и вижу сразу датафрейм, затем понимаю, что с ним нужно сделать, например какие значения заменить, какие строки удалить и т.д. Сделал нужное изменение и потом в следующей ячейке делаю что-то ещё. И у меня перед глазами всегда остаётся результат предыдущего выполнения, предыдущее состояние датафрейма, я визуально понимаю весь пайплайн за счет отпутов. Потом допустим я понимаю, построив какое-то распределение, что у меня не то что-то с данными, возвращаюсь к одной из предыдущих ячеек и выполняю код начиная с неё

Вот вы в jupyter notebook пишете код в одной ячейке?

Если ты видишь сразу весь датафрейм, и по аутпуту решаешь какие строки удалить, то это какой-то датафрейм из десяти строк.

Ну и понимать пайплайн за счёт аутпутов это такое себе, если честно.

Нет.

всем привет.
новичок в python пока всему только учусь.
подскажите можно ли описанную ниже задачу обернуть в последовательное выполнение (видел примеры как с pipe работают или через цепочки вызывают выполнение) и нужно ли?

logs.columns = ['ip', 'drop1', 'date','url', 'status', 'drop2', 'referrer', 'userAgent', 'drop3', 'drop4','drop5', 'domain']
logs = logs.drop(['drop1', 'drop2', 'drop3', 'drop4','drop5'], axis=1)
logs['url'] = logs['url'].map(lambda x: re.sub('\s|GET|HTTP\/1.1|POST','', str(x)))
logs['date'] = logs['date'].map(lambda x: re.sub('\[|\]|\+0300|\s','', x))

columns можно переименовать через set_axis с параметром axis=1 и inplace=True

drop также можно сделать с inplace=True

А вот map, наверно, можно сделать только через pipe. По сути, можно будет сделать одну функцию и в неё завернуть обе эти операции

Тогда в итоге получится logs.set_axis([...], inplace=True, axis=1).drop([...], inplace=True).pipe(function)