玩物数据流的逻辑设计

前言

数据的产出，从总的角度来说，是在规划和调整数据流向。

在互联网电商的体系中，用户在终端的操作，会拆分两条路线，一条为业务的数据，流经后端框架，关系型数据库等。一条为日志数据，通过文件采集或者消息中间件的方式来沉淀，这里的日志可能是前端行为日志，或者后端的接口日志。

数据集成：数据的采集阶段

一般在业务的初期，本身库的数据量不大，在业务数据流向离线大数据处理平台的过程中，是可以通过常见的集成工具来完成，其实现的逻辑还是基于扫表来完成，随着业务的逐渐发展，这样的方式不再满足需求，

• 第一，对于库的压力比较大。基于更新/创建字段进行的增量扫描一定程度上能缓解，但是无法规避，更别说在业务先行的道路上，这类增量标识字段可能未设置索引。
• 第二，资源的利用不充分。在这类同步中，集成的同步主要集中于凌晨，其他的时间段使用相对较低。其次对于计算资源来讲，在数据同步的时候，是处于闲置的状态。
• 第三，成本高。一般来说，出于安全的角度，以上说的库都是只读实例，规格和数量上都会带来一大笔成本。
• 第四，并发的问题，出于库的压力，集成任务以并行几条线进行压力分摊，避免同一时间段相同实例上运行的集成任务过多，压力过大。

当下针对这类场景，采用的方式改为消费 binlog，将集成的压力分摊在整天的时间段，凌晨时刻，启动合并脚本。提高计算资源的利用率，同时也能提高任务的并发度。而日志类的数据，采集基于消息中间件，是类似的方式。

数据处理：数据的过滤和沉淀

• 离线更多基于批处理，其数仓的各个层级往往采取同一存储方案。

• 实时则是基于流式处理，其中间过程表是放置在消息队列中存储，而维度表则是存储在支持高频访问kv框架上。

1. 结构的稳定性，即外界改变时候，结构自身受影响较少，正如三角形的结构是稳定的，当然三角恋不是。不同的层级划分和隔离，是为了保证在外界结构发生变动时候，只需要对应的处理层改动，不需要下游任何使用者都随之改动。这种可以类比后端开发中的枚举维护以及 mvc 框架。
2. 降低开发成本，结构化的信息能大大减少其他人在使用上的准备成本。
3. 资源的有效利用。这一点主要体现在于重复性工作的收口，提炼相同的使用场景，在上层直接进行统一处理。

流批本质上，殊路同归，只是数据不同场景下的处理方式，当下的一种发展方向是二者在存储层进行整合，共同维护同一份元数据。这样的方式能降低二者的交互成本。

数据应用：数据的下游

• 使用者划分：机器学习平台，业务前端展示，Bi可视化平台，人群画像系统等等。
• 交互：数据库，搜索引擎，api调用等。
• 数据的使用目的：描述性使用，相关性分析，预测性分析等。

下游输出上，离线和实时共同构建指标平台，当然想要达到这一点，需要结构和口径上维护比较完善。这方面更多是倾向用工具来实现，规范和准则依靠个体本身来实现还是比较弱的约束，容易导致最后结构和口径都是口口相传。

这里聊的更多的是数据的流向，如何实现数据价值细节介绍较少，我们仍在努力。借用看的文章的话就是在践行数据价值的这条道路上，每个数据人都在用自己的方式积极备考。