建模杂谈系列171 APIFunc继续实践-数据处理体系2

说明

题外话：最近博客的审核比较奇怪，算了，也懒得吐槽了：

• 1 我写博客的本义是梳理一些技术上的细节，顺便分享给可能需要的人。
• 2 我在本站的计划是写到1000篇左右（搞全栈，确实很多内容），然后就不写了。
• 3 会员到期估计也不续了，略微对c站失望。

言归正传，现在继续谈APIFunc实践的事。总体上这几天还是有不少进展的，整体项目完整跑完。F-Score大概94，还是不错的，在不太动脑的情况下实现了一次逻辑复现。

从产品的角度上，待完成的功能越来越清晰。最先要解决的是编辑与监控。这次开发过程中最耗时的是对着图一个个的粘贴，然后改代码，大量的手工复制代码，这在未来是不可接受的，所以要改。另外一个主题是监控，了解流的状态，了解静态数据点的状态，以及了解问题数据的状态。

内容

以下分为回顾和展望两部分，看看到目前为止做到了什么，以及接下来要做什么。

1 Wrapped Up

完成了处理流的全过程

完成处理的全过程只是一个起点，而非终点。因为首先我们假定数据处理总是存在缺陷和问题的，所以重点是：

• 1 处理框架是否是健壮而灵活的。主要体现在运行时吞吐可以达到设计要求(单机1400万~1亿/天)，并且在出现错误时可以很轻易的找到并修改
• 2 是否随时可以了解系统的运行状态，并且可以很容易或者很清晰的去干预。

所以目前的状态很好，绝大部分(95%)完成，说明系统的底子是可以的。而系统遗留问题不是个例，而是通例，简单来说我并不该怕去debug。

原始数据281,847,规则处理留下的元数据是280,671,最终输出的数据是262,276。因为整个过程伴随着开发调试，所以我也不太清楚为什么规则会与输入差几百条。但这样很好，查差异是系统必须具备的功能。

而元数据比输出数据多则是本身固有的设计，其实我也已经大致知道了问题出在哪里。关键是我可以很容易的把数据挑出来，调试，然后再次运行这部分。

然后看看队列：这个是在处理时的

这是任务完全处理完毕的，非常干净

在本次开发中，我很大一部分精力在于构建队列(S),数据库(M)和程序§之间的通用交互逻辑与工具，这个是比较看的见的部分。然后还有一系列的规范与约定，这些软的部分反而更要梳理好。

简单的挑三个要点：

• 1 主键。这个比我想象中的要重要，从原始数据开始，怎么构成主键就比较难，这需要对业务的理解。在数据库中，主键被设为了唯一索引，它使得体系内所有的静态数据点都有一个唯一对应。即使在不相干的队列，主键的命名得当的话可以避免错误的串扰。例如A队列的数据因为笔误查到了B队列，但是由于主键命令规则不同，并不会影响到B队列（获取后被丢弃，日志里能看到一些信息）。
• 2 通道。通道使得数据可以多次被不同任务处理，甚至还可以借用通道表达主键的差异。默认的_ch001是整个流的基础，如果我要知道数据差异，则创建一个新的通道_ch002_step1_ruleresult进行比对。这对于执行全表大量数据是一个可靠有效的方法。
• 3 瀑布图。这次在一个图中就完整了整个任务，抽象上和listofdict是一个原理，所以APIFunc的处理流程图是一个瀑布图。横向上分布若干变量（进行编号），纵向则是长短不一的处理流程。

2 Next

通过前端完成最后的工具化

编辑器

我需要一个基于JS的代码编辑器，这样每次我就不用拷贝代码了，有很多共同的基础函数我称为根函数。甚至还可以复制流。通过前端的编辑器，我只需要进行简单的修改，并直接在页面上进行调试（实质上是将代码和执行内容向我的后端API请求）

然后我就发现了下面这个组件，顺利的话下周就会开始嵌入。
Monaco Editor

互动表单

除了函数本身的编辑，还有就是依赖关系以及参数的设定。这部分我已经完全参数化，然后就需要使用交互式表格来进行快速的编辑。

目前单个表格与数据库的交互开发已经完成，还差灵活的参数化就可以通用，最初我是计划用于所有网内主机的数据库交互的，当然也包括APIFunc的参数。

还差表格通用化，顺利的话本周末我应该会完成。