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

Question

У нас есть выходная пакетная обработка, которая работает, как указано ниже

• Hive SQL используется для ежедневной пакетной обработки.
• Данные поступают либо из файлов, либо из RDMBS
• Данные попадают в Raw -> Staging -> Mart , причем подготовка к витрине является всей бизнес-трансформациейсырье для постановки - это просто очистка и форматирование данных.

Теперь, как часть получения реальных данных или данных, близких к реальному, я оцениваю Лямбда-архитектура и это какой план?

• ВСЕ исходная система приземлится на Кафку.
• Та же система пакетной обработки будет использовать темы Кафки.
• Новое приложение Spark будет использовать темы кафки для потоковой передачи.
• Обслуживающий слой создаст представления, которые будут объединять как агрегированные данные из потоковой передачи, так и пакетной обработки для обработки в реальном (почти реальном) времени.

Проблема в том, что логика будет дублироваться в HiveQL (Batch) и Spark (Streaming).Есть ли способ, которым я могу избежать этого или минимизировать это?

Answer 1

Проблема дублированной кодовой базы присуща лямбда-архитектуре.Об этом упоминается в разделе «Критика» на странице википедии

Другая проблема заключается в том, что данные между пакетом и потоком не синхронизированы, что может привести к неожиданным результатам при объединении данных,Например, объединение потоков и пакетов, когда ключи еще не существуют в пакетном режиме.

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

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

использование искровой структурированной потоковой передачи для пакетной обработки

проблемы с лямбда-архитектурой и способы их решения только при использовании потоковой передачи

опросархитектура лямбда

Answer 2

Вы можете построить свои этапы обработки, используя Spark SQL и Spark Structured Streaming: https://spark.apache.org/docs/2.2.0/structured-streaming-programming-guide.html. В зависимости от ваших потребностей возможны некоторые несовместимости.Но я бы попытался построить Spark Aggregations + Transformations, используя api набора данных [_], а затем попытаться порождать их двумя способами: пакетно и потоково.