Iceberg + Spark + Trino: 블록체인을 위한 최신 오픈소스 데이터 스택

1. 최신 블록체인 데이터 스택의 과제

최신 블록체인 인덱싱 스타트업이 직면할 수 있는 몇 가지 문제는 다음과 같습니다.

• 엄청난 양의 데이터. 블록체인의 데이터 양이 증가함에 따라 증가된 부하를 처리하고 데이터에 대한 효율적인 액세스를 제공하기 위해 데이터 인덱스를 확장해야 합니다. 결과적으로 보관 비용이 높아집니다. 메트릭 계산이 느려지고 데이터베이스 서버의 부하가 증가합니다.
• 복잡한 데이터 처리 파이프라인. 블록체인 기술은 복잡하며 포괄적이고 신뢰할 수 있는 데이터 인덱스를 구축하려면 기본 데이터 구조 및 알고리즘에 대한 깊은 이해가 필요합니다. 그것은 블록체인 구현의 다양성에 의해 상속됩니다. 구체적인 예가 주어지면 이더리움의 NFT는 일반적으로 ERC721 및 ERC1155 형식을 따르는 스마트 계약 내에서 생성되는 반면, 예를 들어 Polkadot의 NFT 구현은 일반적으로 블록체인 런타임 내에서 직접 구축됩니다. 결국 NFT로 간주하고 NFT로 저장해야 합니다.
• 통합 기능. 사용자에게 최대 가치를 제공하기 위해 블록체인 인덱싱 솔루션은 데이터 인덱스를 분석 플랫폼 또는 API와 같은 다른 시스템과 통합해야 할 수 있습니다. 이는 도전적이며 아키텍처 설계에 상당한 노력이 필요합니다.

블록체인 기술의 사용이 보편화되면서 블록체인에 저장되는 데이터의 양이 증가했습니다. 더 많은 사람들이 이 기술을 사용하고 있고 각 거래가 블록체인에 새로운 데이터를 추가하기 때문입니다. 또한 블록체인 기술의 사용은 비트코인 사용과 관련된 단순한 자금 이체 애플리케이션에서 스마트 계약 내의 비즈니스 로직 구현과 관련된 보다 복잡한 애플리케이션으로 발전했습니다. 이러한 스마트 계약은 많은 양의 데이터를 생성할 수 있으며, 이는 블록체인의 복잡성과 크기 증가에 기여했습니다. 시간이 지남에 따라 이것은 더 크고 복잡한 블록체인으로 이어졌습니다.

이 기사에서는 Footprint Analytics의 진화를 검토합니다. Iceberg-Trino 기술 스택이 온체인 데이터의 문제를 해결하는 방법을 탐구하기 위한 사례 연구로 단계별 기술 아키텍처.

Footprint Analytics는 약 22개의 퍼블릭 블록체인 데이터, 17개의 NFT 마켓플레이스, 1900개의 GameFi 프로젝트, 100,000개 이상의 NFT 컬렉션을 시맨틱 추상화 데이터 레이어로 인덱싱했습니다. 세계에서 가장 포괄적인 블록체인 데이터 웨어하우스 솔루션입니다.

200억 행 이상의 금융 거래 기록을 포함하는 블록체인 데이터와 관계없이 데이터 분석가가 자주 쿼리합니다. 기존 데이터 웨어하우스의 침입 로그와 다릅니다.

증가하는 비즈니스 요구 사항을 충족하기 위해 지난 몇 개월 동안 3가지 주요 업그레이드를 경험했습니다.

2. 아키텍처 1.0 빅쿼리

Footprint Analytics 초기에 우리는구글 빅쿼리우리의 스토리지 및 쿼리 엔진으로; BigQuery는 훌륭한 제품입니다. 매우 빠르고 사용하기 쉬우며 동적 산술 기능과 작업을 신속하게 완료하는 데 도움이 되는 유연한 UDF 구문을 제공합니다.

그러나 BigQuery에도 여러 가지 문제가 있습니다.

• 데이터가 압축되지 않아 특히 Footprint Analytics의 22개가 넘는 블록체인의 원시 데이터를 저장할 때 높은 스토리지 비용이 발생합니다.
• 불충분한 동시성: Bigquery는 100개의 동시 쿼리만 지원하므로 많은 수의 분석가와 사용자에게 서비스를 제공할 때 Footprint Analytics의 동시성 시나리오에 적합하지 않습니다.
• 비공개 소스 제품인 Google Bigquery로 고정。

그래서 우리는 다른 대체 아키텍처를 탐색하기로 결정했습니다.

3. 아키텍처 2.0 OLAP

우리는 큰 인기를 얻은 일부 OLAP 제품에 매우 관심이 있었습니다. OLAP의 가장 매력적인 장점은 쿼리 응답 시간입니다. 일반적으로 방대한 양의 데이터에 대한 쿼리 결과를 반환하는 데 1초 미만이 소요되며 수천 개의 동시 쿼리도 지원할 수 있습니다.

최고의 OLAP 데이터베이스 중 하나를 선택했습니다.도리스, 시도해 보세요. 이 엔진은 성능이 좋습니다. 그러나 어느 시점에서 우리는 곧 몇 가지 다른 문제에 부딪혔습니다.

• Array 또는 JSON과 같은 데이터 유형은 아직 지원되지 않습니다(2022년 11월). 배열은 일부 블록체인에서 일반적인 데이터 유형입니다. 예를 들어,주제 필드evm 로그에서. 어레이에서 계산할 수 없으면 많은 비즈니스 지표를 계산하는 능력에 직접적인 영향을 미칩니다.
• DBT 및 병합 문에 대한 지원이 제한됩니다. 이는 새로 인덱싱된 일부 데이터를 업데이트해야 하는 ETL/ELT 시나리오에 대한 데이터 엔지니어의 일반적인 요구 사항입니다.

즉, 프로덕션에서 전체 데이터 파이프라인에 Doris를 사용할 수 없었기 때문에 Doris를 OLAP 데이터베이스로 사용하여 데이터 프로덕션 파이프라인에서 문제의 일부를 해결하고 쿼리 엔진 역할을 하며 빠른 제공을 제공하려고 했습니다. 고도의 동시 쿼리 기능.

아쉽게도 Bigquery를 Doris로 교체할 수 없었기 때문에 Bigquery에서 Doris를 쿼리 엔진으로만 사용하여 주기적으로 데이터를 동기화해야 했습니다. 이 동기화 프로세스에는 여러 가지 문제가 있었는데, 그 중 하나는 OLAP 엔진이 프런트 엔드 클라이언트에 쿼리를 제공하느라 바쁠 때 업데이트 쓰기가 빠르게 쌓이는 것이었습니다. 결과적으로 쓰기 프로세스의 속도가 영향을 받았고 동기화가 훨씬 오래 걸리고 때로는 완료가 불가능해졌습니다.

우리는 OLAP가 우리가 직면한 몇 가지 문제를 해결할 수 있으며 특히 데이터 처리 파이프라인을 위한 Footprint Analytics의 턴키 솔루션이 될 수 없다는 것을 깨달았습니다. 우리의 문제는 더 크고 더 복잡하며 쿼리 엔진으로서의 OLAP만으로는 충분하지 않다고 말할 수 있습니다.

4. 아키텍처 3.0 아이스버그 + 트리노

기본 아키텍처를 완전히 개편한 Footprint Analytics 아키텍처 3.0에 오신 것을 환영합니다. 우리는 전체 아키텍처를 처음부터 다시 설계하여 데이터의 저장, 계산 및 쿼리를 세 가지 다른 부분으로 분리했습니다. Footprint Analytics의 두 가지 이전 아키텍처에서 교훈을 얻고 Uber, Netflix 및 Databricks와 같은 다른 성공적인 빅 데이터 프로젝트의 경험에서 배웁니다.

4.1. 데이터 레이크 소개

우리는 먼저 정형 데이터와 비정형 데이터 모두를 위한 새로운 유형의 데이터 스토리지인 데이터 레이크에 관심을 돌렸습니다. 데이터 레이크는 온체인 데이터의 형식이 구조화되지 않은 원시 데이터에서 구조화된 추상화 데이터에 이르기까지 광범위하기 때문에 온체인 데이터 스토리지에 적합합니다. Footprint Analytics는 잘 알려져 있습니다. 우리는 데이터 레이크를 사용하여 데이터 스토리지 문제를 해결할 것으로 예상했으며 이상적으로는 Spark 및 Flink와 같은 주류 컴퓨팅 엔진도 지원하여 Footprint Analytics가 발전함에 따라 다른 유형의 처리 엔진과 통합하는 데 어려움이 없을 것이라고 예상했습니다. .

Iceberg는 Spark, Flink, Trino 및 기타 계산 엔진과 매우 잘 통합되며 각 메트릭에 가장 적합한 계산을 선택할 수 있습니다. 예를 들어:

• 복잡한 계산 논리가 필요한 사람들에게는 Spark가 선택될 것입니다.
• 실시간 계산을 위한 Flink.
• SQL을 사용하여 수행할 수 있는 간단한 ETL 작업의 경우 Trino를 사용합니다.

4.2. 쿼리 엔진

Iceberg가 저장 및 계산 문제를 해결하면서 쿼리 엔진을 선택하는 방법에 대해 생각해야 했습니다. 사용 가능한 옵션이 많지 않습니다. 우리가 고려한 대안은

• 삼위 일체: SQL 쿼리 엔진
• 곧: SQL 쿼리 엔진
• Kyuubi: 서버리스 스파크 SQL

더 깊이 들어가기 전에 고려한 가장 중요한 것은 미래의 쿼리 엔진이 현재 아키텍처와 호환되어야 한다는 것이었습니다.

• BigQuery를 데이터 소스로 지원하려면
• 생성할 많은 지표에 의존하는 DBT를 지원하기 위해
• BI 도구 메타베이스를 지원하려면

위의 내용을 바탕으로 우리는 Iceberg를 매우 잘 지원하는 Trino를 선택했고 팀의 반응이 너무 좋아서 버그를 제기했고 다음날 수정되어 다음 주에 최신 버전으로 릴리스되었습니다. 이것은 높은 구현 응답성을 요구하는 Footprint 팀을 위한 최선의 선택이었습니다.

4.3. 성능 시험

방향을 결정한 후 Trino + Iceberg 조합에 대한 성능 테스트를 수행하여 요구 사항을 충족할 수 있는지 확인했고 놀랍게도 쿼리 속도가 매우 빨랐습니다.

Presto + Hive가 모든 OLAP 과대 광고에서 수년 동안 최악의 비교 대상이었음을 알고 Trino + Iceberg의 조합은 우리의 마음을 완전히 사로잡았습니다.

테스트 결과는 다음과 같습니다.

사례 1: 대규모 데이터세트 조인

800GB 테이블1이 다른 50GB 테이블2를 결합하고 복잡한 비즈니스 계산을 수행합니다.

case2: 별도의 쿼리를 수행하기 위해 큰 단일 테이블 사용

테스트 sql: 일별 테이블 그룹에서 고유(주소) 선택

Trino+Iceberg 조합은 동일한 구성에서 Doris보다 약 3배 빠릅니다.

이 외에도 Iceberg는 데이터를 압축하고 저장할 Parquet, ORC 등과 같은 데이터 형식을 사용할 수 있기 때문에 또 다른 놀라움이 있습니다. Iceberg의 테이블 스토리지는 다른 데이터 웨어하우스 공간의 약 1/5만 차지합니다. 세 개의 데이터베이스에서 동일한 테이블의 스토리지 크기는 다음과 같습니다.

4.4. 업그레이드 효과

성능 테스트 보고서는 우리 팀이 마이그레이션을 완료하는 데 약 2개월이 걸렸을 정도로 충분한 성능을 제공했으며 이것은 업그레이드 후 아키텍처의 다이어그램입니다.

• 여러 컴퓨터 엔진이 우리의 다양한 요구 사항을 충족합니다.
• Trino는 DBT를 지원하고 Iceberg를 직접 쿼리할 수 있으므로 더 이상 데이터 동기화를 처리할 필요가 없습니다.
• Trino + Iceberg의 놀라운 성능 덕분에 모든 Bronze 데이터(원시 데이터)를 사용자에게 공개할 수 있습니다.

5. 요약

Footprint Analytics 팀은 2021년 8월 출범 이후 1년 반도 안 되는 기간 동안 3개의 아키텍처 업그레이드를 완료했습니다. 이는 암호화폐 사용자에게 최고의 데이터베이스 기술의 이점을 제공하려는 강한 열망과 결단력과 구현에 대한 견고한 실행 덕분입니다. 기본 인프라와 아키텍처를 업그레이드합니다.

Footprint Analytics 아키텍처 업그레이드 3.0은 사용자에게 새로운 경험을 제공하여 다양한 배경을 가진 사용자가 보다 다양한 사용 및 애플리케이션에 대한 통찰력을 얻을 수 있도록 합니다.

• Metabase BI 도구로 구축된 Footprint는 분석가가 디코딩된 온체인 데이터에 액세스하고, 도구 선택의 완전한 자유(노코드 또는 하드코드)로 탐색하고, 전체 기록을 쿼리하고, 데이터 세트를 교차 검사하고, 시각.
• 온체인 및 오프체인 데이터를 통합하여 web2 + web3 전반에 걸쳐 분석합니다.
• Footprint의 비즈니스 추상화 위에 메트릭을 구축/쿼리함으로써 분석가 또는 개발자는 반복적인 데이터 처리 작업의 80%에서 시간을 절약하고 비즈니스를 기반으로 의미 있는 메트릭, 연구 및 제품 솔루션에 집중할 수 있습니다.
• Footprint 웹에서 REST API 호출에 이르기까지 모두 SQL을 기반으로 하는 원활한 경험
• 투자 결정을 지원하기 위해 주요 신호에 대한 실시간 경고 및 실행 가능한 알림