impala 내부 테이블이나 csv, parquet, hbase와 같은 외부 테이블 형식과 같은 여러 종류의 파일 형식이 있습니다. 이제 평균 삽입 비율이 50K 행/초이고 각 행이 약 1K임을 보장해야합니다. 또한 일부 데이터는 간혹 업데이트 될 수 있습니다. 또한 이러한 데이터에 대해 일부 집계 연산을 수행해야합니다.임팔라를 사용할 때 데이터 모델을 선택하는 방법을 아는 사람이 있습니까?
외부 테이블과 임팔라를 사용할 때 Hbase가 큰 집계 계산에 적합하지 않다고 생각합니다. 아무도 그것에 대해 제안을 가지고 있습니까?
감사합니다.
필자는 임팔라와 함께 일한 적이 없지만 하이브를 사용한 경험을 토대로 몇 가지 사실을 알려 드릴 수 있습니다.
Hive와 마찬가지로 Impala는 WHERE를 검색 필터로 변환하기 때문에 좋은 키 디자인과 적절한 스키마가 있으면 더 빠를 것입니다. 실행되는 쿼리 유형에 따라 많이 달라질 것입니다. 작업에서 읽는 데이터의 양을 줄이기위한 여러 가지 기술이 있습니다. 시작 및 중지 행 키 제공, 타이머, 일부 패밀리/열 읽기, 이미 언급 한 필터 ... 실시간 집계 수행과 같은 솔루션보다 복잡한 작업 귀하의 데이터 (*)를 카운터로 유지하십시오.
삽입 속도와 관련하여 적절한 인프라 (HBase 기본 JAVA API를 사용하는 것이 더 좋습니다)로 완벽하게 처리 할 수 있으며 더 나은 성능을 얻기 위해 쓰기 작업을 버퍼링 할 수도 있습니다.
* 임팔라가 HBase 카운터를 지원하는지 확실하지 않습니다.
매우 훌륭한 제안입니다. 시나리오를 기반으로 키를 다시 설계하려고합니다. 그건 그렇고, 우리는 버퍼를 시도, 그것은 극적으로 삽입 성능을 향상시킬 수 있습니다. 귀하의 도움에 매우 감사드립니다! –
키를 계획 할 때 순차적 행 키가 지역 핫스팟 문제를 일으킬 수 있다는 점에 유의하십시오. (http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver 쓰기에도 불구하고 기록 - 순차 키 포함). 질문을 해결했다면 답변을 수락하십시오. –
BTW, HBase의 읽기 성능은 50K 스캐너 캐시 크기의 지역 서버 당 +500000 req/sec였습니다. 이번 주말에 몇 가지 HIVE 쿼리를 실행했습니다 (전체 테이블 스캔). 임팔라에서 캐시 크기는 "HBASE_CACHING"쿼리 옵션을 사용하여 설정할 수 있습니다. –