티스토리 뷰
1) 빅쿼리란? 빅쿼리는 페타바이트 급의 데이터 저장 및 분석용 클라우드 서비스이다. 8800개의 CPU와 3600개의 디스크를 사용하는 대규모 인프라를 통해 1000억개의 레코드에 대한 질의를 약 30초에 수행하며, 가격도 저렴하다. 2) 특징 서버리스, NoOps, 실시간 분석, 자동 고가용성, 표준 SQL, 저장소와 컴퓨팅 분리, 세분화된 액세스 제어, 자동 백업 및 간편한 복원, 분산 저장, 데이터 전송 서비스, 빅데이터 생태계 통합, 데이터 암호화 및 보안, 프로그래매틱 상호작용, 배치/스트리밍 모두 지원, REST API 제공, stackdriver를 통한 모니터링 및 로깅, 쿼리당 과금 등등 특징도 참 많다. 구조적인 특징으로는, ㄱ. No Key, No Index (키나 인덱스 개념이 없고 풀스캔) ㄴ. No Update, Delete Row (데이터를 추가하는 것만 지원, 한번 입력된 데이터는 변경 삭제 안되며 삭제 후 다시 생성해야 함) ㄷ. Eventual Consistency (3개의 데이터센터에 걸쳐 복제하므로 데이터 입력 후 바로 조회가 안될 수 있음, 복제 시간이 걸리고 보통 바로 반영되지만 최대 수 분이 걸림) - Project / Dataset / Table / Job (1) 빅데이터에 SQL 쿼리 (병렬) 수 초 내에 테라바이트를 읽는 방법은 어떤 것이 있을까? ㄱ. 많은 데이터를 건너뛴다. 던질 질문을 미리 알고 있을 때 좋은 방법이다. 데이터를 미리 집계하거나 접근해야 하는 열의 색인을 생성할 수 있다. 하지만 다른 질문을 던지거나 다른 방법으로 질문하고 싶을 때는 풀스캔하여야 한다. ㄴ. 비싼 H/W ㄷ. 병렬 수행. DB 쿼리 성능의 주요 제약사항 중 하나는 쿼리의 순차적인 실행이다. 대부분의 DB는 다수의 프로세서를 사용할 수 있지만, 하나의 쿼리를 위해 다수의 프로세서를 사용하지는 않는다. 다수의 쿼리를 한번에 수행하기 위해(batch 등) 병렬성을 활용하기는 한다. 하나의 쿼리를 병렬로 실행한다고 해도 DB 성능은 디스크 I/O 속도에 의해 여전히 제한될 수 있다. 기존 DBMS상에서는 하나의 디스크에 데이터를 저장하여 순차적으로 읽는 것보다 다수의 위치에서 디스크를 병렬로 읽는게 더 느리다. 과거 구글은 이 문제를 맵리듀스를 통해 해결하였다. - 맵리듀스 : 문제를 쉽게 병렬화할 수 있게 나눈 후, 장비 클러스터 전체에서 이들을 조정하는 계산 패러다임이다. 하둡은 분석을 병렬로 수행할 수 있도록 나눠주며, HDFS는 많은 디스크에 흩어져 있는 데이터를 병렬로 읽는다. 문제는 어렵고, 느릴 수 있다는 것이다. 긴 배치 잡이 완전히 끝날 때까지 수 분 또는 수 시간을 기다려야 하므로 대화형 스타일 분석에 부적합하다. 현재 빅쿼리엔진인 드레멜은 빅데이터 구조의 스토리지에 전통적인 SQL 쿼리 인터페이스를 추가하여 SQL 실행을 수천개의 장비로 병렬화 할 수 있다. (2) 클라우드 스토리지 시스템 ㄱ. 빅쿼리는 데이터에 대한 쿼리를 수행하기도 하지만 구조화된 데이터를 클라우드에 저장하기도 한다. ㄴ. 데이터는 사용성과 내구성 향상을 위해 지리적으로 다수의 위치에 복제된다. ㄷ. 데이터 입력 a. 스트리밍과 직접 업로드, 구글클라우드스토리지 등의 세가지 방법 제공 b. 데이터 타입에 Record Type, Repeated Type이 있음 c. legacy SQL 기준) 행단위 업데이트 지원 X (3) 분산 클라우드 컴퓨팅 ㄱ. 병렬 계산에 필요한 많은 조정과 집계에 있어, 구글 클라우드의 빠른 네트워크가 핵심 ㄴ. 클라우드 데이터 웨어하우징(결함내성, 지리적 분배, 자동 백업 제공) IDC를 사용할 경우 결함내성을 위해 장비 내에 추가 전원이나 RAID 디스크 컨트롤러, ECC 메모리같은 복제본을 추가한다. 장비 비용이 증가해도 하드웨어 고장을 피할 수는 없다. 디스크가 고장나면 누군가는 데이터센터에서 고장난 디스크가 있는 렉을 찾고 새 것으로 바꿔야 한다. 클라우드 데이터 웨어하우징을 사용하면 RAID-5로 충분한지, 테이프 백업이 충분한 주기로 돌아가고 있는지, 자연 재앙이 사용자를 완전히 오프라인 상태로 만들지는 않는지에 대해 신경쓰지 않아도 된다. ㄷ. 멀티테넌시와 병렬 실행 다수의 사용자가 던지는 다수의 쿼리를 한꺼번에 수행한다. 모든 쿼리에는 I/O와 프로세싱이 섞여있다. I/O를 기다리는 동안 프로세서는 유휴상태에 있다. 쿼리엔진은 연산을 시간 단위로 쪼개서 다른 쿼리가 디스크나 네트워크 I/O를 기다리는 동안 주어진 쿼리를 수행한다. 빅쿼리의 근간인 드레멜 엔진은 쿼리를 파이프라이닝한 후 어떤 쿼리가 I/O 연산을 기다리는 동안 다른 쿼리가 그 프로세서를 사용하게 함으로써 시스템의 처리량을 최대화한다. (4) 서비스형 애널리틱스(AaaS) 전역 데이터 네임스페이스, 웹 UI, HTTP REST API, 비동기식 잡 실행(대부분의 쿼리 프레임워크는 쿼리를 시작하고 쿼리 결과를 포함하는 응답을 기다릴 때 동기화 모델을 강제한다. 동기식으로 쿼리를 수행하면 네트워크 오류나 요청 타임아웃이 생겼을 때 쿼리를 처음부터 재시작해야 한다. 빅쿼리 잡은 비동기식이며, 잡마다 이름이 있으므로 한 번의 요청으로 모든 결과를 읽지 않아도 된다. 한번에 한 페이지씩 요청할 수 있다.) 3) 빅쿼리와 유사 개념 비교 (1) OLTP도 OLAP도 아니다. OLTP 시스템은 보통 간단한 쿼리를 다루며, 높은 업데이트율을 갖는다. 빅쿼리는 연산을 늘리고 줄이는 것만 지원할 뿐 OLTP 시스템이 요구하는 행 기준 업데이트는 직접적으로 지원하지 않는다. (2) 관계형도 NoSQL도 아니다. 빅쿼리는 RDBMS의 좋은 대안이 아니다. RDBMS는 행별 업데이트를 지원하고, 대부분 1초 내에 쿼리를 수행한다. 빅쿼리가 사용하는 드레멜 쿼리 엔진도 실제로는 1초보다 훨씬 적은 시간 내에 쿼리를 수행할 수 있지만, 모든 사용자에게 충분한 용량을 제공하기 위해 일반적으로 한 사용자가 동시에 수행할 수 있는 쿼리 수를 조절한다. 빅쿼리가 RDBMS가 이나라면 NoSQL일까? 빅쿼리는 데이터 쿼리에 SQL 통용어를 사용한다. NoSQL이 확장성 향상을 위해 쿼리를 좀 더 어렵게 만들었다면, 빅쿼리는 업데이트를 어렵게 만들었다. 하지만 덕분에 빅쿼리는 전통적인 SQL DB보다 훨씬 더 큰 데이터셋에 쿼리할 수 있다. (3) 맵리듀스도 아니다. 맵리듀스는 근본적으로 배치 지향 기술이다. 즉, 대화형이 아닌 오래 수행되는 배치 잡을 위해 디자인됐다. 맵리듀스는 빅쿼리보다 느리지만 좀 더 유연한 아키텍처를 갖는다. SQL에서 계산하기 어려운 많은 것들이 가능해졌고, 원하는 언어로 원하는 코드로 작성해서 계산할 수 있다. (4) 오픈소스가 아니다 4) 빅쿼리 기술스택 (1) 메타데이터 스토리지 빅쿼리는 사용자 테이블의 데이터를 일관성과 트랜잭션, 전역 복제를 지원하는 데이터스토어인 메가스토어(NoSQL)에 저장한다. 메가스토어는 데이터의 항상성을 위해 다수의 데이터센터에 데이터를 동기식으로 복제한다. (2) 테이블 스토리지 Colossus는 GFS의 단점을 보완하고자 만든 것으로, 메타데이터를 샤딩하여 여러 컴퓨터에 나누어 분산저장할 수 있게 되었는데, 이는 매우 큰 규모로의 확장을 가능하게 해주며, 좀 더 작은 파일을 사용할 수 있게 하여 어플리케이션 작성을 좀 더 단순하게 할 수 있도록 해준다. 그리고 In-memory 데이터베이스와 유사한 성능을 보인다. 빅쿼리는 콜로서스에 구조화된 데이터에 대한 컬럼기반 저장형식과 압축 알고리즘을 활용하여 데이터를 저장한다. 이에 반해, HDFS에서는 하나의 중앙서버에서 메모리상에 메타데이터를 관리하는데, 이에 데이터량이 커져 파일이 굉장히 많아지고 클라이언트가 많아지는 경우 단일 네임노드아키텍처로서 한계를 갖게 된다.(http://static.usenix.org/publications/login/2010-04/openpdfs/shvachko.pdf) 페이스북의 메시징 시스템에서는 여러 HDFS/HBase 클러스터를 두는 것으로 해결하였지만, 구글은 시스템 자체를 고쳐 해결하였다.
(3) 쿼리연산(병렬 분산 열 지향 쿼리엔진인 드레멜) 트리 구조 아키텍처로 쿼리를 리프노드에서 병렬로 처리하고 트리 상단에서 결과를 집계한다. 트리 아키텍처를 사용해 다수의 쿼리를 트리 내에서 동시에 수행할 수 있으며, 서로 다른 사용자가 같은 하드웨어를 공유한다. (4) 네트워킹