github에 압축 파일

DT 코드의 구덩이

2주 동안 DT를 지원하고 관련 label의 개발을 통해 DT가 제공하는 코드의 질이 매우 나쁘다는 것을 뚜렷하게 알 수 있다.앞일을 열거하면 뒷일의 교훈을 잊지 않는다.

hard core

spark 코드에서 마스터와 모든 Hard core를 삽입합니다. 삽입은 말할 것도 없고, 마스터를 설정한 후에, 저spark submit은 잘못 보고할 것입니다.

String 대신 saveAsTextFile 직접

자주 나타나다

(ABACD,ADF,1)

[Ljava.long.String;@76abcd405]

전자는 원조가 직접 출력하고 후자는 주소를 출력하니 코드를 쓸 때 반드시 주의해야 한다

클러스터 600G 메모리, 200G 전체 캐치 입력

응cache는 확실히 효율을 높일 수 있지만, 네가 이렇게 하면 oom이 되지 않을 거야?

여러 번

입력은 (A, B, C)이 원하는 출력(A, B/sum(B), B, D)으로join을 여러 번 했는데 비용이 많이 든다. 실천하기 전에 샘플링을 하고 A에 대한 Reduce를 추가한 후 키에 따라 분포된 데이터량이 크지 않고 기울기가 심각하지 않은 상황에서join을 RDD[string, Map]로 바꾸어 RDDDD[string, Map]로 처리한 다음에 Reduce를 얻어 RDDD[string, Map]를 맵 내부에서 비슷한 논리적인 조작을 할 수 있다.이렇게 하면 효율을 높일 수 있다.

이상 검사 안 해요.

차트에 빈 값이 존재할 수 있으며 이상 검출을 하지 않고string=int의 전환을 직접 진행하면 반드시 이상합니다.

데이터 필터링

이어서 빈 값에 대한 필터는 신중하고 신중해야 한다. 모든 데이터는 매우 귀중하기 때문에 매우 진지하게 대해야 한다. 필터를 하기 전에 Sample을 하고 데이터가 어떤 모양인지 보고 필터를 할 데이터가 어떤 모양인지 보고 결단을 내리는 것을 권장한다.

sample의 중요성

스파크 처리에 사용된 데이터의 양은 자연히 작지 않을 것이다. 빅데이터 양 테스트를 하기 전에 반드시 빅데이터 양을 이용하여 논리적인 검증을 해야 한다. 빅데이터 양으로 직접 뛰면 시간 소모 자원을 말하지 않고 만약에 틀리면 대가도 크다.

기타 비코드 구덩이

차원 과다

차트가 너무 많아서 관리하기가 매우 어렵기 때문에 반드시 새로운 메커니즘을 잘 협상해야 한다

Spark-submit 스크립트

이것은 반드시 있어야 한다. 정리가 늦었고 제출할 때마다 다시 작성해야 한다. 비록 시간이 많지 않지만 몇 번을 더 하면 사람을 초조하게 하기 쉽다. 다음과 같은 템플릿을 정리했다spark-submit 템플릿

정보 소통은 반드시 제때에 해야 한다.