빅데이터 (22) 썸네일형 리스트형 Hbase Hbase란? Hbase는 hdfs위에 있는 Storage Engine으로 Parquet와 Kudu와 비교하여 Full scan보다는 Random Access 기반의 Read/Insert 작업에 특화되어 있습니다. 또한 Column-oriented DB로 칼럼 접근이 빠르고, sorted map형식으로 물리적으로 데이터가 저장되기 때문에 순차탐색에 유리합니다. 추가적으로 Hbase를 비롯한 대부분은 NoSQL이 Write performance가 빠른이유가 바로 LSM Tree 기반이기 때문입니다. Memory에서 memTable이 self balancing binary tree로 구조 가져가 있어서 sorted된 형태로 데이터를 유지합니다. 해당 형태를 기준으로 특정 기준이 되면 disk에 flush하며.. [Hadoop] corrupt/missing block Datanode의 디스크가 문제가 생기던지 혹은 Namenode에 너무 많은 Metadata를 가지고 있어서 block에 대한 문제가 발생할 수 있습니다. Corrput block, Missing block이 이에 따른 문제입니다. Corrput block block replicas 중에서 일부가 손상된 상태입니다. Namenode는 주기적으로 Datanode로 부터 heartbeat와 block report를 받기 때문에 Datanode 별 최신정보를 업데이트 합니다. 그렇기 때문에 corrupt block은 Namenode가 자동으로 채워줍니다. 복구가 가능한 상황이기 때문에 별도의 리포트 또한 없습니다. 만약 Missing block 복제본이 아예 없는 경우로 block이 복구 불가능한 상태입니다... kerberos 예제 커버로스 프로토콜은 principal과 keytab을 이용해 계정을 인증 받은 후 커버로스 티켓을 이용해 서비스 이용 커버로스는 AS, TGS로 구성 kinit : 커버로스 적용된 시스템 로그인 사용명령어 principal : kdc가 인증하는 사용자 및 서버 realm : 네트워크 단위 server-client 집합 / domain이름으로 구분 keytab : principal대한 정보와, 그에 대한 키 값 저장 파일. ticket : 사용자에 대한 인증 확인 위한 토큰 kadmin.local(kadmin) : 커버로스 서버에서 실행할 수 있는 관리자프로그램 klist : 티켓목록 확인(expire, principal...) listprincs : 키탭 확인 get_poilcy default : 비밀번.. Spark Mapreduce 느린 이유 1)여러 Stage별 dag가 아니라서 실행 계획 최적화X 2) Disk I/O Spark 1) Edge(transformation), Vertices(RDD) 를 기본으로 DAG 구성하여, 실행 계획 최적화. Lazy execution으로 인해 Action이 나오는 시점에 이전 단계에서의 각각의 stage별 job에 대한 계산을 해두고, Action할 때 최적화된 것으로 수행. 2) RDD(resilient distritbuted dataset)으로 immuatable한 특징을 갖고 있어 dag기반의 lineage를 확인하여 이전 단계에서 다시 객체 생성한다. 각 작업을 메모리 기반으로 하기 때문에 Disk I/O 발생 없음 Reference https://eyeballs... Kudu Kudu는 Columnar Storage로 칼럼마다 압축 방식과 인코딩 방식을 지원합니다. 또한 Primary Key가 필수고 B+트리로 저장되어있어서 인덱스 처럼 저장되어있어서 delete, update 등 Random Access가 빠른 특징을 갖고 있습니다. 또한 Parquet처럼 Sequental read에도 최적화 되어있습니다. Parquet, Kudu, Hbase 간 primary key를 기준으로 Random Access 그리고 substring() 연산통해서 성능 비교 시 Kudu가 Parquet와 Hbase의 중간 정도 성능을 보이 연구 또한 있습니다.(참고자료에 있음) 또한 Table들은 Tablet(partition)으로 구성되어있는데, resiliance를 위해 여러 노드에 분산저장.. 주키퍼(2) znode 종류 lifecycle에 따른 option으로 Persistent / Ephermeral 을 선택할 수 있고, uniqueness으로 sequential 여부를 설정할 수 있습니다. Persistent mode : 명시적으로 삭제하지 않는 한 지워지지 않는 파일로 볼 수 있습니다. Ephermeral mode : zookeeper client와 session이 끊겨지면 자동으로 지워지는 개념입니다. 해당 모드로 lock이나 leader election을 구현합니다. Sequence mode : Persistent / Ephermeral 모두 sequence mode로 만들 수 있으며, znode는 주어진 이름 뒤에 postfix로 10진수 숫자가 더 붙여집니다. Stat znode는 node와.. RabbitMQ vs Kafka RabbitMQ RabbitMQ는 메세지 기반 미들웨어로 서비스 간 데이터를 교환해주는 역할을 하며, Exchange를 통해 라우팅 방법을 결정하고 Queue에 메세지를 저장했다가 Consumer가 consume하는 구조입니다. ack와 durable 모드를 통해 consumer에게 메세지 전달 보장성과 메세지 유실 방지 할 수 있습니다. 그 외, 재처리 방식, clustering, rpc 모드 등 다양한 기능을 제공합니다. 클러스터링 경우에는 RabbitMQ가 single node로 작동 시 node가 죽으면 메세지가 모두 유실되고, 서비스가 장애나기 때문에 HA를 고려하여 미러링 방식의 master-slave구조를 갖습니다. slave node는 master의 메세제를 sync하기만 하고, produ.. Block Count / Small files 해결 Block Count snappy, gzip 등 compress/decompress 라이브러리들이기 때문에 어느 데이터 파일 포맷에 사용하는지, 그리고 데이터(테이블) 특성에 따라 성능은 달라질 수 있습니다. gzip Deflate알고리즘을 사용하며, Snappy 보다 더 많은 CPU리소스를 사용하지만 더 높은 압축을 할 수 있습니다. 그러나 압축률이 snappy보다 약 2배 높기 때문에 자주 사용하지 않는 콜드 데이터(잘 사용하지 않는 백업용 데이터)에 적합합니다. 실제로 HIVE 통해서 MapReduce의 결과로 cpu extenseive time을 확인했을 때 snappy보다 더 높은 시간이 나왔습니다. snappy 구글에서 자체 개발한 압축 라이브러리로, 압축률을 적당한 수준으로 제공하면서 빠르게.. 이전 1 2 3 다음
