У меня есть приложение batch / spark, которое считывает данные sqoop / mysql как снимок и выполняет большую статистику на основе всех исторических данных и записывает результат в mongodb.
, как вы можете понять, навернякарезультат mongodb генерируется в пакетном / автономном режиме с интервалом около 1,5 часов.
Теперь мой начальник попросил меня преобразовать весь результат в реальное время, поэтому я решил использовать потоковую систему для этого.,Во-первых, я хочу превратить все данные mysql в сообщения kafka, а затем использовать одну из потоковых технологий sparkstreaming / flink / beam.но после попытки действительно слишком долго преобразовывать и отправлять все данные в виде msgs на kafka, особенно когда я изменил логику потокового приложения и данные должны быть повторно отправлены, если не весь отправленный набор данных сказать сложноесли мой результат потоковой передачи правильный по сравнению с пакетным.
, а также другая проблема, в моем случае у меня нет окна, только все исторические данные, которые нужно отфильтровать и суммировать / считать как куб.Потоковая система действительно поддерживает глобальные окна, которые желательны в моем случае, но запись в приемник / базу данных должна вызываться «триггером», который для меня как таймер, а затем не в реальном времени, чтопо сравнению с первоначальной целью использовать потоковую систему.
также идея глобального окна использует объемную память, как и пакетное задание.
, так что я думаю о том, могу ли я включить / обновить mongodbданные, сохраненные пакетным заданием, в режиме реального времени новым потоковым приложением (flink / beam), которое будет потреблять меньше памяти / процессора, а также данные будут обновляться при каждом поступлении новых потоковых элементов, возможно, таким образом в «реальном» времени.
но я проверил руководство по программам потокового флинка / луча, как будто мой случай идет в каталог без сохранения состояния, и я сам должен выполнить контр-работу incr / update.например, flink, я должен реализовать это в асинхронном вводе-выводе flink или API-интерфейсе таблиц.это нормально для меня сделать это самому, но у меня есть проблема, так как все потоковые системы имеют этот механизм «точно один раз» для ответа / повторной отправки потоковых элементов по всей топологии / даг потоковой передачи в случае сбоя в задании / задачекоторый между барьером (моргание).затем, если эти элементы будут повторно отправлены, то результаты будут записаны в mongodb дважды?
эта проблема заставляет меня копать глубже в исходном коде flink / beam (потоковая искра, как говорят, не так хороша в задержке, так как она скорее пакетная)кроме чистой потоковой системы.).К счастью, я обнаружил, что flink \ flink-connectors \ flink-connector-cassandra \ src \ main \ java \ org \ apache \ flink \ streamink \ streaming \ connectors \ cassandra \ CassandraRowWriteAheadSink.java похож на использование этого приемника, fink может буферизовать элементы до того, как«Барьер» - это успешный успех.
Тем не менее у меня есть вопросы: 1, является ли единственный / лучший способ для меня перенести вышеупомянутый приемник кассандры на mongodb, чтобы полностью заполнить мой incr / update на основе результата партии?2, во всяком случае, использовать механизм WriteAhead в луче, поскольку я не могу найти аналогичную реализацию в луче (beam \ sdks \ java \ io \ mongodb \ src \ main \ java \ org \ apache \ beam \ sdk \ io \ mongodb \ MongoDbIO.Джава)?поскольку мне нравится идея луча запускать приложения в раннерах (спарк, флинк), теперь у меня есть приложение для пакетной обработки и новое потоковое приложение для fink.позже я не хочу прилагать усилия дважды.Я хочу написать приложение в Beam и запустить его в пакетном режиме (я мало беспокоюсь о производительности пакета Flink, так как оно не используется в пакетном производстве много?), и транслировать в Flink.почему бы не моргнуть как для партии, так и для потоковой передачи, которые некоторые могут спросить.это связано с моим личным положительным отношением к API, отличному от SQL, поскольку flink может повторно использовать код только для пакетного / потокового API таблицы, но эти API таблицы являются более чистым SQL, чем API-интерфейсы Spark DataFrame, более API-способом, который не требует форматированияОператор SQL, если в вашем требовании много динамических сумм / целевых чисел в полях динамической фильтрации как условие.