Iceberg + Spark + Trino：区块链的现代开源数据堆栈

1. 现代区块链数据堆栈的挑战

现代区块链索引初创公司可能面临多项挑战，包括：

• 海量数据。随着区块链上数据量的增加，数据索引将需要扩展以处理增加的负载并提供对数据的高效访问。因此，它会导致更高的存储成本；指标计算缓慢并增加数据库服务器的负载。
• 复杂的数据处理管道。区块链技术复杂，构建全面可靠的数据索引需要对底层数据结构和算法有深刻理解。它是由区块链实现的多样性所继承的。举个具体的例子，以太坊中的 NFT 通常是在遵循 ERC721 和 ERC1155 格式的智能合约中创建的，而在 Polkadot 上的 NFT 的实现通常直接在区块链运行时中构建。归根结底，这些应该被视为 NFT，并应作为它们保存。
• 整合能力。为了向用户提供最大价值，区块链索引解决方案可能需要将其数据索引与其他系统集成，例如分析平台或 API。这是具有挑战性的，需要在架构设计上投入大量精力。

随着区块链技术的使用越来越广泛，存储在区块链上的数据量也越来越大。这是因为越来越多的人在使用该技术，并且每笔交易都会向区块链添加新数据。此外，区块链技术的使用已经从简单的汇款应用程序（例如涉及使用比特币的应用程序）发展到涉及在智能合约中实施业务逻辑的更复杂的应用程序。这些智能合约可以生成大量数据，这导致区块链的复杂性和规模不断增加。随着时间的推移，这导致了更大、更复杂的区块链。

在本文中，我们回顾了足迹分析的演变'分阶段的技术架构作为案例研究，探索 Iceberg-Trino 技术堆栈如何应对链上数据的挑战。

Footprint Analytics 已将大约 22 个公共区块链数据、17 个 NFT 市场、1900 个 GameFi 项目和超过 100,000 个 NFT 集合编入语义抽象数据层。它是世界上最全面的区块链数据仓库解决方案。

抛开区块链数据不谈，其中包括超过 200 亿行的金融交易记录，数据分析师经常查询这些数据。它不同于传统数据仓库中的入口日志。

我们在过去几个月经历了 3 次重大升级，以满足不断增长的业务需求：

2.架构1.0 Bigquery

在足迹分析开始时，我们使用谷歌大查询作为我们的存储和查询引擎； Bigquery 是一个很棒的产品。它速度极快，易于使用，并提供动态算术能力和灵活的 UDF 语法，可帮助我们快速完成工作。

然而，Bigquery 也有一些问题。

• 数据未压缩，导致存储成本高，尤其是在存储 Footprint Analytics 超过 22 个区块链的原始数据时。
• 并发不足：Bigquery仅支持100个并发查询，不适合足迹分析的高并发场景，服务于大量分析师和用户。
• 锁定 Google Bigquery，它是一个闭源产品。

所以我们决定探索其他替代架构。

3.架构2.0 OLAP

我们对一些非常流行的 OLAP 产品非常感兴趣。 OLAP 最吸引人的优势是它的查询响应时间，通常需要亚秒级才能返回海量数据的查询结果，并且它还可以支持数千个并发查询。

我们选择了最好的 OLAP 数据库之一，多丽丝, 试一试。该引擎性能良好。然而，在某些时候我们很快遇到了一些其他问题：

• 尚不支持 Array 或 JSON 等数据类型（2022 年 11 月）。数组是一些区块链中常见的数据类型。例如，话题领域在 evm 日志中。无法在 Array 上计算直接影响我们计算许多业务指标的能力。
• 对 DBT 和合并语句的支持有限。这些是数据工程师对 ETL/ELT 场景的常见需求，我们需要更新一些新索引的数据。

也就是说，我们不能将 Doris 用于我们整个生产数据管道，因此我们尝试使用 Doris 作为 OLAP 数据库来解决我们在数据生产管道中的部分问题，充当查询引擎并提供快速以及高并发查询能力。

不幸的是，我们无法用 Doris 替换 Bigquery，因此我们不得不定期将数据从 Bigquery 同步到 Doris，仅将其用作查询引擎。这个同步过程有很多问题，其中之一是当 OLAP 引擎忙于为前端客户端提供查询服务时，更新写入很快堆积起来。随后写入过程的速度受到影响，同步时间更长，有时甚至无法完成。

我们开始意识到 OLAP 可以解决我们面临的几个问题，并且不能成为 Footprint Analytics 的交钥匙解决方案，尤其是对于数据处理管道。我们的问题更大更复杂，我们可以说，OLAP 仅作为查询引擎对我们来说是不够的。

4. 架构 3.0 Iceberg + Trino

欢迎使用 Footprint Analytics 架构 3.0，这是对底层架构的彻底改造。我们从头开始重新设计了整个架构，将数据的存储、计算和查询分为三个不同的部分。从 Footprint Analytics 的两个早期架构中吸取教训，并借鉴其他成功的大数据项目（如 Uber、Netflix 和 Databricks）的经验。

4.1.数据湖简介

我们首先将注意力转向数据湖，这是一种用于结构化和非结构化数据的新型数据存储。数据湖非常适合链上数据存储，因为链上数据的格式范围广泛，从非结构化原始数据到结构化抽象数据，足迹分析是众所周知的。我们期望使用数据湖来解决数据存储的问题，理想情况下它也支持主流的计算引擎，如Spark和Flink，这样随着Footprint Analytics的发展，与不同类型的处理引擎集成并不困难.

Iceberg 与 Spark、Flink、Trino 等计算引擎集成得很好，我们可以为每个指标选择最合适的计算。例如：

• 对于那些需要复杂计算逻辑的人，Spark 将是不二之选。
• Flink 用于实时计算。
• 对于可以使用 SQL 执行的简单 ETL 任务，我们使用 Trino。

4.2.查询引擎

随着 Iceberg 解决了存储和计算问题，我们不得不考虑如何选择查询引擎。可用的选项不多，我们考虑的替代方案是

• 三位一体: SQL 查询引擎
• 很快: SQL 查询引擎
• 九尾: 无服务器 Spark SQL

在深入研究之前，我们考虑的最重要的事情是未来的查询引擎必须与我们当前的架构兼容。

• 支持 Bigquery 作为数据源
• 支持 DBT，我们依赖它来生成许多指标
• 支持BI工具元数据库

基于以上，我们选择了 Trino，它对 Iceberg 的支持非常好，团队反应非常迅速，我们提出了一个错误，第二天就修复了，并在下周发布到最新版本。对于同样需要高实施响应能力的 Footprint 团队来说，这绝对是最佳选择。

4.3.性能测试

一旦我们确定了方向，我们就对 Trino + Iceberg 组合进行了性能测试，看它是否能满足我们的需求，令我们惊讶的是，查询速度非常快。

知道 Presto + Hive 多年来一直是所有 OLAP 炒作中最差的比较器，Trino + Iceberg 的组合完全让我们大吃一惊。

这是我们的测试结果。

案例 1：加入大型数据集

一个800GB的table1加入另一个50GB的table2做复杂的业务计算

case2：使用一个大的单表做一个不同的查询

测试sql: select distinct(address) from table group by day

Trino+Iceberg 组合比同配置的 Doris 快 3 倍左右。

除此之外，还有一个惊喜，因为Iceberg可以使用Parquet、ORC等数据格式，将数据进行压缩存储。 Iceberg的表存储占用空间仅为其他数仓的1/5左右 同一张表在三个数据库中的存储大小如下：

4.4.升级效果

性能测试报告给了我们足够的性能，我们的团队花了大约 2 个月的时间才完成迁移，这是升级后的架构图。

• 多个计算机引擎满足我们的各种需求。
• Trino 支持DBT，可以直接查询Iceberg，不再需要处理数据同步问题。
• Trino + Iceberg 的惊人性能使我们能够向用户开放所有 Bronze 数据（原始数据）。

5.总结

自 2021 年 8 月推出以来，Footprint Analytics 团队在不到一年半的时间内完成了三项架构升级，这要归功于其将最好的数据库技术的好处带给其加密用户的强烈愿望和决心，以及在实施方面的扎实执行并升级其底层基础设施和架构。

Footprint Analytics架构升级3.0为用户带来了全新的体验，让不同背景的用户获得更多样化的使用和应用洞察：

• Footprint 使用 Metabase BI 工具构建，可帮助分析师访问已解码的链上数据，完全自由地选择工具（无代码或硬编码）进行探索，查询整个历史记录，交叉检查数据集，以获取洞察力时间。
• 整合链上和链下数据，跨 web2 + web3 进行分析；
• 通过在 Footprint 的业务抽象之上构建/查询指标，分析师或开发人员可以节省 80% 的重复数据处理工作的时间，并专注于基于其业务的有意义的指标、研究和产品解决方案。
• 从 Footprint Web 到 REST API 调用的无缝体验，全部基于 SQL
• 针对关键信号的实时警报和可操作通知，以支持投资决策