数据中台之数据计算篇

数据中台之数据计算篇

数据直接开放适用的场景

上一篇，我们谈到数据中台的数据开放模式，接下来我们将围绕数据开放的更深层次需求--数据计算来进行说明。

如上图所示，无论是线下的数据开放（ETL接口、文件）还是线上的数据开放（API接口），对于数据体量都是有要求的，一般一次传输的数据量会控制在十万级以下，数据量再大则会出现传输的性能瓶颈造成应用访问的延时。

但是，当前大数据的背景下，高校新纳入了类似传感器、机器设备的数据源，而这些数据体量比传统的业务系统要大的多，比如某学校防火墙一天产生的数据在500G。与此同时，学校又需要对这些数据进行统计（比如每5-10分钟刷新一次当天的会话访问排名），这样就对数据开放提出了更高的要求，不仅要求开放基础数据，还要求对这些应用终端无法在短期内处理好的数据提供结果数据，这就涉及到数据计算模块了。

希嘉数据中台体系中的数据计算模块就是针对这个实际需求，应运而生。

1. 数据计算的使用场景

如上图所示，数据计算体系是为了解决大体量数据直接对外供给面临的性能问题，而选择把公共数据计算的部分整合到数据中台，利用中台底层的计算功能来完成。

例如上图中大量的过程数据，在当前一些业务场景中越来越开始发挥其核心价值，但直接提供数据传输的成本非常高，同时也会额外造成巨量的存储成本，所以需要通过公共数据计算模块来预先完成一部分场景的预处理，核心是减小对外数据供给的体量，提高数据使用的效率。

典型使用场景

举例：如上图中的红框部分，某用户想基于防火墙流量数据(3000W+/小时)和上网认证数据(2W+/天)来定位某些终端用户行为是否异常，那么首先就需要按照规则关联这两类数据。

过程如下：

a).基于上网认证查询2W条记录的IP地址、上线时间、下线时间、认证账号

b).将上面获取上网认证的IP地址、上线时间、下线时间作为关联条件，先基于1小时的防火墙流量数据（3000W）进行关联，其关联条件如下：

1). 上网认证.IP地址 = 防火墙流量数据.IP地址

2). 上网认证.上线时间 < 防火墙流量数据.记录产生时间 < 上网认证.下线时间

c).将满足步骤b)关联条件的防火墙流量数据与上网认证的账号进行关联和标记，合并成具体用户的流量行为数据(防火墙初始只提供基于ip地址的访问记录，大部分学校是动态的DHCP，同一个IP在不同的时间段分配给的终端用户是不一致的)

以上面2W的认证数据与3000W的流量数据进行一个简单的范围关联，实际在Oracle数据库里面测试的执行时间在100秒左右，相当于要执行2W次对3000W条记录的扫描和匹配。如果把数据量各自扩大10倍，变成20W认证数据与3亿条流量数据的关联，则在数据库里面执行的时间理论上是10000秒(接近3小时)。

上面还只是大数据计算中比较简单和体量相对较小的场景，如果对于上面的类似数据要求提供数据开放和共享，无论如何都不可能将原始数据通过ETL或者API接口的方式提供数据，传输体量实在太大，所以必须要把计算过程基于大数据底层的计算能力，在本地完成，后将结果对外输出。

2. 数据计算层的整体架构设计

如上图所示，紫色模块即为数据计算在整个数据中台体系中的位置，其核心是提供基于数据存储层的计算能力，兼容主流的存储容器（如Oracle、MySQL、HDFS、Hive等）。

在希嘉的数据中台体系中，选择采用Spark作为数据计算的核心组件，结合Hadoop集群的分布式存储和计算能力，解决海量数据运算的场景。

Spark的分布式计算原理

Spark是当前Hadoop大数据体系中为成熟的计算组件，能够兼容绝大部分的数据源，与HDFS搭配天然互补，可提供Java，Scala，Python，简单快速的编写并行的应用处理大数据量。

希嘉对Spark模块进行深度整合，提供了基于业务流程的数据计算服务，使得高校能够将数据使用的流程管理与大数据底层计算过程进行融合，大幅度降低在数据开放过程中使用数据计算的门槛。

3. 希嘉中台体系对于数据计算模块的产品化

希嘉的数据开放平台，通过集成Spark-SQL组件，提供基于SQL的语法来创建计算任务，并提供图形化的界面查看和管理当前的各类计算任务。

同时，各类计算任务之后的结果也可以直接发布成标准的API接口，对于上层使用数据的用户来说，几乎感受不到哪些数据是直接调取，哪些数据是经过计算之后发布的。

总体上来说，数据中台所提供的数据计算能力实现方式有多种，但核心解决的问题都是一类--大体量数据预处理。希嘉公司结合教育行业的特点，选择首先通过SQL方式提供的计算能力，使得高校信息化的管理人员能够以较小的学习成本掌握基于分布式计算的能力，同时后续会引入更多的计算模块来丰富实际使用的场景。