웹사이트 검색

Hadoop, Storm, Samza, Spark 및 Flink: 빅 데이터 프레임워크 비교


소개

빅 데이터는 대규모 데이터 세트에서 통찰력을 수집, 구성, 처리 및 수집하는 데 필요한 비전통적 전략 및 기술에 대한 포괄적인 용어입니다. 단일 컴퓨터의 컴퓨팅 성능 또는 스토리지를 초과하는 데이터로 작업하는 문제는 새로운 것이 아니지만 이러한 유형의 컴퓨팅의 보급성, 규모 및 가치는 최근 몇 년 동안 크게 확장되었습니다.

이전 가이드에서는 빅 데이터 시스템에서 사용되는 일반적인 개념, 처리 단계 및 용어에 대해 논의했습니다. 이 기사에서는 빅 데이터 시스템의 가장 중요한 구성 요소 중 하나인 처리 프레임워크를 살펴보겠습니다. 처리 프레임워크는 비휘발성 저장소에서 읽거나 시스템에 수집될 때 시스템의 데이터를 계산합니다. 데이터 컴퓨팅은 대량의 개별 데이터 포인트에서 정보와 통찰력을 추출하는 프로세스입니다.

다음 프레임워크를 다룰 것입니다.

  • 배치 전용 프레임워크:\n
    • 아파치 하둡

    • 아파치 스톰
    • 아파치 삼자

    • 아파치 스파크
    • 아파치 플링크

    빅 데이터 처리 프레임워크란 무엇입니까?

    처리 프레임워크 및 처리 엔진은 데이터 시스템의 데이터 컴퓨팅을 담당합니다. "프레임워크\와 "엔진\을 구분하는 권위 있는 정의는 없지만 전자를 데이터 작업을 담당하는 실제 구성 요소로 정의하고 후자를 동일한 작업을 수행하도록 설계된 구성 요소 집합으로 정의하는 것이 때때로 유용합니다.

    예를 들어 Apache Hadoop은 MapReduce를 기본 처리 엔진으로 사용하는 처리 프레임워크로 간주될 수 있습니다. 엔진과 프레임워크는 종종 교체하거나 동시에 사용할 수 있습니다. 예를 들어, 또 다른 프레임워크인 Apache Spark는 Hadoop에 연결하여 MapReduce를 대체할 수 있습니다. 이러한 구성 요소 간의 상호 운용성은 빅 데이터 시스템이 뛰어난 유연성을 갖는 한 가지 이유입니다.

    데이터 수명 주기의 이 단계를 처리하는 시스템은 복잡할 수 있지만 광범위한 수준의 목표는 매우 유사합니다. 즉, 이해도를 높이고 패턴을 표면화하고 복잡한 상호 작용에 대한 통찰력을 얻기 위해 데이터를 조작하는 것입니다.

    이러한 구성 요소에 대한 논의를 단순화하기 위해 처리하도록 설계된 데이터의 상태별로 이러한 처리 프레임워크를 그룹화합니다. 일부 시스템은 데이터를 배치로 처리하는 반면 다른 시스템은 데이터가 시스템으로 유입될 때 연속 스트림으로 데이터를 처리합니다. 여전히 다른 사람들은 이러한 방법 중 하나로 데이터를 처리할 수 있습니다.

    다양한 구현의 세부 사항과 결과를 살펴보기 전에 개념으로 각 유형의 처리를 소개합니다.

    일괄 처리 시스템

    일괄 처리는 빅 데이터 세계에서 오랜 역사를 가지고 있습니다. 일괄 처리에는 대규모 정적 데이터 세트에 대한 작업과 나중에 계산이 완료될 때 결과를 반환하는 작업이 포함됩니다.

    일괄 처리의 데이터 세트는 일반적으로…

    • 제한됨: 배치 데이터세트는 유한한 데이터 모음을 나타냅니다.
    • 영구적: 데이터는 거의 항상 일종의 영구 저장소로 백업됩니다.
    • 대형: 배치 작업은 매우 큰 데이터 집합을 처리하기 위한 유일한 옵션인 경우가 많습니다.

    일괄 처리는 전체 레코드 집합에 대한 액세스가 필요한 계산에 매우 적합합니다. 예를 들어 총계와 평균을 계산할 때 데이터 세트는 개별 레코드의 모음이 아니라 전체적으로 취급되어야 합니다. 이러한 작업을 수행하려면 계산 기간 동안 상태를 유지해야 합니다.

    매우 많은 양의 데이터가 필요한 작업은 종종 배치 작업으로 가장 잘 처리됩니다. 데이터 세트가 영구 저장소에서 직접 처리되든 메모리에 로드되든 배치 시스템은 대용량을 염두에 두고 구축되며 이를 처리할 리소스가 있습니다. 일괄 처리는 대량의 영구 데이터를 처리하는 데 탁월하기 때문에 기록 데이터와 함께 자주 사용됩니다.

    많은 양의 데이터를 처리하는 대가로 계산 시간이 길어집니다. 이 때문에 처리 시간이 특히 중요한 상황에서는 일괄 처리가 적합하지 않습니다.

    아파치 하둡

    Apache Hadoop은 일괄 처리를 독점적으로 제공하는 처리 프레임워크입니다. Hadoop은 오픈 소스 커뮤니티에서 상당한 견인력을 얻은 최초의 빅 데이터 프레임워크였습니다. 당시 엄청난 양의 데이터를 어떻게 처리했는지에 대한 Google의 여러 논문과 프레젠테이션을 기반으로 Hadoop은 알고리즘과 구성 요소 스택을 다시 구현하여 대규모 배치 처리에 보다 쉽게 접근할 수 있도록 했습니다.

    최신 버전의 Hadoop은 배치 데이터를 처리하기 위해 함께 작동하는 여러 구성 요소 또는 계층으로 구성됩니다.

    • HDFS: HDFS는 클러스터 노드에서 스토리지 및 복제를 조정하는 분산 파일 시스템 계층입니다. HDFS는 불가피한 호스트 장애에도 불구하고 데이터를 계속 사용할 수 있도록 합니다. 중간 처리 결과를 저장하고 최종 계산 결과를 유지하기 위해 데이터 소스로 사용됩니다.
    • YARN: Yet Another Resource Negotiator를 의미하는 YARN은 Hadoop 스택의 클러스터 조정 구성 요소입니다. 기본 리소스를 조정 및 관리하고 실행할 작업을 예약하는 일을 담당합니다. YARN을 사용하면 클러스터 리소스에 대한 인터페이스 역할을 하여 이전 반복에서 가능했던 것보다 Hadoop 클러스터에서 훨씬 더 다양한 워크로드를 실행할 수 있습니다.
    • MapReduce: MapReduce는 Hadoop의 기본 일괄 처리 엔진입니다.

    일괄 처리 모델

    Hadoop의 처리 기능은 MapReduce 엔진에서 나옵니다. MapReduce의 처리 기술은 키-값 쌍을 사용하는 맵, 셔플, 축소 알고리즘을 따릅니다. 기본 절차에는 다음이 포함됩니다.

    • HDFS 파일 시스템에서 데이터세트 읽기
    • 데이터세트를 청크로 나누고 사용 가능한 노드에 배포
    • 각 노드의 계산을 데이터 하위 집합에 적용(중간 결과는 HDFS에 다시 기록됨)
    • 중간 결과를 키별로 그룹화하여 재배포
    • \\개별 노드에서 계산된 결과를 요약하고 결합하여 각 키의 값을 \감소\
    • 계산된 최종 결과를 다시 HDFS에 기록

    장점과 한계

    이 방법론은 영구 저장소를 많이 활용하고 작업당 여러 번 읽고 쓰기 때문에 상당히 느린 경향이 있습니다. 반면에 디스크 공간은 일반적으로 가장 풍부한 서버 리소스 중 하나이므로 MapReduce가 방대한 데이터 세트를 처리할 수 있음을 의미합니다. 이것은 또한 Hadoop의 MapReduce가 모든 것을 메모리에 저장하려고 시도하지 않기 때문에 일반적으로 일부 대안보다 저렴한 하드웨어에서 실행될 수 있음을 의미합니다. MapReduce는 놀라운 확장성 잠재력을 가지고 있으며 수만 개의 노드에서 프로덕션에 사용되었습니다.

    개발 대상으로서 MapReduce는 학습 곡선이 다소 가파른 것으로 알려져 있습니다. Hadoop 생태계에 대한 다른 추가 사항은 이것의 영향을 다양한 정도로 줄일 수 있지만 Hadoop 클러스터에서 아이디어를 신속하게 구현하는 데 여전히 요인이 될 수 있습니다.

    Hadoop은 Hadoop 클러스터 자체가 다른 소프트웨어의 빌딩 블록으로 자주 사용되는 광범위한 생태계를 가지고 있습니다. 다른 많은 처리 프레임워크 및 엔진에는 HDFS 및 YARN 리소스 관리자를 활용하기 위한 Hadoop 통합이 있습니다.

    요약

    Apache Hadoop 및 해당 MapReduce 처리 엔진은 시간이 중요한 요소가 아닌 매우 큰 데이터 집합을 처리하는 데 가장 적합한 잘 테스트된 일괄 처리 모델을 제공합니다. 제대로 작동하는 Hadoop 클러스터에 필요한 구성 요소의 비용이 낮기 때문에 이 처리는 많은 사용 사례에서 저렴하고 효과적입니다. 다른 프레임워크 및 엔진과의 호환성 및 통합은 Hadoop이 종종 다양한 기술을 사용하는 다중 처리 워크로드의 기반 역할을 할 수 있음을 의미합니다.

    스트림 처리 시스템

    스트림 처리 시스템은 데이터가 시스템에 들어올 때 데이터를 계산합니다. 이를 위해서는 배치 패러다임과 다른 처리 모델이 필요합니다. 전체 데이터 세트에 적용할 작업을 정의하는 대신 스트림 프로세서는 시스템을 통과할 때 각 개별 데이터 항목에 적용할 작업을 정의합니다.

    스트림 처리의 데이터 세트는 "제한이 없는\ 것으로 간주됩니다. 여기에는 몇 가지 중요한 의미가 있습니다.

    • 데이터세트는 지금까지 시스템에 입력된 데이터의 양으로만 정의됩니다.
    • 작동하는 데이터세트는 아마도 더 관련성이 있으며 한 번에 하나의 항목으로 제한됩니다.
    • 처리는 이벤트 기반이며 명시적으로 중지될 때까지 "종료\되지 않습니다. 결과는 즉시 사용할 수 있으며 새 데이터가 도착하면 계속 업데이트됩니다.

    스트림 처리 시스템은 거의 무제한에 가까운 데이터를 처리할 수 있지만 한 번에 하나(진정한 스트림 처리) 또는 아주 적은 수의 항목(마이크로 배치 처리)만 처리하고 레코드 간에 최소한의 상태만 유지합니다. 대부분의 시스템은 일부 상태를 유지하는 방법을 제공하지만 증기 처리는 부작용이 거의 없는 보다 기능적인 처리를 위해 고도로 최적화되어 있습니다.

    기능적 작업은 제한된 상태 또는 부작용이 있는 개별 단계에 중점을 둡니다. 동일한 데이터에 대해 동일한 작업을 수행하면 다른 요소와 관계없이 동일한 출력이 생성됩니다. 이러한 종류의 처리는 항목 간의 상태가 일반적으로 어렵고 제한적이며 때로는 바람직하지 않은 조합이기 때문에 스트림에 잘 맞습니다. 따라서 일부 유형의 상태 관리가 일반적으로 가능하지만 이러한 프레임워크는 부재 시 훨씬 더 간단하고 효율적입니다.

    이러한 유형의 처리는 특정 유형의 워크로드에 적합합니다. 거의 실시간 요구 사항을 가진 처리는 스트리밍 모델에서 잘 제공됩니다. 분석, 서버 또는 애플리케이션 오류 로깅 및 기타 시간 기반 메트릭은 이러한 영역의 변화에 대응하는 것이 비즈니스 기능에 중요할 수 있기 때문에 자연스럽게 적합합니다. 스트림 처리는 변화 또는 스파이크에 대응해야 하고 시간 경과에 따른 추세에 관심이 있는 데이터에 적합합니다.

    아파치 스톰

    Apache Storm은 대기 시간이 매우 짧은 스트림 처리 프레임워크이며 거의 실시간 처리가 필요한 워크로드에 가장 적합한 옵션일 것입니다. 매우 많은 양의 데이터를 처리하고 다른 솔루션보다 짧은 대기 시간으로 결과를 제공할 수 있습니다.

    스트림 처리 모델

    Storm 스트림 처리는 토폴로지라고 하는 프레임워크에서 DAG(방향성 비순환 그래프)를 오케스트레이션하여 작동합니다. 이러한 토폴로지는 들어오는 각 데이터 조각이 시스템에 입력될 때 수행되는 다양한 변환 또는 단계를 설명합니다.

    토폴로지는 다음으로 구성됩니다.

    • 스트림: 기존 데이터 스트림. 이것은 지속적으로 시스템에 도착하는 무제한 데이터입니다.
    • Spouts: 토폴로지 가장자리에 있는 데이터 스트림의 소스입니다. 작업할 데이터를 생성하는 API, 대기열 등이 될 수 있습니다.
    • 볼트: 볼트는 스트림을 소비하고 작업을 적용하며 결과를 스트림으로 출력하는 처리 단계를 나타냅니다. 각각의 주둥이에 볼트로 연결한 후 서로 연결하여 필요한 모든 가공을 합니다. 토폴로지 끝에서 최종 볼트 출력은 연결된 시스템의 입력으로 사용될 수 있습니다.

    Storm의 기본 아이디어는 위의 구성 요소를 사용하여 작고 개별적인 작업을 정의한 다음 이를 토폴로지로 구성하는 것입니다. 기본적으로 Storm은 최소 한 번 처리 보장을 제공합니다. 즉, 각 메시지가 한 번 이상 처리되도록 보장할 수 있지만 일부 실패 시나리오에서는 중복이 있을 수 있습니다. Storm은 메시지가 순서대로 처리된다고 보장하지 않습니다.

    정확히 한 번만 상태 저장 처리를 수행하기 위해 Trident라는 추상화도 사용할 수 있습니다. 명시적으로 말하면 Trident가 없는 Storm은 종종 Core Storm이라고 합니다. Trident는 Storm의 처리 역학을 크게 변경하여 대기 시간을 늘리고 처리에 상태를 추가하며 항목별 순수 스트리밍 시스템 대신 마이크로 배치 모델을 구현합니다.

    Storm 사용자는 일반적으로 이러한 페널티를 피하기 위해 가능할 때마다 Core Storm을 사용하는 것이 좋습니다. 이를 염두에 두고 항목을 정확히 한 번만 처리한다는 Trident의 보장은 시스템이 중복 메시지를 지능적으로 처리할 수 없는 경우에 유용합니다. 또한 Trident는 한 시간 동안 얼마나 많은 사용자가 링크를 클릭했는지 계산할 때와 같이 항목 사이의 상태를 유지해야 하는 경우 Storm 내에서 유일한 선택입니다. Trident는 Storm의 유연성을 제공하지만 프레임워크의 고유한 강점을 발휘하지는 않습니다.

    Trident 토폴로지는 다음으로 구성됩니다.

    • 스트림 배치: 이는 일괄 처리 시맨틱을 제공하기 위해 청크되는 스트림 데이터의 마이크로 배치입니다.
    • 작업: 데이터에 대해 수행할 수 있는 배치 절차입니다.

    장점과 한계

    Storm은 현재 거의 실시간으로 처리할 수 있는 최고의 솔루션일 것입니다. 최소한의 지연으로 처리해야 하는 워크로드에 대해 매우 짧은 대기 시간으로 데이터를 처리할 수 있습니다. 처리 시간이 사용자 경험에 직접적인 영향을 미칠 때 Storm은 종종 좋은 선택입니다. 예를 들어 처리 피드백이 웹 사이트의 방문자 페이지로 직접 피드백되는 경우입니다.

    Storm with Trident는 순수 스트림 처리 대신 마이크로 배치를 사용할 수 있는 옵션을 제공합니다. 이는 사용자가 의도한 용도에 맞게 도구를 구성할 수 있는 더 큰 유연성을 제공하지만 다른 솔루션에 비해 소프트웨어의 가장 큰 이점 중 일부를 무효화하는 경향이 있습니다. 즉, 스트림 처리 스타일을 선택하는 것이 여전히 도움이 됩니다.

    Core Storm은 메시지의 순서 보장을 제공하지 않습니다. Core Storm은 최소 한 번 처리 보장을 제공합니다. 즉, 각 메시지의 처리가 보장될 수 있지만 중복이 발생할 수 있습니다. Trident는 정확히 한 번 보장을 제공하며 배치 간 주문을 제공할 수 있지만 내부는 제공하지 않습니다.

    상호 운용성 측면에서 Storm은 Hadoop의 YARN 리소스 협상자와 통합할 수 있으므로 기존 Hadoop 배포에 쉽게 연결할 수 있습니다. 대부분의 처리 프레임워크보다 Storm은 매우 광범위한 언어 지원을 제공하여 사용자에게 토폴로지를 정의하기 위한 다양한 옵션을 제공합니다.

    요약

    대기 시간 요구 사항이 매우 엄격한 순수 스트림 처리 워크로드의 경우 Storm이 아마도 가장 성숙한 옵션일 것입니다. 메시지 처리를 보장할 수 있으며 많은 프로그래밍 언어와 함께 사용할 수 있습니다. Storm은 일괄 처리를 수행하지 않기 때문에 이러한 기능이 필요한 경우 추가 소프트웨어를 사용해야 합니다. 정확히 한 번 처리 보장이 필요한 경우 Trident가 이를 제공할 수 있습니다. 그러나 다른 스트림 처리 프레임워크도 해당 시점에 더 적합할 수 있습니다.

    아파치 삼자

    Apache Samza는 Apache Kafka 메시징 시스템과 밀접하게 연결된 스트림 처리 프레임워크입니다. Kafka는 많은 스트림 처리 시스템에서 사용할 수 있지만 Samza는 Kafka의 고유한 아키텍처 및 보장을 활용하도록 특별히 설계되었습니다. Kafka를 사용하여 내결함성, 버퍼링 및 상태 저장을 제공합니다.

    Samza는 리소스 협상에 YARN을 사용합니다. 즉, 기본적으로 Hadoop 클러스터가 필요하지만(최소한 HDFS 및 YARN) Samza가 YARN에 내장된 풍부한 기능에 의존할 수 있음을 의미합니다.

    스트림 처리 모델

    Samza는 스트림 처리 방식을 정의하기 위해 Kafka의 의미론에 의존합니다. Kafka는 데이터를 처리할 때 다음 개념을 사용합니다.

    • 주제: Kafka 시스템에 입력되는 각 데이터 스트림을 주제라고 합니다. 주제는 기본적으로 소비자가 구독할 수 있는 관련 정보의 흐름입니다.
    • 파티션: 노드 간에 주제를 분산하기 위해 Kafka는 수신 메시지를 파티션으로 나눕니다. 파티션 분할은 동일한 키를 가진 각 메시지가 동일한 파티션으로 전송되도록 보장하는 키를 기반으로 합니다. 파티션에는 순서가 보장되어 있습니다.
    • 브로커: Kafka 클러스터를 구성하는 개별 노드를 브로커라고 합니다.
    • 프로듀서: Kafka 토픽에 작성하는 모든 구성 요소를 프로듀서라고 합니다. 생산자는 주제를 분할하는 데 사용되는 키를 제공합니다.
    • 소비자: 소비자는 Kafka 주제에서 읽는 모든 구성 요소입니다. 소비자는 자신의 오프셋에 대한 정보를 유지 관리할 책임이 있으므로 오류가 발생한 경우 어떤 레코드가 처리되었는지 알 수 있습니다.

    Kafka는 변경 불가능한 로그를 나타내므로 Samza는 변경 불가능한 스트림을 처리합니다. 이는 모든 변환이 초기 스트림에 영향을 주지 않고 다른 구성 요소에서 사용하는 새 스트림을 생성함을 의미합니다.

    장점과 한계

    Kafka와 같은 대기열 시스템에 대한 Samza의 의존성은 언뜻 보기에 제한적으로 보일 수 있습니다. 그러나 다른 스트림 처리 시스템에서는 일반적이지 않은 몇 가지 고유한 보장과 기능을 시스템에 제공합니다.

    예를 들어 Kafka는 짧은 대기 시간으로 액세스할 수 있는 복제된 데이터 저장소를 이미 제공하고 있습니다. 또한 각 개별 데이터 파티션에 매우 쉽고 저렴한 다중 가입자 모델을 제공합니다. 중간 결과를 포함한 모든 출력도 Kafka에 기록되며 다운스트림 단계에서 독립적으로 사용할 수 있습니다.

    여러 면에서 Kafka에 대한 이러한 긴밀한 의존은 MapReduce 엔진이 HDFS를 자주 참조하는 방식을 반영합니다. 각 계산 사이에 HDFS를 참조하면 일괄 처리 시 몇 가지 심각한 성능 문제가 발생하지만 스트림 처리 시 여러 가지 문제를 해결합니다.

    Samza와 Kafka의 강력한 관계를 통해 처리 단계 자체를 매우 느슨하게 연결할 수 있습니다. 사전 조정 없이 임의의 수의 가입자를 모든 단계의 출력에 추가할 수 있습니다. 이는 여러 팀이 유사한 데이터에 액세스해야 하는 조직에 매우 유용할 수 있습니다. 팀은 시스템에 입력되는 데이터의 주제를 모두 구독하거나 일부 처리를 거친 다른 팀에서 만든 주제를 쉽게 구독할 수 있습니다. 이는 데이터베이스와 같은 로드에 민감한 인프라에 추가적인 스트레스를 추가하지 않고도 수행할 수 있습니다.

    Kafka에 직접 작성하면 배압 문제도 제거됩니다. 배압은 부하 급증으로 인해 구성 요소가 실시간으로 처리할 수 있는 것보다 더 빠른 속도로 데이터 유입이 발생하여 처리 중단 및 잠재적인 데이터 손실로 이어지는 경우입니다. Kafka는 매우 오랜 기간 동안 데이터를 보유하도록 설계되었습니다. 즉, 구성 요소가 편리하게 처리될 수 있고 결과 없이 다시 시작할 수 있습니다.

    Samza는 로컬 키-값 저장소로 구현된 내결함성 체크포인트 시스템을 사용하여 상태를 저장할 수 있습니다. 이를 통해 Samza는 최소 한 번 배달 보장을 제공할 수 있지만 데이터가 두 번 이상 배달될 수 있으므로 장애 발생 시 집계된 상태(카운트 등)의 정확한 복구를 제공하지 않습니다.

    Samza는 Storm과 같은 시스템에서 제공하는 프리미티브보다 작업하기 쉬운 여러 가지 방법으로 높은 수준의 추상화를 제공합니다. 현재 Samza는 JVM 언어만 지원합니다. 즉, Storm과 같은 언어 유연성이 없습니다.

    요약

    Apache Samza는 Hadoop 및 Kafka가 이미 사용 가능하거나 구현하기에 적합한 스트리밍 워크로드에 적합한 선택입니다. Samza 자체는 다양한 처리 단계에서 데이터 스트림을 사용하는(반드시 긴밀하게 조정할 필요는 없음) 여러 팀이 있는 조직에 적합합니다. Samza는 스트림 처리의 많은 부분을 크게 단순화하고 대기 시간이 짧은 성능을 제공합니다. 배포 요구 사항이 현재 시스템과 호환되지 않는 경우, 대기 시간이 매우 짧은 처리가 필요한 경우 또는 정확히 한 번 의미 체계가 필요한 경우에는 적합하지 않을 수 있습니다.

    하이브리드 처리 시스템: 배치 및 스트림 프로세서

    일부 처리 프레임워크는 배치 및 스트림 워크로드를 모두 처리할 수 있습니다. 이러한 프레임워크는 동일하거나 관련된 구성 요소 및 API를 두 가지 유형의 데이터 모두에 사용할 수 있도록 하여 다양한 처리 요구 사항을 단순화합니다.

    보시다시피 이것이 달성되는 방식은 우리가 논의할 두 프레임워크인 Spark와 Flink 간에 크게 다릅니다. 이것은 주로 두 처리 패러다임이 결합되는 방식과 고정 데이터 세트와 비고정 데이터 세트 간의 관계에 대해 어떤 가정이 이루어지는지에 대한 함수입니다.

    하나의 처리 유형에 초점을 맞춘 프로젝트는 특정 사용 사례에 적합할 수 있지만 하이브리드 프레임워크는 데이터 처리를 위한 일반적인 솔루션을 제공하려고 시도합니다. 데이터 처리 방법을 제공할 뿐만 아니라 그래프 분석, 기계 학습 및 대화형 쿼리와 같은 작업을 수행하기 위한 자체 통합, 라이브러리 및 도구가 있습니다.

    아파치 스파크

    Apache Spark는 스트림 처리 기능을 갖춘 차세대 일괄 처리 프레임워크입니다. Hadoop의 MapReduce 엔진과 동일한 여러 원칙을 사용하여 구축된 Spark는 전체 인메모리 계산 및 처리 최적화를 제공하여 일괄 처리 워크로드 속도를 높이는 데 주로 중점을 둡니다.

    Spark는 독립 실행형 클러스터(가능한 스토리지 계층과 쌍을 이루는 경우)로 배포하거나 MapReduce 엔진의 대안으로 Hadoop에 연결할 수 있습니다.

    일괄 처리 모델

    MapReduce와 달리 Spark는 모든 데이터를 메모리 내에서 처리하며 스토리지 계층과만 상호 작용하여 초기에 데이터를 메모리에 로드하고 마지막에 최종 결과를 유지합니다. 모든 중간 결과는 메모리에서 관리됩니다.

    메모리 내 처리가 속도에 크게 기여하는 반면 Spark는 전체 작업 세트를 미리 분석하여 달성할 수 있는 전체론적 최적화로 인해 디스크 관련 작업에서도 더 빠릅니다. 수행해야 하는 모든 작업, 작업할 데이터 및 이들 간의 관계를 나타내는 방향성 비순환 그래프(Directed Acyclic Graphs, DAG)를 생성하여 프로세서가 지능적으로 작업을 조정할 수 있는 더 큰 기능을 제공함으로써 이를 달성합니다.

    메모리 내 배치 계산을 구현하기 위해 Spark는 RDD(Resilient Distributed Datasets)라는 모델을 사용하여 데이터 작업을 수행합니다. 이들은 데이터 컬렉션을 나타내는 메모리 내에 존재하는 불변 구조입니다. RDD에 대한 작업은 새로운 RDD를 생성합니다. 각 RDD는 상위 RDD를 통해 궁극적으로 디스크의 데이터까지 계보를 추적할 수 있습니다. 기본적으로 RDD는 스파크가 각 작업 후 디스크에 다시 쓸 필요 없이 내결함성을 유지하는 방법입니다.

    스트림 처리 모델

    스트림 처리 기능은 Spark Streaming에서 제공합니다. Spark 자체는 배치 중심 워크로드를 염두에 두고 설계되었습니다. 엔진 설계와 스트리밍 워크로드의 특성 간의 차이를 처리하기 위해 Spark는 마이크로 배치*라는 개념을 구현합니다. 이 전략은 데이터 스트림을 배치 엔진의 기본 의미 체계를 사용하여 처리할 수 있는 일련의 매우 작은 배치로 처리하도록 설계되었습니다.

    Spark Streaming은 1초 미만의 증분으로 스트림을 버퍼링하여 작동합니다. 이들은 일괄 처리를 위해 작은 고정 데이터 세트로 전송됩니다. 실제로 이것은 꽤 잘 작동하지만 실제 스트림 처리 프레임워크와 다른 성능 프로필을 초래합니다.

    장점과 한계

    Hadoop MapReduce보다 Spark를 사용하는 분명한 이유는 속도입니다. Spark는 인메모리 계산 전략과 고급 DAG 스케줄링 덕분에 동일한 데이터 세트를 훨씬 빠르게 처리할 수 있습니다.

    Spark의 또 다른 주요 장점은 다용도성입니다. 독립 실행형 클러스터로 배포하거나 기존 Hadoop 클러스터와 통합할 수 있습니다. 배치 및 스트림 처리를 모두 수행할 수 있으므로 단일 클러스터를 운영하여 여러 처리 스타일을 처리할 수 있습니다.

    엔진 자체의 기능 외에도 Spark에는 기계 학습, 대화형 쿼리 등에 사용할 수 있는 라이브러리 에코시스템이 있습니다. Spark 작업은 생산성에 상당한 영향을 미칠 수 있는 MapReduce보다 작성하기 쉬운 것으로 거의 보편적으로 인정됩니다.

    스트림 처리를 위한 배치 방법론을 적용하려면 데이터가 시스템에 입력될 때 데이터를 버퍼링해야 합니다. 버퍼를 사용하면 많은 양의 수신 데이터를 처리할 수 있으므로 전체 처리량이 증가하지만 버퍼 플러시를 기다리면 대기 시간이 크게 증가합니다. 이는 짧은 대기 시간이 필수적인 처리에는 Spark 스트리밍이 적합하지 않을 수 있음을 의미합니다.

    RAM은 일반적으로 디스크 공간보다 비싸기 때문에 Spark는 디스크 기반 시스템보다 실행 비용이 더 많이 들 수 있습니다. 그러나 향상된 처리 속도는 작업을 훨씬 더 빨리 완료할 수 있음을 의미하며, 시간당 리소스 비용을 지불하는 환경에서 운영할 때 비용을 완전히 상쇄할 수 있습니다.

    Spark의 인메모리 설계의 또 다른 결과는 리소스 부족이 공유 클러스터에 배포될 때 문제가 될 수 있다는 것입니다. Hadoop의 MapReduce와 비교할 때 Spark는 훨씬 더 많은 리소스를 사용하므로 당시 클러스터를 사용하려고 할 수 있는 다른 작업을 방해할 수 있습니다. 본질적으로 Spark는 Hadoop 스택에서 작동할 수 있는 다른 구성 요소보다 덜 사려 깊은 이웃일 수 있습니다.

    요약

    Spark는 다양한 처리 워크로드가 있는 사람들에게 훌륭한 옵션입니다. Spark 배치 처리는 놀라운 속도 이점을 제공하여 높은 메모리 사용량을 상쇄합니다. Spark Streaming은 대기 시간보다 처리량을 중시하는 워크로드에 적합한 스트림 처리 솔루션입니다.

    아파치 플링크

    Apache Flink는 일괄 작업도 처리할 수 있는 스트림 처리 프레임워크입니다. 배치를 단순히 경계가 한정된 데이터 스트림으로 간주하므로 배치 처리를 스트림 처리의 하위 집합으로 취급합니다. 모든 처리에 대한 이 스트림 우선 접근 방식에는 여러 가지 흥미로운 부작용이 있습니다.

    이 스트림 우선 접근 방식은 더 널리 알려진 Lambda 아키텍처(초기에 정제되지 않은 결과를 보완하고 제공하는 데 사용되는 스트림과 함께 일괄 처리가 기본 처리 방법으로 사용됨)와 달리 Kappa 아키텍처라고 불립니다. 스트림이 모든 것에 사용되는 Kappa 아키텍처는 모델을 단순화하고 스트림 처리 엔진이 더욱 정교해짐에 따라 최근에야 가능해졌습니다.

    스트림 처리 모델

    Flink의 스트림 처리 모델은 들어오는 데이터를 항목별로 진정한 스트림으로 처리합니다. Flink는 무제한 데이터 스트림으로 작업할 수 있는 DataStream API를 제공합니다. Flink와 함께 작동하는 기본 구성 요소는 다음과 같습니다.

    • 스트림은 시스템을 통해 흐르는 불변의 무제한 데이터 세트입니다.
    • 연산자는 데이터 스트림에서 작동하여 다른 스트림을 생성하는 기능입니다.
    • 소스는 시스템에 들어오는 스트림의 진입점입니다.
    • 싱크는 스트림이 Flink 시스템에서 흘러나오는 곳입니다. 데이터베이스 또는 다른 시스템에 대한 커넥터를 나타낼 수 있습니다.

    스트림 처리 작업은 문제 발생 시 복구에 사용하기 위해 계산 중에 설정 지점에서 스냅샷을 찍습니다. 상태를 저장하기 위해 Flink는 다양한 수준의 복잡성과 지속성에 따라 여러 상태 백엔드와 함께 작동할 수 있습니다.

    또한 Flink의 스트림 처리는 이벤트가 실제로 발생한 시간을 의미하는 "이벤트 시간\의 개념을 이해할 수 있으며 세션도 처리할 수 있습니다. 즉, 몇 가지 흥미로운 방식으로 순서 지정 및 그룹화를 보장할 수 있습니다.

    일괄 처리 모델

    여러 면에서 Flink의 일괄 처리 모델은 스트림 처리 모델의 확장일 뿐입니다. 연속 스트림에서 읽는 대신 영구 저장소에서 제한된 데이터 세트를 스트림으로 읽습니다. Flink는 이러한 처리 모델 모두에 대해 정확히 동일한 런타임을 사용합니다.

    Flink는 배치 워크로드에 대한 몇 가지 최적화를 제공합니다. 예를 들어 배치 작업은 영구 스토리지에서 지원하므로 Flink는 배치 로드에서 스냅샷을 제거합니다. 데이터는 여전히 복구 가능하지만 일반 처리가 더 빨리 완료됩니다.

    또 다른 최적화에는 단계와 구성 요소가 필요할 때만 관련되도록 배치 작업을 분할하는 작업이 포함됩니다. 이를 통해 Flink는 클러스터의 다른 사용자와 잘 어울립니다. 작업에 대한 선제적 분석을 통해 Flink는 전체 작업 집합, 데이터 집합의 크기 및 진행 중인 단계의 요구 사항을 확인하여 최적화할 수 있습니다.

    장점과 한계

    Flink는 현재 처리 프레임워크 세계에서 고유한 옵션입니다. Spark는 배치 및 스트림 처리를 수행하지만 스트리밍은 마이크로 배치 아키텍처로 인해 많은 사용 사례에 적합하지 않습니다. Flink의 스트림 우선 접근 방식은 낮은 대기 시간, 높은 처리량 및 실제 항목별 처리를 제공합니다.

    Flink는 자체적으로 많은 것을 관리합니다. 성능상의 이유로 기본 Java 가비지 수집 메커니즘에 의존하는 대신 자체 메모리를 관리합니다. Spark와 달리 Flink는 처리하는 데이터의 특성이 변경될 때 수동 최적화 및 조정이 필요하지 않습니다. 데이터 분할 및 캐싱도 자동으로 처리합니다.

    Flink는 작업을 분석하고 다양한 방법으로 작업을 최적화합니다. 이 분석의 일부는 SQL 쿼리 플래너가 관계 데이터베이스 내에서 수행하는 작업과 유사하며 주어진 작업을 구현하는 가장 효과적인 방법을 매핑합니다. 병렬로 완료할 수 있는 단계를 병렬화하는 동시에 차단 작업을 위해 데이터를 함께 가져올 수 있습니다. 반복 작업의 경우 Flink는 성능상의 이유로 데이터가 저장된 노드에서 계산을 시도합니다. 또한 "델타 반복\ 또는 변경 사항이 있는 데이터 부분에 대해서만 반복을 수행할 수 있습니다.

    사용자 도구 측면에서 Flink는 작업을 쉽게 관리하고 시스템을 볼 수 있는 웹 기반 일정 보기를 제공합니다. 또한 사용자는 제출된 작업에 대한 최적화 계획을 표시하여 클러스터에서 실제로 어떻게 구현되는지 확인할 수 있습니다. 분석 작업을 위해 Flink는 SQL 스타일 쿼리, 그래프 처리 및 기계 학습 라이브러리, 메모리 내 계산을 제공합니다.

    Flink는 다른 구성 요소와 잘 작동합니다. 주어진 시간에 필요한 리소스만 차지하는 Hadoop 스택 내에서 사용하는 경우 좋은 이웃이 되도록 작성되었습니다. YARN, HDFS 및 Kafka와 쉽게 통합됩니다. Flink는 호환성 패키지를 사용하여 Hadoop 및 Storm과 같은 다른 처리 프레임워크용으로 작성된 작업을 실행할 수 있습니다.

    현재 Flink의 가장 큰 단점 중 하나는 아직 초기 프로젝트라는 것입니다. 야생에서의 대규모 배포는 여전히 다른 처리 프레임워크만큼 일반적이지 않으며 Flink의 확장 제한에 대한 연구가 많지 않았습니다. 빠른 개발 주기와 호환성 패키지와 같은 기능을 통해 조직에서 실험할 기회를 얻음에 따라 더 많은 Flink 배포가 시작될 수 있습니다.

    요약

    Flink는 기존 배치 작업을 지원하는 대기 시간이 짧은 스트림 처리를 모두 제공합니다. Flink는 스트림 처리 요구 사항이 많고 일부 배치 중심 작업이 있는 조직에 가장 적합할 것입니다. 기본 Storm 및 Hadoop 프로그램과의 호환성 및 YARN 관리 클러스터에서 실행할 수 있는 기능을 통해 쉽게 평가할 수 있습니다. 그것의 급속한 발전은 눈여겨볼 가치가 있습니다.

    결론

    빅 데이터 시스템 내에서 처리할 수 있는 많은 옵션이 있습니다.

    시간에 민감하지 않은 배치 전용 워크로드의 경우 Hadoop은 다른 솔루션보다 구현 비용이 적게 드는 좋은 선택입니다.

    스트림 전용 워크로드의 경우 Storm은 광범위한 언어를 지원하고 대기 시간이 매우 짧은 처리를 제공할 수 있지만 중복을 제공할 수 있으며 기본 구성에서 주문을 보장할 수 없습니다. Samza는 유연성, 쉬운 다중 팀 사용, 간단한 복제 및 상태 관리를 제공하기 위해 YARN 및 Kafka와 긴밀하게 통합됩니다.

    혼합 워크로드의 경우 Spark는 스트리밍을 위한 고속 배치 처리 및 마이크로 배치 처리를 제공합니다. 광범위한 지원, 통합 라이브러리 및 도구, 유연한 통합이 있습니다. Flink는 일괄 처리 지원을 통해 진정한 스트림 처리를 제공합니다. 매우 최적화되어 있고 다른 플랫폼용으로 작성된 작업을 실행할 수 있으며 대기 시간이 짧은 처리를 제공하지만 아직 채택 초기 단계에 있습니다.

    귀하의 상황에 가장 적합한 것은 처리할 데이터의 상태, 요구 사항이 얼마나 제한적인지, 관심 있는 결과의 종류에 따라 크게 달라집니다. 올인원 솔루션을 구현하는 것 사이에는 장단점이 있습니다. 밀접하게 초점을 맞춘 프로젝트와 함께 작업하며, 성숙하고 잘 테스트된 솔루션에 대해 새롭고 혁신적인 솔루션을 평가할 때 유사한 고려 사항이 있습니다.