交易|方法论、工具与团队:如何成为一名 Web3 数据分析师?( 二 )


4、之后 , 我们可以随时查看公众查询/仪表板 , 看看提案如何创造出更具竞争力的产品 。
5、在未来 , 如果另一个 DEX 出现(或升级到一个新版本) , 这个过程将重复 。 有人将创建插入查询来更新这个表 。 这将反过来反映在所有的仪表板和模型(没有任何人必须回去和手动修复/更改任何东西) 。 任何其他分析师/科学家都可以以别人已经完成的工作为基础 。
由于共享的生态系统 , 讨论、协作和学习在一个更紧密的反馈循环中发生 。 我承认这有时会让人难以承受 , 我认识的分析师基本上都在轮换数据耗尽 。 然而 , 只要我们中的一个人继续推动数据向前(例如 , 某人创建了插入 DEX 查询) , 那么其他人都会受益 。
它并不总是必须是复杂的抽象视图 , 有时它只是实用功能 , 如使它容易搜索 ENS 反向解析器或工具的改进 , 如自动生成大多数 graphQL 映射与一个 CLI 命令!所有这些都可以被每个人重用 , 并且可以在某些产品前端或您自己的个人交易模型中进行 API 的使用 。
虽然这里开启的可能性是惊人的 , 我确实承认 , 轮子还没有平稳地运行 。 与数据工程相比 , 数据分析师/科学领域的生态系统仍然很不成熟 。 我认为有以下几个原因:
数据工程是web3多年来的核心焦点 , 从客户端 RPC API 的改进到基本的 SQL/graphQL 聚合 。 像 theGraph 和 Dune 这样的产品就是他们在这方面所付出努力的例证 。
对于分析师来说 , 要理解 web3 独特的跨协议关系表是非常困难的 。 例如 , 分析人员可以理解如何只分析 Uniswap , 但却很难在混合中添加聚合器、其他 DEXs 和不同的代币类型 。 最重要的是 , 实现这一切的工具直到去年才真正出现 。 数据科学家通常习惯于收集原始数据并独自完成所有的工作(建立他们自己的管道) 。 我认为他们不习惯在开发初期与分析师和工程师进行如此密切和公开的合作 。 对我个人来说 , 这花了一段时间 。
除了学习如何协同工作之外 , web3 数据社区还在学习如何跨这个新的数据堆栈工作 。 你不再需要控制基础设施 , 或者慢慢地从 excel 构建到数据池或数据仓库 , 只要你的产品上线 , 你的数据就会到处上线 。 你的团队基本上是被扔到了数据基础设施的最深处 。
数据工具以下是一些数据工具汇总:

下面我们看看每种类型以及用法:
1、交互+数据源:这主要用于前端、钱包和较低层次的数据摄取 。 1
.1、客户端:虽然以太坊的底层实现是相同的 , 但每个客户端都有不同的额外特性 。 例如 , Erigon 对数据存储/同步进行了大量优化 , Quorum 支持隐私链 。
1.2、节点即服务:你不必选择运行哪个客户端 , 但使用这些服务将为你节省维护节点和 API 正常运行的麻烦 。 节点的复杂性取决于你想要捕获多少数据(轻节点→全节点→归档节点) 。
2、查询+数据映射:这一层中的数据要么作为 URI 在合约中引用 , 要么来自使用合约 ABI 将交易数据从字节映射到表模式 。 合约 ABI 告诉我们合约中包含哪些函数和事件 , 否则 , 我们只能看到部署的字节码(没有这个 ABI , 你无法反向工程/解码合约交易) 。
2.1、交易数据:这些是最常用的 , 主要用于仪表板和报告 。 theGraph 和 Flipside API 也在前端中使用 。 有些表是合约的 1:1 映射 , 有些表允许模式中额外的转换 。
2.2、元数据“协议”:这些并不是真正的数据产品 , 而是用于存储 DIDs 或文件存储的 。 大多数 NFT 将使用其中的一个或多个数据源 , 我认为今年我们将开始越来越多地使用这些数据源来增强我们的查询 。