Footprint Events Domain上线流程实测日记-20220602

新手入门

新手入门看readme

项目代码结构如下：

这里的问题：
readme 没有 告诉我， 如果要新增表，需要进入src\domain里面去新增events这个领域，是同事口述告诉我的。如下图，src路径下，还有个readme，好的，继续看readme

以下摘抄至src/readme.md

新增指标流程指引

1. 和数据产品负责人讨论一个新指标该放到哪个领域
2. 梳理该领域的数据流程，并输出流程图（使用 puml，参考 src/domain/token_info/token_info.puml）
3. 实现每一个 Block，并在本地完成调试
4. 实现基础测试 （参考 src/domain/token_info/blocks/token_info.yml）
5. 实现业务逻辑测试 （示例准备中）
6. 跑出少量 beta 数据，并使用该指标制作 Dashboard ，检查并验收
7. 跑出全量数据，并发布指标
8. 制作该指标的 Dashboard，展示该指标的覆盖和质量等情况
9. 提交 PR，Review 后进入生产环境，开始日增

装环境啥的准备工作就不说了，谁装谁知道。好，我们开始讨论领域设计。

领域设计

events的问题前置有讨论过，就是单独作为events领域，接下来画流程图。
第一版长这样：

其实第一版也改了蛮多次，这里先不说。

这里还只是展示了我可能需要用于洗DeFi流水的event，如果是所有event，那就太多了，我一个人真的写不完。而且后来发现，events的开发流程其实比较统一，所以最后抽象成这样：

注意这里的表命名，{protocol_name}.{contract}_event_{name}，看起来非常合理，因为涉及到3个变量，protocol, contract & event name, 但是也给后面留了坑，先mark一下。

添加Event configs

设计完成，进入开发阶段，但是由于历史原因，填写event config的入口并不在src目录下，还在旧的basic_src目录下(所以我前面的图说他是第二入口)。我是怎么知道的？问人呗。而且入口还这么深：

当然，这个defi_parser也是有个readme的，只不过在语雀上。需要先执行一段命名，才会生成上图的aave文件目录和里面的文件。

往aave.yml文件里，添加如下配置：

day: 7
protocol: AAVE
protocol_slug: aave
version: '1'
events:
- chain: Avalanche
  contract_address: '0xb6a86025f0fe1862b372cb0ca18ce3ede02a318f'
  version: '1'
  abi: '{"anonymous": false, "inputs": [{"indexed": false,"internalType": "bytes32","name": "id","type": "bytes32"},{"indexed": true,"internalType": "address","name": "newAddress","type": "address"}],"name": "ProxyCreated","type": "event"}'
  name: 'LendingPoolAddressesProvider_ProxyCreated'

可以看到name我是按照上面的规范进行命名的，protocol忽略，因为在protocol_slug里有体现了，LendingPoolAddressesProvider是这个合约的名字，官方提交的，这个事件的名字是ProxyCreated，在abi的name属性里，可以确认。

这里，每个event都需要配置上去，嗯，交给社区吧，社区的力量是巨大的！ 开完后面的流程，你再看能不能交给社区。

配置完成后，按照语雀，再run一次命令，要去另外一个文件路径找到根据这份配置生成的yml和sql文件。如下：

然后把新生成的这两个文件，复制回src目录下：

DBT

DBT确实是一个好工具，但是使用好它的前提，就是掌握它。开源的话，社区一定会有学习成本的。

昨天刚分享了SQL入门，大家应该都知道 select * from table了吧
现在我们来看看SQL的DBT升级版：

SELECT * FROM {{ source('crypto_avalanche_basic', 'topic_logs') }}

技术的同事应该看不懂也能大概猜到什么意思。所以代码问题不大，我觉得问题是，当这个表在项目里没有被登记注册的时候，我怎么知道去哪里登记它，还是那句话，问呗。在下图的路径中注册登记需要用到的新表：

BigQuery

做到现在，终于在BQ上看见这张event表，然而，他并不在FP的数据集下面，它存在另一个数据集下，需要手动创建视图，把数据集映射到FP的数据集Gaia下面。注意，是手动！一个event是手动，10个也是手动，event表可能有多少？去看看Dune呗。

Doris

Doris也是个好东西，让我们逐渐与BigQuery解绑，用户能在FP用到更多的数据。
凡是好东西都有学习成本的，但是值得吗？我认为值得。同事说学习成本有点高，我说不存在的，学习成本高是不存在，只有我学习效率低的问题，活该我加班学，公司带薪让你学技能，哪有这么好的公司？

由于底层数据是在BigQuery上生产，所以需要同步到Doris，Footprint上才能看到。

Doris同步的代码在哪里？什么？在另外一个项目？又要装一次环境？？？？
同事整理Doris同步的文档，整理了3天(听说)，总算把步骤压缩到3步。

继续按文档操作呗。看到如下注意事项

唯一键设置：

需要设置好唯一键，如果没有则需要在 BQ 的实体表上新增 UUID

BQ 兼容性：

BQ 数据 int 或 bignumber 类型需要注意 Doris 是否能存放下，如果是大数类型，在 Doris 需要使用 largeint 存放，避免在 Doris 出现溢出问题而导入失败

Metabase 兼容性：

字符类型需要使用 varchar在 Metabase 才能被索引搜索，使用 string 则不能，同时注意 varchar 不需要设置长度大，根据字段实际业务，原则上够用就好，以下是一些参考：
block_hash varchar(200)
token_symbol varchar(200)
address varchar(100)
token_slug varchar(100)

唯一键：好险，我不用新增uuid，不然前面的操作我还要重来？？？
BQ 兼容性 和 Metabase 兼容性：好一个 “根据字段实际业务”， 意思就是，每一个event我都需要为了兼容性去调整每个字段的数据类型呗，是每一个，每一个，手动！！

Doris创建表的代码改好了，一跑，报错了，同事说，你去测试环境用IDE跑一下，语法错了。明白，就是要调试呗，先装个DBeaver，配置测试库。run了几次，用以身试法的方式，帮大家总结出了如下最佳实践：

1. Doris Best Practice

2. ENGINE=olap
   UNIQUE KEY(transaction_hash, log_index, block_timestamp) – UNIQUE KEY的位置放在这里，放其他地方报错
   DISTRIBUTED BY HASH(block_timestamp)

3. 设为unique key的字段，在创建表时，字段顺序要排在前面，distributed by里的字段，也一定要列入unique key

万事俱备，正当我准备来一发时，Doris又报错了：

SQL 错误 [1103] [42000]: errCode = 2, detailMessage = Incorrect table name ‘aave_avalanche_parse_lending_pool_addresses_provider_proxy_created_event’

表名错了吗？哪里错了？问Doris的开发人员，哪里错了，他说我表名错了，英文我不会看吗？你倒是说我哪里错了啊？！！！还是我们同事有经验，说我表名过长了，让我换个短的试试，我一试就成功了，那么问题来了，还记得前面说过的坑吗？所以我是需要从那个地方开始重新做一遍吗？！！！表名已经是按规范来设计的了，要改短，改短的规范是啥？我要找谁讨论确定？！！一颗绊脚石被我踢开了，但是我之前走的路塌了？

日小结

写的有点high了，什么？我早上9点发的同步任务，现在11点半还在pending中？就2行数据。我的KR又要完不成了。。。活该我加班，工作都没完成，写个毛的工作日记啊，你不加班谁加班？

后记

pending的原因，是table_info.json的配置中，select_key需要一定要选时间。
另外，如果要让FP左侧菜单栏看到该表，还需要调一个API