区块链ETL数据同步怎么做？踩过坑的实操笔记

导读： 搞区块链数据管道这三年, 从 DeFi 一直到 L2 结算层, 最直观的感受就是: 链上数据是纯追加的, 它没有更新操作, 也没有删除操作, 同时还带着确认延迟以及重组风险。...

搞区块链数据管道这三年, 从 DeFi 一直到 L2 结算层, 最直观的感受就是: 链上数据是纯追加的, 它没有更新操作, 也没有删除操作, 同时还带着确认延迟以及重组风险。如果你还拿传统的那些插入、查询、更新和删除的思维硬套到这儿来, 那么在第一周你就得返工, 重新调整方案。

ETL区块链数据怎么同步

目前遇到的主要困难并不是仅仅去把数据抓回来, 真正的难点在于到底需要等待多长时间才算是有效的。

针对这个问题, 考虑到以太坊生成一个区块的时间大概是12秒, 并且为了保证数据不可逆转我们需要等待后续的15个区块来确认, 而Solana系统所采用的最终性机制又与前者存在不同, 因此我现在采取的办法是为每一条区块链网络单独设置一个确认深度参数, 当数据的确认程度还没有达到设定的阈值时将其先存入临时表中, 只有当超过这个阈值之后才允许将其写入主干数据库, 以此来有效避免因发生区块重组而导致已经入库的数据被搅乱的情况。

在数据来源这一块, 早期他们自己建RPC来跑eth_getLogs这个环节, 当数据量变大了以后, 就转去用The Graph和Alpaca的索引服务了。

RPC比较合适做增量监控, 索引服务做历史回填的效率是很高的, 但是得注意API里面的强限制标签里的英文部分rate limit这个事儿, 一次性把全部的数据拉回来, 能够一下子就把配额给消耗完毕。

ETL区块链管道怎么搭

整个系统把结构分成了三个层级, 第一层是专门来监听新出来的区块以及最新发生的交易的, 第二层就是那个转换层, 它会负责去做地址的解析工作, 还会把不同代币的小数位进行统一化处理, 同时也能够处理多签交易被拆分的情况, 经过这些处理之后, 最后一步是把数据落地写进ClickHouse里面,或者是也支持直接写入Parquet格式的文件, 在开发的过程中, 那个转换层是最容易产生各种问题的地方, 非常复杂, 因为在一笔简单的交易里面, 往往会嵌套着十几层的内部调用逻辑, 如果不把这些细节全部展开去仔细核对的话, 根本就不能确保账目是对得上的。

另外还有一个漏洞存在这种情形: 在区块链上的数据结构定义仅仅是一种约定俗成的规则, 而并非一份必须严格遵守的正式声明。因此当智能合约执行了升级操作之后, 事件字段很有可能会悄悄发生变化。

数据管道在处理这些数据的时候, 应当具备对未知类型的事件进行容忍的能力, 而不是直接抛出错误从而中断整个流程。我在其中添加了兜底性的处理逻辑, 如果系统在输入中遇到从未见过的和事件签名标识符, 它会将这些异常数据放入死信队列之中, 以便后续由人工介入来进行补充运行和数据修复工作。

在进行区块链 ETL 工作的时候, 大家会发现这里头并没有那种一劳永逸就能解决问题的好办法。协议这东西是在不停迭代的, 链条也是会分叉的。所以管道本身就是一个需要人们一直去维护、去处理的活体。把容错能力做好, 把可回溯的功能弄扎实了, 这比去追求某一次流程能够顺利跑通更加重要。