架构分享|系统服务化构建-数据解读通用模型

本篇文章旨在讨论常见的数据统计编程模型以及数据解读通用的解决方式.

首先我们先看一张完整的流程图，再依次展开各个模块的技术实现细节

 

整个流程我们可以分为元数据收集，数据加工，数据存储，数据分析和数据展现四个部分

元数据收集

元数据是用来描述业务的最小单位，任何涉及数据统计及处理的业务的都是从元数据收集开始的。元数据既可以是从其他数据源抽取同步而来，也可以从业务终端收集而来。

业务终端是指生产环境下的业务行为的触发点，比如智能手表系统中的用户佩戴行为就是业务终端，佩戴智能手表的用户的一次摆手或者走路就是一次元数据的触发点，共享单车系统中的用户骑行行为也是一次元数据的触发。

假设我们的系统是一个物联网系统，那么负责元数据收集的功能组件一般由传感器完成。

 

 

数据加工

在涉及到数据处理的相关系统中，数据加工是数据解读整个过程中的第二部分，主要任务是对终端收集到的数据进行初次加工，过滤明显的异常数据，也就是严重的噪音数据，近而进行第一次持久化处理。

下面举两个例子

在APP端-Server端的架构中，这里的持久化存在APP端。

在传感器-Server端的架构中，这里的持久化存在传感器的闪存中。

当然持久化的时间和存储能力视具体情况而定。

在工业生产环境及大数据量，并发情况下，以上的架构会引入消息Hub或者消息队列的角色

APP端--Server  ==》APP端-MQ-Server

传感器-Server端  ==》传感器-MQ-Server端

 

 

Broker就是服务消息存储和分发调度的消息中心，注意作为数据解读的第二部分，数据加工只能完成以上图解的客户端角色的任务，也就是只负责发送数据到应用程序服务器或者MQ消息中心

以上是元数据流转的整体流程，接下来介绍数据加工的输出介质和格式

接上文提到数据持久化继续深入阐述

在常见的数据加工阶段，系统会对初加工的数据进行存储，存储的介质是本地数据库或者内存闪存。本地数据库以sqlite最为推荐。按照业务规则会以小时，天，日，周，月等不同的维度进行持久化。各个统计维度会成为更高维度的数据基础，比如 以天为维度的统计计算是以小时的统计结果为基础。

那么问题来了，已生成的数据会涉及到重新统计分析和覆盖写入吗？

除了严格意义上的财务系统以外，这里的统计分析在系统中更多充当流水数据的作用，一旦统计完成，不会再次更新和覆盖重写。

以上的统计都是同步机制吗

很确定的说，不是。同步和异步并存，遵循同步和异步的使用场景要求，更多场景下，配合上午说到的流水数据的属性，以异步模式处理更多。

数据存储

数据存储以最终持久化数据为准，以数据库的形式存储。元数据的数据类型包括结构化数据，非结构化数据，半结构化数据。数据库对应包括关系型数据库，非关系型数据库。如何选型，取决于业务类型等多种因素。

实际上，在这个宣扬大数据，人工智能的时代，涉及到数据处理的应用系统对于数据库的存储都是以redis，mongoDb为标配的。大量的不确定的元数据的存储，处理，分布式计算，更适合使用MongoDB，增强应用系统的稳定性和后续扩展弹性，而缓存，排名，队列的相关场景，Redis更为擅长。

 

数据分析与呈现

数据分析是数据处理的核心，以上从数据采集开始的各个部分都是为了这一步的数据分析做准备。

下图是整个数据分析处理的基本处理方式

 

 

何为数据产品

数据产品就是产品经理基于已有的数据设计出来以数据为主要展示内容的产品。我们暂把数据产品也归为互联网产品，那么数据产品会有两个特点

1 主要以数据来实现产品的功能

2产品呈现给用户的最终目的是更有效，更直观的解读原始数据

例如以下两张图

 

数据解读的结果最终需要以产品的形式来呈现。无论报表，趋势图，甚至是列表，页面，都是展示形式不同而已，核心还是数据。数据的价值也就在整个数据处理的过程中体现。

本篇文章描述了基于数据统计相关的编程模型。在实际开发中，可以基于这个模型进行扩展和调整，同时结合同步异步机制，数据库存储模型，结合物联网传感器，构建高可用，有实际生产价值的互联网应用系统