요잔에서 드루이드의 연습

Druid는 MetaMarket Company가 개발한 데이터 저장 및 분석 시스템으로, 대용량 데이터 세트에 대한 고성능 OLAP(OnLine Analysis Processing)을 위해 특별히 설계되었습니다. 기반. Druid의 주요 기능:

Druid의 공통 응용 분야:

SaaS 회사인 Youzan은 많은 비즈니스 시나리오와 매우 많은 양의 실시간 데이터 및 오프라인 데이터를 보유하고 있습니다. Druid를 사용하기 전에 개발 학생들은 SparkStreaming 또는 Storm을 사용하여 일부 OLAP 시나리오에 대한 시나리오 분석을 수행했습니다. 이러한 유형의 솔루션을 사용하려면 실시간 작업을 작성하는 것뿐만 아니라 쿼리를 위한 스토리지를 신중하게 설계해야 합니다. 문제는 개발 주기가 길고, 초기 스토리지 설계가 반복적인 개발 요구 사항을 충족하기 어렵다는 것입니다.

Druid를 사용한 후 개발자는 위에서 설명한 Druid 기능에서 데이터 수집 구성을 작성하고 차원과 표시기를 지정하기만 하면 됩니다. 우리는 Druid가 SQL을 지원한다는 것을 알고 있습니다. 일반 JDBC를 사용하는 것과 같습니다. Youzan이 자체 개발한 OLAP 플랫폼 덕분에 데이터 수집 구성이 더욱 간편해지고 편리해졌습니다. 실시간 작업을 생성하는 데 약 10분밖에 걸리지 않아 개발 효율성이 크게 향상되었습니다.

Druid의 아키텍처는 Lambda 아키텍처로 실시간 레이어(Overlord, MiddleManager)와 배치 레이어(Broker, Historical)로 구분됩니다. 주요 노드에는 다음이 포함됩니다(PS: Druid의 모든 기능은 동일한 소프트웨어 패키지에 있으며 다른 명령을 통해 시작됩니다):

4.1 Youzan OLAP 플랫폼의 주요 목표:

4.2 Youzan OLAP 플랫폼 아키텍처

Youzan OLAP 플랫폼은 Druid 및 주변 구성 요소 관리 시스템을 관리하는 데 사용됩니다. OLAP 플랫폼의 주요 기능은 다음과 같습니다.

OLAP 플랫폼에서 사용하는 데이터 수집 방법은 다음과 같습니다. Tranquility 도구는 트래픽 크기에 따라 각 DataSource에 서로 다른 수의 Tranquility 인스턴스를 할당합니다. DataSource의 구성이 에이전트-마스터로 푸시되고 에이전트-마스터는 각 서버의 리소스 사용량을 수집하고 리소스를 선택합니다. Tranquility 인스턴스를 시작하려면 풍부한 시스템이 필요합니다. 현재는 서버의 메모리 리소스만 고려하세요. 동시에 OLAP 플랫폼은 Tranquility 인스턴스 시작 및 중지, 확장 및 축소와 같은 기능도 지원합니다.

스트리밍 데이터 처리 프레임워크에는 기간이 있으며 기간보다 늦게 도착하는 데이터는 삭제됩니다. 지연된 데이터를 세그먼트에 구축하고 실시간 작업 창이 오랫동안 닫히지 않도록 하는 방법. Druid 데이터 보상 기능을 개발하고 OLAP 플랫폼을 통해 스트리밍 ETL을 구성하여 원본 데이터를 HDFS에 저장했습니다. Flume 기반 스트리밍 ETL은 이벤트 시간에 따라 동일한 시간의 데이터가 동일한 파일 경로에 있음을 보장할 수 있습니다. 그런 다음 OLAP 플랫폼을 통해 Hadoop-Batch 작업을 수동 또는 자동으로 트리거하여 세그먼트를 오프라인으로 구축합니다.

Flume 기반 ETL은 HDFS Sink를 사용하여 데이터를 동기화하고 Timestamp Interceptor를 구현하며 Event의 Timestamp 필드에 따라 파일을 생성합니다(1시간마다 폴더가 생성됨). 지연된 데이터는 해당 폴더에 올바르게 보관될 수 있습니다. 시간 파일.

액세스하는 서비스의 증가와 장기간의 실행 시간으로 인해 데이터 크기도 점점 커지고 있습니다. Historical 노드는 많은 양의 Segment 데이터를 로드하는데, 대부분의 쿼리가 최근에 집중되는 것을 볼 수 있습니다. 즉, 최근의 Hot 데이터를 쉽게 쿼리할 수 있으므로 Hot 데이터와 Cold 데이터의 분리가 개선되어야 합니다. 쿼리 효율성. Druid는 구성을 통해 핫 데이터와 콜드 데이터를 효과적으로 분리할 수 있는 Historical의 Tier 그룹화 메커니즘과 데이터 로딩 규칙 메커니즘을 제공합니다.

먼저 Historical 클러스터를 그룹화합니다. 기본 그룹은 "_default_tier"입니다. 소수의 Historical 노드를 계획하고 SATA 디스크를 사용합니다. "hot" 그룹에 SSD 디스크를 사용합니다. . 그런 다음 각 DataSource 구성에 대한 규칙을 로드합니다.

"핫" 그룹 클러스터의 druid.server.priority 값을 늘리면(기본값은 0) 핫 데이터 쿼리가 "핫" 그룹에 속하게 됩니다. .

Druid 아키텍처의 각 구성 요소는 우수한 내결함성을 가지며 단일 장애 지점이 발생하는 경우에도 클러스터는 외부 세계에 서비스를 제공할 수 있습니다. Coordinator와 Overlord에는 HA가 여러 개 보장됩니다. HDFS/S3에 저장되는 동시에 Historical에 의해 로드된 Segment 및 Peon 노드에 의해 수집된 실시간 데이터의 여러 복사본을 설정하여 서비스를 제공할 수 있습니다. 동시에, 노드/클러스터가 잘못된 상태에 들어가거나 용량 제한에 도달할 때 가능한 한 빨리 경보 메시지를 보내기 위해. 다른 빅 데이터 프레임워크와 마찬가지로 Druid에 대한 자세한 모니터링 및 경보 항목도 만들었습니다. 이는 두 가지 수준으로 구분됩니다.

Historical 클러스터 배포는 섹션 4.4에 설명된 데이터의 핫 및 콜드 분리에 해당합니다. , SSD 클러스터를 사용하여 지난 N일의 핫 데이터(로드 일수는 조정 가능)를 저장하고, 상대적으로 저렴한 Sata 모델을 사용하여 더 긴 기록 콜드 데이터를 저장하고, Sata의 IO 기능을 최대한 활용하여 세그먼트를 로드합니다. Youzan에는 많은 유료 서비스가 있습니다. 이러한 서비스가 쿼리 측에 충분한 리소스를 갖도록 보장하기 위해 라우터는 단일 지점 문제를 방지합니다. 브로커는 매우 클 수도 있습니다. MiddleManager 클러스터의 클러스터 쿼리 처리량은 인덱스 작업(메모리 작업)을 배포하는 것 외에도 일부 높은 트래픽 Tranquility 작업(CPU 유형 작업)을 혼합하여 배포했습니다. MiddleManager 클러스터의 리소스 활용도.

Youzan에서 비즈니스 쿼리 방법은 일반적으로 SQL On Broker/Router입니다. 느린 쿼리 수가 적으면 클라이언트가 쿼리에 응답하지 않고 연결이 점점 더 느려지는 것을 발견했습니다. 얻기가 어렵습니다. 브로커 서버에 로그인한 후, 사용 가능한 연결 수가 소진될 정도로 급격히 감소하고 동시에 많은 수의 TCP Close_Wait이 나타나는 것을 발견했습니다. jstack 도구를 사용하여 조사한 결과 교착 상태가 발견되었습니다. 특정 스택에 대해서는 ISSUE-6867을 참조하세요.

소스 코드를 조사한 결과 DruidConnection이 각 명령문에 대해 콜백을 등록한 것으로 나타났습니다. 일반적인 상황에서는 명령문이 끝난 후 콜백 함수가 실행되어 DruidConnection 명령문에서 자체 상태를 제거합니다. 쿼리가 느리면(최대 연결 시간을 초과하거나 클라이언트에서 종료) 연결이 강제로 닫힙니다. 그 아래의 모든 문에 대해 두 스레드(연결을 닫는 스레드와 명령문을 종료하는 스레드)는 각각 상대방이 잠금을 해제하기를 기다리며 교착 상태가 발생합니다. 연결이 즉시 소진됩니다.

문제를 해결한 후 PR-6868을 커뮤니티에 올렸습니다. Master 브랜치에 성공적으로 병합되었으며 버전 0.14.0에 출시될 예정입니다. 독자들에게도 이 문제가 발생하면 PR을 자신의 브랜치로 직접 선택하여 문제를 해결할 수 있습니다.

현재 더 일반적으로 사용되는 데이터 수집 솔루션은 KafkaIndex 및 Tranquility입니다. 현재 Tranquility에서는 데이터 수집을 위해 Kafka 및 Http 방식을 지원하지만 수집 방식이 풍부하지 않습니다. Tranquility도 MetaMarket Company의 오픈 소스 프로젝트로 업데이트 속도가 가장 느리고 많은 기능이 없습니다. 중요한 것은 모니터링 기능이 부족하여 인스턴스의 실행 상태, 수집 속도, 백로그, 손실 및 기타 정보를 모니터링할 수 없다는 것입니다.

현재 Tranquility의 인스턴스 관리는 시작 및 중지, 확장 및 축소 등의 작업을 지원합니다. 구현 방법은 Peon 노드를 관리하는 Druid의 MiddleManager와 동일합니다. Tranquility 또는 자체 개발한 수집 도구를 Yarn 애플리케이션 또는 Docker 애플리케이션으로 변환하면 리소스 스케줄링 및 인스턴스 관리를 보다 안정적인 스케줄러로 전달할 수 있습니다.

Druid는 현재 JOIN 쿼리를 지원하지 않으며 모든 집계 쿼리는 단일 데이터 소스로 제한됩니다. 그러나 실제 사용 시나리오에서는 필요한 결과를 얻기 위해 JOIN 쿼리를 수행하기 위해 여러 DataSource가 필요한 경우가 많습니다. 이것이 우리가 직면한 문제이자, Druid 개발팀이 직면한 문제입니다.

C측 OLAP 쿼리 시나리오의 경우 RT 요구 사항이 상대적으로 높습니다. Druid는 현재 시간에 대한 Index 작업을 생성하므로 쿼리가 새로 생성된 Index 작업에 속하게 되면 다음 그림과 같이 쿼리에 큰 결함이 발생하게 됩니다.

몇 가지 최적화 및 조정을 수행했습니다. 먼저 WarmingPeriod 매개변수를 조정하고 시간 전에 Druid의 Index 작업을 시작합니다. TPS는 낮지만 QPS는 높은 일부 데이터 소스의 경우 대부분의 쿼리가 지난 24시간의 데이터를 쿼리하도록 합니다. 쿼리된 데이터가 메모리에 있고, 새로운 인덱스 작업 수가 줄어들었으며, 쿼리 결함이 크게 개선되었습니다. 그럼에도 불구하고 우리가 원하는 목표와는 여전히 어느 정도 격차가 있습니다. 다음으로 소스 코드를 최적화해 보겠습니다.

현재 대부분의 DataSource의 세그먼트 세분성(SegmentGranularity)은 HDFS에 저장될 때 시간당 하나의 세그먼트입니다. 쿼리 시간 범위가 상대적으로 길면 쿼리 속도가 매우 느려지고 많은 양의 기록 리소스를 차지하며 Broker OOM이 발생할 수도 있습니다.

Hadoop-Batch 작업을 생성하고, 예를 들어 일주일 전의 데이터를 일별 단위로 Rull-Up하고 Index를 다시 작성하면 스토리지 압축 및 쿼리 성능 향상에 좋은 효과가 있을 것입니다. 과거 데이터 Rull-Up에 대해서는 이미 실용화 단계에 있으며, 추후 특별 블로그 포스팅을 통해 소개할 예정입니다.

마지막으로 유잔의 빅데이터팀 인프라팀은 유잔의 데이터 플랫폼(DP), 실시간 컴퓨팅(Storm, Spark Streaming, Flink), 오프라인 컴퓨팅을 주로 담당하고 있습니다. (HDFS, YARN), HIVE, SPARK SQL), 온라인 스토리지(HBase), 실시간 OLAP(Druid) 및 기타 여러 기술 제품에 관심이 있는 파트너는 zhaojiandong@youzan.com으로 문의하세요.