Google Cloud로 통합된 최신 분석 데이터 플랫폼 빌드

많은 데이터가 생성됩니다. IDC 연구에 따르면 2025년까지 전 세계 데이터가 175제타바이트에 이를 것으로 추산됩니다¹. 매일 생성되는 데이터 볼륨이 어마어마하며 따라서 기업에서 접근성과 사용성이 뛰어난 방식으로 데이터를 수집, 저장, 구성하는 것이 점점 더 어려워지고 있습니다. 실제로 데이터 전문가의 90%는 신뢰할 수 없는 데이터 소스로 인해 업무 속도가 느려졌다고 말합니다. 데이터 분석가의 약 86%는 오래된 데이터로 어려움을 겪고 있으며, 데이터 작업자의 60% 이상은 매달 데이터를 정리하고 준비하는 동안 엔지니어링 리소스를 기다려야 하므로 영향을 받고 있습니다².

비효율적인 조직 구조와 아키텍처 방식의 의사 결정은 데이터를 집계하는 것과 데이터를 활용하는 것 사이에 기업이 겪는 격차의 원인이 됩니다. 기업에서는 데이터 분석 시스템을 현대화하기 위해 클라우드로 이전하고자 하지만, 그것만으로는 사일로화된 데이터 소스와 불안정한 처리 파이프라인과 관련된 근본적인 문제를 해결할 수 없습니다. 데이터 소유권에 대한 전략적인 의사 결정과 스토리지 메커니즘에 대한 기술적인 의사 결정은 조직에서 데이터 플랫폼을 더 성공적으로 활용하기 위해 종합적인 방식으로 이루어져야 합니다.

이 도움말에서는 Google Cloud를 기반으로 하는 최신 통합 분석 데이터 플랫폼을 만드는 데 필요한 결정 지점을 설명합니다.

빅데이터는 지난 20년 동안 비즈니스에 엄청난 기회를 창출해 왔습니다. 하지만 조직에서 비즈니스 사용자에게 관련성이 높고 실행 가능하며 시의적절한 데이터를 제공하는 것은 복잡합니다. 연구에 따르면 분석가의 86%가 여전히 오래된 데이터로 인해 어려움을 겪고 있고³ 기업의 32%만이 데이터에서 실질적인 가치를 실현하고 있다고 여기는 것으로 나타났습니다⁴. 첫 번째 문제는 데이터 최신 상태와 관련한 것입니다. 두 번째 문제는 사일로 전반에서 서로 이질적인 레거시 시스템을 통합하기가 어렵다는 데서 비롯됩니다. 조직에서는 클라우드로 마이그레이션하고 있지만, 단일 사업부의 요구사항을 충족하기 위해 수직으로 구조화된 오래된 레거시 시스템의 실질적인 문제를 해결하지는 못합니다.

조직의 데이터 요구사항을 계획할 때 하나의 일관된 데이터 소스 세트, 하나의 엔터프라이즈 데이터 웨어하우스, 하나의 시맨틱스, 하나의 비즈니스 인텔리전스용 도구로 이루어진 단순한 단일 구조를 지나치게 일반화하여 고려하기가 쉽습니다. 이는 매우 작고 고도로 중앙 집중화된 조직에서 활용할 수 있으며, 자체 통합 IT 및 데이터 엔지니어링팀이 있는 단일 사업부에도 적합할 수 있습니다. 하지만 실제로 조직은 그렇게 단순하지 않으며 데이터 수집, 처리, 사용과 관련하여 항상 문제를 더욱 복잡하게 만드는 이외의 복잡성이 존재합니다.

수백 명의 고객과 대화하면서 데이터 및 분석에 대해 보다 종합적인 접근 방식이 필요하다는 사실을 확인했습니다. 즉, 데이터 처리를 위한 중복 단계를 최대한 줄이면서 여러 사업부와 사용자 캐릭터의 요구사항을 충족할 수 있는 플랫폼이 필요합니다. 이는 새로운 아키텍처나 소프트웨어 구성요소를 구매하는 데 그치지 않습니다. 기업에서는 기술 업그레이드 외에도 전반적인 데이터 성숙도를 살펴보고 체계적인 조직 차원의 변화를 도모해야 합니다.

2024년 말까지 기업의 75%가 파일럿 단계에서 AI 운영으로 전환하여 스트리밍 데이터 및 분석 인프라가 5배 증가할 것으로 예상됩니다⁵. 사일로화된 환경에서 근무하는 데이터 과학팀과 함께 AI를 쉽게 파일럿 테스트해 볼 수 있습니다. 하지만 이러한 유용한 정보가 프로덕션 시스템에 배포되는 것을 막는 근본적인 문제는 데이터 소유권을 계속 세분화하는 조직, 아키텍처 차원의 마찰입니다. 그 결과, 조직의 비즈니스 운영에 접목되는 대부분의 유용한 정보는 설명적인 특성을 띠고 있고, 예측 분석은 리서치팀의 영역으로 밀려나게 됩니다.

데이터 작업은 한 개인이 수행하는 경우는 거의 없습니다. 조직에는 데이터 수명 주기에서 중요한 역할을 담당하는 데이터 관련 사용자가 많습니다. 이들은 데이터 거버넌스, 최신 상태, 검색 가능성, 메타데이터, 처리 일정, 쿼리 가능성 등에 대해 서로 다른 관점을 가지고 있습니다. 대부분의 경우 서로 다른 처리 단계에서 동일한 데이터 작업에 대해 서로 다른 시스템과 소프트웨어를 사용합니다.

예를 들어 머신러닝 수명 주기를 살펴보겠습니다. 데이터 엔지니어는 적절한 보안 및 개인 정보 보호 제약 조건을 적용하여 데이터 과학팀에서 최신 데이터를 사용할 수 있도록 해야 할 수 있습니다. 데이터 과학자는 데이터 엔지니어가 미리 집계한 데이터 소스를 기반으로 학습 및 테스트 데이터 세트를 만들고, 모델을 빌드 및 테스트하고, 다른 팀에 유용한 정보를 제공할 수 있습니다. ML 엔지니어는 프로덕션 시스템에 배포할 모델을 다른 데이터 처리 파이프라인을 방해하지 않는 방식으로 패키징해야 할 수 있습니다. 제품 관리자 또는 비즈니스 분석가는 Data QnA(BigQuery 데이터 분석을 위한 자연어 인터페이스) 또는 시각화 소프트웨어를 사용하여 도출된 유용한 정보를 확인할 수도 있고 IDE 또는 명령줄 인터페이스를 통해 직접 결과 세트를 쿼리할 수도 있습니다. 다양한 요구사항을 가진 수많은 사용자가 있으므로, 이들을 모두 지원할 수 있는 압축형 플랫폼을 빌드했습니다. Google Cloud는 비즈니스의 요구사항을 충족하는 도구를 통해 고객의 요구사항을 충족합니다.

데이터 분석 요구사항에 대해 고객과 대화할 때 "데이터 레이크와 데이터 웨어하우스 중 어느 것이 필요한가요?"라는 질문을 자주 듣게 됩니다. 조직 내 데이터 사용자와 사용자의 요구사항이 다양하기 때문에 이 질문은 사용 목적, 데이터 유형, 직원에 따라 답변하기 어려운 질문이 될 수 있습니다.

• 분석해야 하는 데이터 세트를 알고 있고, 구조를 명확하게 이해하고 있으며, 답을 구해야 하는 질문이 정해져 있다면 데이터 웨어하우스를 고려하고 있을 가능성이 높습니다.
• 반면에 여러 데이터 유형을 아우르는 검색 기능이 필요하고, 실행해야 할 분석 유형이 확실하지 않으며, 유용한 정보를 제시하기보다는 탐색할 기회를 찾고 있고, 이러한 환경을 효과적으로 관리하고 탐색할 수 있는 리소스가 있는 경우 데이터 레이크가 요구사항에 더 적합할 수 있습니다.

하지만 결정에는 더 많은 요소가 작용하므로 각 조직이 직면한 몇 가지 과제를 살펴보겠습니다. 데이터 웨어하우스는 관리하기 어려운 경우가 많습니다. 지난 40년 동안 효과적으로 작동해 온 레거시 시스템은 비용이 많이 들고 데이터 최신 상태, 확장, 고비용과 관련해 많은 문제를 야기하는 것으로 나타났습니다. 더욱이 사후에 AI나 실시간 기능을 제공하려면 까다로운 연결 과정을 거쳐야 합니다. 이러한 문제는 온프레미스 레거시 데이터 웨어하우스에만 있는 것이 아닙니다. 새로 생성된 클라우드 기반 데이터 웨어하우스에서도 마찬가지로 이 같은 문제를 확인할 수 있습니다. 주장과 달리 통합된 AI 기능을 제공하지 못하는 경우도 많습니다. 기본적으로 새 데이터 웨어하우스는 클라우드로 이전되긴 했으나 기존과 동일한 환경이기 때문입니다. 데이터 웨어하우스 사용자는 보통 특정 사업부에 소속된 분석가인 경우가 많습니다. 이들은 비즈니스에 대한 이해를 높이는 데 유용한 추가 데이터 세트에 대한 아이디어가 있을 수 있습니다. 또한 분석, 데이터 처리, 비즈니스 인텔리전스 기능 요구사항의 개선을 위한 아이디어가 있을 수도 있습니다.

그러나 기존 조직에서는 데이터 소유자와 직접 소통할 수 없으며 데이터 세트와 도구를 결정하는 기술 의사 결정권자에게 쉽게 영향을 미칠 수 없는 경우가 많습니다. 또한 원시 데이터와 별개로 유지되기 때문에 가설을 검증하거나 기본 데이터를 더 깊이 이해할 수 없습니다. 데이터 레이크에도 고유한 문제가 있습니다. 이론적으로는 비용이 저렴하고 쉽게 확장할 수 있지만, 많은 고객이 온프레미스 데이터 레이크에서 다른 현실을 경험했습니다. 특히 매우 다양한 양의 데이터를 생성하는 조직의 경우 충분한 스토리지를 계획하고 프로비저닝하는 데 비용이 많이 들고 어려울 수 있습니다. 온프레미스 데이터 레이크는 불안정할 수 있으며 기존 시스템을 유지보수하는 데는 시간이 오래 걸립니다. 많은 경우 새로운 기능을 개발해야 하는 엔지니어가 데이터 클러스터의 관리 및 제공에 전념하게 됩니다. 즉, 새로운 가치를 창출하기보다는 가치를 유지하는 일을 하고 있다고 할 수 있습니다. 전반적으로 많은 기업에서 총 소유 비용이 예상보다 높습니다. 뿐만 아니라, 특히 조직 내 여러 부서에서 서로 다른 보안 모델을 사용하는 경우에는 시스템 전반에서 거버넌스 문제가 쉽게 해결되지 않습니다. 그 결과 데이터 레이크가 사일로화되고 세분화되어 팀 간에 데이터와 모델을 공유하기가 어려워집니다.

데이터 레이크 사용자는 일반적으로 원시 데이터 소스에 더 가깝고 데이터를 탐색할 수 있는 도구와 기능을 갖추고 있습니다. 기존 조직에서 이러한 사용자는 데이터 자체에 집중하는 경향이 있으며 나머지 사업부와는 어느 정도 거리를 두는 경우가 많습니다. 이러한 단절은 사업부에서 매출 증대, 비용 절감, 위험 감소, 새로운 기회라는 비즈니스 목표를 추진할 수 있는 유용한 정보를 찾을 기회를 놓친다는 것을 의미합니다. 이러한 장단점을 감안하여 많은 기업에서는 결국 데이터 레이크를 설정하여 일부 데이터를 데이터 웨어하우스로 전환하거나 데이터 웨어하우스에 추가 테스트 및 분석을 위한 사이드 데이터 레이크를 제공하는 하이브리드 접근 방식을 채택합니다. 하지만 여러 팀에서 각각의 요구사항에 맞게 자체적으로 데이터 아키텍처를 제작하고 있기 때문에 중앙 IT 팀의 데이터 공유와 충실도 관리가 더욱 복잡해집니다. 서로 다른 목표를 가진 별도의 팀, 즉 비즈니스를 탐색하는 팀과 비즈니스를 이해하는 팀을 두는 대신, 이러한 기능과 데이터 시스템을 통합하면 비즈니스에 대한 심층적인 이해가 직접적인 탐색을 유도하고 이러한 탐색이 비즈니스에 대한 이해를 더욱 높이는 선순환 구조를 형성할 수 있습니다.

Google Cloud에서 데이터 웨어하우스 또는 데이터 레이크를 개별적으로 빌드할 수 있지만 둘 중 하나를 선택할 필요는 없습니다. 대부분의 경우 고객이 사용하는 기본 제품은 두 가지 모두에 동일하며, 데이터 레이크와 데이터 웨어하우스 구현의 유일한 차이점은 적용된 데이터 액세스 정책입니다. 실제로 이 두 용어는 보다 통합된 기능인 최신 분석 데이터 플랫폼으로 통합되기 시작했습니다. Google Cloud에서 어떻게 작동하는지 살펴보겠습니다.

BigQuery Storage API는 Dataflow 및 Dataproc과 같은 다른 여러 시스템에서 Cloud Storage와 같은 BigQuery Storage를 사용할 수 있는 기능을 제공합니다. 이를 통해 데이터 웨어하우스 스토리지의 경계 해소하고 BigQuery에서 고성능 데이터 프레임을 실행할 수 있습니다. 즉, BigQuery Storage API를 사용하면 BigQuery 데이터 웨어하우스가 데이터 레이크처럼 작동할 수 있습니다. 그렇다면 실제 사용 사례에는 어떤 것이 있을까요? 그중 하나로 일련의 커넥터(예: 맵리듀스, Hive, Spark)를 빌드하여 BigQuery의 데이터에서 직접 Hadoop 및 Spark 워크로드를 실행할 수 있도록 했습니다. 따라서 데이터 웨어하우스 외에 데이터 레이크도 더 이상 필요하지 않습니다. Dataflow는 일괄 처리와 스트림 처리에 매우 강력합니다. 이제는 BigQuery 데이터를 기반으로 Dataflow 작업을 실행하여 Pub/Sub, Spanner 또는 기타 데이터 소스의 데이터로 보강할 수 있습니다.

BigQuery는 스토리지와 컴퓨팅을 모두 독립적으로 확장할 수 있으며 각각 서버리스이므로 다양한 팀, 도구, 액세스 패턴의 사용량에 관계없이 수요에 맞게 무제한 확장이 가능합니다. 동시에 BigQuery에 액세스하는 다른 작업의 성능에 영향을 주지 않으면서 앞서 언급한 모든 애플리케이션을 실행할 수 있습니다. 이 외에도 BigQuery Storage API는 노드 간에 데이터를 이동하여 쿼리 요청을 효율적으로 처리하여 인메모리 작업과 유사한 성능을 실현하는 페타비트 수준의 네트워크를 제공합니다. 또한 NoSQL 및 OLTP 데이터베이스뿐만 아니라 Parquet 및 ORC와 같은 널리 사용되고 있는 Hadoop 데이터 형식과도 직접 페더레이션할 수 있습니다. BigQuery에 내장된 Dataflow SQL이 제공하는 기능으로 한 단계 더 나아갈 수 있습니다. 이 기능을 통해 스트림을 파일에 상주하는 BigQuery 테이블 또는 데이터와 조인하여 람다 아키텍처를 효과적으로 생성할 수 있으므로, 대량의 일괄 및 스트리밍 데이터를 수집하는 동시에 쿼리에 응답할 수 있는 서빙 레이어를 제공할 수 있습니다. BigQuery BI Engine과 구체화된 뷰를 사용하면 이 다회성 아키텍처에서 효율성과 성능을 훨씬 더 쉽게 높일 수 있습니다.

조직에서 데이터 사일로를 넘어 유용한 정보를 얻고 작업을 수행할 수 있는 영역으로 나아가려면 서버리스 데이터 솔루션이 절대적으로 필요합니다. Google의 핵심 데이터 분석 서비스는 모두 서버리스이며 긴밀하게 통합되어 있습니다.

변경 관리는 새로운 기술을 조직에 통합하는 데 있어 가장 어려운 부분 중 하나입니다. Google Cloud는 개발자와 비즈니스 사용자 모두에게 익숙한 도구, 플랫폼, 통합 기능을 제공하여 고객이 현재 어떤 상황에 있든 고객의 요구사항을 충족하고자 합니다. Google Cloud의 사명은 조직에서 데이터에 기반한 혁신을 통해 신속하게 비즈니스를 디지털 방식으로 혁신하고 재편할 수 있도록 지원하는 것입니다. Google Cloud는 진정한 하이브리드 클라우드를 구현하기 위해 공급업체 종속을 야기하지 않고 온프레미스 환경과 간소화된 방식으로 간단하고 통합할 수 있는 옵션과 기타 클라우드 제품 및 서비스, 심지어 에지를 제공합니다.

• BigQuery Omni는 한 환경에서 다른 환경으로 데이터를 포팅할 필요가 없으며 대신 환경에 관계없이 데이터에 대한 분석을 수행합니다.
• Dataflow에 활용되는 SDK인 Apache Beam은 Apache Spark 및 Apache Flink와 같은 실행기에 전송 가능성과 이동성을 제공합니다.
• Apache Spark 또는 Apache Hadoop을 실행하려는 조직을 위해 Google Cloud는 Dataproc를 제공합니다.

대부분의 데이터 사용자는 데이터가 어떤 시스템에 있는지가 아니라 어떤 데이터를 보유하고 있는지에 관심이 있습니다. 필요할 때 필요한 데이터에 액세스할 수 있는 것이 가장 중요합니다. 따라서 대부분의 경우 사용자가 데이터 세트를 탐색하든, 데이터 스토어에서 소스를 관리하든, 임시 쿼리를 실행하든, 핵심 이해관계자를 위한 내부 비즈니스 인텔리전스 도구를 개발하든 익숙한 도구로 사용 가능한 최신 데이터에 액세스할 수 있다면 플랫폼 유형은 사용자에게 문제가 되지 않습니다.

데이터 레이크와 데이터 웨어하우스를 통합 분석 데이터 플랫폼으로 통합한다는 이 개념에 이어 몇 가지 추가 데이터 솔루션이 주목을 받고 있습니다. 일례로 레이크하우스와 데이터 메시에 대한 많은 개념이 새롭게 등장하고 있습니다. 이러한 용어 중 일부에 대해서는 들어보셨을 것입니다. 일부 용어는 새로운 것이 아니며 수년 동안 다양한 형태와 형식으로 존재해 왔습니다. 하지만 Google Cloud 환경에서 매우 원활하게 작동합니다. 데이터 메시와 레이크하우스가 Google Cloud에서 어떻게 나타나는지 그리고 조직 내 데이터 공유에 어떤 영향을 미치는지 자세히 살펴보겠습니다. 레이크하우스와 데이터 메시는 상호 배타적이지 않지만 조직 내의 서로 다른 과제를 해결하는 데 도움이 됩니다. 둘 중 하나는 데이터를 사용 설정하는 데 유리하고 다른 하나는 팀을 지원하는 데 유리합니다. 데이터 메시는 한 팀에 의해 병목 현상이 발생하지 않도록 하여 전체 데이터 스택을 가능하게 합니다. 이는 제휴 방식으로 데이터에 액세스할 수 있는 아키텍처에서 사일로를 소규모 조직 단위로 나눕니다. 레이크하우스는 데이터 웨어하우스와 데이터 레이크를 함께 사용하여 다양한 유형과 더 많은 볼륨의 데이터를 지원합니다. 이를 통해 엔터프라이즈 데이터 웨어하우스의 성능 격차를 일부 해소하는 것으로 여겨지던 데이터 레이크의 기능인 쓰기 시 스키마(Schema-on-write) 대신 읽기 시 스키마(Schema-on-read)가 효과적으로 구현됩니다. 이 아키텍처는 데이터 레이크에는 일반적으로 없는 더 엄격한 데이터 거버넌스를 구현하는 추가적인 이점이 있습니다.

위에서 언급한 바와 같이 BigQuery의 Storage API를 사용하면 데이터 웨어하우스를 데이터 레이크처럼 취급할 수 있습니다. Dataproc 또는 유사한 Hadoop 환경에서 실행되는 Spark 작업은 데이터 웨어하우스에서 스토리지를 만들어 별도의 스토리지 매체 없이 BigQuery에 저장된 데이터를 사용할 수 있습니다. BigQuery 내의 스토리지와 분리된 강력한 컴퓨팅 성능은 SQL 기반 변환을 지원하고 이러한 변환의 다양한 레이어 전반에서 뷰를 활용합니다. 이는 ELT 유형의 접근 방식으로 이어지고 더 민첩한 데이터 처리 플랫폼을 가능하게 합니다. BigQuery에서는 ETL보다 ELT를 활용하여 SQL 기반 변환을 논리적 뷰로 저장할 수 있습니다. 기존 데이터 웨어하우스를 사용하면 모든 원시 데이터를 데이터 웨어하우스 스토리지에 덤프하는 데 많은 비용이 들 수 있지만 BigQuery 스토리지에는 프리미엄 요금이 부과되지 않습니다. 비용은 Google Cloud Storage의 blob 스토리지와 상당히 비슷합니다.

ETL을 수행할 때 변환은 BigQuery 외부에서, 잠재적으로 확장성이 좋지 않은 도구에서 이루어질 가능성이 있습니다. 쿼리를 병렬화하지 않고 데이터를 한 줄씩 변환하게 될 수도 있습니다. Spark 또는 다른 ETL 프로세스가 이미 코드화되어 있어서 새로운 기술을 위해 이를 변경하는 것이 적절하지 않은 경우도 있을 수 있습니다. 그러나 SQL로 작성할 수 있는 변환이 있는 경우 BigQuery에서 변환을 수행하는 것이 좋습니다.

또한 이 아키텍처는 Composer, Data Catalog, Data Fusion과 같은 모든 Google Cloud 구성요소에서 지원됩니다. 다양한 사용자 캐릭터를 위한 엔드 투 엔드 레이어를 제공합니다. 운영 오버헤드를 줄이는 데 있어 또 다른 중요한 측면은 기본 인프라의 기능을 활용하는 것입니다. 모두 컨테이너에서 실행되는 Dataflow와 BigQuery를 고려해 보세요. 여기서 업타임과 메커니즘은 백그라운드에서 관리됩니다. 서드 파티 도구 및 파트너 도구로 확장되고 Kubernetes와 같은 유사한 기능을 탐색하기 시작하면 관리와 이동이 훨씬 더 간단해집니다. 결과적으로 리소스 및 운영 오버헤드가 감소합니다. 또한 Cloud Composer로 모니터링 대시보드를 활용하여 운영 우수성을 이끌어냄으로써 관측 가능성을 개선하여 이를 보완할 수 있습니다. 데이터 이동이나 중복 없이 Cloud Storage와 BigQuery에 저장된 데이터를 통합하여 데이터 레이크를 빌드할 수 있을 뿐만 아니라 데이터 소스를 관리할 수 있는 추가 관리 기능도 제공합니다. Dataplex는 Cloud Storage 및 BigQuery에서 데이터를 조정하는 중앙 집중식 관리 레이어를 제공하여 레이크하우스를 지원합니다. 이렇게 하면 비즈니스 요구사항에 따라 데이터를 구성할 수 있으므로 더 이상 데이터가 저장되는 방식이나 위치에 제한을 받지 않습니다.

Dataplex는 데이터를 적절한 가격 대비 성능으로 분산하고 모든 분석 도구에서 안전하게 액세스할 수 있도록 지원하는 지능형 데이터 패브릭입니다. 데이터 품질 및 거버넌스가 기본 제공되는 메타데이터 주도의 데이터 관리 기능을 제공하므로 인프라 경계와 비효율성 문제를 해결하는 데 드는 시간을 줄이고, 보유한 데이터를 신뢰하며, 이 데이터에서 가치를 창출하는 데 더 많은 시간을 할애할 수 있습니다. 또한 Google Cloud와 오픈소스의 장점을 결합한 통합 분석 환경을 제공하므로 대규모 데이터를 신속하게 선별, 보호, 통합, 분석할 수 있습니다. 마지막으로, 기존 아키텍처를 개선하고 재무 관리 목표를 충족하는 분석 전략을 수립할 수 있습니다.

데이터 메시는 데이터 웨어하우스와 데이터 레이크를 아우르는 오랜 혁신의 역사를 바탕으로 구축된 것으로, 탁월한 확장성과 성능, 지불 모델, API, DevOps가 결합되어 있고 Google Cloud 제품이 긴밀하게 통합되어 있습니다. 이 접근 방식을 사용하면 주문형 데이터 솔루션을 효과적으로 만들 수 있습니다. 데이터 메시는 도메인 데이터 소유자 간에 데이터 소유권을 분산합니다. 도메인 데이터 소유자는 각자 표준 방식으로 데이터를 제품으로 제공할 책임이 있습니다. 또한 데이터 메시는 조직의 여러 부서 간에 서로 다른 위치에 분산된 데이터 세트에 대한 커뮤니케이션을 지원합니다. 데이터 메시에서는 데이터에서 가치를 창출해야 할 책임이 데이터를 가장 잘 이해하는 사람들에게 집중됩니다. 즉, 데이터를 생성했거나 데이터를 조직에 가져온 사람들은 사용 가능한 데이터 애셋을 자신이 생성한 데이터의 제품으로 만드는 책임도 져야 합니다. 많은 조직에서는 새로 생성된 데이터에 대한 명확한 소유권 책임 없이 조직 전체에서 데이터를 반복적으로 추출하고 변환하기 때문에 '단일 정보 소스' 또는 '신뢰할 수 있는 데이터 소스'를 구축하기가 어렵습니다. 데이터 메시에서 신뢰할 수 있는 데이터 소스는 소스 도메인에서 게시한 데이터 제품으로, 데이터 소유자와 해당 데이터를 책임지는 스튜어드가 명확하게 할당되어 있습니다.

요약하면 데이터 메시는 도메인 중심의 분산된 데이터 소유권과 아키텍처를 보장합니다. 이는 Google Cloud에 제공하는 것과 마찬가지로 제휴 계산을 사용하고 레이어에 액세스함으로써 가능해집니다. 또한 조직에서 더 많은 기능을 사용하려는 경우 데이터에 대한 모델에 통합 레이어를 제공하고 데이터에 액세스할 수 있는 Looker와 같은 제품을 사용하면 됩니다. Looker 플랫폼은 단일 창 UI를 통해 가장 최신 버전의 회사 데이터와 비즈니스 정의에 액세스할 수 있습니다. 비즈니스에 대한 이 통합 뷰를 사용하면 사용자와 시스템이 니즈에 가장 적합한 방식으로 데이터를 제공하도록 보장하는 데이터 환경을 선택하거나 설계할 수 있습니다. 데이터 과학자, 분석가, 심지어 비즈니스 사용자도 단일 시맨틱 모델로 데이터에 액세스할 수 있으므로 매우 적합합니다. 데이터 과학자는 계속 원시 데이터에 액세스하지만 데이터가 이동하고 중복되지 않습니다.

Google은 데이터 세트를 더 쉽게 만들고 관리할 수 있도록 BigQuery와 같은 주요 제품을 기반으로 추가 기능을 구축하고 있습니다. Analytics Hub는 비공개 데이터 교환을 만들 수 있는 기능을 제공하며, 교환 관리자(일명 데이터 큐레이터)는 회사 내부 및 외부 비즈니스 파트너 또는 구매자의 특정 개인 또는 그룹을 대상으로 교환의 데이터를 게시하고 구독할 권한을 부여합니다.

BigQuery의 확장성을 기반으로 하는 오픈소스 형식을 비롯한 공유 애셋을 게시, 검색, 구독하세요. 게시자는 집계된 사용량 측정항목을 볼 수 있습니다. 데이터 제공업체는 데이터, 통계, ML 모델 또는 시각화를 통해 엔터프라이즈 BigQuery 고객에게 도달하고 Cloud Marketplace를 활용하여 앱, 통계 또는 모델을 통해 수익을 창출할 수 있습니다. 이는 Google 관리형 거래소를 통해 BigQuery 공개 데이터 세트를 관리하는 방식과도 비슷합니다. 고유한 Google 데이터 세트, 상용/산업 데이터 세트, 공개 데이터 세트, 조직 또는 파트너 생태계의 선별된 데이터 교환에 액세스하여 혁신을 주도하세요.

완전히 새로운 데이터 플랫폼을 처음부터 빌드하는 것이 바람직하지만 Google은 모든 회사가 이렇게 할 수 없다는 점을 알고 있습니다. 대부분은 교체할 수 있을 때까지 마이그레이션, 포팅 또는 패치해야 하는 기존 레거시 시스템을 다루고 있습니다. Google은 데이터 플랫폼 여정의 모든 단계에서 고객과 협력하고 있으며 고객의 상황에 맞는 솔루션을 갖추고 있습니다.

일반적으로 고객들은 리프트 및 리플랫폼, 리프트 및 리홈, 완전 현대화라는 세 가지 마이그레이션 카테고리 중 하나를 수행합니다. 대부분의 비즈니스는 리프트 및 리플랫폼부터 시작하는 것이 좋습니다. 중단과 위험을 최소화하면서 영향력이 큰 마이그레이션을 제공하기 때문입니다. 이 전략을 사용하면 기존 데이터 웨어하우스와 Hadoop 클러스터에서 BigQuery 또는 Dataproc으로 데이터를 마이그레이션합니다. 데이터가 이전된 후 성능 향상을 위해 데이터 파이프라인과 쿼리를 최적화할 수 있습니다. 리프트 및 리플랫폼 마이그레이션 전략을 사용하면 워크로드의 복잡성에 따라 단계별로 이 작업을 수행할 수 있습니다. 복잡성을 고려할 때 중앙 집중식 IT와 여러 사업부가 있는 대기업 고객은 이 방식을 사용하는 것이 좋습니다.

두 번째로 가장 많이 사용되는 마이그레이션 전략은 첫 번째 단계로 완전 현대화를 적용하는 것입니다. 클라우드 기반 접근 방식으로 완전히 전환하게 되므로 기존 시스템에서 완전히 벗어날 수 있습니다. Google Cloud를 기반으로 빌드되지만 모든 것을 한 번에 변경하므로 여러 개의 대규모 기존 환경이 있는 경우 마이그레이션 속도가 느려질 수 있습니다. 

기존 시스템에서 완전히 연결 해제하려면 작업을 다시 작성하고 다른 애플리케이션을 변경해야 합니다. 그러나 이 방식은 다른 방식에 비해 장기적으로는 더 빠른 속도와 민첩성을 제공하며 총소유비용이 가장 낮습니다. 이는 애플리케이션이 이미 최적화되어 있어 재구성할 필요가 없고 데이터 소스를 마이그레이션하면 동시에 두 환경을 관리할 필요가 없다는 2가지 주요 이유 때문입니다. 이 접근 방식은 기존 환경이 거의 없는 디지털 기반 또는 엔지니어링 중심의 조직에 가장 적합합니다.

마지막으로, 가장 보수적인 접근 방식은 리프트 및 리홈이며, 데이터 자산을 클라우드로 이전하기 위한 단기 전술적 솔루션으로 권장됩니다. 기존 플랫폼을 리프트 앤 리홈 방식으로 이전한 다음 이전처럼 Google Cloud 환경에서 계속 사용할 수 있습니다. 이는 초기 위험을 줄이고 애플리케이션 실행을 허용하도록 Teradata 및 Databricks와 같은 환경에 적용할 수 있습니다. 하지만 이렇게 하면 기존의 사일로화된 환경을 변환하지 않고 클라우드로 가져오므로 Google Cloud를 기반으로 빌드된 플랫폼의 성능 이점을 누릴 수 없습니다. 그러나 Google은 사용자가 상호 운용성을 활용하고 Google Cloud에서 완전 최신 분석 데이터 플랫폼을 만들 수 있도록 Google Cloud 기반 제품으로 완전히 마이그레이션하는 데 도움을 드릴 수 있습니다.

Google Cloud를 기반으로 하는 분석 데이터 플랫폼의 주요 차별점은 개방적이고 지능적이며 유연하고 긴밀하게 통합된다는 점입니다. 시중에는 편안하고 익숙한 전술적 솔루션을 제공하는 솔루션이 많이 있습니다. 그러나 이러한 솔루션은 일반적으로 단기적인 해결책이며 시간이 지남에 따라 복합적인 구성과 기술적인 문제를 제공합니다.

Google Cloud는 데이터 분석을 크게 간소화합니다. 컴퓨팅에서 스토리지를 분리하고 기가바이트에서 페타바이트에 이르는 데이터를 몇 분 만에 분석할 수 있게 해주는 클라우드 기반 서버리스 접근 방식으로 데이터에 숨겨진 잠재력을 활용할 수 있습니다. 이를 통해 확장성, 성능, 비용이라는 기존의 제약 조건을 없애 데이터 질문에 답하고 비즈니스 문제를 해결할 수 있습니다. 그 결과 신뢰할 수 있는 단일 데이터 패브릭으로 기업 전체에서 유용한 정보를 보다 쉽게 운영할 수 있게 되었습니다. 

이점

• 인프라가 아닌 분석에 집중할 수 있습니다.
• 수집에서 변환 및 분석, 비즈니스 인텔리전스 등에 이르기까지 데이터 애널리틱스 수명 주기의 모든 단계를 해결합니다.
• 머신러닝 운영을 위한 견고한 데이터 기반을 구축합니다.
• 조직에 가장 적합한 오픈소스 기술을 활용할 수 있습니다.
• 특히 비즈니스 운영 및 디지털 혁신에 데이터 사용이 증가하는 경우 기업의 니즈를 충족하도록 확장 가능합니다.

Google Cloud를 기반으로 하는 최신 통합 분석 데이터 플랫폼은 데이터 레이크와 데이터 웨어하우스의 최고의 기능을 제공하면서도 AI 플랫폼과의 긴밀한 통합을 제공합니다. 스트리밍 이벤트 수십억 개에서 실시간 데이터를 자동으로 처리하고 최대 밀리초 단위로 유용한 정보를 제공하여 변화하는 고객 니즈에 대응할 수 있습니다. 업계 최고의 AI 서비스를 사용하면 조직의 의사 결정과 고객 경험을 최적화할 수 있으므로 새로운 팀을 충원할 필요 없이 기술적 분석과 처방적 분석 사이의 격차를 줄일 수 있습니다. 기본 제공되는 자동화된 인텔리전스로 기존 기술을 강화하여 AI의 영향력을 확대할 수 있습니다.