复杂业务是从数据搜集者的角度来看的，也就是说，在线下要收集到整个业务流程的各个信息经常需要将多个来源的日志、binlog、消息队列等的数据join在一起，形成一个所谓的“宽表”。

　　之所以会出现这样的场景一般有如下原因：

　　业务逻辑较为复杂，无法在一个大服务里维护，只能拆解为多个模块，每个处理自己相关的部分。

　　由于请求量比较大，将所有状态和历史信息都放在一个数据库表中会对数据库的压力比较大，所以一般会按字段关联性和访问服务的耦合进行拆解，拆分为多个逻辑表。

　　还有一些业务历史信息，因为业务本身不再需要访问，都放在数据库中不经济，往往会形成日志或日志消息，等待异步/离线分析。

　　实时监控指标与特征

　　从生产方式的角度上来说，实时监控与实时特征其实是同一类，差别主要就在到底是人来观察，还是给线上模型/程序来使用。

　　虽然工程实现的时候会尽量倾向于拆解和解耦，但大部分业务相关的监控指标和业务特征的粒度都比最终工程拆解的粒度要大，所以经常需要融合多个来源的数据之后才能产生。这时我们不光要在线下做数据join，还经常需要在线上实时的join各来源的数据，形成线上实时宽表数据。

　　在一些不太复杂的系统中，这种逻辑可能会直接在数据使用方实现，数据使用方直接请求各个原始数据源并实时计算响应的结果，这不可避免地增加了线上存储系统的读压力。

　　但直接和线上业务使用同一个存储系统是不经济的，因为：

　　线上业务主要关心的业务状态的一致性，并且业务需要的读写性能能够满足业务流量的需求。

　　实时监控大多数时候不关心单个case级的异常，而是关心一段时间内的整体状态分布。不需要太强的一致性，对时效性有一定要求（分钟级）。

　　由于大部分实时特征也都不需要非常严格的准确性，模型能够自动承受一定范围内的抖动，所以实时特征的场景下，也不需要严格的一致性，时效性方面只要不影响模型最终效果就好。

　　所以很明显，结论是实时监控和特征没必要和线上业务使用相同的存储系统。

　　业务实时状态视图

　　考虑到监控和特征都是经常变动的，所以为他们服务的存储方式在性能能接受的情况下，最好是直接保存所有最细粒度的订单级数据，由每个指标来定义聚合方式。

　　那么这个在逻辑上就是一个实时更新的数据宽表，考虑到需求方没有强一致的需求，可以接受数据上有轻微的延迟和不一致。

　　在实现层面可以：

　　直接使用线上数据库的从库

　　实时计算join所有数据源

　　单独为此准备的宽表数据库，当接收到业务状态变更时进行更新等，根据具体场景选择合适的方案。

　　标签：车底监控