Apache Spark 2.1 - 행 객체의 스칼라 길이/무거운 속성

Question

Spark 2.1.0 독립 실행 형 클러스터에서 실행되는 스칼라 2.11에서 스파크 애플리케이션을 작성했습니다. 디자인/요구 사항에 따라 우리는 100과 같은 많은 수의 직접 열이있는 행 개체를 만들었으며 중첩 된 열 중 일부는 시퀀스가 ​​20k에서 30k까지있는 것처럼 중첩 된 열이 거의 없습니다. Spark 데이터 세트를 처리하기위한 대소 문자 클래스도 있습니다. 예를 들어

서열 중 일부는 30K에 20K의 크기를 가지고있다

Row(column_01, 
    column_02... 
    .....column_150, 
     column_151 = Seq, 
     column_152 = Seq...column_160 = Seq) 

.

행 개체의 길이가 길거나 많은 특성이 성능에 어떤 영향을 미치는지 조금 걱정이됩니까? 성능 향상을 위해 코드에서 수행 할 수있는 최적화는 무엇입니까? 클러스터 튜닝을위한 제안 사항이 있습니까?

우리는 이미 다음과 같은 최적화에 노력하고 있습니다 -

1. 는

Answer 1

스파크 물어 압축 마루 파일 형식을 사용하여 파티션

의 # 증가는 무거운 행 특별한 문제가 없습니다. 수백 개의 필드가있는 중첩 된 행에서 문제없이 페타 바이트 단위의 데이터를 관리합니다. , 구조체로지도를 통해 구조체를 선호 할 수

1. 가 자동으로 마루에 평평하고 맵의 인스턴스를 더 복잡 :

   염두에 두어야 할 몇 가지가 있습니다.

2. 대부분의 시간에 모든 데이터를 처리해야하며 독점적으로 데이터 세트를 사용할 수있는 경우 일반적으로 데이터 프레임을 사용할 때보 다 성능이 좋아지며 데이터 세트 인코딩/변환을 사용하려면 사례 클래스에 투자 할 가치가 있습니다. 디코딩.

3. 약간의 데이터 만 필요로하는 쿼리의 경우 df.explain()을 실행하여 Spark이 구조체의 한 필드 만 필요할 때 전체 구조체를 너무 많이 당기지 않는지 확인하십시오. 이 글을 쓸 당시에는 몇 가지 문제가 있습니다. 일반적으로 가장 먼저 필요한 최소한의 데이터 집합을 명시 적으로 선택하기 위해 변환/쿼리를 다시 작성하여 문제를 해결할 수 있습니다.

4. 가능한 경우 처리가 복잡해질 수 있으므로 중첩 배열을 피하십시오. 배열 자체는 문제가되지 않습니다.