Google Bigquery -1 (설계적 특성 - OLAP, Columnar, MPP, Serverless)
https://nani-log.tistory.com/161
Amazon Redshift -1 (설계적 특성 - OLAP, Columnar, MPP, Provisioning)
Amazon Redshift는 직접 하둡 클러스터를 운영하지 않아도 클라우드상에서 데이터 웨어하우스를 운영할 수 있게 해준다. 데이터 웨어하우스는 대규모의 데이터를 분석하기 위해 설계되었기 때문에
nani-log.tistory.com
Google Bigquery는 서버리스 데이터 웨어하우스 제품이다. Redshift와 마찬가지로 대규모 데이터를 저장하고 분석하기 위한 데이터 웨어하우스의 공통적인 여러 설계적 특성을 지니고 있다
OLAP(Online Analytics Processing), Columnar Storage, 컬럼별 압축
Redshift에서 설명했듯 대규모 데이터셋을 통해 우리가 보고싶은건 사용자 단위(로우 단위)가 아니라 속성 단위(컬럼 단위)의 검색 결과다. 따라서 데이터 웨어하우스는 OLAP 데이터베이스로 데이터를 컬럼 단위로 저장해 빠르게 대규모 데이터셋을 검색한다
데이터를 컬럼 단위로 저장하면 컬럼별로 비슷한 값이 다수 존재하기 때문에 압축의 효율 또한 높아진다. 이로 인해 스토리지를 절약할 수 있다는 장점이 있다. 후에 더 자세히 살펴보겠지만 Bigquery는 클러스터링 키를 설정해 압축과 검색의 효율성을 더 높일 수 있다
MPP(Massively Parallel Processing)
하나의 서버에서 처리할 수 없는 데이터를 분산시키고 각 서버의 병렬성을 극대화해 클라이언트에게 빠르게 결과를 전달하려는 구조다. Bigquery에서는 Dremel이라는 컴퓨팅 레이어가 쿼리를 분할하고 각 서버에서 처리후 결과를 취합해 반환한다
후에 살펴보겠지만 Redshift는 스토리지와 연산 기능을 모두 담당하는 컴퓨팅 노드를 구현한 반면, Bigquery는 페타비트 단위의 네트워크를 구축해 필요한 데이터를 스토리지 레이어에서 가져와 컴퓨팅 레이어에 존재하는 각 서버에 신속하게 전달해 스토리지와 컴퓨팅의 단위를 적절한 만큼 사용할 수 있다는 장점이 있다
Serverless
Bigquery는 개발자가 직접 인프라를 관리할 필요가 없다. 그저 데이터셋을 저장하고 쿼리 비용을 줄이기 위해 쿼리 튜닝을 하는 등 인프라 관리는 구글에게 맡겨두고 즉시 시작할 수 있다
프로비저닝인 Redshift와 비교하면 인프라 관리의 품이 확 줄어든다. 이로 인해 사용자는 데이터 분석이나 인사이트 도출에 집중할 수 있게 되고 데이터 엔지니어는 각 데이터를 적재 및 품질 검사와 워크플로우를 조정하는 측면에 더 집중할 수 있다
정리
Bigquery는 데이터 웨어하우스라는 관점에서 Redshift와 여러 설계적 특성(OLAP, Columnar, MPP)이 공통적으로 존재하지만 스토리지/연산 레이어를 구분한 것과 서버리스로 구현했다는 점에서 사용자의 사용성을 극대화했다는 생각이 든다. 각 데이터 웨어하우스의 장단점이 존재하기에 상황에 적절한 선택지를 선택하는 것이 좋을 것 같다