현재 Kerberos 통합되어 있습니다.
1) Virtualbox 사용가 가능하시고요 2) Cloud환경이 있는 경우 Director라는 프로비저닝 기능을 사용하여 빠르게 설치 배포 테스트가능하십니다.
DR은 Cloudera의 경우 Cloudera Manger의 DR 기능을 지원하기 때문에 간편하게 구현가능하십니다.
Batch Insert API가 있기 때문에 Bulk load의 경우 SQL 기반보다는 API 기반으로 접근하시는 부분을 권장드립니다.
Kudu를 기존 Hadoop 클러스터에 통합으로 아키텍처 하실 수 있으며, Kudu 별도의 클러스터로 아키텍처 설계를 하셔도 됩니다.
현재 Sentry기반으로 허가 기능을 추가중에 있으며 금년에 Sentry와 통합될 예정입니다.
https://blog.cloudera.com/blog/2017/02/performance-comparing-of-different-file-formats-and-storage-engines-in-hadoop-file-system/
https://db-blog.web.cern.ch/blog/zbigniew-baranowski/2017-01-performance-comparison-different-file-formats-and-storage-engines 비교 벤치마킹 테스트를 3rd 에서 한 결과를 참조하실 수 있습니다.
다양한 압축 알고리즘을 지원합니다. 예 snappy~ 등
HDFS이 데이터를 Spark에서 활용하는 것과 마찬가지로 Kudu Table의 데이터를 Spark에서 사용하기 위해서는 SparkContext를 Kudu로 설정하시면 되겠습니다.
하둡이 11년동안 진화하면서 개선하고자 하는 모든 부분이 개선된 막강한 에코 프로젝트라고 보시면 되겠습니다. 1) 아키텍처 2) 기능 3) 외부 컴포넌트 의존성 4) 성능 등
오픈소스 입니다.
파티셔닝은 기본적을 1) Hash 2) Range 3) multi-level 파티셔닝이 지원됩니다.
기본 엔진이 Java가 아닌 C++로 구현이 되어 있으며, Data Write / Update의 경우 WAL(Write Ahead Log)를 활용하기 때문에 데이터 정합성을 맞추면서 성능을 최적화 했다고 보시면 됩니다.
특정 tablet server가 장애가 발생한 경우 해당 노드에 저장된 데이터의 replica의 개수가 감소되기 때문에 마스터에서 인지하여 re-distribution되어 replica의 일치성을 맞춥니다.
네 좋은 Use Case입니다. 기본 적으로 Pos에서 생성된 데이터를 통합하여 판매 예측 사례로 많이 활용할 수 있으면, SCM 고도화 용도로도 활용 가능합니다.
즉, Delete / Compaction의 경우 Operation만을 전달하여 네트워크 영향도를 최소화 하도록 설계되어 있습니다.
operation replication 방식을 채택하고 있습니다.
apacke spark + sparksql은 프레임워크입니다. kudu는 스토리지 엔진입니다.
마스터도 multi master기반으로 설계되어있습니다. 즉, HA가 지원됩니다.
