Лямбда-архитектура с Apache Spark

Question

Я пытаюсь реализовать Лямбда-архитектуру, используя следующие инструменты: Apache Kafka для получения всех данных, Spark для пакетной обработки (Big Data), Spark Streaming для реального времени (Fast Data) и Cassandra для сохранения результатов.

Кроме того, все получаемые данные связаны с сеансом пользователя, и поэтому для пакетной обработки мне интересно только обрабатывать данные, как только сессия завершится. Итак, поскольку я использую Kafka, единственный способ решить эту проблему (при условии, что все точки данных хранятся в одной и той же теме) заключается в том, чтобы пакет получал все сообщения в теме, а затем игнорировал те, которые соответствуют сеансам, которые еще не закончены.

Итак, что я хотел бы спросить:

• ли это хороший подход к реализации лямбда-архитектуры? Или вместо этого следует использовать Haddop и Storm? (Я не могу найти информацию о людях, использующих Kafka и Apache Spark для пакетной обработки, Map Reduce)
• Есть ли лучший подход к решению проблемы с пользовательскими сеансами?

Спасибо.

Answer 1

Это хороший подход. Использование Spark для скорости и пакетов позволяет вам написать логику один раз и использовать ее в обоих контекстах.

Что касается вашей проблемы с сеансом, так как вы делаете это в пакетном режиме, почему бы просто не глотать данные с Kafka в HDFS или Cassandra, а затем писать запросы для полных сессий? Вы можете использовать прямую связь Spark Streaming с Kafka для этого.

Answer 2

В настоящее время я работаю над той же реализацией. Я использую Kafka, HBase, Spark и Spark Streaming.

При использовании этих технологий есть много вещей, и, вероятно, нет простого ответа.

Основные моменты использования Spark Streaming - это то, что вы получаете минимальную задержку в 100 мс для данных потока, а также еще одну большую проблему для меня - беспорядок упорядочения данных, потребляемых потоковым заданием. То, что с комбинацией потенциальных отставших приводит к полному недоверию к тому, что я обрабатываю данные, по крайней мере, в частичном порядке (насколько мне известно, по крайней мере). Шторм, мол, решает эти проблемы, но я не могу этого гарантировать, так как я его не использовал.

Что касается пакетного слоя, Spark определенно лучше, чем MapReduce, поскольку он быстрее и гибче.

Затем возникает проблема с синхронизацией между Batch и Speed ​​с точки зрения понимания того, где данные пакетного задания останавливают скорость. Я решаю эту проблему, так как мой уровень скорости также является тем, который помещает данные в HBase, прежде чем выполнять обработку на нем.

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

Answer 3

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

Вам не нужно повторно потреблять все данные для сеанса из темы, прежде чем вы сможете обработать ее, предполагая, что вы с ней работаете (ваше сокращение) является ассоциативной операцией , Даже если это не ассоциативно (например, «Уникальные пользователи»), вы все равно можете быть в порядке с очень точной оценкой, которая может быть рассчитана итеративно, как журнал Hyper Log Log. Скорее всего, вы будете использовать какую-то агрегацию состояний. В Spark вы можете это сделать либо с помощью updateStateByKey, либо, предпочтительно, с функциями mapWithState.

Если вы ищете конкретные примеры на конкретно технологии и случаях использования вы упоминаете, я укажу вам на курс Pluralsight, где вы можете узнать все об этом и на практике это Applying the Lambda Architecture with Spark, Kafka, and Cassandra

Я также отметить, что, если вы делаете достаточно прямо, и потому что вы уже используете Kafka, вы можете захотеть рассмотреть Kafka Connect для сохранения HDFS и потоков Kafka для потоковой передачи. Вы даже можете использовать потоки Kafka для потоковой передачи данных прямо в Kafka и использовать Kafka Connect для ее передачи в несколько пунктов назначения, таких как Cassandra и ElasticSearch. Я упоминаю Kafka Streams, потому что он также имеет возможность удерживать некоторое состояние в памяти и выполнять простые потоковые операции.

Удачи вам!