Я лично как PMC (Project Management Committee) Apache Airflow не знаю кто тот самый контрибьютор, что дает 99% кода? Свою лепту вносят на регулярной основе довольно много крупных компаний и сторонних контрибьюторов, это если брать конкретный проект внутри ASF.
Шанс, что в один момент времени тот или иной проект ASF проект станет мало интересным для пользователей/контрибьюторов/PMC всегда есть, в таком случае проект закончит свое существование в Apache Attic - это обычный жизненный цикл.
Я далее продолжу примеры конкретного Apache Airflow, так как все же считаю себя достаточно компетентным в вопросах кто и как его использует и кто вносит свою лепту. "Локальный сборщик" в данном случае это не только импортозаместитель, но и такие компании как Amazon, Google, Microsoft, Huawei, Yandex, Astronomer и прочие кто предоставляют свой Managed service вокруг Airflow. Эти компании должны быть напрямую заинтересованы в развитии проекта (уточнение это их право, но не обязанность), а так же упрощение самой "перепаковки" под свои нужды, чтобы не приходилось мучительно больно каждый раз патчить новую версию.
И тут вариантов несколько - это забить и плыть по течению или вносить свою лепту в проект, упрощая жизнь себе и прочим пользователям/компаниям. Хороший пример это AWS, который сначала внедрил у себя MWAA, помучался с ним и выделил целую команду кто занимается внесение изменений (это может быть даже и не fulltime, этой информации у меня нет). И как результат, за последние год-полтора довольно много фундаментальных изменений было внесено именно этой командой, естественно их цель и мотивация понятна - сделать жизнь легче их работодателю, чтобы он мог получить конкурентное преимущество перед остальными игроками рынка, так как ему придется меньше плясать с патчами вокруг ванильной версии, но остальные также могут пользоваться этими наработками. Есть и плохие примеры, когда тот или иной игрок не участвует в жизни проекта, печально но ладно.
Наверное каждый "перепаковщик" должен как минимум интересоваться как там дела у конкретного проекта, какая там активность, а то может оказаться что проект живой, а на деле нет (косо смотрю на Apache OpenOffice).
Если отойти немного от конкретного проекта конкретного некоммерческого фонда и задаться вопросом: "может ли тот или иной СПО софт стать закрытым или перейти на 'своеобразные' лицензии?", то ответ будет да и примеров много, за последнее время. Другое дело если этот какой либо фонд (не обязательно ASF), у которого основная цель выпускать СПО, тут скорее вопрос в другом, когда конкретный проект потеряет основную массу пользователей или наоборот приобретет, в момент когда другой СПО перестанет (пусть даже формально) быть таковым.
Сильно зависит от владельца СПО, например 2 из 3 в данной статье это проекты ASF (Apache Software Foundation) и вероятность, что эти проекты станут closed source очень низкая.
Но вышло так, что нет нотификатора, который отправляет уведомления в Telegram
Так уж вышло что Apache Airflow в основном развивается сообществом и многие из активных контрибьюторов тоже являются пользователями. Поэтому изменения, новый фичи и т.д. чаще всего появляются мере необходимости в повседневных процессах где используется Airflow.
Конечно скорее всего потребуется привести его в более стандартный вид для Notifiers которые поддерживаются сообществом, за основу всегда можно взять один из представленных
Немного тестов, документация с простым примером, code review, и после того как попадет в main будет доступен в следующем релизе провайдеров для Airflow (где-то в раз в 2-3 недели происходит)
Ну и напоследок, если все же появится интерес добавить его, то есть Contributors' guide который поможет найти ответы на частые вопросы.
Зашел в FAQ, все было неплохо, до момента "Что такое Triggerer в Apache Airflow?" и у меня возникло такое ощущение, что срочно надо было сдавать документацию и поэтому нет времени проверять что вообще написано и насколько информация соответствует действительности.
Ну а в целом чем больше managed сервисов вокруг Airflow, тем больше вероятности, что костыли и велосипеды самого Airflow будут исправляться. Хороший пример это MWAA, где до сих пор существуют "интересные" решения и ограничения, но в целом силами самого Амазона за последний год было внесено несколько довольно крупных изменений который делает жизнь легче как OSS Community так и самому MWAA как сервису.
Ну и последний момент, если вдруг кто-то из Яндекса прочитает, то хочу напомнить о возможности добавить сервис на страницу с экосистемой Airflow
Нюанс в том, что если params на уровне DAGa не был задан, то по-умолчанию возможности запустить такой DAG с конфигом чере UI не будет. Конечно по мелочи еще были баги с самими параметрами, но они по идее к 2.7.2 будут исправлены
Лично мне как человеку, кто регулярно отвечает на вопросы произволительности Airflow, в данной статье явно не хватает указания следующих ссылок на документацию:
Optimizing DAG parsing delays during execution, эксперементальный функционал, но шанс что он останется значительно выше, чем у того, что MsSQL останется в качестве DB Backend для Airflow
Потому как если кто-то попробует повторить этот эксперимент, он может легко столкнуться с проблемой, что Airflow начнет заспамливать базу по интервалу сканирования DAGов. Поэтому еще оставлю ссылку на тюнинг планировщика Airflow
Ну и еще от себя добавляю, официальный Docker Compose файл для Airflow существует чисто для того, чтобы пользователь мог запустить и сказать "Вау! Это действительно работает!"
В первой части соответствующего change proposal создатели стандарты писали, что давайте делать все «using built-in functions».
Как бы логично, типов много. Как бы отработал a.country если a имеет тип int или varchar или point
На самом деле, конечно, сделали по образу и подобию поддержки XML, особо головой не подумав. Тогда подумать было некогда (или не захотели связываться), а сейчас лень.
Как то токсичненько
У них это называется path navigation
Yet another standard
tuple navigation
Cоздатели же знают, что называют кортежами в других языках? Почему интересно не object navigation ?
я так и не понял, как в SQL/JSON получить список ключей, и лучше в привязке к значениям, а не просто значения.
$.keyvalue()
Правда зачем, это не понятно. Нужен бизнес смысл этого действия
эти селекторы не «созависимы». Например, насколько понимаю, при SELECT JSON_VALUE(T.J, '$.persons[].name'), JSON_VALUE(T.J, '$.persons[].surname'), мы получим декартово произведение множеств имен и фамилий.
Не правильно понимаете, в режиме lax получите NULL, в режиме strict получите ошибку.
Хотите массив получить, тогда JSON_QUERY, хотите отношение сгенерировать JSON_TABLE
запросы из SQL-92 останутся работоспособными.
Немного черного юмора: "А также добавят обратную совместимость с Windows 3.1 и дистрибутивами на ядре Linux 0.0.1"
Там упор на функции по работе с JSON, а здесь работа с JSON интегрирована в язык
Если разработчики подписываются под то, что реализовали функционал из SQL/JSON (частичный или полностью), тогда получается, что работа с JSON интегрирована в язык.
И поэтому здесь, например, оказалось возможным поддержать лишь совсем базовый JSONPath, а там поддерживаемые возможности JSONPath раздуты чуть ли не до имеющихся в XPath
JSONPath в отличии от XPath не стандартизирован, поэтому каждый делает свою реализацию. Кстати какого функционала не хватает в реализации JSONPath по SQL/JSON?
Ну и в (спеке PartiQL) нет вообще информации по JSONPath
Просто пока выглядит как "очередной язык, который хочет казаться SQL, но работает несколько иначе, поэтому вы будете думать почему привычное вам, перестало работать". Как всегда рассудит время
У меня переход на Uber BY \ Uber Russia так и не произошел, по уже описанной причине:
региональная привязка
Пришлось перейти на Я.Такси. Отдельный плюс Яндексу, что в их родном приложении можно легко менять аккаунты, чего в убере не было
По качеству обслуживания, не скажу что для меня как-то сильно поменялось, возможно связано с тем, что такси в Минске пользуюсь не так часто, как в Москве.
Я бы не стал сейчас углублять в написание машины Тьюринга на SQL, лучше сфокусироваться на возможностях\обходных путях того или иного синтаксиса ну и самое главное это возможности самой (О)РСУБД.
Ну… можно написать свои функции, я такие себе собираю, когда нужно быстро мигрировать с ORACLE с сохранением бизнес логики с наименьшими потерями
К примеру в данном случае можно использовать что-то навроде такого
CREATE OR REPLACE FUNCTION f_array_has_null (ANYARRAY)
RETURNS bool LANGUAGE sql IMMUTABLE AS
'SELECT array_position($1, NULL) IS NOT NULL';
CREATE FUNCTION f_least_ora(VARIADIC arr numeric[])
RETURNS numeric LANGUAGE plpgsql IMMUTABLE AS $$
BEGIN
IF f_array_has_null($1) THEN
RETURN NULL;
ELSE
RETURN (SELECT min(x) FROM unnest($1) x);
END IF;
END
$$ ;
CREATE FUNCTION f_greatest_ora(VARIADIC arr numeric[])
RETURNS numeric LANGUAGE plpgsql IMMUTABLE AS $$
BEGIN
IF f_array_has_null($1) THEN
RETURN NULL;
ELSE
RETURN (SELECT max(x) FROM unnest($1) x);
END IF;
END
$$ ;
Ох, еще вспомнил, что с to_date(text, text) надо быть осторожным, так как PostgreSQL спокойно скушает to_date('30.02.2017', 'dd.mm.yyyy') и вернет 2 марта 2017, когда Oracle и DB2 LUW вернет ошибку.
В таком случае, если позволяет задача переключится на другой datestyle и сделать простое приведение типов
sql> set datestyle to DMY
sql> SELECT '30.02.2017'::date
[22008] ERROR: date/time field value out of range: "30.02.2017" Position: 8
Крутое решение, хотя я бы все же сделал через старый добрый CASE .. THEN .. ELSE .. END, тогда результат был такой же, однако тому кто потому будет доробатовать это дело не пришлось бы думать, а что вот здесь вот происходит
WITH TEST_DATA as (
SELECT unnest(ARRAY[1,NULL,42,-3,0,2,-15,NULL,55])::int field
)
SELECT
field
, GREATEST(field, 0) * (field::integer::boolean::integer) option_1
, CASE WHEN field < 0 THEN 0 ELSE field END option_2
FROM TEST_DATA
Я лично как PMC (Project Management Committee) Apache Airflow не знаю кто тот самый контрибьютор, что дает 99% кода? Свою лепту вносят на регулярной основе довольно много крупных компаний и сторонних контрибьюторов, это если брать конкретный проект внутри ASF.
Шанс, что в один момент времени тот или иной проект ASF проект станет мало интересным для пользователей/контрибьюторов/PMC всегда есть, в таком случае проект закончит свое существование в Apache Attic - это обычный жизненный цикл.
Я далее продолжу примеры конкретного Apache Airflow, так как все же считаю себя достаточно компетентным в вопросах кто и как его использует и кто вносит свою лепту. "Локальный сборщик" в данном случае это не только импортозаместитель, но и такие компании как Amazon, Google, Microsoft, Huawei, Yandex, Astronomer и прочие кто предоставляют свой Managed service вокруг Airflow. Эти компании должны быть напрямую заинтересованы в развитии проекта (уточнение это их право, но не обязанность), а так же упрощение самой "перепаковки" под свои нужды, чтобы не приходилось мучительно больно каждый раз патчить новую версию.
И тут вариантов несколько - это забить и плыть по течению или вносить свою лепту в проект, упрощая жизнь себе и прочим пользователям/компаниям. Хороший пример это AWS, который сначала внедрил у себя MWAA, помучался с ним и выделил целую команду кто занимается внесение изменений (это может быть даже и не fulltime, этой информации у меня нет). И как результат, за последние год-полтора довольно много фундаментальных изменений было внесено именно этой командой, естественно их цель и мотивация понятна - сделать жизнь легче их работодателю, чтобы он мог получить конкурентное преимущество перед остальными игроками рынка, так как ему придется меньше плясать с патчами вокруг ванильной версии, но остальные также могут пользоваться этими наработками. Есть и плохие примеры, когда тот или иной игрок не участвует в жизни проекта, печально но ладно.
Наверное каждый "перепаковщик" должен как минимум интересоваться как там дела у конкретного проекта, какая там активность, а то может оказаться что проект живой, а на деле нет (косо смотрю на Apache OpenOffice).
Если отойти немного от конкретного проекта конкретного некоммерческого фонда и задаться вопросом: "может ли тот или иной СПО софт стать закрытым или перейти на 'своеобразные' лицензии?", то ответ будет да и примеров много, за последнее время. Другое дело если этот какой либо фонд (не обязательно ASF), у которого основная цель выпускать СПО, тут скорее вопрос в другом, когда конкретный проект потеряет основную массу пользователей или наоборот приобретет, в момент когда другой СПО перестанет (пусть даже формально) быть таковым.
Сильно зависит от владельца СПО, например 2 из 3 в данной статье это проекты ASF (Apache Software Foundation) и вероятность, что эти проекты станут closed source очень низкая.
Так уж вышло что Apache Airflow в основном развивается сообществом и многие из активных контрибьюторов тоже являются пользователями. Поэтому изменения, новый фичи и т.д. чаще всего появляются мере необходимости в повседневных процессах где используется Airflow.
Если есть желание, то всегда можно сделать Pull Request в соответствующий провайдер, в данном случае
apache-airflow-providers-telegram
, он как и все остальные провайдеры и ядро Airflow живут в монорепе https://github.com/apache/airflow/Конечно скорее всего потребуется привести его в более стандартный вид для Notifiers которые поддерживаются сообществом, за основу всегда можно взять один из представленных
SlackNotifier
SlackWebhookNotifier
OpsgenieNotifier
SnsNotifier
И остальные
Немного тестов, документация с простым примером, code review, и после того как попадет в
main
будет доступен в следующем релизе провайдеров для Airflow (где-то в раз в 2-3 недели происходит)Ну и напоследок, если все же появится интерес добавить его, то есть Contributors' guide который поможет найти ответы на частые вопросы.
Прям все-все-все-все? Просто статистика скачиваний говорит немного о другом:
Apache Airflow
Prefect
Dagster
Ни в коем случае это не умоляет другие решения отличные от Airflow, но не стоит выдавать желаемое за действительное.
Зашел в FAQ, все было неплохо, до момента "Что такое Triggerer в Apache Airflow?" и у меня возникло такое ощущение, что срочно надо было сдавать документацию и поэтому нет времени проверять что вообще написано и насколько информация соответствует действительности.
Ну а в целом чем больше managed сервисов вокруг Airflow, тем больше вероятности, что костыли и велосипеды самого Airflow будут исправляться. Хороший пример это MWAA, где до сих пор существуют "интересные" решения и ограничения, но в целом силами самого Амазона за последний год было внесено несколько довольно крупных изменений который делает жизнь легче как OSS Community так и самому MWAA как сервису.
Ну и последний момент, если вдруг кто-то из Яндекса прочитает, то хочу напомнить о возможности добавить сервис на страницу с экосистемой Airflow
Нюанс в том, что если params на уровне DAGa не был задан, то по-умолчанию возможности запустить такой DAG с конфигом чере UI не будет.
Конечно по мелочи еще были баги с самими параметрами, но они по идее к 2.7.2 будут исправлены
"Ничего не понятно, но очень интересно"
Правильно ли я понял, что вы в условной первой таске в DAGe выполняете всю свою магию и потом передаете в остальные через XCom/XСomArg?
Тогда Вас может неприятно удивить Airflow 2.7+
Лично мне как человеку, кто регулярно отвечает на вопросы произволительности Airflow, в данной статье явно не хватает указания следующих ссылок на документацию:
Dynamic DAG Generation
Optimizing DAG parsing delays during execution, эксперементальный функционал, но шанс что он останется значительно выше, чем у того, что MsSQL останется в качестве DB Backend для Airflow
Потому как если кто-то попробует повторить этот эксперимент, он может легко столкнуться с проблемой, что Airflow начнет заспамливать базу по интервалу сканирования DAGов. Поэтому еще оставлю ссылку на тюнинг планировщика Airflow
Ну и еще от себя добавляю, официальный Docker Compose файл для Airflow существует чисто для того, чтобы пользователь мог запустить и сказать "Вау! Это действительно работает!"
Ну прямо сейчас можно поднять AWS EMR с Presto или тоже самое сделать с AWS EC2 или вообще поднять на своем железе и работать все это будет на SQL
Как бы логично, типов много. Как бы отработал
a.country
еслиa
имеет типint
илиvarchar
илиpoint
Как то токсичненько
Yet another standard
Cоздатели же знают, что называют кортежами в других языках? Почему интересно не object navigation ?
$.keyvalue()
Правда зачем, это не понятно. Нужен бизнес смысл этого действия
Не правильно понимаете, в режиме
lax
получите NULL, в режимеstrict
получите ошибку.Хотите массив получить, тогда JSON_QUERY, хотите отношение сгенерировать JSON_TABLE
Немного черного юмора: "А также добавят обратную совместимость с Windows 3.1 и дистрибутивами на ядре Linux 0.0.1"
Кстати интересно, как отработает по такому JSON:
Если разработчики подписываются под то, что реализовали функционал из SQL/JSON (частичный или полностью), тогда получается, что работа с JSON интегрирована в язык.
JSONPath в отличии от XPath не стандартизирован, поэтому каждый делает свою реализацию. Кстати какого функционала не хватает в реализации JSONPath по SQL/JSON?
Ну и в (спеке PartiQL) нет вообще информации по JSONPath
Просто пока выглядит как "очередной язык, который хочет казаться SQL, но работает несколько иначе, поэтому вы будете думать почему привычное вам, перестало работать". Как всегда рассудит время
SQL/JSON Standard-2016, не ?
У меня переход на Uber BY \ Uber Russia так и не произошел, по уже описанной причине:
Пришлось перейти на Я.Такси. Отдельный плюс Яндексу, что в их родном приложении можно легко менять аккаунты, чего в убере не было
По качеству обслуживания, не скажу что для меня как-то сильно поменялось, возможно связано с тем, что такси в Минске пользуюсь не так часто, как в Москве.
Печалит, что
.stignore
не передается между нодами и необходимо придумывать велосипеды с #includeЯ бы не стал сейчас углублять в написание машины Тьюринга на SQL, лучше сфокусироваться на возможностях\обходных путях того или иного синтаксиса ну и самое главное это возможности самой (О)РСУБД.
Ну, да… А на функционал это как-то влияет?
Правильней сказать, что синтаксис курсора несколько иной:
MS SQL, Oracle, PostgreSQL
Ну… можно написать свои функции, я такие себе собираю, когда нужно быстро мигрировать с ORACLE с сохранением бизнес логики с наименьшими потерями
К примеру в данном случае можно использовать что-то навроде такого
Ну и как результат
Ох, еще вспомнил, что с
to_date(text, text)
надо быть осторожным, так как PostgreSQL спокойно скушаетto_date('30.02.2017', 'dd.mm.yyyy')
и вернет 2 марта 2017, когда Oracle и DB2 LUW вернет ошибку.В таком случае, если позволяет задача переключится на другой
datestyle
и сделать простое приведение типовКрутое решение, хотя я бы все же сделал через старый добрый
CASE .. THEN .. ELSE .. END
, тогда результат был такой же, однако тому кто потому будет доробатовать это дело не пришлось бы думать, а что вот здесь вот происходит