В зависимости от потокового (я использую Кафка), вам не нужно использовать контрольно-пропускные пункты и т.д.
С искрой 1.3 они внедрили прямой подход с таким количеством преимуществ.
Упрощенный параллелизм: нет необходимости создавать несколько входных потоков Kafka и объединение их. С помощью directStream Spark Streaming будет создавать как множество разделов RDD, так как есть разделы Kafka, которые будут потреблять, которые все будут читать данные из Kafka параллельно. Таким образом, существует однократное сопоставление между разделами Kafka и RDD, которое проще понять и настроить.
Эффективность: для достижения нулевых потерь данных в первом подходе требуется данные, которые должны быть сохранены в журнале Write Ahead, который далее реплицировал данные . Это фактически неэффективно, так как данные эффективно получают , воспроизведенный дважды - один раз Kafka, а второй раз - Write Ahead Log. Этот второй подход устраняет проблему, поскольку нет приемника , и, следовательно, нет необходимости записывать записи вперед.
Семантика семантической точности: первый подход использует API высокого уровня Kafka для хранения использованных смещений в Zookeeper. Это традиционно способ потреблять данные от Kafka. Хотя этот подход (в сочетании с записывает вперед журналы) может обеспечить нулевую потерю данных (т. Е. По меньшей мере один раз семантики), существует небольшая вероятность, что некоторые записи могут потребляться дважды при некоторых отказах. Это происходит из-за несоответствий между данными, надежно полученными Spark Streaming и смещениями, отслеживаемыми от Zookeeper. Следовательно, в этом втором подходе мы используем простой API Kafka , который не использует Zookeeper и смещения, отслеживаемые только Spark Потоковая передача через свои контрольные точки. Это устраняет несоответствия между Spark Streaming и Zookeeper/Kafka, поэтому каждая запись , полученная Spark Streaming эффективно ровно один раз, несмотря на неудачи.
подход 2.