5 가지 대형 데이터 처리 아키텍처
대용량 데이터는 대용량 데이터 세트를 수집, 정리, 처리하고 통찰력을 얻는 데 필요한 비전통적인 전략과 기술의 총칭이다. 데이터를 처리하는 데 필요한 컴퓨팅 성능이나 스토리지 용량은 이미 한 대의 컴퓨터 한도를 초과했지만, 이러한 컴퓨팅 유형의 보편성, 규모 및 가치는 최근 몇 년 동안 대규모로 확장되었습니다. < P > 이 문서에서는 대용량 데이터 시스템의 가장 기본적인 구성 요소인 처리 프레임워크에 대해 설명합니다. 처리 프레임워크는 비휘발성 스토리지에서 읽은 데이터 처리 또는 방금 시스템에 섭취한 데이터 처리와 같은 시스템의 데이터 계산을 담당합니다. 데이터 계산은 대량의 단일 데이터 포인트에서 정보와 견해를 추출하는 프로세스입니다.
다음은 이러한 프레임에 대한 설명입니다.
배치 전용 프레임:
Apache Hadoop
흐름 전용 프레임:
Apache storm
Apache Sam za >
처리 프레임워크 및 처리 엔진은 데이터 시스템의 데이터 계산을 담당합니다. 엔진과 프레임 사이의 차이에는 권위있는 정의가 없지만 대부분의 경우 데이터 작업을 실제로 담당하는 구성 요소로 전자를 정의할 수 있으며, 후자는 유사한 역할을 수행하는 일련의 구성 요소로 정의할 수 있습니다. < P > 예를 들어 Apache Hadoop 은 MapReduce 를 기본 처리 엔진으로 사용하는 처리 프레임워크로 볼 수 있습니다. 엔진과 프레임워크는 일반적으로 서로 교체하거나 동시에 사용할 수 있습니다. 예를 들어, 다른 프레임인 Apache Spark 는 Hadoop 에 포함되어 MapReduce 를 대체할 수 있습니다. 구성 요소 간의 이러한 상호 운용성은 대용량 데이터 시스템의 유연성이 매우 높은 이유 중 하나입니다. < P > 수명 주기 동안 이 단계의 데이터를 처리하는 시스템은 일반적으로 복잡하지만, 광범위한 차원에서 볼 때 목표는 매우 일관적입니다. 즉, 데이터에 대한 작업을 수행하여 이해력을 높이고, 데이터에 포함된 패턴을 밝히고, 복잡한 상호 작용에 대한 통찰력을 얻을 수 있습니다.
이러한 구성 요소에 대한 토론을 단순화하기 위해 다양한 처리 프레임워크의 설계 의도를 통해 처리된 데이터 상태별로 분류합니다. 일부 시스템은 일괄 처리 방식으로 데이터를 처리할 수 있고, 일부 시스템은 지속적으로 시스템으로 유입되는 데이터를 스트리밍할 수 있습니다. 이 두 가지 유형의 데이터를 동시에 처리할 수 있는 시스템도 있습니다.
다양한 구현의 지표와 결론을 심층적으로 소개하기 전에 다양한 처리 유형의 개념에 대한 간단한 소개가 필요합니다.
배치 시스템
배치 처리는 빅 데이터 세계에서 오랜 역사를 가지고 있습니다. 일괄 처리는 주로 대용량 정적 데이터 세트를 조작하고 계산 프로세스가 완료된 후 결과를 반환합니다.
배치 모드에서 사용되는 데이터 세트는 일반적으로 다음과 같은 특징을 따릅니다 ...
경계: 배치 데이터 세트는 제한된 데이터 세트를 나타냅니다.
영구: 데이터는 항상 일정한 유형의 영구 저장 위치에 저장됩니다.
대량: 배치 작업은 일반적으로 매우 많은 양의 데이터 세트를 처리하는 유일한 방법입니다.
배치 매우 예를 들어, 총수와 평균을 계산할 때 데이터 세트를 하나의 전체로 처리해야 하며, 이를 여러 레코드의 모음으로 볼 수는 없습니다. 이러한 작업을 수행하려면 계산이 진행되는 동안 데이터가 자체 상태를 유지해야 합니다.
대량의 데이터를 처리해야 하는 작업은 일반적으로 일괄 처리 작업으로 처리하는 것이 가장 좋습니다. 영구 스토리지 장치에서 직접 데이터 세트를 처리하든, 먼저 데이터 세트를 메모리로 로드하든, 배치 시스템은 설계 과정에서 데이터 양을 충분히 고려하여 충분한 처리 자원을 제공합니다. 일괄 처리는 대량의 영구 데이터를 처리하는 데 매우 뛰어나기 때문에 과거 데이터를 분석하는 데 자주 사용됩니다.
대량의 데이터를 처리하는 데 많은 시간이 걸리기 때문에 처리 시간이 많이 필요한 경우에는 일괄 처리가 적합하지 않습니다.
Apache Hadoop
Apache Hadoop 은 배치 전용 처리 프레임워크입니다. Hadoop 은 오픈 소스 커뮤니티에서 큰 관심을 받은 최초의 대형 데이터 프레임워크입니다. 구글이 대량 데이터 처리에 대해 발표한 여러 논문과 경험을 바탕으로 한 Hadoop 은 관련 알고리즘과 구성 요소 스택을 다시 구현하여 대규모 배치 기술을 더욱 쉽게 사용할 수 있게 했다.
새 버전의 Hadoop 에는 여러 구성 요소, 즉 여러 계층이 포함되어 있으며 함께 사용하여 배치 데이터를 처리할 수 있습니다.
HDFS: HDFS 는 클러스터 노드 간 스토리지 및 복제를 조정하는 분산 파일 시스템 계층입니다. HDFS 는 불가피한 노드 장애 후에도 데이터를 계속 사용할 수 있도록 하고, 데이터 소스로 사용할 수 있으며, 중간 상태의 처리 결과를 저장하고, 계산의 최종 결과를 저장할 수 있도록 합니다.
yarn: yarn 은 Yet Another Resource Negotiator 의 약어로 Hadoop 스택의 클러스터 조정 구성 요소 역할을 합니다. 이 구성 요소는 기본 리소스를 조정 및 관리하고 작업 실행을 예약하는 역할을 합니다. YARN 은 클러스터 리소스 역할을 하는 인터페이스를 통해 사용자가 Hadoop 클러스터에서 이전 반복보다 더 많은 유형의 워크로드를 실행할 수 있도록 합니다.
MapReduce: MapReduce 는 Hadoop 의 기본 배치 엔진입니다. 배치 모드
Hadoop 의 처리 기능은 MapReduce 엔진에서 제공됩니다. MapReduce 의 처리 기술은 키 값 쌍을 사용하는 map, shuffle, reduce 알고리즘 요구 사항을 준수합니다. 기본 처리 프로세스는 다음과 같습니다.
HDFS 파일 시스템에서 데이터 세트 읽기
데이터 세트를 작은 블록으로 분할하고 사용 가능한 모든 노드에 할당
각 노드의 데이터 하위 집합에 대해 계산 (계산된 중간 결과는 HDFS 에 다시 기록됨)
중간 결과를 재할당하고 키를 눌러 그룹화 < Cing "
계산된 최종 결과를 HDFS
이점 및 한계 다시 쓰기
이 방법은 영구 스토리지에 크게 의존하므로 작업당 읽기 및 쓰기 작업을 여러 번 수행해야 하므로 속도가 상대적으로 느립니다. 그러나 디스크 공간은 일반적으로 서버에서 가장 풍부한 리소스이기 때문에 MapReduce 는 매우 많은 양의 데이터 세트를 처리할 수 있습니다. 또한 Hadoop 의 MapReduce 는 모든 것을 메모리에 저장할 필요가 없기 때문에 일반적으로 다른 유사한 기술에 비해 저렴한 하드웨어에서 실행할 수 있습니다. MapReduce 는 대규모 확대 잠재력을 가지고 있으며, 프로덕션 환경에서는 수만 개의 노드가 포함된 어플리케이션이 등장했습니다.
MapReduce 의 학습 곡선은 가파르다. Hadoop 생태계의 다른 주변 기술이 이 문제의 영향을 크게 줄일 수 있지만, Hadoop 클러스터를 통해 특정 어플리케이션을 빠르게 구현할 때는 이 문제에 유의해야 한다. < P > Hadoop 을 둘러싸고 이미 광활한 생태계가 형성되어 있으며, Hadoop 클러스터 자체도 종종 다른 소프트웨어의 구성 요소로 사용되고 있다. HDFS 및 YARN Explorer 는 Hadoop 와의 통합을 통해 다른 많은 처리 프레임워크와 엔진도 사용할 수 있습니다.
요약
Apache Hadoop 과 MapReduce 처리 엔진은 시간이 많이 걸리지 않는 대규모 데이터 세트를 처리하는 검증된 배치 모델을 제공합니다. 매우 저렴한 구성 요소를 통해 모든 기능을 갖춘 Hadoop 클러스터를 구축할 수 있으므로 이 저렴하고 효율적인 처리 기술을 여러 경우에 유연하게 적용할 수 있습니다. 다른 프레임워크 및 엔진과의 호환성 및 통합 기능을 통해 Hadoop 은 다양한 기술을 사용하는 다양한 워크로드 처리 플랫폼의 기반이 될 수 있습니다.
흐름 처리 시스템
흐름 처리 시스템은 언제든지 시스템에 들어오는 데이터를 계산합니다. 이것은 배치 모드에 비해 매우 다른 처리 방식이다. 스트림 처리는 전체 데이터 세트에 대한 작업이 아니라 시스템을 통해 전송되는 각 데이터 항목에 대한 작업을 수행합니다. < P > 스트리밍 중인 데이터 세트는 "경계 없음" 이므로 몇 가지 중요한 영향을 미칩니다. < P > 전체 데이터 세트는 지금까지 시스템에 들어온 데이터의 총량만 나타낼 수 있습니다.
작업 데이터 세트가 더 관련성이 높을 수 있으며 특정 시간에는 단일 데이터 항목만 나타낼 수 있습니다.
처리 작업은 이벤트 기반이며 명시적으로 중지되지 않는 한 "끝" 이 없습니다. 처리 결과는 즉시 사용할 수 있으며 새 데이터가 도착함에 따라 계속 업데이트됩니다. < P > 스트리밍 시스템은 거의 무제한의 데이터를 처리할 수 있지만 한 번에 하나의 (실제 스트리밍) 또는 소량의 (마이크로배치 처리) 데이터만 처리할 수 있으며 레코드 간에 최소한의 상태만 유지됩니다. 대부분의 시스템은 특정 상태를 유지할 수 있는 방법을 제공하지만 흐름 처리는 주로 부작용이 적고 보다 기능적인 처리 (Functional processing) 에 최적화되어 있습니다.
기능 작업은 주로 상태나 부작용이 제한된 이산단계에 초점을 맞추고 있습니다. 동일한 데이터에 대해 동일한 작업을 수행하면 동일한 결과가 생성되거나 약간 다른 요소가 생성됩니다. 이러한 처리는 흐름 처리에 적합합니다. 일반적으로 여러 항목의 상태가 특정 어려움, 제한 사항 및 경우에 따라 원하지 않는 결과의 조합이기 때문입니다. 따라서 일부 유형의 상태 관리는 일반적으로 가능하지만 이러한 프레임워크는 일반적으로 상태 관리 메커니즘이 없을 때 더 간단하고 효율적입니다.
이러한 처리는 특정 유형의 워크로드에 적합합니다. 거의 실시간 처리 요구 사항이 있는 작업은 흐름 처리 모드를 사용하는 데 적합합니다. 분석, 서버 또는 애플리케이션 오류 로그 및 기타 시간 기반 측정 지표가 가장 적합한 유형입니다. 이러한 영역의 데이터 변화에 대응하는 것이 비즈니스 기능에 매우 중요하기 때문입니다. 흐름 처리는 변동이나 최고점에 응답하고 일정 기간 동안 변화하는 추세에 집중해야 하는 데이터를 처리하는 데 적합합니다.
Apache Storm
Apache Storm 은 매우 짧은 대기 시간에 초점을 맞춘 스트림 처리 프레임워크로 거의 실시간 처리가 필요한 워크로드에 가장 적합합니다. 이 기술은 매우 많은 양의 데이터를 처리하고 다른 솔루션보다 짧은 지연 시간을 통해 결과를 제공합니다. < P > 흐름 처리 모드
Storm 의 흐름 처리는 프레임 워크에서 Topology 라는 DAG(Directed Acyclic Graph) 를 구성할 수 있습니다. 이러한 토폴로지는 데이터 조각이 시스템에 들어온 후 수신되는 각 조각에 대해 수행해야 하는 다양한 변환 또는 단계를 설명합니다.
토폴로지에는
stream: 시스템에 계속 도착하는 무한 데이터인 일반 데이터 스트림이 포함됩니다. < P > Spout: 토폴로지 가장자리에 있는 데이터 스트림 소스 (예: API 또는 쿼리 등) 로, 여기서 처리할 데이터를 생성할 수 있습니다.
bolt: bolt 는 흐름 데이터를 소비하고, 작업을 적용하고, 결과를 스트림으로 출력해야 하는 처리 단계를 나타냅니다. Bolt 는 각 Spout 과 연결을 설정한 다음 서로 연결하여 필요한 모든 프로세스를 구성해야 합니다. 위상의 끝에서 최종 Bolt 출력을 서로 연결된 다른 시스템의 입력으로 사용할 수 있습니다.
Storm 의 아이디어는 위의 구성 요소를 사용하여 많은 수의 작은 개별 작업을 정의한 다음 여러 구성 요소를 원하는 토폴로지로 구성하는 것입니다. 기본적으로 Storm 은 "한 번 이상" 처리 보증을 제공합니다. 즉, 각 메시지를 한 번 이상 처리할 수 있지만 경우에 따라 실패가 발생할 경우 여러 번 처리될 수 있습니다. Storm 은 특정 순서로 메시지를 처리할 수 있는지 확인할 수 없습니다. < P > 엄격한 한 번의 처리, 즉 상태 처리를 위해 Trident 라는 추상화를 사용할 수 있습니다. 엄밀히 말하면 Trident 를 사용하지 않는 Storm 을 Core Storm 이라고 합니다. Trident 는 Storm 의 처리 능력에 큰 영향을 미치며, 지연 시간을 늘리고, 처리를 위한 상태를 제공하고, 항목별 순수 흐름 처리 모드 대신 마이크로배치 모드를 사용합니다.
이러한 문제를 방지하기 위해 Storm 사용자는 가능한 한 Core Storm 을 사용하는 것이 좋습니다. 그러나 Trident 의 엄격한 콘텐츠 처리 보증은 시스템이 중복 메시지를 지능적으로 처리할 수 없는 경우와 같은 특정 상황에서도 유용할 수 있습니다. 항목 간에 상태를 유지해야 하는 경우 (예: 한 시간 동안 몇 명의 사용자가 링크를 클릭했는지 계산하려는 경우) Trident 만 선택할 수 있습니다. 프레임워크의 타고난 장점을 충분히 발휘할 수는 없지만 Trident 는 Storm 의 유연성을 높였습니다.
Trident 토폴로지는 다음과 같습니다.
Stream batch: 블록을 통해 배치 의미를 제공하는 스트림 데이터의 미세 배치입니다.
작업 (Operation): 데이터에 대해 수행할 수 있는 배치 프로세스를 나타냅니다.
의 장점과 한계
현재 Storm 은 거의 실시간 처리 분야에 가장 적합한 솔루션일 수 있습니다. 이 기술은 매우 짧은 지연 시간으로 데이터를 처리할 수 있으며, 최소 지연 시간을 원하는 워크로드에 사용할 수 있습니다. 처리 속도가 사용자 경험에 직접적인 영향을 미치는 경우 (예: 방문자가 연 웹 페이지에 처리 결과를 직접 제공해야 하는 경우) Storm 이 좋은 선택이 될 것입니다.
Storm 은 Trident 와 함께 작동하여 순수 스트림 처리 대신 마이크로배치를 사용할 수 있습니다. 이를 통해 사용자는 더 많은 유연성을 확보하여 보다 요구 사항에 맞는 도구를 만들 수 있지만, 동시에 이 방법은 이 기술이 다른 솔루션에 비해 가장 큰 장점을 약화시킬 수 있습니다. 말은 그렇긴 하지만, 여러 가지 흐름 처리 방식이 항상 좋다.
Core Storm 은 메시지 처리 순서를 보장할 수 없습니다. Core Storm 은 메시지에 대해 "한 번 이상" 처리 보증을 제공합니다. 즉, 모든 메시지를 처리할 수 있지만 중복될 수도 있습니다. Trident 는 서로 다른 배치 간에 순차 처리를 제공할 수 있지만 배치 내에서 순차 처리를 수행할 수는 없는 엄격한 처리 보증을 제공합니다.
상호 운용성 측면에서 Storm 은 Hadoop 의 YARN explorer 와 통합되므로 기존 Hadoop 배포에 쉽게 통합할 수 있습니다. Storm 은 대부분의 처리 프레임워크를 지원하는 것 외에도 여러 언어를 지원할 수 있어 사용자의 위상 정의에 더 많은 옵션을 제공합니다.
요약
Storm 은 지연 수요가 많은 순수 스트리밍 워크로드에 가장 적합한 기술일 수 있습니다. 이 기술은 각 메시지가 여러 프로그래밍 언어와 함께 처리되도록 보장합니다. Storm 은 일괄 처리할 수 없으므로 이러한 기능이 필요한 경우 추가 소프트웨어가 필요할 수 있습니다. 엄격한 1 회 처리 보증에 대한 요구가 높은 경우 Trident 사용을 고려해 볼 수 있습니다. 그러나 이 경우 다른 흐름 처리 프레임워크가 더 적합할 수 있습니다.
Apache Samza
Apache Samza 는 Apache Kafka 메시지 시스템과 밀접하게 연결된 스트림 처리 프레임워크입니다. 카파카는 많은 스트리밍 시스템에서 사용할 수 있지만