반응형

분류 전체보기 23

Spark 3.0 무엇이 바뀌었을까?

- Spark 3.0은 3,400개 이상 JIRA 해결 - Spark SQL, Spark Core 중심으로 버전업 - Hadoop3 지원 01. Adaptive query execution를 위한 새로운 프레임워크(AQE) 02. Nested Column Pruning 03. Spark를 위한 Accelerator-aware task 스케줄링 01. AQE - JIRA: https://issues.apache.org/jira/browse/SPARK-31412, https://issues.apache.org/jira/browse/SPARK-11150 Spark 2.0 버전까지 Cost-based Optimzer를 사용하였는데 이 방법의 단점은 데이터의 통계가 있어야 퍼포먼스가 좋고 데이터의 통계가 최신화되..

Spark 2021.07.18

[Kudu] kudu, hdfs의 관계

kudu와 hdfs는 동일한 클러스터 위에서 구동할 수 있으므로 kudu의 데이터가 hdfs에 저장되지 않는가 하는 생각이 들수도 있습니다. 하지만 kudu는 hdfs와 별개의 저장 시스템으로 hdfs에 의존하거나 위에서 실행되지 않습니다. 초기에 kudu에서 HDFS로 데이터를 저장하는 설계를 고려했지만 아래와 같은 이유로 별개의 저장 시스템으로 가게 되었다고 합니다. Kudu는 Raft 합의를 사용하여 논리적 수준에서 복제를 처리하므로 HDFS 복제가 중복됩니다. 복제 수준을 1로 지정할 수 있었지만 HDFS의 최상의 사용 사례는 아닙니다. HDFS에서 제공하는 파일 시스템 수준 스냅 샷은 특정 데이터가 메모리에서 플러시되는시기를 예측하기 어렵기 때문에 스냅 샷에 대한 Kudu 지원으로 직접 변환되지..

Kudu 2021.05.30

[Kudu] 데이터 백업

- Kudu 1.10.0부터 Kudu는 Apache Spark를 사용하여 구현 된 작업을 통해 전체 및 증분 테이블 백업을 모두 지원 - Apache Spark를 사용하여 구현 된 복원 작업을 통해 전체 및 증분 백업에서 테이블 복원 지원 - 내장 백업 메커니즘이없는 이전 버전의 경우 Impala 사용 다음과 같은 명령문을 사용하여 데이터를 Parquet 형식으로 복사 INSERT INTO TABLE some_parquet_table SELECT * FROM kudu_table 그런 다음 distcp 를 사용 하여 Parquet 데이터를 다른 클러스터로 복사합니다. 출처: https://kudu.apache.org/faq.html

Kudu 2021.05.30

[Kudu] kudu disk 구성은 왜 JBOD로 해야하는가?

kudu의 디스크 구성은 보통 JBOD로 구성하며 LVM이면 안됩니다. JBOD로 구성된 디스크는 데이터를 순차적으로 저장합니다. 예를 들어, 데이터는 디스크 1에 먼저 기록됩니다. 디스크 1이 꽉 차면 디스크 2, 디스크 3 순으로 데이터를 저장합니다. 이 RAID 수준의 장점 두 가지는 총 스토리지 용량을 100% 사용할 수 있고 확장이 쉽다는 것입니다. 그러나 디스크가 1개라도 고장나면 모든 데이터가 손실됩니다. Kudu는 로컬 파일 시스템을 통해 저장 장치에 액세스하며 Ext4 또는 XFS에서 가장 잘 작동합니다. Kudu는 JBOD 마운트 지점에서 스트라이핑을 처리 하며 RAID 가 필요하지 않습니다 . Kudu의 미리 쓰기 로그 (WAL)는 데이터 파일과 별도의 위치에 저장할 수 있습니다. 즉..

Kudu 2021.05.30

[Hive] LLAP(Live Long And Process)의 특징

hive2.0 에서 도입 자주 사용 되는 데이터를 캐싱 하여 작업속도를 올리는 기술 LLAP를 활용해 Hive 를 이용할 경우 캐싱을 위한 YARN Queue 를 별도로 할당 받고 설정한 리소스를 상시 점유 LLAP 구성 구분 설명 Hive Interactive Server Hive LLAP에 연결하기 위해 JDBC 인터페이스를 제공하는 Thrift 서버 Slider AM LLAP 데몬을 생성, 모니터링, 유지하는 슬라이더 프로그램 TEZ AM query coordinator TEZ AM은 사용자의 요청을 받아 LLAP 데몬(JVM) 내에서 사용할 수 있는 실행기에서 실행 LLAP 데몬 캐싱, JIT 최적화를 용이하게 하고 바로 호출할 수 있도록 클러스터의 worker node에서 실행 I/O, 캐싱, ..

Hive 2021.04.16

[Hive] Hive3 주요 특징

ACID 트랜잭션처리 Hive3 쓰기 및 읽기 작업은 트랜잭션 테이블 성능 향상 원자적 작업에는 단순 쓰기 및 삽입, 여러 파티션에 대한 쓰기, 단일 SELECT 문에 여러 삽입이 포함 읽기 작업은 작업 중에 발생하는 변경사항의 영향을 받지 않음. 데이터를 삽입하거나 삭제할 수 있으며 소프트웨어 및 하드웨어 충돌시에도 일관성을 유지. 더 이상 테이블을 버킷화할 필요 없기에 Hive 테이블의 생성 및 유지 관리 간소화 Hive 메타스토어 공유 HMS는 여러 컴퓨팅 엔진 (예 : Impala 및 Spark)의 상호 운용을 지원 HMS는 다양한 엔진과 사용자 데이터 액세스 간의 액세스 단순화 Hive와 Spark 통합 Spark 및 Hive 테이블은 Hive Warehouse Connector 및 Spark ..

Hive 2021.04.06

[kudu] 3편 - Scaling cluster

클러스터 memory 충분한지 어떻게 알 수 있을까? 1) 진행중인 워크로드 기반하여 메모리 사용량 추론 Scans 대시보드 https://tserver:8050/scans Transaction 대시보드 https://tserver:8050/transactions 클라우데라 매니져를 통해 Metrics 확인 2) 메모리 사용량 측정 Mem-trackers https://tserver:8050/mem-trackers pprof gperftools 사용 pprof -svg tserver:8050/pprof/heap Node density 한 서버당 1000-2000 태블릿 replica 적당 현재 모든 태블릿은 하나의 WAL disk 공유 속도를 위해 빠른 disk 사용 필요(SSD나 NVM) 서버는 공유 ..

Kudu 2021.04.06

[kudu] 2편 - Schema, Compaction, Disk, Memory

Schema Primary Key의 역할 각 row를 고유하게 식별 PK를 이용한 쿼리 검색 지원 index - tablet의 길이를 줄여줌(height) - near-primary-key 순서로 insert 가능 병합 압축(Merge Compaction) tablet에서 하나의 단일 rowset으로 여러 개의 rowset을 결합 성능을 향상시키려면 아래 조건 만족해야함 tablet의 높이(height) 줄이기 row 조회 성능 개선(write, read 모두) 동일한 tablet 기준 첫번째 그림의 경우 height가 균일하지 않은 상태이고 두번째 그림은 균일한 상태 조회나 기타 성능 면에서 두번째 그림이 유리 Schema 예시(최적화) id, timestamp 컬럼 row는 timestamp 순서대로..

Kudu 2021.04.06

[kudu] 1편 - write, read, partition

Write 단일 tablet으로 wirte 발송 블룸 필터 검사(bloom filter checking)를 통해 kudu는 디스크에서 일부 검색을 피할 수 있습니다. PK를 사용하면 주어진 키에 대한 확실한 검색이 가능합니다. inserts: key 존재하지 않음 updates/deletes: key 존재 upsert: key가 존재할수도 존재하지 않을 수도 있음 Read 연관없는 tablets들은 넘기고 연관있는 각 tablet을 PK 이용하여 데이터를 읽는다. 데이터를 통해 반복하는 동안 deltas를 읽는다. Partitioning 일반적인 쿼리의 경우 "pruing"를 활성화하여 전체 태블릿을 건너 뛰고 I / O를 줄입니다. write 작업을 많은 partition으로 분산화 각 tablet의 ..

Kudu 2021.03.30
반응형