1.现代区块链数据栈的挑战
现代区块链索引初创企业可能面临的挑战有：
1.现代区块链数据栈的挑战
- 海量的数据。随着区块链上数据量的增加，数据索引将需要扩大规模以处理增加的负载，并提供对数据的有效访问。因此，它导致了更高的存储成本，缓慢的指标计算，以及数据库服务器的负载增加。
- 复杂的数据处理管道。区块链技术很复杂，建立一个全面可靠的数据索引需要深入了解底层数据结构和算法。区块链实现的多样性继承了它。鉴于具体的例子，以太坊中的NFT通常是在智能合约内按照ERC721和ERC1155格式创建的。相比之下，例如Polkadot上的那些实现通常直接建立在区块链运行时间内。那些应该被认为是NFT，应该被保存为那些。
- 整合能力。为了给用户提供最大的价值，区块链索引解决方案可能需要将其数据索引与其他系统整合，如分析平台或API。这很有挑战性，需要在架构设计中投入大量精力。
随着区块链技术的普及，存储在区块链上的数据量也在增加。这是因为更多的人在使用这项技术，而每笔交易都会给区块链增加新的数据。此外，区块链技术已经从简单的资金转移应用，如涉及使用比特币的应用，发展到涉及在智能合约内实施商业逻辑的更复杂应用。这些智能合约可以产生大量的数据，促使区块链的复杂性和规模增加。随着时间的推移，这导致了更大、更复杂的区块链。
在这篇文章中，我们分阶段回顾了Footprint Analytics技术架构的演变，作为一个案例研究，探讨Iceberg-Trino技术栈如何解决链上数据的挑战。
Footprint Analytics已经将大约22个公共区块链数据，和17个NFT市场，1900个GameFi项目，以及超过10万个NFT集合索引到一个语义抽象的数据层。这是世界上最全面的区块链数据仓库解决方案。
无论区块链数据，其中包括超过200亿行的金融交易记录，数据分析师经常查询。它与传统数据仓库的摄取日志不同。
在过去的几个月里，我们经历了3次重大的升级，以满足不断增长的业务需求：
2. 架构1.0 Bigquery
在Footprint Analytics的初期，我们使用Google Bigquery作为我们的存储和查询引擎；Bigquery是一个伟大的产品。它的速度快得惊人，易于使用，并提供动态算术能力和灵活的UDF语法，帮助我们快速完成工作。
然而，Bigquery也有几个问题。
- 数据没有被压缩，导致成本很高，特别是在存储超过22个区块链的足彩代理分析的原始数据时。
- 并发性不足。Bigquery只支持100次同时查询，在为众多分析师和用户服务时，不适合Footprint Analytics的高并发场景。
- 锁定谷歌Bigquery，它是一个闭源产品。
所以我们决定探索其他替代架构。
3. 架构2.0 OLAP
我们对一些已经变得非常流行的OLAP产品非常感兴趣。OLAP最吸引人的优点是它的查询响应时间，对于海量的数据，通常需要亚秒级的时间来返回查询结果，而且它还可以支持成千上万的并发查询。
我们挑选了最好的OLAP数据库之一Doris来试一试。这个引擎表现得很好。然而，在某些时候，我们很快就遇到了一些其他问题：
- 还不支持数组或JSON等数据类型（11月，2022年）。在一些区块链中，数组是一种常见的数据类型。例如，evm日志中的主题字段。无法对数组进行计算直接影响了我们计算许多业务指标的能力。
- 对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解决了存储和计算问题，我们不得不考虑选择一个查询引擎。可用的选择不多。我们考虑的替代方案是
。
- Trino。SQL查询引擎
- Presto: SQL查询引擎
- Kyuubi: 无服务器的Spark SQL
在深入研究之前，我们考虑的最重要的事情是，未来的查询引擎必须与我们目前的架构兼容。
- 要支持Bigquery作为一个数据源
- 要支持DBT，我们依靠它来产生许多指标。
- 要支持BI工具元数据库
基于上述情况，我们选择了Trino，它对Iceberg有很好的支持，团队的反应非常迅速，我们提出了一个bug，第二天就被修复了，并在下周发布了最新版本。这对于同样需要高执行响应的Footprint团队来说是最好的选择。
4.3. 性能测试
一旦我们决定了方向，我们就对Trino+Iceberg的组合进行了性能测试，看看它是否能满足我们的需求，令我们惊讶的是，查询速度快得惊人。
要知道Presto + Hive多年来一直是所有OLAP炒作中最差的比较对象，Trino + Iceberg的组合完全让我们大跌眼镜。
以下是我们的测试结果。
案例1：加入一个大数据集
一个800GB的表1加入另一个50GB的表2，并进行复杂的商业计算
案例2：使用一个大的单表来做一个区分查询
测试 sql: select distinct(address) from the table group by day
注意：以上测试是我们在实际生产中遇到的例子，仅作参考。
4.4. 升级效果
性能测试报告给了我们足够的性能，我们的团队花了大约2个月的时间来完成迁移，这是升级后的架构图。
- 多个计算机引擎符合我们的各种需求。
- Trino支持DBT，可以直接查询Iceberg，所以我们不再需要处理数据同步的问题。
- Trino+Iceberg的惊人性能使我们可以向用户开放所有青铜器数据（原始数据）。
5. 摘要
自2021年8月推出以来，Footprint Analytics团队在不到一年半的时间里完成了三次架构升级，这得益于其为加密货币用户带来最佳数据库技术优势的强烈愿望和决心，以及对实施和升级其底层基础设施和架构的扎实执行。
脚印分析架构升级3.0为其用户买到了全新的体验，让来自不同背景的用户在更多样化的使用和应用中获得洞察力：
- 与Metabase BI工具一起构建，Footprint便于分析师获得解码的链上数据，完全自由地选择工具进行探索（无代码或硬记录），查询整个历史，并交叉检查数据集，在短时间内获得洞察力。
- 将链上和链下数据整合到分析中 跨 web2 + web3。
- 通过在Footprint的业务抽象之上建立/查询指标，分析师或开发人员可以节省80%的重复性数据处理工作的时间，并专注于有意义的指标、研究和基于其业务的产品解决方案。
- 从Footprint Web到REST API调用的无缝体验，全部基于SQL
对关键信号进行实时提醒和可操作的通知，以支持投资决策
。
