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

上游流控及自身资源允许的情况下考虑多线程的方式请求提高时效性，说起请求离不开的是接口幂等，关于幂等的逻辑也可自行百度（一般接口提供方就会兼容幂等，最常见的是支付系统）控制好请求参数也是学问；比如获取前一整年的订单数据，可参考接口性能及预估响应数据量和自身消费数据的能力来评判请求方式，也并不是一味的增加线程数据就是好的，一来会命中上游流控规则，二来对于自身负载也是负担；适度考虑调度逻辑时同时考虑接口自身的流控规则，在现有流控内将调度控制在最合理的范围，考虑到调度层以后需要兼容的是数据安全的问题。
国家也已发出过公告再者随着这个数据时代的洪口，数据安全是个严肃的命题，在拥有海量数据流的数据中台如何合理的控制数据存储的安全及数据流出入的安全性；一些普遍的加密算法应该是多数上游接口已经实现的，如加入token、sign等策略来提高数据获取时的门槛，同时在一定层面上控制数据的输出是给定到某些拥有合法“授权”的数据需求方。

文章插图
上图取自某电商开放平台数据传输示意图
二、异构系统异常分析如果说请求调度的逻辑有理解的话，那下面要考虑的也就是请求过程中的不确定因素（没有绝对稳定的接口）；如请求失败（异构系统网络层面失败或业务失败）会直接导致你的落库数据有差异，这里会涉及到数据治理的其中一大要素：数据一致性。
如出现以上情况需要考虑补偿机制，补偿时你需要考虑为什么补？
怎么补的问题，数据在什么场景产生的缺失，缺失的是哪部分数据，通过什么方式来补偿最为合理，值守化的补偿机制是必要的，自动化的补偿机制来最大化确保数据完整性、一致性。
这里提到了接口的不稳定性和值守，简单提及一下，因为接口的不稳定性所以一般后端会加入监控系统、值守系统。
三、数据存储本段落简单概述下存储方面的思路，考虑存储方式前请先分析清楚你的数据流来源及来源方式，考虑清楚前置条件才能清楚对于你数据存储系统的要求，考虑到易用性或成本方面会涉及到考虑适用的数据库；数仓和所谓的“数据湖”数据库方面在评估未来业务增长量，数据量及数据使用需求模式等因素可以合理制定分库分表规则，合理完成数据隔离数据一致性，灾备等一系列保障措施；保证业务库宕机或者上游服务停滞时无缝切换备用库及备用服务能力，保证主业务的正常运行。
数据完成存储后根据数据分析需求考虑引入数仓技术，市面上也有很多提供laas能力的第三方平台，提供云存储云计算等基建能力；服务上云或许可以从一方面降低企业自身的维护成本，数仓内提供持久化数据存储及根据各个bu制定其适用的数据模型，以便业务需要时能及时更准确的提供数据分析服务。

文章插图
上图取自知乎某博文
四、监控系统最后监控系统和值守系统准备单独出来说，有同学会觉得监控系统很容易实现，这话不假，实现很容易，但是做好很难——全链路的监控体系是必要的，便于掌握系统健康状态；监控系统需要考虑的纬度简化后得出，你需要明确被监控的对象是什么？如何监控？监控后需要做什么？
我们一步一步来，被监控的对象大到整套系统以及接口交互的环节，小到某个job，在前期的产品流程图接口交互图上很容易定位到节点——哪些节点是业务依赖的往往优先级会被提高？哪些节点是有容错率的？
举个例子一般互联网系统都需要日志库，海量的日志写入如果都在你的监控范围内，那一定是个不成熟的监控程序；有些非核心流程日志，如部分用户行为日志写入失败即可丢弃，并不影响正常业务流转，如支付日志写入失败会直接对后续的业务造成影响那这个节点就值得被监控。
如果你一定找到了需要被监控的节点那你可以考虑第二步通知方式，通知方式最普遍的是群消息、短信、邮件或者更及时的电话；不同场景的监控需要推送给不同的处理人员，如服务器异常需要推送给运维人员；业务异常需要推送给业务线产品技术人员，选择合理的推送渠道和推送方式会让整个作业流程更顺畅，以达到异常能够及时得到对应人员的处理，也不至于影响到处理人员的正常生活。
可以考虑一下如果监控系统每天推送10条给到研发人员，可能他可以很高效的处理掉每一个异常；如果每天推送100条消息给到研发人员，作为心智的角度考虑人迟早会倦怠处理，就形成了恶性循环；异常越推越多，异常无人处理那监控系统也丧失了能力。