Вообще в 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 инструментов бизнес так и не делает в них ничего руками, а нанимают условных "программистов", которые доводят всю эту подложку до состояния бери и смотри.
Такой конфиг проще реализовать ребалансом команды, как во время отпусков: часть работает с выходным в один день, часть в другой. И все закрыто. Повстречаться в свой выходной тоже по-разному может быть: несколько раз бывало, что подключишься в середине дня на встречку в отгул, а потом ощущение, что и +- час вокруг встречи какие-то некомфортные, и вроде поотдыхал, но вроде и не отдохнул.
Следующим будет стартап по замене тестировщиков (а чем они хуже кодеров?), в котором будут говорить об успешном применении абсолютно нового ИИ и ненужности "профессиональных тестировщиков". Далее позаботятся об аналитиках, которых заменят модели по генерации промптов для ИИ-тестировщиков из потока сознания заказчика на естественном языке (заодно с навыками угадывания мыслей). И вот собирается эта компашка стартапов и пишут сами себе приложения в своей уютной идеальной вселенной, где все друг друга понимают.
Задача: Определить порядок поездок для каждого клиента, отсортировав их по времени.
А я в решении прочёл полагание на то, что row_number все сделает за нас. Встречал решения, которые используют подобные предположения, но это сайд эффект, который в параллельной обработке может не сработать.
В запросе номер 4 вернётся просто месиво из данных. Чтобы это была последовательность поездок, надо явно указывать порядок сортировки в order by всего запроса. А тогда row_number() вообще не особо нужен: можно отсортировать по client_id, start_time. Ну и ограничения по числу строк везде отсутствует, как это потом смотреть?
Как-то сложно: класс-генератор дага, который хаком подсовываем в globals созданный даг (потому что для обнаружения нужен вызов на верхнем уровне, который отрабатывает при python -m dagfile.py), хотя можно использовать менеджер контекста with DAG(**conf) as dag: , и магическим образом все внутренние вызовы сложатся в этот даг. А для доступа к предыдущему шагу вполне "из коробки" подходит reduce. И не надо никакой класс.
Это все работает для однотипных задач с минимумом гибкости. Потому что когда-то возникнет мое любимое - передача параметров по пайплайну: в таком виде только xcom_pull с запоминанием id тасков спасет (не дай бог понадобится добавить группировку в таск группы). Ну и минус Jinja, минус питон объекты в качестве параметров (например, колбэки, кастомные расписания, динамически определяемые параметры запуска). Либо ту же Jinja прикручивать в обработчик YAML и парсить в нативные объекты. И вот мы вернулись к исходной задаче: написали YAML конфиг, написали парсер, это все преобразуется в питон объекты и генерирует даг. А можно было сразу написать питон файлы с тем же самым. Отличие только в from my.super.module import DoStuffOperator.
Подскажите, пожалуйста, способ выхода на глобальный рынок без локального. Или без слова "импортозамещение" тот же Яндекс станет компанией добра? Судя по всему, выходит так, что на локальном рынке только "быдланы", слушающие русский рэп (то есть 100% слушателей), а вот в глобальном - одни интеллектуалы и розовые пони, которые слушают правильную музыку. На том же Яндексе я узнал много хороших отечественных групп, что я делаю не так?
Хранить секреты можно в стандартных connection Airflow: там есть и аудит, и шифрование, и маскирование в логах. Доп параметры типа ID чата можно разместить в extra подключения. Тогда функцию считывания можно упростить, да и управление единообразное.
Так ровно по этой причине оракл не может вставить колонку в середину, иначе придется перелопатить все данные и устроить в них chained rows. Так как СУБД все же стала уделом программистов, и запросы типа select * не частые гости в UI (или как минимум являются бомбой замедленного действия), то порядок колонок после добавления чаще всего мало кого волнует. Если очень хочется навести порядок и использовать магию с наллами, то есть как альтернативные способы хранения разреженных данных, так и online redefinition. А вот как в MySQL реализована вставка колонки в середину при конкурентных апдейтах/инсертах и насколько оно действительно хорошо работает - интересный вопрос.
Сервер приложений SAP написан на ЯП 80-х годов, который взял многое из COBOL и который хоть и обогащался новыми фичами, но так и оставил легаси. Почему-то в 2024 году компании все ещё не гнушаются им пользоваться, а пользователи, не поверите, спокойно смотрят в без преувеличения УЖАСНЕЙШЕ выглядящие UI. А все потому, что они в нем работают, а не тестируют новые фичи ЯП и не любуются красотой кода.
Вообще в 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 инструментов бизнес так и не делает в них ничего руками, а нанимают условных "программистов", которые доводят всю эту подложку до состояния бери и смотри.
Такой конфиг проще реализовать ребалансом команды, как во время отпусков: часть работает с выходным в один день, часть в другой. И все закрыто. Повстречаться в свой выходной тоже по-разному может быть: несколько раз бывало, что подключишься в середине дня на встречку в отгул, а потом ощущение, что и +- час вокруг встречи какие-то некомфортные, и вроде поотдыхал, но вроде и не отдохнул.
Следующим будет стартап по замене тестировщиков (а чем они хуже кодеров?), в котором будут говорить об успешном применении абсолютно нового ИИ и ненужности "профессиональных тестировщиков". Далее позаботятся об аналитиках, которых заменят модели по генерации промптов для ИИ-тестировщиков из потока сознания заказчика на естественном языке (заодно с навыками угадывания мыслей). И вот собирается эта компашка стартапов и пишут сами себе приложения в своей уютной идеальной вселенной, где все друг друга понимают.
Про нумерацию даже не сказано.
А я в решении прочёл полагание на то, что row_number все сделает за нас. Встречал решения, которые используют подобные предположения, но это сайд эффект, который в параллельной обработке может не сработать.
В запросе номер 4 вернётся просто месиво из данных. Чтобы это была последовательность поездок, надо явно указывать порядок сортировки в order by всего запроса. А тогда row_number() вообще не особо нужен: можно отсортировать по client_id, start_time. Ну и ограничения по числу строк везде отсутствует, как это потом смотреть?
Как-то сложно: класс-генератор дага, который хаком подсовываем в globals созданный даг (потому что для обнаружения нужен вызов на верхнем уровне, который отрабатывает при
python -m dagfile.py), хотя можно использовать менеджер контекстаwith DAG(**conf) as dag:, и магическим образом все внутренние вызовы сложатся в этот даг. А для доступа к предыдущему шагу вполне "из коробки" подходитreduce. И не надо никакой класс.Это все работает для однотипных задач с минимумом гибкости. Потому что когда-то возникнет мое любимое - передача параметров по пайплайну: в таком виде только
xcom_pullс запоминанием id тасков спасет (не дай бог понадобится добавить группировку в таск группы). Ну и минус Jinja, минус питон объекты в качестве параметров (например, колбэки, кастомные расписания, динамически определяемые параметры запуска). Либо ту же Jinja прикручивать в обработчик YAML и парсить в нативные объекты. И вот мы вернулись к исходной задаче: написали YAML конфиг, написали парсер, это все преобразуется в питон объекты и генерирует даг. А можно было сразу написать питон файлы с тем же самым. Отличие только вfrom my.super.module import DoStuffOperator.Подскажите, пожалуйста, способ выхода на глобальный рынок без локального. Или без слова "импортозамещение" тот же Яндекс станет компанией добра? Судя по всему, выходит так, что на локальном рынке только "быдланы", слушающие русский рэп (то есть 100% слушателей), а вот в глобальном - одни интеллектуалы и розовые пони, которые слушают правильную музыку. На том же Яндексе я узнал много хороших отечественных групп, что я делаю не так?
Хранить секреты можно в стандартных connection Airflow: там есть и аудит, и шифрование, и маскирование в логах. Доп параметры типа ID чата можно разместить в extra подключения. Тогда функцию считывания можно упростить, да и управление единообразное.
То ли Яндекс как обычно: изменение ради изменения, тестировать не обязательно, все равно релиз через неделю. Надо же чем-то занять разрабов.
Так ровно по этой причине оракл не может вставить колонку в середину, иначе придется перелопатить все данные и устроить в них chained rows. Так как СУБД все же стала уделом программистов, и запросы типа select * не частые гости в UI (или как минимум являются бомбой замедленного действия), то порядок колонок после добавления чаще всего мало кого волнует. Если очень хочется навести порядок и использовать магию с наллами, то есть как альтернативные способы хранения разреженных данных, так и online redefinition. А вот как в MySQL реализована вставка колонки в середину при конкурентных апдейтах/инсертах и насколько оно действительно хорошо работает - интересный вопрос.
Сервер приложений SAP написан на ЯП 80-х годов, который взял многое из COBOL и который хоть и обогащался новыми фичами, но так и оставил легаси. Почему-то в 2024 году компании все ещё не гнушаются им пользоваться, а пользователи, не поверите, спокойно смотрят в без преувеличения УЖАСНЕЙШЕ выглядящие UI. А все потому, что они в нем работают, а не тестируют новые фичи ЯП и не любуются красотой кода.