Всем привет, а есть какой-нибудь framework для go, работа на потоке(real-time), по типу flink(а) для Java/scala?

Для батчей я использую airflow

Это не real-time.

Всем привет, а есть какой-нибудь framework для go, работа на потоке(real-time), по типу flink(а) для Java/scala?

А и написал для батчей :)

что значит для батчей?

Такого фреймворка не может быть по определению. В рамках го он теоретически может быть реализован, но не может быть использован.

Пакетная обработка- то есть например выгрузка из файлов, который приходят раз в 5 минут, по таймеру раз в 5 минут забираешь. Вот все что из файлов собрал это один батч.

То есть у go нет такого понятия как работа в окнах?

Чем вас не устраивает простой цикл?

Было бы интересно видеть все subtask которые я создаю в коде

И мониторить передачу между тасками*

Для этого вам нужны логи/прометеус/графана/готовые тулзы (аля ОпенТрейс). Подобных средств выше крыше.

Такое есть, но то что подкапотом, это надо будет настраивать для каждого приложения, flink для Java позваляет запускать и распределять в кластере джобу(приложение), мониторить все это дело, отрисовывать граф

Такое есть, но то что подкапотом, это надо будет настраивать для каждого приложения, flink для Java позваляет запускать и распределять в кластере джобу(приложение), мониторить все это дело, отрисовывать граф

Легко. Пишите читатель топика, запускаете в нём 50 коннектов к 50 сервисам — каждому отправляете по одному сообщению.

И как админить подобную хурму:))

Вешаете наружу веб-морду с парочкой АПИ для запроса статистики. Либо как в прометеусе — прописываете адрес куда сервису стучаться самому по заданному условию либо периоду веремени.

Тут это будет очень сложно, каждый поток должен отдавать статусы и т.д. Потом если у тебя таких джобов более 10, как правильно раскидать нагрузку лежит на том кто запускает и как он будет просчитывать нагрузку уже на запущенных джобах? Это нужно и описать этот механизм, но как понял таких решений, которые поддерживали go нет?

1) Ответсвенность всегда лежит на кодере. 2) Создайте один общий канал четния — кт освободен ,тот первый и схватил. 3) создайте общий канал отчёта — поток сделал — отчитался.

Вам нужна экспертиза внутри команды, чтобы выбрать подходящую архитектуру под существующую задачу (с учетом имеющихся ограничений). Go тут вообще ни при чем 🤷‍♂

Так а чего не нравится из Кафки той же читать и воркеры каким-нибудь кубернетесом плодить?

Кубернетес это прикольно, но мне кажется это не совсем очевидное решение для описанных мной задач + это нужно всю инфру там держать, думаю когда-нибудь к этому придём.

Здравствуйте господа. Изучаю Golang с целью дальнейшего трудоустройства. Но закрадываются мысли о том что без опыта коммерческой разработки на другом языке устроится не удастся, что оказывает деморализующий эффект. Могли бы вы разбить мои опасения своим метким аргументом?

в смысле всю инфу там держать? очереди кафка или что угодно, инфа соответственно какая-то СУБД, может не одна вне кубернетеса

ну интересно получается, то есть это одна штука в которой вся инфраструктура налажена, которую в моем понимании вручную делают скорее. а почему она только на джаве джобы позволяет запускать?

Да не совсем так, flink - это Фреймворк(движек) распределённый потоковой обработки, там есть понятие jobmanager и taskmanager, taskmanager фактически выполняют вашу джобу, а jobmanager отвечает за загрузку, за распределение и координацию джобов. В нем очень легко можно увеличивать количество ресурсов на джобу и т.п. Это все распределяется внутри Java машин, так как сам flink написан на Java и сделать это для Java очень просто, это и есть преимущество. Засчет этого достигается высокая пропускная способность, гибкость настройки, низкая задержка, надёжность и т.д

Мне кажется, что вы не понимаете: го успешно продаёт себя тем, что он заточен под конкурентную коробку бай дезинг. Ему в этом смысле не нужны никакие фреймворки.

Java тоже не нужны фреймворки в таком случае :)

Мне кажется, что вы не понимаете: го успешно продаёт себя тем, что он заточен под конкурентную коробку бай дезинг. Ему в этом смысле не нужны никакие фреймворки.

Я понимаю, что вы имеете ввиду, но это не совсем к тому что я имею ввиду, я говорю о средстве, которое бы помогло запускать множество приложений и администрировать их

Условно говоря, когда у вас 100 приложений написанных на go, вы же не будете это все в кроне хранить

Так я и не говорю про винду, есть сервера, есть много написанных джобов, как это все правильно админить ?

1) Сервис, который запущен всегда (сборщик инфы) 2) Сервисы, которые знают где стоит сборщик инфы. 3) net/http Этого достаточно.

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

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

Поэтому я у вас и спросил что для go вы можете посоветовать

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

Кто напишет мне flink для go в студию 😂😂😂

Кто напишет мне flink для go в студию 😂😂😂

Можно просто было сказать такого нет пока что :))

тоже не пойму, как балансировщик связан с языком и зачем

не знаю, для меня прям дичь и шок, что девопсовая тулза завязана на один язык. очень странно

Т.е. вас не смущает тот факт, что ядро линукса целиком написано на Си?

https://ru.m.wikipedia.org/wiki/Apache_Flink

Как интересно описана работа stdin, stdout и stderr. Я бы не догадался вокруг трёх потоков построить целый фреймворк...)))

Жду от вас «Фреймворк»на go😂

В го есть каналы и конкурентность бай дизайн (ещё раз). Никакие фреймворки в Го не нужны для этого.