[HADOOP] 람다 아키텍처 - 왜 배치 레이어

람다 아키텍처 - 왜 배치 레이어

나는 람다 (lambda) 아키텍처를 통해 결함 허용 (fault tolerant) 대용량 데이터 시스템을 구축하는 데 어떻게 사용될 수 있는지 이해할 것입니다.

모든 것이 실시간보기에 저장되고 그 결과를 생성 할 수있을 때 어떻게 배치 레이어가 유용할까요? 실시간 저장 장치가 모든 데이터를 저장하는 데 사용할 수 없기 때문에 데이터를 검색하는 데 걸린 시간이 데이터를 저장하는 데 소요 된 공간에 따라 달라 지므로 실시간이 아닙니다.

해결법

1. ==============================

   1.시간과 돈을 절약하기 위해!

   시간과 돈을 절약하기 위해!

   기본적으로 두 가지 기능이 있습니다.

   데이터가 100'1000 페타 바이트 일 수 있고 결과를 생성하는 데 많은 시간이 걸릴 수 있으므로 위와 같은 작업은 가능하지만 불가능합니다.

   여기에서 핵심은 대용량 데이터 집합에 대해 대기 시간이 짧은 쿼리를 얻는 것입니다. 일괄 처리 계층은 일괄 처리 뷰를 생성하는 데 사용되며 실시간 레이어는 대개 작은 최근 / 업데이트 된 데이터에 사용됩니다. 이제 모든 마스터 데이터 세트를 계산하는 대신 일괄보기 및 실시간보기의 ​​결과를 병합하여 임의의 임의 (ad-hoc) 쿼리에 응답 할 수 있습니다.

   또한, 거대한 dataset에 대해 반복적으로 실행되는 쿼리 (동일한 쿼리?)를 생각해보십시오. 시간과 비용의 손실!

2. ==============================

   2.@karthik manchala에서 제공하는 답변 외에도 데이터 처리는 배치, 대화 형 및 실시간 / 스트리밍의 세 가지 방식으로 처리 할 수 ​​있습니다.

   @karthik manchala에서 제공하는 답변 외에도 데이터 처리는 배치, 대화 형 및 실시간 / 스트리밍의 세 가지 방식으로 처리 할 수 ​​있습니다.

   모든 유스 케이스가 스트리밍 관련이있는 것은 아니므로 실시간에 대한 참조는 스트리밍보다 대화식 응답이 더 많습니다.

   대화 형 응답은 유스 케이스에 따라 1 초에서 2 초에서 몇 분까지 응답을 예상 할 수있는 곳입니다. 여기에서의 핵심은 프로세싱이 정지 된 데이터에 대해, 즉 이미 저장 매체에 저장되어 있다는 것을 이해하는 것이다. 사용자는 처리하는 동안 시스템과 상호 작용하므로 응답을 기다립니다. Tez, Impala, Spark core 등에 대한 Hive의 모든 노력은이 문제를 해결하고 가능한 한 빨리 반응을 이끌어내는 것입니다.

   다른 측면에서의 스트리밍은 데이터가 실시간으로 시스템으로 유입되는 곳입니다. 예를 들어 트위터 피드, 클릭 스트림 등은 데이터가 생성되는 즉시 처리해야합니다. Storm, Spark Streaming과 같은 프레임 워크는이 공간을 처리합니다.

   일괄 처리의 경우는 거대한 데이터 세트에서 수동으로 수행해야하는 과도한 작업이 필요한 시나리오를 처리하여 사용자가 볼 수있는 응답이 실시간이라고 믿게 만듭니다. 예를 들어 거대한 문서 모음을 Apache Solr로 인덱싱하는 배치 작업은 데이터 집합에 따라 인덱싱을 몇 분 또는 몇 시간 동안 실행하는 배치 작업입니다. 그러나 Solr 인덱스를 쿼리하는 사용자는 1 초 미만의 응답으로 응답을 얻습니다. 보시다시피, 색조 양이있을 수 있으므로 실시간으로 인덱싱을 수행 할 수 없습니다. 색인 생성이 배치 모드에서 수행되고 결과가 대화식 모드로 표시되는 Google 검색의 경우도 마찬가지입니다.

   모든 세 가지 데이터 처리 모드는 데이터 문제를 해결하는 모든 조직과 관련이 있습니다. Lambda Architecture는 여러 데이터 처리 요구 사항에 대해 동일한 데이터 소스를 효과적으로 사용하기 위해 이러한 과제를 해결합니다.

3. ==============================

   3.별도의 Batch-Layer가없는 Kappa-Architecture를 확인할 수 있습니다. 모든 것은 Stream-Layer에서 분석됩니다. 올바른 구성에서 Kafka를 master-datasetstorage로 사용하고 계산 된 데이터를 데이터베이스에 뷰로 저장할 수 있습니다.

   별도의 Batch-Layer가없는 Kappa-Architecture를 확인할 수 있습니다. 모든 것은 Stream-Layer에서 분석됩니다. 올바른 구성에서 Kafka를 master-datasetstorage로 사용하고 계산 된 데이터를 데이터베이스에 뷰로 저장할 수 있습니다.

   다시 계산하려면 새로운 Stream-Processing 작업을 시작하고 Kafka에서 데이터베이스로보기를 다시 계산하고 이전보기를 바꿀 수 있습니다. 임시 쿼리의 주 저장소로 실시간보기 만 사용할 수도 있지만 이미 다른 답변에서 언급 했으므로 배치 작업을 수행하는 대신 대량 처리 작업을 수행하고 일괄 작업을 수행하는 대신 별도의 스트림 처리를 수행하는 것이 더 빠릅니다 스트림 작업으로. 데이터 크기에 따라 다릅니다. 또한 배치 컴퓨팅을위한 데이터베이스 대신 hdfs와 같은 스토리지를 갖는 것이 더 저렴합니다.

   그리고 대부분의 경우 배치와 스트림 처리를위한 알고리즘이 다르므로 별도로 처리해야합니다. 그러나 기본적으로 Kafka를 마스터 세트로 사용하지 않고도 배치 및 스트림 레이어로만 "실시간보기"를 사용할 수 있습니다. 그것은 당신의 유스 케이스에 달려 있습니다.

from https://stackoverflow.com/questions/34373454/lambda-architecture-why-batch-layer by cc-by-sa and MIT license