现代区块链数据堆栈面临的挑战

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

巨大的数据量。随着区块链上数据量的增加，数据索引将需要扩展以处理增加的负载并提供高效的数据访问。这会导致更高的存储成本、缓慢的指标计算和数据库服务器负载的增加。

复杂的数据处理管道。区块链技术很复杂，构建全面可靠的数据索引需要深入了解底层数据结构和算法。这也受到区块链实现方案多样性的影响。举个具体的例子，以太坊中的NFT通常是在遵循ERC721和ERC1155格式的智能合约中创建的，而Polkadot上的NFT通常是直接在区块链运行时构建的。但最终，它们都应被视为NFT并应以此方式保存。

集成能力。为了为用户提供最大价值，区块链索引解决方案可能需要将其数据索引与其他系统（如分析平台或API）集成。这是具有挑战性的，需要在架构设计上投入大量努力。

随着区块链技术的使用越来越广泛，存储在区块链上的数据量也增加了。这是因为随着越来越多的人使用该技术，每笔交易都会向区块链添加新数据。此外，区块链技术的使用已经从简单的货币转移应用（如关于比特币使用的应用）发展到在智能合约中实现业务逻辑的更复杂的应用。这些智能合约会产生大量数据，导致区块链更加复杂、更加庞大。

在本文中，我们分阶段回顾了Footprint Analytics技术架构的演变，并以此为例，探讨了Iceberg-Trino技术堆栈如何应对链上数据的挑战。

Footprint Analytics已经将大约22个公链数据、17个NFT市场、1900个GameFi项目和超过10万个NFT集合索引到语义抽象数据层中。它是世界上最全面的区块链数据仓库解决方案。

区块链数据包括超过200亿行的金融交易记录，经常被数据分析师查询。

为满足不断增长的业务需求，在过去的几个月中，我们进行了3次重大升级，包括：

架构1.0 Bigquery

在Footprint Analytics最初，我们使用谷歌Bigquery作为我们的存储和查询引擎。Bigquery是一个很棒的产品，它速度极快，易于使用，并提供动态算术能力和灵活的UDF语法，能够帮助我们快速完成工作。

然而，Bigquery也存在一些问题。

数据没有压缩，导致存储成本很高，特别是在存储Footprint Analytics超过22个区块链的原始数据时。

并发能力不足：Bigquery仅同时支持100条查询，不适用于Footprint Analytics的高并发场景，因为需要为大量分析师和用户提供服务。

非开源产品，绑定 Google 一家供应商。

因此，我们决定探索其他替代架构。

架构2.0 OLAP

我们对一些非常流行的OLAP（联机分析处理）产品感兴趣，OLAP最吸引人的优势是它的查询响应时间，通常能在亚秒内返回大量数据的查询结果，并且还支持数千个同时查询。

我们选择了最好的OLAP数据库之一Doris。这个引擎表现不错，但我们很快遇到了一些其他问题：

尚不支持数组或JSON等数据类型（截至2022年11月）。数组是某些区块链中常见的数据类型。例如，evm日志中的topic字段。无法直接对数组进行计算，会影响我们计算许多业务指标。

对DBT和merge语法的支持有限。它们是数据工程师在ETL/ELT(数据提取-加载-转换）场景中常见的需求，我们需要更新一些新索引的数据。

话虽如此，我们无法在生产中完全使用Doris作为整个数据管道，因此我们尝试将Doris作为OLAP数据库来解决我们在数据生产管道中的一部分问题，作为查询引擎并提供快速和高并发的查询能力。

然而，我们无法用Doris替代Bigquery，因此需要定期将数据从Bigquery同步到Doris，仅将Doris作为查询引擎。这个同步过程存在许多问题，其中之一是当OLAP引擎忙于向前端客户端提供查询时，写入数据会迅速堆积起来。随后，写入过程的速度受到影响，同步会花费更长的时间，有时甚至无法完成。

我们意识到，OLAP可以解决我们面临的几个问题，但无法成为Footprint Analytics的一站式解决方案，特别是对于数据处理管道而言。我们的问题更大更复杂，可以说，OLAP仅仅作为一个查询引擎对我们来说还不够。

架构3.0 Iceberg + Trino

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

数据湖的引入

我们首先将注意力转向了数据湖，这是一种用于结构化和非结构化数据的新型数据存储方式。数据湖非常适合链上数据的存储，因为链上数据的格式范围广泛，包括非结构化原始数据和Footprint Analytics所著名的结构化抽象数据。我们期望用数据湖来解决数据存储问题，理想情况下，它还将支持Spark和Flink等主流计算引擎，这样，随着Footprint Analytics的发展，在与不同类型的处理引擎集成就不会出现额外问题。

Iceberg与Spark、Flink、Trino和其他计算引擎可以非常好地集成到一起，我们可以为每个指标选择最合适的计算方式。例如：

对于需要复杂计算逻辑的指标，Spark将是首选。

Flink适用于实时计算。

对于可以用SQL执行的简单ETL任务，我们使用Trino。

查询引擎

Iceberg解决了存储和计算问题，接下来，我们将需要考虑如何选择查询引擎。可用的选项并不多，我们考虑的替代方案包括：

Trino：SQL查询引擎

Presto：SQL查询引擎

Kyuubi：无服务器Spark SQL

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

支持Bigquery作为数据源

支持DBT（我们依赖它来生成许多指标）

支持BI（商业智能）工具Metabase

基于以上考虑，我们选择了Trino，它对Iceberg有很好的支持，团队响应非常迅速，我们曾提出的bug在第二天便修复了，并在第二周发布了最新版本。对于需要较高响应能力的团队Footprint而言，这绝对是Footprint的最佳选择。

性能测试

定好方向之后，我们就对Trino+Iceberg组合进行了性能测试，看看它是否能满足我们的需求。出乎意料的是，它的查询速度非常快。

我们知道多年来，Presto+Hive一直是OLAP领域中性能最差的对手，但Trino+Iceberg组合完全颠覆了我们的认知。

我们的测试结果如下。

示例1：连接大型数据集

将一个800 GB的表1与另一个50 GB的表2连接，并进行复杂的业务计算。

示例2：大表单执行不重复查询

测试用的sql：从表中按日期分组选择不同的地址

Trino+Iceberg组合在相同配置下比Doris快约3倍。

此外，Iceberg可以使用Parquet、ORC等数据格式，这些格式会对数据进行压缩存储。Iceberg的表存储占用的空间仅为其他数据仓库的1/5左右，三个数据库中相同表的存储大小如下：

注：以上测试是我们在实际生产中遇到的个别示例，仅供参考。

升级效果

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

多个计算机引擎满足我们的各种需求。

Trino支持DBT，可以直接查询Iceberg，所以我们不再需要处理数据同步。

Trino+Iceberg的惊人性能使我们能够向用户开放所有黄铜数据（原始数据）。

小结

自2021年8月推出以来，Footprint Analytics团队在不到一年半的时间内完成了三次架构升级，这要归功于团队为加密货币用户带来最佳数据库技术优势的渴望和决心，以及在实施和升级底层基础设施和架构方面的出色表现。

Footprint Analytics架构3.0升级为用户带来了全新的体验，让具有不同背景的用户能够深入了解更多样化的用途和使用场景：

Footprint使用Metabase BI工具进行构建，有助于分析师访问解码的链上数据，完全自由地选择工具（无需代码或硬编码）进行探索，查询完整的历史记录，交叉检查数据集，及时获得深入分析。

将链上和链下数据整合到Web2+Web3的分析中。

通过在Footprint的业务抽象之上构建/查询指标，分析师或开发人员可以节省80%的重复数据处理时间，并专注于基于其业务的有意义的指标、研究和产品解决方案。

从Footprint Web到REST API调用的无缝体验，全部基于SQL。

提供关键信号的实时警报和可操作通知，以支持投资决策。

声明：本网站所有相关资料如有侵权请联系站长删除，资料仅供用户学习及研究之用，不构成任何投资建议！