数据|线下业务数据体系搭建（三）：跨部门数据交互体系搭建( 二 ) marvell|产品|bom|融资|清华|芯片

从上面的事实记录模式看，两者时间实际只有时间记录颗粒度的差距，线上订单系统的记录能正常精准到秒，但实际以线下行为（且行为的记录主体是催收员，和线上的行为记录主体用户完全是两套不同的记录角度），这种颗粒度差距看起来差距不大，但是在实际快速响应的风控系统中，会产生很大的影响。
简单来说，用户在经过催收员沟通之后在一点时间内回款，这个时间差从日期来看是天数的差距，而不是小时、分钟的差距，这个回款天数差能够用于实际评估用户的还款能力。
举个例子，用户在接到催收电话后马上还款，那可以根据模型估计用户的还款行为是代表其有较强的还款能力的，这种有借款行为且有高还款能力的用户在风控上就可以相对提高用户的额度。
同样的，用户如果都在催收员跟进当天内进行还款，又可能代表了不同行为特征的用户。如果均按“0天”进行计算，就需要从别的维度补充这部分数据，可能是催收员进行跟进的文本维度，这就需要NLP介入进行判断。
某种程度上来说，更复杂的模型让各个系统之间的握手次数和交互流程更为复杂，这和实际业务上的追求就相悖了。
所以，在各个系统的交互上，更需要将所有的交互结构、尤其是数据颗粒度，数据产生的逻辑进行统一。
这就需要从公司层面上进行业务线梳理，明确哪一条是核心业务线，根据核心业务线的用户流程去进行各个系统之间的改造。不然就像我刚刚说的，不同的系统之间有不同的服务目标，这是好事，但过多的服务目标会导致底层数据的存储逻辑不同意，在高并发的核心业务部门会导致大量数据被无效拉取计算，这就不利于核心业务线的增长。
二、数据交互时效除了数据交互口径可能会产生不一致冲突的情况，数据交互时效也会对不同业务系统产生差异。
几乎大部分涉及线上业务的公司都会有数仓和大数据这两个部门。从公司业务反馈来说，一般数仓是历史数据的留存处置，大数据用于线上实时业务数据的更新计算。
从某种意义上，传统数仓的模式也更容易按统一的业务规范，按数据仓库工具箱：维度建模（第二版）中Kimball说：“我们花了二十年的时间往数据库中加入数据，现在该是拿出来使用的时候了。”数仓对公司整体业务的发展实际上是起到底层数据夯实奠基的作用。
大数据部门的作用则更多体现在实时数据的生产，由于传统数仓本身依托于大数据量级的关系型数据库建立，很难大量、同时提取数仓的数据去做到即时性的分析，而从用户的维度则更希望看到实时的结果（这种需求在涉及供需、金额变化的业务场景会更为突出，像12306的实时车票计算系统），突出的特点就是“及时性”、“快”，高速响应用户的所有定制化需求，用户的这种需求在互联网消金公司显得尤为关键。
尤其是当用户收到我方催收作业下还款的场景下，会更希望在APP前端展示的欠款产生变化，这种及时性的需求就会要求系统能直接调用大数据的接口完成实时账单的计算。
这时候就需要考虑如何将这部分数按统一的规则落库到数仓中，去记录用户各个事件节点收到影响的行为变化，就需要数仓留存的数据是按业务流转节点去进行记录的，这些互相之间数据的交换。
如果在事件随时发生就随时交换，会极大影响系统的性能（这种大量判断的逻辑会极大影响交互逻辑，如果发起交互超时了未报错，会导致实际收集的数据不全等情况），这种情况并不只发生在某个系统中，而会出现在每个系统和数仓、大数据的交互中，而一个系统尚且会碰上数据交互时间、事件维度不统一的情况，多个系统想要完成两者逻辑的汇总，更是难上加难。