Greenplum, NiFi и Airflow на страже импортозамещения: но есть нюансы

Я лично как 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), у которого основная цель выпускать СПО, тут скорее вопрос в другом, когда конкретный проект потеряет основную массу пользователей или наоборот приобретет, в момент когда другой СПО перестанет (пусть даже формально) быть таковым.

Greenplum, NiFi и Airflow на страже импортозамещения: но есть нюансы

Сильно зависит от владельца СПО, например 2 из 3 в данной статье это проекты ASF (Apache Software Foundation) и вероятность, что эти проекты станут closed source очень низкая.

Алертинг состояния выполения DAG`ов Apache Airflow в Telegram за 1 минуту

Но вышло так, что нет нотификатора, который отправляет уведомления в Telegram

Так уж вышло что 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 который поможет найти ответы на частые вопросы.

Airflow в Kubernetes. Часть 1

Прям все-все-все-все? Просто статистика скачиваний говорит немного о другом:

• Apache Airflow

• Prefect

• Dagster

Ни в коем случае это не умоляет другие решения отличные от Airflow, но не стоит выдавать желаемое за действительное.

Yandex Cloud добавила сервис на базе технологии Apache Airflow в свои облака

Зашел в FAQ, все было неплохо, до момента "Что такое Triggerer в Apache Airflow?" и у меня возникло такое ощущение, что срочно надо было сдавать документацию и поэтому нет времени проверять что вообще написано и насколько информация соответствует действительности.

Ну а в целом чем больше managed сервисов вокруг Airflow, тем больше вероятности, что костыли и велосипеды самого Airflow будут исправляться. Хороший пример это MWAA, где до сих пор существуют "интересные" решения и ограничения, но в целом силами самого Амазона за последний год было внесено несколько довольно крупных изменений который делает жизнь легче как OSS Community так и самому MWAA как сервису.

Ну и последний момент, если вдруг кто-то из Яндекса прочитает, то хочу напомнить о возможности добавить сервис на страницу с экосистемой Airflow

Эластичный DAG или «гнём, где не гнулось»

Нюанс в том, что если params на уровне DAGa не был задан, то по-умолчанию возможности запустить такой DAG с конфигом чере UI не будет.
Конечно по мелочи еще были баги с самими параметрами, но они по идее к 2.7.2 будут исправлены

Эластичный DAG или «гнём, где не гнулось»

"Ничего не понятно, но очень интересно"

Правильно ли я понял, что вы в условной первой таске в DAGe выполняете всю свою магию и потом передаете в остальные через XCom/XСomArg?

Если единожды требуется запустить DAG со специфическими параметрами, то в Airflow предусмотрена возможность «Запуск DAGа с параметрами».

Тогда Вас может неприятно удивить Airflow 2.7+

Таблица-справочник – генератор DAG? А что так можно было?

Лично мне как человеку, кто регулярно отвечает на вопросы произволительности Airflow, в данной статье явно не хватает указания следующих ссылок на документацию:

• Dynamic DAG Generation

  • Optimizing DAG parsing delays during execution, эксперементальный функционал, но шанс что он останется значительно выше, чем у того, что MsSQL останется в качестве DB Backend для Airflow

Потому как если кто-то попробует повторить этот эксперимент, он может легко столкнуться с проблемой, что Airflow начнет заспамливать базу по интервалу сканирования DAGов. Поэтому еще оставлю ссылку на тюнинг планировщика Airflow

Ну и еще от себя добавляю, официальный Docker Compose файл для Airflow существует чисто для того, чтобы пользователь мог запустить и сказать "Вау! Это действительно работает!"

Amazon представил PartiQL: SQL-совместимый язык запросов к данным в различных форматах

Ну прямо сейчас можно поднять AWS EMR с Presto или тоже самое сделать с AWS EC2 или вообще поднять на своем железе и работать все это будет на SQL

Amazon представил PartiQL: SQL-совместимый язык запросов к данным в различных форматах

В первой части соответствующего 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:

{"a": 1, "a": 2, "a": 3, "b": null}

Amazon представил PartiQL: SQL-совместимый язык запросов к данным в различных форматах

Там упор на функции по работе с JSON, а здесь работа с JSON интегрирована в язык

Если разработчики подписываются под то, что реализовали функционал из SQL/JSON (частичный или полностью), тогда получается, что работа с JSON интегрирована в язык.

И поэтому здесь, например, оказалось возможным поддержать лишь совсем базовый JSONPath, а там поддерживаемые возможности JSONPath раздуты чуть ли не до имеющихся в XPath

JSONPath в отличии от XPath не стандартизирован, поэтому каждый делает свою реализацию. Кстати какого функционала не хватает в реализации JSONPath по SQL/JSON?
Ну и в (спеке PartiQL) нет вообще информации по JSONPath

Просто пока выглядит как "очередной язык, который хочет казаться SQL, но работает несколько иначе, поэтому вы будете думать почему привычное вам, перестало работать". Как всегда рассудит время

Amazon представил PartiQL: SQL-совместимый язык запросов к данным в различных форматах

SQL/JSON Standard-2016, не ?

Яндекс! Спасибо за Uber

У меня переход на Uber BY \ Uber Russia так и не произошел, по уже описанной причине:

региональная привязка

Пришлось перейти на Я.Такси. Отдельный плюс Яндексу, что в их родном приложении можно легко менять аккаунты, чего в убере не было

По качеству обслуживания, не скажу что для меня как-то сильно поменялось, возможно связано с тем, что такси в Минске пользуюсь не так часто, как в Москве.

Настраиваем Syncthing. Синяя изолента в мелком бизнесе и дома

Печалит, что .stignore не передается между нодами и необходимо придумывать велосипеды с #include

Какие самые нелюбимые языки программирования?

Я бы не стал сейчас углублять в написание машины Тьюринга на SQL, лучше сфокусироваться на возможностях\обходных путях того или иного синтаксиса ну и самое главное это возможности самой (О)РСУБД.

Какие самые нелюбимые языки программирования?

Ну, да… А на функционал это как-то влияет?

Какие самые нелюбимые языки программирования?

Правильней сказать, что синтаксис курсора несколько иной:
MS SQL, Oracle, PostgreSQL

Курс молодого бойца PostgreSQL

Ну… можно написать свои функции, я такие себе собираю, когда нужно быстро мигрировать с 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
$$ ;

Ну и как результат

SELECT
    least(1, NULL, 42, -3, 0, -0.5, -15, NULL, 55)          -- -15
  , f_least_ora(1, NULL, 42, -3, 0, -0.5, -15, NULL, 55)    -- NULL
  , least(1, 42, -3, 0, -0.5, -15, 55)                      -- -15
  , f_least_ora(1, 42, -3, 0, -0.5, -15, 55)                -- NULL
  , greatest(1, NULL, 42, -3, 0, -0.5, -15, NULL, 55)       -- 55 
  , f_greatest_ora(1, NULL, 42, -3, 0, -0.5, -15, NULL, 55) -- NULL
  , greatest(1, 42, -3, 0, -0.5, -15, 55)                   -- 55
  , f_greatest_ora(1, 42, -3, 0, -0.5, -15, 55)             -- 55

Курс молодого бойца PostgreSQL

Ох, еще вспомнил, что с 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

Курс молодого бойца PostgreSQL

Крутое решение, хотя я бы все же сделал через старый добрый 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