최상의 답변
가능한 벤치 마크에서 Spark Sql은 Hive보다 훨씬빠릅니다. Facebook은 Spark 설계의 값싼 사본 인 Presto를 하이브의 후드 아래에두고 Tez에 새로운 버전의 하이브를 제공했지만 DAG에 대한 오해가 여기에 잘 설명되어 있습니다. Tez의 비극 이지만 모든 SQL 관련 작업 (예 : Map side sqls => 필터, 데이터 변형 또는 축소 side Sqls => Sort / aggregate / Window 함수)에서 Spark는 여전히 밝게 빛납니다.
이 질문에는 왜라는 질문이 없기 때문에 기술적 인 세부 사항은 많이 다루지 않겠습니다. 그러나 이해를 돕기 위해 각 작업이 완료하기 전에 보유하고있는 전체 데이터 세트 (복제 포함)를 작성해야하는 분산 데이터 처리 모델을 생각해보십시오. 애플리케이션이 자체적으로 리소스 사용률을 측정 할 수없고 애플리케이션이있는 위치 작업 / 실행 단계를 시작하는 클러스터 관리자의 자비를 확인하고 작업이 대부분의 시간 동안 메모리에있을 수있는 다른 분산 데이터 처리 모델과 비교합니다. 여기서 리소스는 엔진에 의해 지능적으로 할당되고 프레임 워크가 배치 될 수 있습니다. 클러스터 관리자의 최상위에 있으며 컨테이너 할당 (및 우회 할 수있는 약간의 De / Serialization) 외에는 아무것도 클러스터 관리자에 의존하지 않습니다.
(간결하게 유지하기 위해 Spark 1.6 / 2.x의 Tungsten 또는 쿼리 최적화를위한 simd 구현으로 게임을 강화한다고 언급 할 수도 있습니다.)
어떤 모델이 지연 시간 전투에서 승리 할 것이라고 생각하십니까?
답변
h2>
검색어부터 시작하겠습니다. : Hive는 Hive 및 Hadoop의 기능에 특정한 SQL의 하위 집합 인 Hive 언어 ( LanguageManual-Apache Hive-Apache Software Foundation )를 구현합니다. 제출 된 쿼리는 작업 또는 단계에서 구현할 수있는 조각, 조건 자로 분류됩니다. SELECT col1 , col2 ,… coln 은 반환 된 각 행의 열이 솔루션 집합에 유지되고 반환 될 것인지 지정합니다. 마찬가지로 LEFT 또는 RIGHT 조인은 Map-Reduce (M\_R) 단계와 같은 특정 상태에서 구현됩니다. 쿼리가 특정 작업과 일치하는 조각으로 분리되면 CBO (Cost-Based Optimizer)는 수집 및 저장된 통계를 사용하여 각 단계가 실행되는 방법에 대한 지능적인 결정을 내립니다. 예를 들어, WHERE 절은 그다지 구체적이지 않거나 (낮은 카디널리티) 테이블이 분할되지 않은 경우 테이블 스캔으로 구현 될 수 있습니다. 또는 테이블이 분할되고 WHERE 절이 파티션 열을 지정하는 경우 분할이 제거 될 수 있습니다. 높은 특이성. 쿼리가 여러 조인을 지정하는 경우 각 조인은 Map-Reduce 단계로 구현됩니다. 조인 테이블 중 하나가 매우 작은 경우 성능 향상을 위해 CBO가 Map-Join을 선택하여 실행할 수 있습니다.
CBO가 실행 계획을 배치하면 일반적으로 단계가 예약되고 실행됩니다. 여러 MR 단계로. 쿼리에 EXPLAIN을 실행하여 CBO가 주어진 쿼리를 실행하는 데 사용할 실행 계획을 검토 할 수 있습니다.
비디오 업계에서 사용자의 시청 습관에 대한 통계를 수집 한 클라이언트가있었습니다. 이러한 통계는 클라이언트가 각 비디오, 비디오의 배우, 각 비디오의 플롯, 프로덕션 데이터 등에 대한 데이터를 포함하는 약 20 개의 비교적 작은 테이블과 결합하기를 원하는 매우 큰 테이블 (100 개의 TiB)로 수집되었습니다. 최종적으로보기 테이블과 조인 된 더 작은 테이블을 결과 뷰에 조인 한 다음 출력 테이블에 기록 된 뷰를 생성했습니다. 결과보기에서 출력 테이블로 선택하기위한 간단한 쿼리를 제출했을 때 (CREATE TABLE 출력 (…) AS SELECT * FROM results\_view) Hive는 모든 중간보기를 최종보기로 구체화 한 다음 작성된 25 단계 쿼리를 생성했습니다. 출력 테이블에. 각 단계는 M-R 작업 (YARN의 경우)이고 M-R 작업의 설정 시간은 해당 클러스터의 경우 약 30 초 였으므로 M-R 설정 시간에 약 12 ~ 14 분이 소요되었습니다. 대부분의 M-R 단계는 45 초 미만으로 실행되었으며,이 중 2/3는 M-R 설정 시간이고 1/3은 실제 실행이었습니다. 더 작은 테이블을 뷰어 통계 테이블에 최종 맵 조인하는 데 20 분이 더 걸렸습니다. 결과 테이블에 연속적으로 조인 된 뷰를 여러 개 만들면 하나의 쿼리에서 20 개 이상의 테이블을 조인하려는 대규모 쿼리를 만들지 않고 비교적 간단한 쿼리로 조합 된 파이프 라인을 만들 수있었습니다.