12/07/2020

2021 Gartner 기술 트렌드

COVID-19 유행으로 많은 산업 현장들이 어려움을 겪고 있고 이로 인해 직장내에 많은 것들이 변화되고 있습니다.

직원들이 정기적으로 손을 씻고 있는지 확인하기 위해서 Sensor 또는 RFID 태그가 사용되고 있고 마스크를 착용을 강조하고 있습니다.

이러한 행동을 유도하기 위해 데이터를 수집하고 사용하는 것을 IoB(Internet of Behavior)라고 합니다. 조직에서 생산하는 데이터 뿐만 아니라 다른 소스의 데이터를 결합하고 해당 데이터를 사용하는 방법을 개선함에 따라 IoB가 조직과 사람간의 상호 작용에 많은 영향을 미칠 것 입니다.

IoB는 COVID-19로 인한 경제 상황에서 비즈니스가 탄력을 받기위해 요구하는 전략적 기술 트렌드 중 하나 입니다.

IoB는 데이터를 사용하여 행동을 변경하는 것입니다.

Gartner의 올해의 트렌드는 사람 중심, 위치 독립성 및 탄력적인 전달이라는 세 가지 주제로 분류됩니다.

  • 사람 중심성 (People centricity): 전염병으로 인해 많은 사람들이 조직에서 일하는 방식이 변화되고 있지만 아직까지 사람이 모든 비즈니스의 중심에 있습니다. 따라서 지금같은 상황에서는 디지털화 된 프로세스를 이용하여 비즈니스를 작동되게 해야 합니다.
  • 위치 독립성 (Location independence): COVID-19는 직원, 고객, 공급 업체 및 조직 생태계가 물리적으로 존재하는 곳으로 이동했습니다. 위치 독립성은 새로운 비즈니스를 지원하기 위해 기술 전환을 필요로 합니다.
  • 탄력적인 전달 (Resilient delivery): 전염병 혹은 불황은 전 세계에 존재합니다. 이 상황에 대해서 적응할 준비가 된 조직은 모든 유형의 혼란을 극복할 것입니다.

Gartner의 9가지 기술 전략 트렌드는 서로 독립적으로 작동되지 않고 상호 작용으로 강화됩니다.

트렌드 1: 행동 인터넷 (Internet of Behaviors)

위에서 언급했듯이 IoB는 데이터를 사용하여 행동을 변경하는 것입니다. 일상 생활의 “Digital dust”(디지털 및 현실 세계에 걸친 데이터)를 수집하는 기술이 증가함에 따라 해당 정보는 행동에 영향을 미치는 데 사용 될 수 있습니다.

예를 들어서 상업용 차량의 경우 Telematics는 급제동 및 회전에 이르기까지 운전 행동을 모니터링 할 수 있습니다. 회사는 이 데이터를 사용하여 운전자 스타일 및 안전성을 개선할 수 있습니다.

“IoB는 목표와 결과에 따라 윤리적, 사회적 영향을 미칩니다.”

IoB는 여러 소스에서 데이터를 수집, 결합, 처리 할 수 있습니다. 고객 데이터 및 공공 부문/정부 기관에서 처리하는 시민 데이터, 소셜 미디어, 안면 인식, 위치등의 데이터를 처리하는 기술이 점점 더 정교해지면서 가능성이 커졌습니다.

건강 보험 회사가 보험료를 줄이기 위해 신체 활동을 추적하는데 사용하는 것과 동일하게 식료품 구매를 모니터링 하는데 사용 할 수 있습니다. 건강에 해로운 품목이 너무 많으면 보험료가 올라갈 수 있습니다. 지역마다 다른 개인정보보호법은 IoB의 채택과 규모에 큰 영향을 미치게 될 것 입니다.

트렌드 2: 모든 경험 (Total experience)

Total experience는 다중 경험, 고객 경험, 직원 경험 및 사용자 경험을 결합하여 비즈니스 결과를 혁신합니다. 목표는 이러한 모든 요소가 교차하는 전반적인 경험을 개선하는 것입니다.

“이러한 추세를 통해 조직은 COVID-19를 이겨낼 수 있습니다.”

Silo에서 각각 개별적으로 개선하는 것과 다르게 모든 경험을 긴밀하게 연결하면 비즈니스를 경쟁 업체와 차별화하여 지속 가능한 경쟁 우위를 확보 할 수 있습니다. 이러한 추세를 통해 조직은 원격 작업, 모바일, 가상 및 분산 고객을 포함한 COVID-19를 이겨내는 요인으로 활용할 수 있습니다.

예를 들어, 통신 회사가 안전과 만족도를 높이기 위해 전체 고객 경험을 혁신했습니다.

첫째, 기존 앱을 통해 예약 시스템을 제공합니다. 고객이 예약을 위해서 도착하여 매장에서 75 feet 이내의 거리에 들어 왔을 때, 사회적 거리를 유지하는 아래의 알림을 전달합니다.

  1. 체크인 절차를 안내하는 알림과
  2. 안전 할 수 있을 때까지 걸리는 시간을 알려주는 알림을 받습니다.

이 회사는 더 많은 디지털 키오스크를 제공하도록 서비스를 조정하고 직원들이 하드웨어를 물리적으로 만질 필요없이 자신의 태블릿을 사용하여 고객의 장치를 탐색할 수 있도록 했습니다. 그 결과 고객과 직원을 위해 더 안전한 경험이 제공되었습니다.

트렌드 3: 개인 정보 보호 강화 컴퓨팅 (Privacy-enhancing computation)

개인 정보 보호 강화 컴퓨팅은 데이터를 보호하는 세 가지 기술이 있습니다.

  1. 민감한 데이터를 처리하거나 분석 할 수 있는 신뢰할 수 있는 환경을 제공합니다.
  2. 분산 된 방식으로 데이터를 처리 하거나 분석합니다.
  3. 처리 또는 분석전에 데이터와 알고리즘을 암호화 합니다.

이러한 것을 통해 조직은 기밀성을 유지하면서 지역 및 경쟁 업체와 안전하게 공동 연구 작업을 수행할 수 있습니다. 이 접근 방식은 개인 정보 또는 보안을 유지하면서 데이터를 공유해야하는 필요성이 있을 때 활용될 수 있도록 특별히 설계되었습니다.


트렌드 4: 분산 클라우드 (Distributed Cloud)

분산 클라우드는 클라우드 서비스가 서로 다른 물리적 위치에 분산되는 개념이지만 운영 및 정책등은 여전히 CSP의 책임입니다.

“분산 클라우드는 클라우드의 미래입니다.”

이러한 서비스를 사용하면 지연 시간이 짧은 시나리오에 도움이 되고 데이터 비용도 절감되기에 데이터가 특정 지리적 영역에 남아있어야 한다는 법률을 수용하는데 도움이 됩니다. 또한 비용이 들고 복잡할 수 있는 자체 프라이빗 클라우드말고 퍼블릭 클라우드의 이점을 누리고 있기에 분산 클라우드는 클라우드의 미래입니다.

트렌드 5: 어디서나 운영 (Anywhere operations)

COVID-19 상황에서도 운영이 필수적입니다. 이 운영 모델을 통해 고객, 고용주 및 비즈니스 파트너가 원격환경에서 운영되는 모든 곳에서 비즈니스에 접근하고 활성화 할 수 있습니다.

어디서나 작동하는 운영 모델은 “디지털 우선, 원격 우선”입니다.

예를 들어, 모바일 전용이지만 물리적인 상호 작용없이 자금 이체에서 계좌 개설까지 모든 것을 처리하는 은행이 있습니다. 물리적 지점 없이 디지털 방식으로 제공되어야 현 상황을 이겨낼 수 있습니다. (e.g. 카카오뱅크?)

트렌드 6: 사이버 보안 메시 (Cybersecurity mesh)

사이버 보안 메시는 확장 가능하고 유연한 사이버 보안 제어에 대한 분산 아키텍처 접근 방식입니다. 현재 많은 자산이 기존 보안 체계를 벗어나 외부에 존재합니다. 사이버 보안 메시는 본질적으로 사람이나 사물의 신원을 중심으로 보안 경계를 정의 할 수 있도록 합니다. 정책을 중앙으로 집중시키고 정책 시행을 분산함으로써 모듈식의 대응력있는보안 접근 방식을 가능하게 합니다. 경계 보호의 의미가 낮아짐에 따라 “성벽 도시”의 보안 접근 방식은 현재 요구사항에 맞게 진화해야 합니다.

트렌드 7: 지능형 컴포저블 비즈니스 (Intelligent composable business)

지능형 컴포저블 비즈니스는 상황에 따라 적응하고 근본적으로 재정렬 할 수 있는 비즈니스입니다. 조직이 디지털 비즈니스 전략을 가속화하여 더 빠른 디지털 전환을 추진 함에 따라 민첩하게 현재 사용 가능한 데이터를 기반으로 비즈니스 결정을 내려야 합니다.

이를 성공적으로 수행하기 위해서는 정보에 대해 더 나은 접근이 가능해야 하고 더 나은 통찰력으로 정보를 보강하여 신속하게 대응할 수 있어야 합니다.

트렌드 8: AI 엔지니어링 (AI engineering)

AI 엔지니어링 전략은 AI투자에 대한 전체 가치를 제공하면서 AI 모델의 성능, 확장성, 해석 가능성 및 안정성을 촉진합니다. AI 프로젝트는 유지 보수성, 확장성 및 정책과 관련된 문제에 직면하기에 문제가 될 소지가 있습니다.

AI 엔지니어링은 AI를 전문적이고 격리된 프로젝트 세트가 아닌 DevOps 프로세스의 일부로 만듭니다. 여러 AI 기술의 조합을 운영할 때 명확한 방법을 제공합니다.

AI 엔지니어링의 정책 측면으로 인해 책임감있는 AI가 신뢰, 투명성, 윤리, 공정성, 해석 가능성 및 규정 준수 문제를 처리하기 위해 등장하고 있고 이는 AI 책임 운영화입니다.

트렌드 9: 초자동화 (Hyperautomation)

Hyperautomation은 조직에서 자동화 할 수 있는 모든 것을 자동화해야 한다는 생각입니다. 능률적이지 않은 레거시 비즈니스 프로세스를 가진 조직에 의해 주도되어 조직에 막대한 비용과 광범위한 문제를 발생 시킬 수 있습니다.

많은 조직은 Lean, 최적화, 연결등의 기술 지원을 받습니다. 동시에 디지털 비즈니스의 가속화에는 효율성, 속도가 필요합니다. 효율성 및 비즈니스 민첩성에 초점을 맞추지 않는 조직은 뒤쳐 질 것입니다.

References: https://www.gartner.com/smarterwithgartner/gartner-top-strategic-technology-trends-for-2021/

12/02/2020

언택트 시대의 Virtual Store — Clikshop

코로나 시대에 사람이 붐비는 쇼핑몰을 피하고자 하는 마음은 누구에게나 있을 것이다. 그래서 오프라인 상점들이 직격탄을 맞고 있고 대부분 온라인에서 쇼핑을 하고 있을 것이다.

이런 상황에 실제 매장을 온라인 상에 구현해 놓은 Virtual Store가 등장하고 있다. Virtual Store란 실제 매장을 3차원 스캔 기술을 이용해 온라인으로 옮겨 놓은 상점을 의미한다. 아래의 영상은 Brik + Clik 에서 제공하는 Virtual Store 영상이다.

PC 혹은 모바일 기기에서 매장에서 쇼핑을 하는 듯한 느낌을 주면서 제품의 링크를 통해 온라인 구매가 가능하도록 해준다. 사람마다 편차가 있겠지만, 나의 경우는 그냥 온라인에서 구매하는 것이 편한 것 같다. (VR이라면 좋아했을지도…)

Brik + Clik 뿐만 아니라 국내에서도 Virtual Store를 제공하는 매장들이 많이 생기는 것 같다. 언택트 소비가 대세로 떠오른 코로나 시대에 위기 돌파구 혹은 새로운 기회로 보는 것인가? 매출로 이어지고 있는지 궁금하다.

코로나로 인해 “집콕족”이 증가하는 현시점에 VR/AR 시장이 탄력을 받지 않을까 조심스레 예상해본다.

체험하기: https://app.cart360.shop/s/brik-clik

사업 기획과 서비스 기획의 차이


 사업 기획과 서비스 기획이 같다고 인지하나요? 대부분의 사람들은 “기획”이라는 단어 때문에 둘을 혼동하는 것 같습니다.

사업 기획은 비즈니스 모델을 정의하고 운용하는 것이기에 수익 또는 가치 추구가 중요합니다.

서비스 기획은 추상화된 것을 체계화하여 세부적 요소들을 구체화 하는 것입니다. 따라서 서비스 기획은 수익이나 가치를 보여주지 않을 수 있습니다.

조금 더 자세히 알아 볼까요?

사업 기획

사업 기획은 누구에게, 무엇을, 제공하고, 수익 창출에 대한 모델을 수립하는 것을 의미합니다. 즉, 최종 소비자에게 어떤 가치를 줄 수 있는지 고민하고 이게 사업적으로 가능한 것인지를 검토합니다.


서비스 기획

서비스 기획은 사업 기획에서 만들어진 모델을 기반으로 조금 더 구체화된 작업을 수행합니다.

  • Persona (페르소나)
  • User Scenario (유저 시나리오)
  • Requirements Specification (요구사항 명세서)
  • Flow chart (화면 흐름도)
  • Wire frame (화면 설계서)
  • Functional Specification (기능 명세서)

위에 언급된 것들을 이 사업에 관계된 다양한 Actor를 고려하여 구체화하게 됩니다.

결국, 사업 기획과 서비스 기획 모두 비즈니스를 위한 작업입니다.

사업 기획은 WHAT, WHY에 중점을 둔다면 서비스 기획은 HOW에 중점을 둡니다.

사업 기획

  • 비즈니스 모델을 수립하고 운용
  • 목적이 수익 및 가치에 중점

서비스 기획

  • 비즈니스 모델에 대한 구체적인 기획
  • 비즈니스 모델의 세부적 요소를 구체화하여 서비스를 탄생 시키는 과정
  • 기술과 비즈니스 모델간의 간극을 조정하는 역할을 함

“기획”이라는 단어 속에 숨겨진 모호한 의미의 함정에 빠지지 않았으면 좋겠습니다.


12/01/2020

연필

 

세상에 태어나 글을 배우면서 가장 먼저 손에 쥐게되는 도구가 연필일 것이다.

어릴때에는 연필만 있는줄 알고 사용하다가 나이가 들면서 샤프, 볼펜, 만년필까지 다양한 필기구가 있다라는 것을 알게되었고 다른 필기구에 욕심을 내면서 사용했었다. 그러다가 다시 연필을 쥐었다.

사각사각 소리를 내며 종이 위를 걷는 연필의 소리가 좋게 들리는 것은 갬성인가? 아니면 나이 들었다는 증거인가?

어느 순간부터 나는 여행을 가면 그 나라 혹은 그 지역의 연필을 사게 되었다. 혹은 어느 전시관을 들릴경우 연필을 구매했다. 그렇게 구매한 연필이 보관함을 가득 채우고 있다.

연필의 매력은 무엇일까? 지울수 있다는 점? 나무향? 깍는 재미? 연필을 많이 모으고 있지만, 나는 연필에 대해 그다지 아는게 없지만 연필이 주는 매력에 빠져있다.

요즘 같은 시대에는 손글씨를 쓰는 사람은 많지 않다. 키보드를 두들기는게 편하고 빠를 것이다. 그렇기 때문에 어느샌가 손으로 글을 쓴다는 것이 매우 힘든 것임을 느끼고 있다. 마음이 급하면 휘갈려지게 되고, 집중하면 기다려야 한다는 점이 중심을 잡기가 어려울 때가 있다. 그럼에도 불구하고 연필은 나에게 많은 것을 준다.

연필을 들고 무언갈 끄적이다보면 마음이 평온해지고 아이디어가 막 샘솟듯이 나오는 것 같다. 연필을 모으는 이유가 뭔가 위기일때 쌀이나 식료품을 보관하듯이 연필 공장이 망하지 않을까하는 마음에 그런건 아닐까? 이런 느낌을 간직하려고?

인간이 글을 쓰는걸 지속하는 이상 연필도 함께 존재 할 것이다. 또 모르는 일이다. 디지털로 대체될지…

그 날은 오지 않았으면 한다.

11/30/2020

11/27/2020

Snowflake, BigQuery, Redshift 비교

빅데이터와 분석은 오늘날 업계의 비즈니스를 발전시키는 근본적인 힘으로 작용되었습니다. 수년 동안 매초 생성되는 데이터의 양은 기하급수적으로 증가했으며, 이로 인해 데이터를 처리하는데 효율적인 클라우드 데이터웨어 하우스 기술이 등장했습니다.

데이터웨어 하우스는 데이터를 효율적으로 활용하여 심층적인 통찰력을 도출하는데 매우 중요합니다. 어떤 데이터웨어 하우스가 내 비즈니스에 적합한가?라는 고민이 생길 것 입니다.

데이타웨어 하우스 아키텍처는 빠르게 변화하고 있습니다. 기업은 기존 On-Premise대신 낮은 초기 비용, 향상된 확장성 및 성능을 갖춘 클라우드 기반 데이터웨어 하우스로 점차 이동하고 있습니다.

클라우드기반 데이터웨어 하우스 선택시 고려할 점

클라우드상에서의 데이터웨어 하우스를 선택해야 할 경우 다음을 고려해야 합니다.

데이터웨어 하우스 지리적 위치

아래의 국가에서 해당 솔루션을 사용할 수 있습니다.


데이터 양

데이터 볼륨

  • Postgres, MySQL, MSSQL 및 기타 여러 RDBMS는 최대 1TB 크기의 데이터를 지원하고 이 크기를 초과하면 성능이 저하될 가능성이 존재합니다.
  • Redshift, BigQuery, Snowflake는 최적의 방식으로 최대 수 PB의 데이터 세트 크기를 지원합니다.

데이터 형식

데이터 소스

기존 서비스가 클라우드를 사용하고 있지 않으면 VPN응 이용해 데이터를 전송해야 합니다. 따라서 데이터 파이프 라인 구축에 대한 비용도 고려해야 합니다. 각 서비스별 예제는 다음과 같습니다.

1. Redshift


2. BigQuery


3. Snowflake


파이프라인은 환경에 따라 달라집니다.

보안

구매 결정에 영향을 미치는 주요 요소는 보안입니다. 데이터가 제3장에게 유출되지 않아야 합니다. 세가지 솔루션 모두 데이터를 보호하기 위한 보안 조치가 내장되어 있습니다.


가격 모델

가성비를 가진 솔루션을 결정하는 것은 측정하기가 어려운 부분입니다. 사용 사례를 기반으로 설명하도록 하겠습니다. 아래는 각 솔루션별 가격 모델입니다.

Redshift는 리소스가 미리 결정되기 때문에 예측 가능성이 높습니다. Snowflake는 소요 시간에 따라 가격이 달라지기 때문에 쉽게 측정할 수 있지만, BigQuery는 필요한 쿼리 리소스가 다양하기에 예측하기가 어렵습니다.

가격 책정 모델을 기반으로 각 서비스에 가장 적합한 사례를 살펴보겠습니다.

Redshift

일정한 계산이 필요한 시나리오에 적합합니다.

e.g.

  • NASDAQ 일일 레포트: 데이터 보고를 위한 워크로드
  • 자동 광고 입찰: 광고의 입찰은 실시간으로 예측 모델을 통해 조정
  • 라이브 대시 보드: 새로 고침을 통한 지속적인 쿼리로 라이브 데이터 스트리밍

BigQuery

워크로드가 급증하는 시나리오에 가장 적합합니다. (유휴 시간이 길고 가끔 많은양의 쿼리를 실행하는 경우)

e.g.

  • 권장 모델: 전자상거래 애플리케이션을 위해 하루에 한번 실행
  • 임시보고: 분기별 보고서에 복잡한 쿼리가 있는 경우
  • 영업 인텔리전스: 영업 또는 마케팅 팀이 원하는 방식으로 데이터를 분석하여 임시로 수행할 경우
  • 기계 학습: 데이터, 소비자 행동에서 새로운 패턴을 발견하는 경우

Snowflake

안정적이고 지속적인 사용 패턴에 가장 적합합니다. 하지만 지속적으로 Up/Down 스케일링이 필요합니다.

e.g.

  • 비즈니스 인텔리전스 회사: 데이터의 패턴을 찾기 위해 동시에 데이터를 쿼리하는 사용자가 많은 경우 (100명 ~ 1000명)
  • 데이터를 서비스로 제공: 분석 사용자 인터페이스 또는 데이터 API의 형태로 분석 목적의 데이터를 수천개의 클라이언트에 제공하는 경우

클라우드 기반 데이터웨어 하우스 소개 및 비교

현재 시점에 고려해야 할 데이터웨어 하우스는 Amazon Redshift, Google BigQuery, Snowflake입니다.

본 글에서는 언급한 3가지 솔루션에 대해서 비교하려고 합니다.

Amazon Redshift란?

Redshift는 비즈니스 인텔리전스(BI) 도구와 원할하게 통합 될 수 있는 Managed형 클라우드 데이터웨어 하우스 서비스라고 할 수 있습니다. 웨어하우스에 ETL(Extract, Transform, Load)만 있으면 현명한 비즈니스 의사결정을 내리기가 수월해집니다.

AWS를 사용하면 작은 사이즈의 데이터로 시작하고 요구에 따라 원할하게 확장/축소 할 수 있습니다. 이를 통해 기업은 데이터를 활용하여 자사 또는 고객에 대한 비즈니스 통찰력을 얻을 수 있습니다.

클라우드 데이터웨어 하우스를 사용하려면 Redshift 클러스터로 알려진 노드 그룹을 사용해야 합니다. 클러스터를 프로비저닝 한 후에 데이터 분석 쿼리를 실행하기 위해 데이터 세트를 업로드 해야 합니다.

데이터 세트의 크기에 관계없이 동일한 SQL 기반 도구 및 BI 솔루션을 사용하여 빠른 쿼리 성능을 이용할 수 있습니다.

Google BigQuery란?

Google BigQuery는 Google의 자체 데이터웨어 하우징 솔루션입니다. 2010년에 처음 출시되었고 C-Store 및 MonetDB에 이어 일반적으로 사용할 수 있는 최초의 데이터웨어 하우스 솔루션 중 하나였습니다.

BigQuery는 Google Cloud Platform으로 알려진 Google의 전체 클라우드 컴퓨팅 생태계에서 중요한 부분입니다.

Dremel은 BigQuery에서 쿼리를 실행하는데 사용되는 Google에서 개발한 강력한 쿼리 엔진입니다. Google에 의하면 Dremel은 “매우 큰 데이터 세트에서 SQL과 같은 유사한 쿼리를 실행하고 단 몇 초만에 정확한 결과를 얻을 수 있는 쿼리서비스”입니다.

BugQuery 및 Dremel은 리소스를 할당하고 Dremel 작업에 데이터를 제공하는데 도움이 되는 Borg 및 Colossus와 같은 다른 Google 클라우드 기술을 활용할 수 있습니다.

SnowFlake란?

Redshift와 Snowflake는 관계형 데이터베이스 관리 시스템입니다. SaaS(Software-as-a-Service) 모델로 제공되는 구조화된 데이터와 반 구조화된 데이터 모두를 지원하는 데이터웨어 하우스입니다.

이는 기존 데이터베이스 또는 빅 데이터 소프트웨어 플랫폼(e.g. Hadoop)위에 구축되지 않는 것을 의미합니다. 대신 Snowflake는 클라우드 용으로 설계된 고유한 아키텍처가 존재하는 SQL 데이터베이스 엔진을 사용합니다.

Snowflake는 빠르고 사용자 친화적이며 기존 데이터웨어 하우스보다 더 많은 유연성을 제공합니다.

Redshift ETL과 Snowflake ETL을 모두 사용하는 경우 두 솔루션간에 많은 유사점이 있음을 알고 있을 것입니다.

Snowflake는 Snowflake Elastic Data Warehouse의 형태로 클라우드 기반 데이터 스토리지 및 분석을 제공합니다. 사용자는 클라우드 기반 하드웨어 및 소프트웨어를 사용하여 데이터를 분석하고 저장 할 수 있습니다.

물리 데이터는 Amazon S3에 저장됩니다. Snowflake ETL을 사용하는 경우 Hadoop과 같은 기술을 사용하지 않고도 퍼블릭 클라우드 시스템을 활용할 수 있습니다.

이러한 클라우드웨어 하우스 시스템은 모두 강력하며 데이터 관리와 관련하여 몇 가지 고유한 기능을 제공합니다. 그러나 각 솔루션별 차이점은 존재합니다.

회사에 적합한 솔루션을 선택하려면 통합, 데이터베이스 기능, 유지 관리, 보안등의 비용도 비교해야 합니다.

기능 비교

Computing Layer

  • BigQuery: 분산 컴퓨팅에서 실행됩니다. Google이 제공하는 각 데이터센터의 Borg에서 실행됩니다.
  • Redshift: AWS 가상 머신에서 실행되는 ParAccel의 독점 포크 (부분적으로 Postgres에서 포크됨), Postgres라고 하나 많이 다름
  • SnowFlake: 클라우드(AWS, GCP, Azure)의 가상머신에서 실행되는 Intelligent Predicate Pushdown + Smart Caching이 포함된 독점 컴퓨팅 엔진이고 C-Store, MonetDB에서 영감을 얻은 하이브리드 컬럼 시스템

Storage Layer

Redshift, BigQuery, Snowflake 모두 Hot/Warm/Cold 스토리지를 구현합니다.

  • Big Query: 독점적이며 ColumnIO를 스토리지 형식으로 사용하고 Colossus 파일 시스템에 저장됩니다. 분산 컴퓨팅과 스토리지를 완전히 분리합니다.
  • Redshift: 독점적이지만 일반적으로 SSD(dc1, dc2) / HDD (ds1, ds2) 또는 독점 컬럼 형식을 사용하는 S3기반 (RA3)을 포함하여 혼합됩니다 RA3는 컴퓨팅과 스토리지를 분리하는 반면에 다른 모든 노드 유형은 컴퓨팅과 스토리지를 함께 지역화합니다.
  • Snowflake: 원하는 클라우드의 컴퓨팅/객체 스토리지에서 실행되는 메모리/SSD/객체 저장소의 독점적인 Row 형식으로 제공하며 메타 데이터 캐싱을 사용하여 PAX(하이브리드 컬럼 형식)로 저장됩니다.

Compression

  • BigQuery: ColumnIO 열 형식으로 처리되는 독점 압축입니다. BigQuery는 지속적으로 내부에서 데이터를 압축하지만 압축되지 않은 바이트를 스캔하는 것처럼 쿼리 요금이 청구됩니다.
  • Redshift: Redshift는 LZO, ZStandard와 같은 개방형 알고리즘을 구현하여 투명한 압축을 달성합니다. 최근에 자체 독점 압축 알고리즘(AZ64)을 출시했지만 데이터 유형 선택이 제한적입니다. 열을 압축할 방법을 선택할 수 있습니다. Analyze Compression은 쿼리 패턴과 열에 저장하려는 데이터에 따라 압축 방식을 선택하는 것이 가장 좋습니다.
  • SnowFlake: 자체 압축 레이어를 제공합니다. BigQuery와 달리 스캔한 바이트에 대해서는 요금이 청구되지 않지만 쿼리 플래너가 압축 및 테이블 통계를 활용하여 더 적은 데이터를 스캔하기에 컴퓨팅 비용을 줄일 수 있습니다.

Deployments

  • BigQuery, Redshift, Snowflake 모두 클라우드위에서 동작됩니다.
  • BigQuery: 클라우드 전용이고 Google Cloud Platform내에서만 사용이 가능합니다.
  • Redshift: 클라우드 전용이고 Amazon Web Services내에서만 사용이 가능합니다.
  • Snowflake: 클라우드 전용이고 선호하는 클라우드 유형(AWS, GCP, Azure)에 배포가 가능합니다.

데이터 접근

데이터에 쉽게 접근할 수 없다면 데이터웨어 하우스는 많이 사용될 수 없습니다. 일반적으로 데이터베이스는 ODBC/JDBC에 의존해왔지만 시간이 지남에 따라 새로운 형태의 데이터 검색 및 핸들링이 필요합니다.

  • BigQuery ** Simba 드라이버를 통한 ODBC/JDBC 접근 ** BigQuery 사용자 인터페이스 ** BigQuery 연결 API ** BigQuery Jobs API ** BigQuery Storage API ** BigQuery CLI
  • Redshift ** AWS 제공 드라이버를 통한 ODBC/JDBC 접근 ** Redshift 사용자 인터페이스 ** 데이터 접근 API ** AWS CLI ** Postgres CLI
  • Snowflake ** 드라이버를 통한 ODBC/JDBC 접근 ** Spark 플러그인 (spark-snowflake)을 통한 접근 ** Kafka를 통한 접근 ** 특정 언어용 Python/Node.js/Go/.Net 드라이버 ** SnowSQL ** Snowsight

암호화

세가지 솔루션은 저장 및 전송 중 일부 암호화 방법을 제공합니다.

  • BigQuery: Google에서 제공하는 암호화 키 관리 서비스(KMS) 또는 CMEK를 사용하여 암호화
  • Redshift: AWS 키관리 서비스를 사용하여 암호화
  • Snowflake: 종단간 암호화, VPS(Virtual Private Snowflake)는 전용 서버의 메모리에 암호화 키를 저장하는 기능 제공

타사 도구 지원 (시각화, 데이터 모델링)

대부분의 인기 있는 도구는 모든 데이터베이스를 지원합니다.

AWS와 GCP는 모두 고유한 시각화/데이터 모델링 소프트웨어(각각 QuickSight, Looker/Data Studio)를 제공합니다.

모든 기능 앞에 “Snow”를 배치하는 전통에 따라 Snowflake는 몇 가지 기본 데이터 시각화를 수행할 수 있는 Snowsight를 제공합니다.

Query Language

쿼리 언어 없이는 훌륭한 데이터베이스를 제공할 수 없습니다.

  • BigQuery: BigQuery는 Legacy(BigQuery라고 함) SQL과 표준 SQL이라는 두 가지 주요 언어를 제공합니다.
  • Redshift: ANSI와도 호환되며 Postgres에 대한 경험이 있다면 익숙한 언어를 제공합니다.
  • Snowflake: ANSI와 호환되는 Snowflake 쿼리 언어는 작업하기가 매우 수월합니다. 언어는 처음부터 명확하게 설계되었으며 중첩된 데이터로 작업하는 경우 대부분 쉽게 작업이 가능합니다.

BigQuery와 Redshift는 모두 지리 공간 데이터 쿼리를 지원합니다. Snowflake는 현재 지리 공간 데이터에 대한 미리보기 기능을 제공합니다. 모든 구현은 네이티브 유형을 사용하거나 텍스트 표현(e.g. GeoJSON)간에 변환할 수 있습니다.

통합 쿼리

통합 쿼리는 기존 분석(OLAP) 스타일 데이터베이스와 일반적인 행기반 트랜잭션 스타일의 데이터베이스(Postgres, MySQL)사이의 격차를 해소하기 위해 설계된 기능입니다.

  • BigQuery: Postgres 및 MySQL 데이터베이스 지원을 포함하는 CloudSQL을 통해 통합 쿼리를 지원합니다. 다른 소스로는 Google 스프레트시트 및 Google Cloud Storage가 있습니다.
  • Redshift: Amazon RDS(Postgres, MySQL 및 Aurora)에 대한 통합 쿼리 지원을 합니다.
  • Snowflake: 현재 통합 쿼리를 지원하지 않습니다.

사용자 정의 함수(UDF)

UDF는 데이터베이스에서 수행 할 수 있는 작업에 추가적인 유연성을 도입 할 수 있는 방법입니다. 데이터베이스에 로직을 배포할 수 있다는 점은 과거로 회귀할 수 있지만, 특정 상황에서는 필요할 수 있습니다.

  • BigQuery: SQL 및 Java Script로 사용자 정의 함수 작성을 지원합니다. Java Script 함수의 경우 복잡한 UDF를 작성시 Google Cloud Storage의 외부 라이브러리를 포함할 수 있습니다.
  • Redshift: SQL 또는 Pythob으로 UDF를 작성할 수 있습니다. BigQuery와 유사하게 외부 라이브러리 및 함수를 쉽게 패키징하고 S3에서 호스팅 할 수 있습니다. Python에 대한 지원은 없습니다. 반면 Lambda UDF를 도입했습니다.
  • Snowflake: SQL 및 Java Script 함수를 지원합니다. 하지만 외부 라이브러리를 사용할 수 없습니다.

캐싱

  • BigQuery: 쿼리를 캐시하고 인메모리 캐시를 제공하는 중간 캐시를 제공합니다. 캐시된 쿼리는 비용이 발생하지 않습니다. 캐싱 엔진은 데이터 스튜디오뿐만 아니라 BigQuery에서도 사용 될 수 있기에 쿼리 소스에 관계없이 스마트한 중간 캐싱이 가능합니다.
  • Redshift: 쿼리 및 결과를 캐싱합니다. (노드 유형 및 메모리/디스크의 사용 가능한 스토리지에 따라 다름)
  • Snowflake: 콜드 데이터 스토리지와 분리된 중간 스토리지에 Hot/Warm 쿼리 캐시를 제공합니다.

스트리밍

데이터를 데이터베이스에 빠르고 안정적으로 저장하는 것은 매우 어려운 문제입니다.

  • BigQuery: 기본 스트리밍, 하나의 테이블처럼 보이도록 주어진 테이블에서 분할 된 데이터로 스트리밍 버퍼를 조정하는 몇 가지 방법이 존재합니다. 그러나 이것은 대부분 추상화됩니다.
  • Redshift: Redshit로 마이크로 배치를 할 수 있지만, 기본 스트리밍 기능은 없습니다. 마이크로 배치를 시작하는 가장 쉬운 방법은 Kinesis Firehose를 통해 Redshift를 직접 연결하는 것입니다.
  • Snowflake: Snowpipe를 통해 Amazon S3, Google Cloud Storage, Azure Blob Storage에서 마이크로 배치를 할 수 있지만, 기본 스트리밍 기능은 없습니다.

데이터 소스

일부 제품에서는 데이터베이스 자체에 데이터를 저장하지 않고도 데이터를 쿼리 할 수 있습니다. 이는 유용 할 수 있지만 데이터 현지화 및 최적화 된 데이터 구조를 활용할 수 없을만큼 성능이 현저히 떨어지는 경향이 있습니다.

  • BigQuery: 통합 쿼리를 통해 Cloud Storage, Google Drive, Bigtable, Cloud SQL등을 비롯한 일부 외부 데이터 소스에 대한 연결을 설정 할 수 있습니다.
  • Redshift: S3와 Redshift Cluster 사이의 중간 컴퓨팅 계층 역할을 하는 Redshift Spectrum을 통해 S3에 있는 데이터에 연결할 수 있습니다. 통합 쿼리 설정이 있는 경우에는 RDS(Postgres, MySQL 또는 Aurora)를 쿼리 할 수 있습니다.
  • Snowflake: BigQuery 및 Redshift와 마찬가지로 최상의 성능을 위해서 Snowflake내에 있는 것이 이상적입니다. 그러나 Snowflake는 Snowflake로 데이터를 가져 오지 않고도 주요 클라우드 (Amazon S3, Google Cloud Storage, Azure Blog Storage)의 객체 스토리지에 연결할 수 있는 외부 테이블 기능을 제공합니다.

끝으로,

클라우드 기반의 데이터웨어 하우스를 선택하려는 분들께 도움이 되길 희망합니다.

References:

  • www.xplenty.com/blog/redshift-vs-snowflake/
  • www.xplenty.com/blog/snowflake-vs-bigquery/#bigquery
  • fivetran.com/blog/warehouse-benchmark