[ad_1]
1.现代区块链数据栈的挑战
现代区块链索引初创公司可能面临多项挑战，包括：
- 海量数据。 随着区块链上数据量的增加，数据索引将需要扩展以处理增加的负载并提供对数据的高效访问。 因此，它会导致更高的存储成本、缓慢的指标计算以及增加数据库服务器的负载。
- 复杂的数据处理管道。 区块链技术复杂，构建全面可靠的数据索引需要对底层数据结构和算法有深刻理解。 区块链实现的多样性继承了它。 举个具体的例子，以太坊中的 NFT 通常是在遵循 ERC721 和 ERC1155 格式的智能合约中创建的。 相比之下，例如，Polkadot 上的实现通常直接在区块链运行时内构建。 那些应该被视为 NFT，并且应该被保存为那些。
- 整合能力。 为了向用户提供最大价值，区块链索引解决方案可能需要将其数据索引与其他系统集成，例如分析平台或 API。 这是具有挑战性的，需要在架构设计中投入大量精力。
随着区块链技术的普及，存储在区块链上的数据量也在增加。 这是因为越来越多的人在使用该技术，并且每笔交易都会向区块链添加新数据。 此外，区块链技术已经从简单的汇款应用程序（例如涉及使用比特币的应用程序）发展到涉及在智能合约中实施业务逻辑的更复杂的应用程序。 这些智能合约可以生成大量数据，导致区块链的复杂性和规模增加。 随着时间的推移，这导致了更大、更复杂的区块链。
在本文中，我们以 Footprint Analytics 技术架构的阶段性演进为案例，探讨 Iceberg-Trino 技术栈如何应对链上数据的挑战。
Footprint Analytics 已将大约 22 个公共区块链数据、17 个 NFT 市场、1900 个 GameFi 项目和超过 100,000 个 NFT 集合编入语义抽象数据层。 它是世界上最全面的区块链数据仓库解决方案。
抛开区块链数据不谈，其中包括超过 200 亿行的金融交易记录，数据分析师经常查询这些记录。 它不同于传统数据仓库中的入口日志。
我们在过去几个月经历了 3 次重大升级，以满足不断增长的业务需求：
2.架构1.0 Bigquery
在 Footprint Analytics 之初，我们使用 Google Bigquery 作为我们的存储和查询引擎； Bigquery 是一个很棒的产品。 它速度极快，易于使用，并提供动态算术能力和灵活的 UDF 语法，可帮助我们快速完成工作。
然而，Bigquery 也有几个问题。
- 数据未压缩，导致成本高，尤其是在存储 Footprint Analytics 超过 22 个区块链的原始数据时。
- 并发不足：BigQuery只支持100个并发查询，不适合Footprint Analytics服务很多分析师和用户的高并发场景。
- 锁定 Google Bigquery，它是一个闭源产品。
所以我们决定探索其他替代架构。
3.架构2.0 OLAP
我们对一些非常流行的 OLAP 产品非常感兴趣。 OLAP 最吸引人的优势是它的查询响应时间，通常需要亚秒级的时间来返回海量数据的查询结果，并且它还可以支持数千个并发查询。
我们选择了最好的 OLAP 数据库之一 Doris 来尝试一下。 该引擎性能良好。 然而，在某些时候我们很快遇到了一些其他问题：
- 尚不支持 Array 或 JSON 等数据类型（2022 年 11 月）。 数组是一些区块链中常见的数据类型。 例如，evm 日志中的主题字段。 无法在 Array 上计算直接影响我们计算许多业务指标的能力。
- 对 DBT 和合并语句的支持有限。 这些是数据工程师对 ETL/ELT 场景的常见要求，我们需要更新一些新索引的数据。
话虽这么说，但我们不能将 Doris 用于生产上的整个数据流水线，因此我们尝试使用 Doris 作为 OLAP 数据库来解决我们在数据生产流水线中的部分问题，充当查询引擎并提供快速和高度并发查询能力。
不幸的是，我们无法用 Doris 替换 Bigquery，因此我们不得不使用 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，这样随着足迹分析的发展，与不同类型的处理引擎集成并不困难.
Iceberg 与 Spark、Flink、Trino 等计算引擎集成得很好，我们可以为每个指标选择最合适的计算。 例如：
- 对于那些需要复杂计算逻辑的人，Spark 将是不二之选。
- Flink 用于实时计算。
- 对于可以使用 SQL 执行的简单 ETL 任务，我们使用 Trino。
4.2. 查询引擎
随着 Iceberg 解决了存储和计算问题，我们不得不考虑选择查询引擎。 可用的选项不多。 我们考虑的替代方案是
在深入研究之前，我们考虑的最重要的事情是未来的查询引擎必须与我们当前的架构兼容。
- 支持 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 the 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
- 针对关键信号的实时警报和可操作通知，以支持投资决策
[ad_2]
Source link
