Можно в одном проекте код для нескольких разных задач (Flink jobs) хранить, просто собирать свой образ для каждой. Плюс если у них общие зависимости, это может даже один модуль быть. Если разные версии Flink - другой модуль или отдельный репозиторий. Тут уже кому как удобнее. Но понятно, что над сборкой контейнеров надо поработать.
Работаю с Flink какое-то время. Предположу, что будет не очень удобно иметь несколько разных пайплайнов в одной задаче: - при обновления останавливаться будут все пайплайны сразу; - больше рисков, что проблема с одним пайплайном вызовет сбой в работе всей задачи (память, исключения и т.д.); - ну и если даже разные задачи в одном кластере, то уже проблемы с одной задачей могут затронуть весь кластер.
Чаще разворачивают 1 задачу на кластер. Вижу в этом следующие преимущества: - можно более точно настроить ресурсы под конкретный тип нагрузки и особенности задачи (количество TM, разные настройки Flink, память, RocksDB и т.д); -меньше рисков сбоя и легче обновлять.
Могу еще посоветовать идею упаковки вашего кода в образ на основе Flink (можно экстернализировать и настройки для кластера). И тогда каждый пайплайн будет отдельным образом. Берешь и разворачиваешь в отдельный namespace k8s, например.
Хорошая статья, много подробностей описали. Думаю будет интересно новичкам в стримминге данных. Ну и, раз уж столько элементов не поленились реализовать, единственное, что, на мой взгляд, упущено из важного - это БД для хранения заказов.
Хранить всю историю заказов в Кафке и использовать ее как хранилище (точнее стейт сторы на основе нескольких топиков) будет не очень правильным в данном случае.
Если случится перебалансировка партиций в Kafka Streams, стейт стор будет восстанавливаться, причем довольно долго, если топик большой. А значит, получить информацию по заказу будет невозможно. Плюс надо подумать о транзакциях, заказы вещь такая. Если использовать exactly once semantics в Kafka Streams, то причин для перебалансировки будет ещё больше)) Механизм довольно прихотливый. С БД будет проще и надёжнее.
В целом, я бы первый сервис сделал со своей БД и без KS, слал бы заказы в Кафку после записи в БД, слушал бы топики с результатами от всех остальных тропиков и менял статус заказа. Вынес бы KS в отдельный сервис и это сделало бы архитектуру стабильнее.
Зря Вы так. На Хабре каждый находит посты по своим интересам и потребностям. Просто этот пост не для Вас. Не читайте его, пропустите мимо и нет проблем. Код я свернул, глаза он не мозолит. Описать все старался кратко.
Мне тоже docx4j не очень понравился. Использовал только из-за возможности вставлять значения в поля слияния. В других библиотеках сходу не нашел такой возможности. Вообще, мне больше нравится iText и тот же Apache POI. Я с ними больше работал.
первостепенность подачи — это часть культуры на другом континенте
Вот вот. И, возможно, даже не сами создатели выносят для всеобщей подачи свои разработки, а их окружение (друзья, знакомые, журналисты, блогеры и т.д.)
Что-то мне всё больше кажется, что MIT пиарится на пустом месте.
А это именно проекты ученых (сотрудников) MIT или проекты студентов???
Если студентов, то не будьте настолько критичны… Ребята стараются и делают что-то в интересующих их областях. Пусть не все идеи уникальны, но в них все равно что-то привносят. В конце концов, свои студенческие проекты вспомните… Многие делали их в конце семестра и лишь для того, чтобы сдать! Не бывает так, что каждый новый проект это ПРОРЫВ! А то, что многие проекты выставляется на всеобщее обозрение и пиарятся заслуга современных средств массовой коммуникации. Сейчас не так уж сложно огласить на весь мир о чем-то более менее стоящем.
Если же то, что вы описали проекты ученых, то тогда соглашусь с вами. Стоит подумать, за что им платят деньги. Однако тут тоже нужно быть аккуратным. Например, то, что сегодня на внешний вид кажется смешным и ненужным, может иметь серьезную научную подноготную либо служить толчком для дальнейшего развития. Не стоит об этом забывать.
Можно в одном проекте код для нескольких разных задач (Flink jobs) хранить, просто собирать свой образ для каждой. Плюс если у них общие зависимости, это может даже один модуль быть. Если разные версии Flink - другой модуль или отдельный репозиторий. Тут уже кому как удобнее. Но понятно, что над сборкой контейнеров надо поработать.
Да, всё верно поняли. Спасибо за пояснения. Интересно ещё, каким образом разворачивает Flink кластер. k8s оператор?
Работаю с Flink какое-то время. Предположу, что будет не очень удобно иметь несколько разных пайплайнов в одной задаче:
- при обновления останавливаться будут все пайплайны сразу;
- больше рисков, что проблема с одним пайплайном вызовет сбой в работе всей задачи (память, исключения и т.д.);
- ну и если даже разные задачи в одном кластере, то уже проблемы с одной задачей могут затронуть весь кластер.
Чаще разворачивают 1 задачу на кластер. Вижу в этом следующие преимущества:
- можно более точно настроить ресурсы под конкретный тип нагрузки и особенности задачи (количество TM, разные настройки Flink, память, RocksDB и т.д);
-меньше рисков сбоя и легче обновлять.
Могу еще посоветовать идею упаковки вашего кода в образ на основе Flink (можно экстернализировать и настройки для кластера). И тогда каждый пайплайн будет отдельным образом. Берешь и разворачиваешь в отдельный namespace k8s, например.
Правда теперь тут появляется проблема двойной записи (Dual Writes) и нам нужна CDC (change data capture) или SAGA, например. Да, реальность сурова.
Хорошая статья, много подробностей описали. Думаю будет интересно новичкам в стримминге данных. Ну и, раз уж столько элементов не поленились реализовать, единственное, что, на мой взгляд, упущено из важного - это БД для хранения заказов.
Хранить всю историю заказов в Кафке и использовать ее как хранилище (точнее стейт сторы на основе нескольких топиков) будет не очень правильным в данном случае.
Если случится перебалансировка партиций в Kafka Streams, стейт стор будет восстанавливаться, причем довольно долго, если топик большой. А значит, получить информацию по заказу будет невозможно. Плюс надо подумать о транзакциях, заказы вещь такая. Если использовать exactly once semantics в Kafka Streams, то причин для перебалансировки будет ещё больше)) Механизм довольно прихотливый. С БД будет проще и надёжнее.
В целом, я бы первый сервис сделал со своей БД и без KS, слал бы заказы в Кафку после записи в БД, слушал бы топики с результатами от всех остальных тропиков и менял статус заказа. Вынес бы KS в отдельный сервис и это сделало бы архитектуру стабильнее.
Желаю Вам удачи!
Мне тоже docx4j не очень понравился. Использовал только из-за возможности вставлять значения в поля слияния. В других библиотеках сходу не нашел такой возможности. Вообще, мне больше нравится iText и тот же Apache POI. Я с ними больше работал.
Убило!
Убило!
Вот вот. И, возможно, даже не сами создатели выносят для всеобщей подачи свои разработки, а их окружение (друзья, знакомые, журналисты, блогеры и т.д.)
А это именно проекты ученых (сотрудников) MIT или проекты студентов???
Если студентов, то не будьте настолько критичны… Ребята стараются и делают что-то в интересующих их областях. Пусть не все идеи уникальны, но в них все равно что-то привносят. В конце концов, свои студенческие проекты вспомните… Многие делали их в конце семестра и лишь для того, чтобы сдать! Не бывает так, что каждый новый проект это ПРОРЫВ! А то, что многие проекты выставляется на всеобщее обозрение и пиарятся заслуга современных средств массовой коммуникации. Сейчас не так уж сложно огласить на весь мир о чем-то более менее стоящем.
Если же то, что вы описали проекты ученых, то тогда соглашусь с вами. Стоит подумать, за что им платят деньги. Однако тут тоже нужно быть аккуратным. Например, то, что сегодня на внешний вид кажется смешным и ненужным, может иметь серьезную научную подноготную либо служить толчком для дальнейшего развития. Не стоит об этом забывать.
Как технология — на пневматике далеко не уедешь (в сторону Retina точно).
Область применения — ммм… Презентация???
Но ребята молодцы, безусловно!