Google의 BigQuery가 데이터 분석을 민주화한 방법 1 부

안녕 하브르! 지금 OTUS에서 새로운 강좌 스트림 등록이 진행 중입니다. 데이터 엔지니어. 코스 시작을 예상하여 우리는 전통적으로 여러분을 위해 흥미로운 자료의 번역을 준비했습니다.

매일 XNUMX억 명이 넘는 사람들이 Twitter를 방문하여 세상에서 무슨 일이 일어나고 있는지 알아보고 이에 대해 토론합니다. 각 트윗과 기타 사용자 작업은 Twitter 내에서 내부 데이터 분석에 사용할 수 있는 이벤트를 생성합니다. 수백 명의 직원이 이 데이터를 분석하고 시각화하며, 이들의 경험을 개선하는 것이 트위터 데이터 플랫폼 팀의 최우선 과제입니다.

우리는 광범위한 기술적 능력을 갖춘 사용자가 데이터를 찾을 수 있고 제대로 작동하는 SQL 기반 분석 및 시각화 도구에 액세스할 수 있어야 한다고 믿습니다. 이를 통해 데이터 분석가 및 제품 관리자를 포함하여 기술이 부족한 완전히 새로운 사용자 그룹이 데이터에서 통찰력을 추출하여 Twitter의 기능을 더 잘 이해하고 사용할 수 있습니다. 이것이 우리가 트위터에서 데이터 분석을 민주화하는 방법입니다.

내부 데이터 분석을 위한 도구와 기능이 향상됨에 따라 Twitter 서비스도 개선되었습니다. 그러나 여전히 개선의 여지가 있습니다. Scalding과 같은 현재 도구에는 프로그래밍 경험이 필요합니다. Presto 및 Vertica와 같은 SQL 기반 분석 도구에는 대규모 성능 문제가 있습니다. 또한 데이터에 지속적으로 액세스하지 않고 여러 시스템에 데이터를 배포하는 데 문제가 있습니다.

작년에 우리는 발표했습니다. Google과의 새로운 협업, 그 안에서 우리는 우리의 일부를 전송합니다 데이터 인프라 구글 클라우드 플랫폼(GCP)에서. 우리는 Google Cloud 도구가 빅 데이터 Twitter에서 분석, 시각화 및 기계 학습을 민주화하려는 우리의 이니셔티브에 도움이 될 수 있습니다.

• BigQuery: SQL 엔진 기반의 기업 데이터 웨어하우스 드레 멜, 속도, 단순성 및 대처 능력으로 유명합니다. 기계 학습.
• 데이터 스튜디오: Google Docs와 같은 공동작업 기능을 갖춘 빅데이터 시각화 도구입니다.

이 기사에서는 이러한 도구에 대한 우리의 경험, 즉 우리가 수행한 작업, 배운 작업, 다음에 수행할 작업에 대해 알아봅니다. 이제 일괄 및 대화형 분석에 중점을 둘 것입니다. 실시간 분석은 다음 글에서 다루겠습니다.

트위터의 데이터 웨어하우스의 역사

BigQuery에 대해 알아보기 전에 Twitter에서 데이터 웨어하우스의 역사를 간략하게 다시 설명하는 것이 좋습니다. 2011년에는 Vertica와 Hadoop에서 Twitter 데이터 분석이 수행되었습니다. MapReduce Hadoop 작업을 생성하기 위해 Pig를 사용했습니다. 2012년에 우리는 복잡한 파이프라인을 생성하는 기능과 테스트 용이성 등의 이점을 갖춘 Scala API를 갖춘 Scalding으로 Pig를 대체했습니다. 그러나 SQL 작업에 더 익숙한 많은 데이터 분석가와 제품 관리자에게는 상당히 가파른 학습 곡선이었습니다. 2016년경에 우리는 Presto를 Hadoop 데이터용 SQL 프런트 엔드로 사용하기 시작했습니다. Spark는 임시 데이터 과학 및 기계 학습에 적합한 Python 인터페이스를 제공했습니다.

2018년부터 우리는 데이터 분석 및 시각화를 위해 다음 도구를 사용해 왔습니다.

• 생산라인의 탕화
• 임시 데이터 분석 및 기계 학습을 위한 Scalding 및 Spark
• 임시 및 대화형 SQL 분석을 위한 Vertica 및 Presto
• 시계열 지표에 대한 낮은 대화형, 탐색적, 짧은 대기 시간 액세스를 위한 Druid
• 데이터 시각화를 위한 Tableau, Zeppelin 및 Pivot

우리는 이러한 도구가 매우 강력한 기능을 제공하지만 이러한 기능을 트위터의 더 많은 청중에게 제공하는 데 어려움이 있다는 것을 발견했습니다. Google Cloud로 플랫폼을 확장함으로써 트위터 전체에 대한 분석 도구를 단순화하는 데 중점을 두고 있습니다.

Google의 BigQuery 데이터 웨어하우스

Twitter의 여러 팀은 이미 일부 프로덕션 파이프라인에 BigQuery를 포함했습니다. 그들의 경험을 바탕으로 우리는 모든 Twitter 사용 사례에 대한 BigQuery의 가능성을 평가하기 시작했습니다. 우리의 목표는 BigQuery를 회사 전체에 제공하고 이를 데이터 플랫폼 툴킷 내에서 표준화하고 지원하는 것이었습니다. 이것은 여러 가지 이유로 어려웠습니다. 우리는 대용량 데이터를 안정적으로 수신하고, 전사적 데이터 관리를 지원하고, 적절한 액세스 제어를 보장하고, 고객 개인정보 보호를 보장할 수 있는 인프라를 개발해야 했습니다. 또한 팀이 BigQuery를 효과적으로 사용할 수 있도록 리소스 할당, 모니터링, 지불 거절을 위한 시스템을 만들어야 했습니다.

2018년 250월에 우리는 BigQuery 및 데이터 스튜디오의 전사적 알파 릴리스를 출시했습니다. 우리는 개인 데이터를 정리한 가장 일반적으로 사용되는 스프레드시트 중 일부를 Twitter 직원에게 제공했습니다. BigQuery는 엔지니어링, 재무, 마케팅 등 다양한 팀의 8명 이상의 사용자가 사용했습니다. 가장 최근에는 예약된 요청을 제외하고 약 100개의 요청을 실행하여 매월 약 XNUMXPB를 처리했습니다. 매우 긍정적인 피드백을 받은 후 우리는 앞으로 나아가 BigQuery를 Twitter에서 데이터와 상호작용하기 위한 기본 리소스로 제공하기로 결정했습니다.

다음은 Google BigQuery 데이터 웨어하우스의 상위 수준 아키텍처에 대한 다이어그램입니다.

내부 Cloud Replicator 도구를 사용하여 온프레미스 Hadoop 클러스터에서 Google Cloud Storage(GCS)로 데이터를 복사합니다. 그런 다음 Apache Airflow를 사용하여 "bq_load» GCS의 데이터를 BigQuery로 로드합니다. Presto를 사용하여 GCS에서 Parquet 또는 Thrift-LZO 데이터 세트를 쿼리합니다. BQ Blaster는 HDFS Vertica 및 Thrift-LZO 데이터세트를 BigQuery에 로드하기 위한 내부 Scalding 도구입니다.

다음 섹션에서는 사용 편의성, 성능, 데이터 관리, 시스템 상태 및 비용에 대한 접근 방식과 전문 지식에 대해 논의합니다.

사용 편의성

소프트웨어를 설치할 필요가 없고 직관적인 웹 인터페이스를 통해 BigQuery에 액세스할 수 있으므로 사용자가 BigQuery를 쉽게 시작할 수 있다는 것을 알게 되었습니다. 그러나 사용자는 프로젝트, 데이터세트, 테이블과 같은 리소스를 포함하여 일부 GCP 기능과 개념에 익숙해져야 했습니다. 우리는 사용자가 시작하는 데 도움이 되는 튜토리얼과 튜토리얼을 개발했습니다. 기본 사항을 이해하면 사용자는 쉽게 데이터 세트를 탐색하고, 스키마와 테이블 데이터를 보고, 간단한 쿼리를 실행하고, 데이터 스튜디오에서 결과를 시각화할 수 있습니다.

BigQuery의 데이터 입력에 대한 우리의 목표는 한 번의 클릭으로 HDFS 또는 GCS 데이터세트를 원활하게 로드하는 것이었습니다. 우리는 고려했다 클라우드 컴포저 (Airflow에서 관리) 그러나 "도메인 제한 공유" 보안 모델로 인해 사용할 수 없었습니다(자세한 내용은 아래 데이터 관리 섹션 참조). 우리는 BigQuery 로드 작업을 구성하기 위해 Google Data Transfer Service(DTS)를 사용해 실험했습니다. DTS는 설정이 빠르지만 종속성이 있는 파이프라인을 구축하는 데에는 유연성이 없었습니다. 알파 릴리스의 경우 GCE에서 자체 Apache Airflow 환경을 생성했으며 이를 프로덕션 및 Vertica와 같은 더 많은 데이터 소스를 지원할 수 있는 기능을 준비하고 있습니다.

데이터를 BigQuery로 변환하기 위해 사용자는 예약된 쿼리를 사용하여 간단한 SQL 데이터 파이프라인을 만듭니다. 종속성이 있는 복잡한 다단계 파이프라인의 경우 자체 Airflow 프레임워크 또는 Cloud Composer를 사용할 계획입니다. 클라우드 데이터 흐름.

Производительность

BigQuery는 대량의 데이터를 처리하는 범용 SQL 쿼리를 위해 설계되었습니다. 트랜잭션 데이터베이스에 필요한 낮은 대기 시간, 높은 처리량 쿼리 또는 다음에서 구현되는 낮은 대기 시간 시계열 분석을 위한 것이 아닙니다. 아파치 드루이드. 대화형 분석 쿼리의 경우 사용자는 XNUMX분 미만의 응답 시간을 기대합니다. 우리는 이러한 기대를 충족하기 위해 BigQuery 사용을 설계해야 했습니다. 사용자에게 예측 가능한 성능을 제공하기 위해 우리는 고정 요금으로 고객에게 제공되는 BigQuery 기능을 사용했습니다. 이를 통해 프로젝트 소유자는 쿼리에 대해 최소 슬롯을 예약할 수 있습니다. 슬롯 BigQuery는 SQL 쿼리를 실행하는 데 필요한 컴퓨팅 성능 단위입니다.

각각 약 800TB의 데이터를 처리하는 1개 이상의 쿼리를 분석한 결과 평균 실행 시간은 30초인 것으로 나타났습니다. 우리는 또한 다양한 프로젝트와 작업에서 슬롯을 사용하는 데 성능이 크게 좌우된다는 것을 배웠습니다. 우리는 프로덕션 사용 사례 및 대화형 분석에 대한 성능을 유지하기 위해 프로덕션 및 임시 슬롯 예약을 명확하게 분리해야 했습니다. 이는 슬롯 예약 및 프로젝트 계층 구조 설계에 큰 영향을 미쳤습니다.

우리는 번역의 두 번째 부분에서 앞으로 며칠 동안 데이터 관리, 기능 및 시스템 비용에 대해 이야기할 것이며 이제 모든 사람을 초대합니다. 무료 라이브 웹 세미나에서 과정에 대해 자세히 알아보고 전문가인 Egor Mateshuk(MaximaTelecom 수석 데이터 엔지니어)에게 질문할 수 있습니다.

더 읽어보기:

• 데이터 구축 도구 또는 데이터 웨어하우스와 스무디의 공통점
• Delta Lake 자세히 알아보기: 스키마 적용 및 진화
• Apache Arrow를 사용하는 Python의 고속 Apache Parquet

출처 : habr.com