数据产品|轻量级数据中台构建思路数据|构建|api|数据结构|思路

编辑导语：这几年不少企业都做起了中台业务，搭建自己的数据中台；数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务；本文作者分享了关于轻量级数据中台构建思路，我们一起来看一下。

文章插图
好久没写文章了，一来是为了双11大考在做长期的优化、迭代，确实无力静下来写；二来想了很久这篇文章该写数据产品，数据中台还是写接口；最后决定把两种业务结合一下，后续会投入精力做新的业务，所以整理了下思路，写了这篇文章，也算是给自己这一年的工作暂画一个句号
大部分同学可能涉及业务层偏多，再一些做c端的同学甚至工作内容更依赖运营思维；不过我相信互联网公司里随处可听到接口这个词，我也随机问了身边的一些同行朋友，可能大家对接口这个词的定义就停留在了数据传输这个层面，往深层次考虑的话就会觉得api与产品关联不大“那不是技术该做的事吗？”——实则这话也没错，当然笔者因为是负责整体部门所以也必须要从产品角度去深挖api的实现逻辑。
今天我们不提偏技术的话题，比如http、tcp协议等，网络交互层面的逻辑有兴趣的同学可以自行百度，这方面的技术软文还是比较全面的，挑选写作方式更易自己理解的文档去阅读。
还是那句话——做产品，对于一个业务的入门很重要，往往决定你个人能力的天花板和整条业务线的走势，一定要有深挖底层实现的精神，树根扎实枝叶才能伸到更远更高的地方。
废话不多说，我们今天就从感知最明显的实现层来聊聊api，其实我个人刚接手这个业务时也有这个疑问，接口部门需要产品吗？产品能做什么呢？接口不就是获取数据吗？等疑惑。
其实换一种思路你可能会考虑的更容易，你可以把你的定义放在伪“数据产品”；相信这个词大多数同学也都有所耳闻，毕竟整个时代正在从it向dt发展，很多同学都想从事进来但觉得门槛过于神秘并不知道如何入手；市面上更不乏有各种文章提到国内各个大厂对于数据产品经理的职责要求，会让人觉得自己对数据产品是可望不可即的。
数据产品离不开三步骤，数据挖掘、数据清洗、数据分析。
当然数据获取目前也有很多轻量化便捷化的来源方式，最简单的是大家熟知的表格导入、爬虫等方式，以上方式第一是有数据安全的风险其次是不满足大型企业级项目的数据动力，提高个人工作效率是可以参考的；面对TB，EB乃至ZB，YB级别的数据量及各种大型分布式系统的数据治理场景，人工介入的能力显得是那么粉粉拳；面对这种场景会更偏向自动化，最普遍的应该就是通过接口达成数据传输的需求。
一、接口调度（即API）通常接口离不开请求方和响应方，即request和response，面对时效性要求更强的场景会考虑到DTS等方式，也就是数据传输服务。
如何更高效更及时的传输数据也决定着后续数据分析的产出效率，从产品角度分析数据传输最直观的就是如何提高获取数据的时效和如何提高获取到的数据准确性；如果上游数据方是固定模型，最常见的是各大开放平台：往往上游会约定好固定的数据结构，将各种业务接口封装成不同开发语言的SDK提供给调用方使用。
那如何获取数据的问题就交给数据的获取方了，比较常见的也就是定时任务；如获取电商平台的订单数据，定时任务有很好的兼容性；搭建一套job集群，由一套调度集群来控制，如调度频次，并发量，调度周期等因素；根据不同的使用场景来控制job集群，从不同的上游接口获取到属于上游数据结构的不同数据集。
部分业务可能需要同步的处理机制，多数场景可能都需要异步消费结果，你可以选择建立属于适应自己公司的数据模型去承载结构不一的数据集，化“无序”为“有序”；将不同的数据结构归一为自己的数据结构，通过标准数据结构提供给下游系统方便下游做对应的数据分析需求，或者以结果为导向，以下游数据分析部门制定的数据模型去承接上游数据——当然这样复杂度较高，如下游系统较多也许场景复杂你可能会维护多套模型，最好的就是建立属于自己的标准数据模型；至于调度方式最基础的是定时请求的方式，如条件允许可以考虑“服务上云”等方式实现DTS的场景；根据接口流控、风控等因素来制定请求方式，以目前的资源情况做参考，选择合适的调度逻辑最大化实现业务部门的数据挖掘需求。