轻量级数据中台构建思路

清醒 2023-07-27 03:04:50

好久没写文章了，一来是为了双11大考在做长期的优化、迭代，确实无力静下来写；二来想了很久这篇文章该写数据产品，数据中台还是写接口；最后决定把两种业务结合一下，后续会投入精力做新的业务，所以整理了下思路，写了这篇文章，也算是给自己这一年的工作暂画一个句号

大部分同学可能涉及业务层偏多，再一些做c端的同学甚至工作内容更依赖运营思维；不过我相信互联网公司里随处可听到接口这个词，我也随机问了身边的一些同行朋友，可能大家对接口这个词的定义就停留在了数据传输这个层面，往深层次考虑的话就会觉得api与产品关联不大“那不是技术该做的事吗？”——实则这话也没错，当然笔者因为是负责整体部门所以也必须要从产品角度去深挖api的实现逻辑。

今天我们不提偏技术的话题，比如http、tcp协议等，网络交互层面的逻辑有兴趣的同学可以自行百度，这方面的技术软文还是比较全面的，挑选写作方式更易自己理解的文档去阅读。

还是那句话——做产品，对于一个业务的入门很重要，往往决定你个人能力的天花板和整条业务线的走势，一定要有深挖底层实现的精神，树根扎实枝叶才能伸到更远更高的地方。

废话不多说，我们今天就从感知最明显的实现层来聊聊api，其实我个人刚接手这个业务时也有这个疑问，接口部门需要产品吗？产品能做什么呢？接口不就是获取数据吗？等疑惑。

其实换一种思路你可能会考虑的更容易，你可以把你的定义放在伪“数据产品”；相信这个词大多数同学也都有所耳闻，毕竟整个时代正在从it向dt发展，很多同学都想从事进来但觉得门槛过于神秘并不知道如何入手；市面上更不乏有各种文章提到国内各个大厂对于数据产品经理的职责要求，会让人觉得自己对数据产品是可望不可即的。

数据产品离不开三步骤，数据挖掘、数据清洗、数据分析

产品经理，产品经理网站

上图来源于某技术博文

当然数据获取目前也有很多轻量化便捷化的来源方式，最简单的是大家熟知的表格导入、爬虫等方式，以上方式第一是有数据安全的风险其次是不满足大型企业级项目的数据动力，提高个人工作效率是可以参考的；面对TB，EB乃至ZB，YB级别的数据量及各种大型分布式系统的数据治理场景，人工介入的能力显得是那么粉粉拳；面对这种场景会更偏向自动化，最普遍的应该就是通过接口达成数据传输的需求。

一、接口调度（即API）

通常接口离不开请求方和响应方，即request和response，面对时效性要求更强的场景会考虑到DTS等方式，也就是数据传输服务。

如何更高效更及时的传输数据也决定着后续数据分析的产出效率，从产品角度分析数据传输最直观的就是如何提高获取数据的时效和如何提高获取到的数据准确性；如果上游数据方是固定模型，最常见的是各大开放平台：往往上游会约定好固定的数据结构，将各种业务接口封装成不同开发语言的SDK提供给调用方使用。

那如何获取数据的问题就交给数据的获取方了，比较常见的也就是定时任务；如获取电商平台的订单数据，定时任务有很好的兼容性；搭建一套job集群，由一套调度集群来控制，如调度频次，并发量，调度周期等因素；根据不同的使用场景来控制job集群，从不同的上游接口获取到属于上游数据结构的不同数据集。

部分业务可能需要同步的处理机制，多数场景可能都需要异步消费结果，你可以选择建立属于适应自己公司的数据模型去承载结构不一的数据集，化“无序”为“有序”；将不同的数据结构归一为自己的数据结构，通过标准数据结构提供给下游系统方便下游做对应的数据分析需求，或者以结果为导向，以下游数据分析部门制定的数据模型去承接上游数据——当然这样复杂度较高，如下游系统较多也许场景复杂你可能会维护多套模型，最好的就是建立属于自己的标准数据模型；至于调度方式最基础的是定时请求的方式，如条件允许可以考虑“服务上云”等方式实现DTS的场景；根据接口流控、风控等因素来制定请求方式，以目前的资源情况做参考，选择合适的调度逻辑最大化实现业务部门的数据挖掘需求。

上游流控及自身资源允许的情况下考虑多线程的方式请求提高时效性，说起请求离不开的是接口幂等，关于幂等的逻辑也可自行百度（一般接口提供方就会兼容幂等，最常见的是支付系统）控制好请求参数也是学问；比如获取前一整年的订单数据，可参考接口性能及预估响应数据量和自身消费数据的能力来评判请求方式，也并不是一味的增加线程数据就是好的，一来会命中上游流控规则，二来对于自身负载也是负担；适度考虑调度逻辑时同时考虑接口自身的流控规则，在现有流控内将调度控制在最合理的范围，考虑到调度层以后需要兼容的是数据安全的问题。

国家也已发出过公告再者随着这个数据时代的洪口，数据安全是个严肃的命题，在拥有海量数据流的数据中台如何合理的控制数据存储的安全及数据流出入的安全性；一些普遍的加密算法应该是多数上游接口已经实现的，如加入token、sign等策略来提高数据获取时的门槛，同时在一定层面上控制数据的输出是给定到某些拥有合法“授权”的数据需求方。

产品经理，产品经理网站

上图取自某电商开放平台数据传输示意图

二、异构系统异常分析

如果说请求调度的逻辑有理解的话，那下面要考虑的也就是请求过程中的不确定因素（没有绝对稳定的接口）；如请求失败（异构系统网络层面失败或业务失败）会直接导致你的落库数据有差异，这里会涉及到数据治理的其中一大要素：数据一致性。

如出现以上情况需要考虑补偿机制，补偿时你需要考虑为什么补？

怎么补的问题，数据在什么场景产生的缺失，缺失的是哪部分数据，通过什么方式来补偿最为合理，值守化的补偿机制是必要的，自动化的补偿机制来最大化确保数据完整性、一致性。

这里提到了接口的不稳定性和值守，简单提及一下，因为接口的不稳定性所以一般后端会加入监控系统、值守系统。

三、数据存储

本段落简单概述下存储方面的思路，考虑存储方式前请先分析清楚你的数据流来源及来源方式，考虑清楚前置条件才能清楚对于你数据存储系统的要求，考虑到易用性或成本方面会涉及到考虑适用的数据库；数仓和所谓的“数据湖”数据库方面在评估未来业务增长量，数据量及数据使用需求模式等因素可以合理制定分库分表规则，合理完成数据隔离数据一致性，灾备等一系列保障措施；保证业务库宕机或者上游服务停滞时无缝切换备用库及备用服务能力，保证主业务的正常运行。

数据完成存储后根据数据分析需求考虑引入数仓技术，市面上也有很多提供laas能力的第三方平台，提供云存储云计算等基建能力；服务上云或许可以从一方面降低企业自身的维护成本，数仓内提供持久化数据存储及根据各个bu制定其适用的数据模型，以便业务需要时能及时更准确的提供数据分析服务。

产品经理，产品经理网站

上图取自知乎某博文

四、监控系统

最后监控系统和值守系统准备单独出来说，有同学会觉得监控系统很容易实现，这话不假，实现很容易，但是做好很难——全链路的监控体系是必要的，便于掌握系统健康状态；监控系统需要考虑的纬度简化后得出，你需要明确被监控的对象是什么？如何监控？监控后需要做什么？

我们一步一步来，被监控的对象大到整套系统以及接口交互的环节，小到某个job，在前期的产品流程图接口交互图上很容易定位到节点——哪些节点是业务依赖的往往优先级会被提高？哪些节点是有容错率的？

举个例子一般互联网系统都需要日志库，海量的日志写入如果都在你的监控范围内，那一定是个不成熟的监控程序；有些非核心流程日志，如部分用户行为日志写入失败即可丢弃，并不影响正常业务流转，如支付日志写入失败会直接对后续的业务造成影响那这个节点就值得被监控。

如果你一定找到了需要被监控的节点那你可以考虑第二步通知方式，通知方式最普遍的是群消息、短信、邮件或者更及时的电话；不同场景的监控需要推送给不同的处理人员，如服务器异常需要推送给运维人员；业务异常需要推送给业务线产品技术人员，选择合理的推送渠道和推送方式会让整个作业流程更顺畅，以达到异常能够及时得到对应人员的处理，也不至于影响到处理人员的正常生活。

可以考虑一下如果监控系统每天推送10条给到研发人员，可能他可以很高效的处理掉每一个异常；如果每天推送100条消息给到研发人员，作为心智的角度考虑人迟早会倦怠处理，就形成了恶性循环；异常越推越多，异常无人处理那监控系统也丧失了能力。

最后提供一个监控系统搭建的几个要素：