У проводок же ещё сто пятьдесят аналитик, кроме счета, какого размера будет граф в сколько-нибудь реальном учете? Какую бизнес-задачу решаем? Да, красиво, интересно. Вопрос только в конечной цели.
copy поддерживает commit/rollback, так что судьбу импортированных записей можно решить самому, в том числе в случае удачного завершения (в отличие, к примеру, от ораклового sqlldr). В статье бы, конечно, стоило добавить описание работы "под капотом", чтобы было понятно, за счёт чего это достигается (что это не просто fast=true).
Про МДМ вообще непонятно. Ну, например, есть у нас справочник номенклатур на 1.5 млн позиций. Как заводить меппинг для него? Или про сырой слой DWH. Загружаются к нам данные в виде девятиэтажных вложенных массивов, как их разбираем по объектам и проводим дедубликацию, какой тут подход?
Безотносительно качества примеров, советы в конце статьи - это примерно как говорить "не нарушайте законы, вас могут поймать". Что теряет кандидат, когда обманывает? Ничего, только свое время. При этом получает хороший шанс проскочить в какое-нибудь "богатое" место, где денег очень много, а процессы настолько запутанные, что затеряться там на годик вполне можно. Дальше идём в новое место. И таким образом, все также не имея никакого толкового опыта, этот пилигрим уже имеет реальные записи в резюме с возможностью их подтвердить, но вообще не понимает ничего: потому что крудошлепил/заполнял формочки по шаблону/делал как сказали. А причины тут две: нет никакого способа таких вот накручивателей отсеивать заранее и готовность слишком богатых компаний брать с рынка хоть кого-то, потому что могут. А потом они идут в другие места с соответствующими запросами, и тратят чужое время на тех. собесе. Только в минусе не кандидат, а компания и собеседующие. Знает он там, как должен (не)работать какой-то говнокод или нет - вообще дело десятое. Если человек может внятно объяснить, что именно и зачем он делал, какие задачи решал, как и почему именно так - это уже успех. Часто даже это не могут объяснить (ну я там данные загружал, ну иногда инциденты приходили, искал). А то, что вместо кортежа получится генератор, можно увидеть при первом же запуске кода, и для этого не нужно обладать какими-то особенными знаниями.
Как уже отметили, у Excel есть большой плюс: GUI и привычность пользователю. И обычно шаг от наколеночного решения до опромышливания - гигантский. Если хочется убрать вырвиглазный ВПР (индекс поискпоз куда гибче, кстати), то в качестве первого приближения можно было бы использовать стандартный Power Query:
Всё остаётся в том же файле с тем же интерфейсом.
Можно разделить большой файл сырых данных на отдельные файлы а-ля горячее/холодное хранение и обновлять только горячие данные без ожидания обновления всех формул.
Гибкость не хуже SQL. Есть много настроек через кликание мышкой.
Никакого питона, который неоткуда взять случайному пользователю в компании.
Ноль дополнительной инфраструктуры (ведь Postgres и планируемый Airflow мы не в воздухе запускаем)
Никаких дополнительных проблем с доступами и полномочиями: все на уровне того же файла.
Можно по-прежнему собирать данные из разных источников и локально крутить-вертеть независимо от технологий и интеграций: экспорт поддерживается в том или ином виде почти везде.
Если когда-то наступят светлые времена, можно прозрачно для пользователя подменить некоторые таблицы на таблицы СУБД: для пользователя ничего не изменится, есть pushdown.
Питоны - это классно, но только для упрощения жизни себе. Для того, чтобы такое решение можно было распространить в компании, надо провести очень немало организационных мероприятий и приложить ему усилий, а все это помимо никуда не девающейся сложность настройки и последующей актуализации/доработки.
Это не вписывается в интересы компании. А как же обновления ради обновлений? Сейчас же почти везде так. Передвинули меню, в фильтры добавили никому ненужные критерии и убрали нужные, добавили тормозов и рекламы. И вот уже бэклог того, что нужно фиксить в следующем релизе. А ваш проект выкатил и даже сопровождать не надо, вообще беспредел.
Ни разу не видел в сапе, чтобы перемещения в логистике каким-то образом решались через сторно, в том числе в компаниях с непростой логистикой. Во-первых, там разнесены логистика и бухгалтерия, и не все шевеления в логистике шевелят бухгалтерию, а во-вторых, там достаточно сущностей, которые могут корректно отражать промежуточные состояния заказа без необходимости что-либо сторнировать. И учитывать финансовые и логистические документы до/после фактической поставки. Какие-то выдуманные истории, вы сап видели дальше, чем скрин из SPRO? Я не адепт сапа, и мне все равно, на какой платформе что-то там работает (таковы исходные условия, надо под них подстроиться), но доводы очень слабые. Технологически он зрелый, имеет возможность кастомизации (в том числе через костыли, как любой другой инструмент), причем одно и то же можно настроить по-разному, он выполняет свою задачу, и пользователям в целом плевать на ущербный интерфейс через несколько месяцев работы. А если в какой-то критический момент он встанет раком, ИТ директору не придется изворачиваться, почему он выбрал "этот сап" - потому что проверено многими. Экспериментировать с различными платформами, когда один час простоя твоего предприятия выливается в миллионы денег, не каждый рискнёт.
Я давненько не бывал на собесах сам, но при просмотре кандидатов как раз исхожу из того, чем он занимался ранее: если может внятно рассказывать, можно в случайном месте навести фокус и услышать детали (а не "ну там это потому что ХЗ ТЗ"), на неизвестные подходы/технологии может найти аналогию в своем опыте и объяснить - значит, человек умеет понимать и разбираться. А если 5 лет работал и ответы из серии "в фреймворке X это надо делать вот так", то и у себя он дальше "говорят, что надо так" не уйдет.
Вообще в boto3 put_object умеет принимать на вход стрим, поэтому в текущей реализации без дополнительного кода по обработке частично упавшей загрузки можно сразу соединить вход и выход без явного использования метода read(put_object сам его вызовет под капотом). Заодно неплохо сэкономить на локальном хранилище/памяти.
Исходя из типичного содержания статей по ИИ выходит, что в эпоху ИИ на самом деле важно наличие вайба, инсайтов и неумения программировать (именно программировать, а не набирать код). Интересен вопрос: можно ли имея только вайб раздобыть инсайт от того же ИИ, или источником инсайнов должно быть что-то внешнее относительно этой системы? И как набрать команду вайбкодеров с вайбами, которые будут суммироваться в продукт, а не ноль (вдруг у двух вайбкодеров противоположные вайбы?). Вот такую бы статью запилили для разнообразия.
Описанный флоу выглядит вывернутым наизнанку, потому что в самом пайплайне можно сделать билд, затем тест, а уже работающее потом упаковать в образ и задеплоить. Но если хочется контейнеризовать, а потом тестировать, то в билде собираем образ, пушим в реестр (Github Packages/Gitlab container registry/Dockerhub), потом оттуда забираем образ для стейджа test, указав его явно в файле пайплайна:
test:
stage: test
image: dockeraccount/myapp:test_version_tag
script: |
pytest #example
Тогда и логи, и репорты прокинуть можно без лишних приседаний, и не нужно писать скриптовую обёртку, чтобы запустить контейнер с нужными параметрами, войти в него, а только потом запускать команды теста. Если контейнер нужен как что-то сбоку для тестов (например, СУБД), то в .gitlab-ci.yml, например, есть секция services, где также можно указать нужный кастомный image из первого шага, а тесты запускать в самом контейнере джоба.
Это все, конечно, неизбежно, только сначала необходимо эволюционировать само хранение. Никто не ходит в БД с вопросами "посчитай выручку за месяц", где надо просто сделать суммирование с группировкой. Что это за модель такая, где возврат это просто отдельная колонка в БД? Это целый бизнес процесс с кучей побочных эффектов, и простого описания имён колонок не хватит, нужно описывать все варианты реализации бизнес-логики, которая наполняет эту модель. Буквально недавно как раз в логистике возникла задача добавления даты отгрузки в отчёт. Что может быть проще? А нет, это запись в таблице движения материалов с определенным видом движения и с определенных складов. И только для одной из нескольких схем реализации. Посмотрим на эти же прогнозы лет через 10, уже видели "self service bi".
отсутствие указания алиасов таблиц перед столбцами, не являющееся ошибкой в общем случае, может давать очень интересные результаты
Что это не ошибка, но крайне полезное и важное дополнение запроса для последующего сопровождения и отладки, которым новички обычно пренебрегают. Запрос несуществующего столбца нигде не рассматривался. И комментарий был о том, что ошибки, которые выявляются на этапе парсинга запроса, упоминать в качестве типовых очень странно: их легко исправить (если это не Oracle с его крайне общими текстами ошибок, хотя сейчас LLM должны легко и с ним помочь).
На основании чего мы получим Syntax Error? Где-то запрещены корелляции в списке выражений select/where в подзапросах, если это не join? Ниже есть работающий пример, и с такими ситуациями сталкивался много раз: начиная с того, что кто-то сгенерировал имя поля с кириллицей (и вместо выборки из таблицы получаем кореллированный подзапрос, который возвращает "что-то не то"), заканчивая тем, что оптимизатор напутал в портянке вложенных подзапросов.
Отсутствие group by это все же compile-time ошибка, она выявляется легко, если запрос хотя бы запускали. Сюда можно и пропущенные запятые и несоответствие скобок/кавычек включать тогда. А вот отсутствие указания алиасов таблиц перед столбцами, не являющееся ошибкой в общем случае, может давать очень интересные результаты, особенно с подзапросом:
select *
from t1
where id in (
select id
from t2
)
Дропаем колонку id в таблице t2 и получаем where t1.id is not null. Ну а спутать count и sum - без комментариев. Там можно и с sttdev спутать, чего бы и нет.
Восприятие Airflow как ETL-инструмента - это прям какая-то распространенная болезнь, видимо, из-за примеров в их доке (где таск 1 что-то производит, а таск 2 это потребляет напрямую как данные, хотя обычно так никто не делает). Airflow - это планировщик с GUI. Вот у Dagster другой концепт, хочется тоже попробовать.
Да это все утопические мечты. "Вот сейчас мы напишем фреймворк, и программировать не надо будет". После чего вместо 100 лид синьор девелопер появляется 10000 крудошлепов, рождаются эксперты по использованию фреймворка, внутри него возникает какое-то ранжирование и т.п. По своей работе всегда забавляет тот факт, что в нынешнюю эпоху при наличии SQL и драгндроп BI/ETL инструментов бизнес так и не делает в них ничего руками, а нанимают условных "программистов", которые доводят всю эту подложку до состояния бери и смотри.
Такой конфиг проще реализовать ребалансом команды, как во время отпусков: часть работает с выходным в один день, часть в другой. И все закрыто. Повстречаться в свой выходной тоже по-разному может быть: несколько раз бывало, что подключишься в середине дня на встречку в отгул, а потом ощущение, что и +- час вокруг встречи какие-то некомфортные, и вроде поотдыхал, но вроде и не отдохнул.
У проводок же ещё сто пятьдесят аналитик, кроме счета, какого размера будет граф в сколько-нибудь реальном учете? Какую бизнес-задачу решаем? Да, красиво, интересно. Вопрос только в конечной цели.
copyподдерживает commit/rollback, так что судьбу импортированных записей можно решить самому, в том числе в случае удачного завершения (в отличие, к примеру, от ораклового sqlldr). В статье бы, конечно, стоило добавить описание работы "под капотом", чтобы было понятно, за счёт чего это достигается (что это не просто fast=true).Про МДМ вообще непонятно. Ну, например, есть у нас справочник номенклатур на 1.5 млн позиций. Как заводить меппинг для него? Или про сырой слой DWH. Загружаются к нам данные в виде девятиэтажных вложенных массивов, как их разбираем по объектам и проводим дедубликацию, какой тут подход?
Безотносительно качества примеров, советы в конце статьи - это примерно как говорить "не нарушайте законы, вас могут поймать". Что теряет кандидат, когда обманывает? Ничего, только свое время. При этом получает хороший шанс проскочить в какое-нибудь "богатое" место, где денег очень много, а процессы настолько запутанные, что затеряться там на годик вполне можно. Дальше идём в новое место. И таким образом, все также не имея никакого толкового опыта, этот пилигрим уже имеет реальные записи в резюме с возможностью их подтвердить, но вообще не понимает ничего: потому что крудошлепил/заполнял формочки по шаблону/делал как сказали. А причины тут две: нет никакого способа таких вот накручивателей отсеивать заранее и готовность слишком богатых компаний брать с рынка хоть кого-то, потому что могут. А потом они идут в другие места с соответствующими запросами, и тратят чужое время на тех. собесе. Только в минусе не кандидат, а компания и собеседующие. Знает он там, как должен (не)работать какой-то говнокод или нет - вообще дело десятое. Если человек может внятно объяснить, что именно и зачем он делал, какие задачи решал, как и почему именно так - это уже успех. Часто даже это не могут объяснить (ну я там данные загружал, ну иногда инциденты приходили, искал). А то, что вместо кортежа получится генератор, можно увидеть при первом же запуске кода, и для этого не нужно обладать какими-то особенными знаниями.
Как уже отметили, у Excel есть большой плюс: GUI и привычность пользователю. И обычно шаг от наколеночного решения до опромышливания - гигантский. Если хочется убрать вырвиглазный ВПР (индекс поискпоз куда гибче, кстати), то в качестве первого приближения можно было бы использовать стандартный Power Query:
Всё остаётся в том же файле с тем же интерфейсом.
Можно разделить большой файл сырых данных на отдельные файлы а-ля горячее/холодное хранение и обновлять только горячие данные без ожидания обновления всех формул.
Гибкость не хуже SQL. Есть много настроек через кликание мышкой.
Никакого питона, который неоткуда взять случайному пользователю в компании.
Ноль дополнительной инфраструктуры (ведь Postgres и планируемый Airflow мы не в воздухе запускаем)
Никаких дополнительных проблем с доступами и полномочиями: все на уровне того же файла.
Можно по-прежнему собирать данные из разных источников и локально крутить-вертеть независимо от технологий и интеграций: экспорт поддерживается в том или ином виде почти везде.
Если когда-то наступят светлые времена, можно прозрачно для пользователя подменить некоторые таблицы на таблицы СУБД: для пользователя ничего не изменится, есть pushdown.
Питоны - это классно, но только для упрощения жизни себе. Для того, чтобы такое решение можно было распространить в компании, надо провести очень немало организационных мероприятий и приложить ему усилий, а все это помимо никуда не девающейся сложность настройки и последующей актуализации/доработки.
Это не вписывается в интересы компании. А как же обновления ради обновлений? Сейчас же почти везде так. Передвинули меню, в фильтры добавили никому ненужные критерии и убрали нужные, добавили тормозов и рекламы. И вот уже бэклог того, что нужно фиксить в следующем релизе. А ваш проект выкатил и даже сопровождать не надо, вообще беспредел.
Ни разу не видел в сапе, чтобы перемещения в логистике каким-то образом решались через сторно, в том числе в компаниях с непростой логистикой. Во-первых, там разнесены логистика и бухгалтерия, и не все шевеления в логистике шевелят бухгалтерию, а во-вторых, там достаточно сущностей, которые могут корректно отражать промежуточные состояния заказа без необходимости что-либо сторнировать. И учитывать финансовые и логистические документы до/после фактической поставки. Какие-то выдуманные истории, вы сап видели дальше, чем скрин из SPRO? Я не адепт сапа, и мне все равно, на какой платформе что-то там работает (таковы исходные условия, надо под них подстроиться), но доводы очень слабые. Технологически он зрелый, имеет возможность кастомизации (в том числе через костыли, как любой другой инструмент), причем одно и то же можно настроить по-разному, он выполняет свою задачу, и пользователям в целом плевать на ущербный интерфейс через несколько месяцев работы. А если в какой-то критический момент он встанет раком, ИТ директору не придется изворачиваться, почему он выбрал "этот сап" - потому что проверено многими. Экспериментировать с различными платформами, когда один час простоя твоего предприятия выливается в миллионы денег, не каждый рискнёт.
Да-да, очень напоминает статьи Minerva Soft, и уровень вовлечённости резко падает
Я давненько не бывал на собесах сам, но при просмотре кандидатов как раз исхожу из того, чем он занимался ранее: если может внятно рассказывать, можно в случайном месте навести фокус и услышать детали (а не "ну там это потому что
ХЗТЗ"), на неизвестные подходы/технологии может найти аналогию в своем опыте и объяснить - значит, человек умеет понимать и разбираться. А если 5 лет работал и ответы из серии "в фреймворке X это надо делать вот так", то и у себя он дальше "говорят, что надо так" не уйдет.Вообще в boto3
put_objectумеет принимать на вход стрим, поэтому в текущей реализации без дополнительного кода по обработке частично упавшей загрузки можно сразу соединить вход и выход без явного использования методаread(put_objectсам его вызовет под капотом). Заодно неплохо сэкономить на локальном хранилище/памяти.Исходя из типичного содержания статей по ИИ выходит, что в эпоху ИИ на самом деле важно наличие вайба, инсайтов и неумения программировать (именно программировать, а не набирать код). Интересен вопрос: можно ли имея только вайб раздобыть инсайт от того же ИИ, или источником инсайнов должно быть что-то внешнее относительно этой системы? И как набрать команду вайбкодеров с вайбами, которые будут суммироваться в продукт, а не ноль (вдруг у двух вайбкодеров противоположные вайбы?). Вот такую бы статью запилили для разнообразия.
Описанный флоу выглядит вывернутым наизнанку, потому что в самом пайплайне можно сделать билд, затем тест, а уже работающее потом упаковать в образ и задеплоить. Но если хочется контейнеризовать, а потом тестировать, то в билде собираем образ, пушим в реестр (Github Packages/Gitlab container registry/Dockerhub), потом оттуда забираем образ для стейджа test, указав его явно в файле пайплайна:
Тогда и логи, и репорты прокинуть можно без лишних приседаний, и не нужно писать скриптовую обёртку, чтобы запустить контейнер с нужными параметрами, войти в него, а только потом запускать команды теста. Если контейнер нужен как что-то сбоку для тестов (например, СУБД), то в .gitlab-ci.yml, например, есть секция services, где также можно указать нужный кастомный image из первого шага, а тесты запускать в самом контейнере джоба.
Это все, конечно, неизбежно, только сначала необходимо эволюционировать само хранение. Никто не ходит в БД с вопросами "посчитай выручку за месяц", где надо просто сделать суммирование с группировкой. Что это за модель такая, где возврат это просто отдельная колонка в БД? Это целый бизнес процесс с кучей побочных эффектов, и простого описания имён колонок не хватит, нужно описывать все варианты реализации бизнес-логики, которая наполняет эту модель. Буквально недавно как раз в логистике возникла задача добавления даты отгрузки в отчёт. Что может быть проще? А нет, это запись в таблице движения материалов с определенным видом движения и с определенных складов. И только для одной из нескольких схем реализации. Посмотрим на эти же прогнозы лет через 10, уже видели "self service bi".
Именно об этом и было сказано:
Что это не ошибка, но крайне полезное и важное дополнение запроса для последующего сопровождения и отладки, которым новички обычно пренебрегают. Запрос несуществующего столбца нигде не рассматривался. И комментарий был о том, что ошибки, которые выявляются на этапе парсинга запроса, упоминать в качестве типовых очень странно: их легко исправить (если это не Oracle с его крайне общими текстами ошибок, хотя сейчас LLM должны легко и с ним помочь).
На основании чего мы получим Syntax Error? Где-то запрещены корелляции в списке выражений select/where в подзапросах, если это не join? Ниже есть работающий пример, и с такими ситуациями сталкивался много раз: начиная с того, что кто-то сгенерировал имя поля с кириллицей (и вместо выборки из таблицы получаем кореллированный подзапрос, который возвращает "что-то не то"), заканчивая тем, что оптимизатор напутал в портянке вложенных подзапросов.
Отсутствие group by это все же compile-time ошибка, она выявляется легко, если запрос хотя бы запускали. Сюда можно и пропущенные запятые и несоответствие скобок/кавычек включать тогда. А вот отсутствие указания алиасов таблиц перед столбцами, не являющееся ошибкой в общем случае, может давать очень интересные результаты, особенно с подзапросом:
Дропаем колонку id в таблице t2 и получаем
where t1.id is not null. Ну а спутать count и sum - без комментариев. Там можно и с sttdev спутать, чего бы и нет.Восприятие Airflow как ETL-инструмента - это прям какая-то распространенная болезнь, видимо, из-за примеров в их доке (где таск 1 что-то производит, а таск 2 это потребляет напрямую как данные, хотя обычно так никто не делает). Airflow - это планировщик с GUI. Вот у Dagster другой концепт, хочется тоже попробовать.
Автоматическое снятие денег с карты с определенной периодичностью - это и есть подписка (определение модели оплаты), так что калька тут не при чем.
Да это все утопические мечты. "Вот сейчас мы напишем фреймворк, и программировать не надо будет". После чего вместо 100 лид синьор девелопер появляется 10000 крудошлепов, рождаются эксперты по использованию фреймворка, внутри него возникает какое-то ранжирование и т.п. По своей работе всегда забавляет тот факт, что в нынешнюю эпоху при наличии SQL и драгндроп BI/ETL инструментов бизнес так и не делает в них ничего руками, а нанимают условных "программистов", которые доводят всю эту подложку до состояния бери и смотри.
Такой конфиг проще реализовать ребалансом команды, как во время отпусков: часть работает с выходным в один день, часть в другой. И все закрыто. Повстречаться в свой выходной тоже по-разному может быть: несколько раз бывало, что подключишься в середине дня на встречку в отгул, а потом ощущение, что и +- час вокруг встречи какие-то некомфортные, и вроде поотдыхал, но вроде и не отдохнул.