宜人贷 PaaS 数据服务平台Genie 简介（一）

数据平台的发展简介

随着数据时代的到来，数据量和数据复杂度的增加推动了数据工程领域的快速发展。为了满足各类数据获取/计算等需求业内涌现出了诸多解决方案。

但大部分方案遵循以下原则：

1 降低数据处理成本

2 合理提高数据使用/计算效率

3 提供统一的编程范式

对于宜人贷的数据服务平台我们也是遵循的这3个原则。本人有幸亲身经历了宜人贷数据平台的整个发展过程，纵观宜人贷和业内，可以说宜人贷数据平台的发展是工业界数据平台发展的缩影。

Google 的3篇论文和Apache Hadoop 开源生态圈的发布应该是大数据处理技术走进’寻常百姓家’的起点。Hadoop 的组件均可运行在普通的廉价机器加上其代码又是开源的，因此得到了众多公司的热捧。

那么一开始这些公司都用它来做什么呢？答案是数据仓库。

所以早期的数据平台大概的架构都是由sqoop+hdfs+hive这三个组件组成，因为这个是搭建数据仓库最廉价高效的方式。此时数据仓库只能回答过去发生了什么（离线阶段）因为sqoop离线抽取一般采用的t+1快照方案，也就是说只有昨天的数据。

紧接着由于对数据实时性的需求提高了，需要实时做增量数据的关联聚合等复杂运算，这个时候数据平台就会加入分布式流计算的架构如：Strom ，Flink， Spark Streaming 等。此时的数据仓库可以回答的是什么正在发生（实时阶段）。

由于离线数据处理流程（如：sqoop+hdfs+hive）和实时数据处理流程（如：binlog+spark steaming+hbase）两套流程计算逻辑耦合较大，并且通过组合才能支持实时全量的数据分析，所以就生出了很多架构 如早期的lambda，kappa等。此时历史数据和实时数据结合数据仓库可以回答什么终将会发生（预测阶段）。

数据平台发展至此已经不再是一个数据仓库就能解释的了，它与各类业务部门紧密合作（如营销，电销，运营）打造出诸多数据产品。此时数据仓库（数据平台）已经进入了主动决策阶段。

其实预测和实时的发展顺序不同的公司有所不同，只用历史数据就可以做出预测。

数据平台应该属于基础架构的重要环节，曾经互联网行业内有很多公司跟风搭建了大数据集群后发现很难发挥真正价值，其实最重要的原因应该是对数据使用的定位以及对数据平台的定位问题。目前的数据平台的定位有以下几点：

1: 决策赋能

为决策层赋能，决策层通过使用bi 报表 快速了解公司运营情况，因为数据不会说假话。

2: 业务数据分析/业务数据产品

平台可以提供adhoc即时分析帮助分析师快速分析业务快速定位问题快速反馈。

3：计算存储

业务数据产品也可以充分利用平台的计算存储资源打造数据产品，如 推荐，智能营销等等

4: 效率

提升数据处理效率，从而节约数据挖掘/处理的时间成本

人员架构方面早期大部分公司如下图：

运营，营销 以及决策层直接使用平台其实大部分就是直接查看bi 报表。业务分析师梳理完业务需求会把需求提供给数据仓库工程师，然后专业的数据仓工程师会把新的需求加入已存在的公司级别的数据仓库之中。数据工程团队主要负责运维集群。初期为什么是这样的架构这里就不做过多描述了，我直接说它的缺点。1，当决策层使用报表时发现总是慢了一拍，总会有新的需求出来，原因其实很简单其实互联网公司的业务并不像传统行业（如银行保险等）的业务那么稳定。因为互联网公司的发展比较快业务更新迭代的也很快。2，业务分析总有各种临时的需求，原因和1类似。3，数据仓库工程师累成狗。因为有一个庞大笨重的数据仓库，很难灵活，牵一发动全身。4，集群作业运维困难，作业间耦合性太大，例如：A业务的表a 没跑出来直接影响了整个公司的所有的作业。

相信这些头疼的问题很多公司都遇到过，解决方式应该也是类似的。大体如下(见下图)：

1: 搭建产品化的数据服务平台

2: 数据仓库能量转移到更加基础更加底层的数据问题，如数据质量问题，数据使用规范，数据安全问题，模型架构设计

3: 业务分析师直接利用平台搭建业务数据集市，提高敏捷性和专用性

4: 数据工程主要职责不再是运维集群，而是搭建数据服务平台和构建业务数据产品

这样做的好处是：

1: 解决了数据仓库的瓶颈问题

2: 让最熟悉自己数据的人自己搭建数据集市 效率更高

3: 业务数据产品可以直接使用数据服务平台提高效率，缩减公司成本。

宜人贷数据平台特点介绍

宜人贷属于互联网金融公司，由于是有金融属性所有对平台的安全性，稳定性，数据质量等方面要高于一般的互联网公司。目前宜人贷的数据结构数据总量PB级别，每天增量TB级别。除了结构化的数据之外还有日志，语音等数据。数据应用类型分运营和营销两大类。如智能电销，智能营销等。数据服务平台需要保证每天几千个批量作业按时运行和保证数据产品对数据实时计算的效率以及准确性，与此同时，又要保证每天大量的adhoc查询的实效性。

以上是平台底层技术架构表示图，整体是一个lambda架构，batch layer 负责计算t+1的数据，大部分定时报表和数据仓库/集市的主要任务在这一层处理。speed layer 负责计算实时增量数据，实时数仓，增量实时数据同步，数据产品等主要使用这一层的数据。batch layer 采用sqoop定时同步到hdfs 集群里，然后用hive和spark sql 进行计算。batch layer的稳定性要比运算速度重要，所以我们主要针对稳定性做了优化。batch layer的输出就是batch view。speed layer 相对batch layer 来说数据链路会长一些，架构也相对复杂。dbus和wormhole是宜信的开源项目，主要是用来做数据管道用的。dbus的基本原理是通过读取数据库的binlog来进行实时的增量数据同步。其实主要解决的问题是无侵入式的进行增量数据同步。当然也有其他的方案，比如 卡时间戳，增加trigger等 也能实现增量数据同步，但是对业务库的压力和侵入性太大。wormhole的基本原理是消费dbus同步过来的增量数据并把这些数据同步给不同的存储，支持同构和异构的同步方式。总体来说speed layer 会把数据同步到我们的各种分布式数据库中，这些分布式数据库统一称为 speed view 。然后我们把batch 和speed的元数据统一抽象出来一层叫service layer。service layer 通过ndb对外统一提供服务。因为数据有两个主要属性 data=when+what。 在when这个时间维度上来说数据是不可变的，增删改其实都是产生了新的数据。在平时的数据使用中我们常常只关注what的属性，其实when+what才能确定data的唯一不可变特性。所以按照时间这个维度我们可以对数据进行了时间的维度的抽象划分，即 t+1的数据在batch view ，t+0的数据在speed view 。这是标准的lambda架构的意图。把离线和实时计算分开。但是我们的lambda架构有些许差异（此处不做过多表述）。

要知道的是集群资源是有限的，把离线和实时等计算架构放在一个集群内必然会出现资源抢占的问题。因为每个公司的计算存储方案可能不一样，我在这里仅仅以我们的方案为例 希望能够做到抛砖引玉的作用。要解决抢占问题，首先让我们清晰的认识一下抢占。从用户使用维度上来说，如果平台是多租户的也那么租户之间是存在抢占的可能性的；从数据架构上来说，如果离线计算和实时计算没有分开部署那么也是存在抢占的；需要强调的是抢占不仅仅是指cpu 和内存的资源，网络io 磁盘io也是会抢占的。目前开源市场上的资源调度系统，如 yarn，mesos等 资源隔离做的都很不成熟，只能在cpu和内存上做一些轻度隔离。（hadoop 3.0的 yarn 已经加入了磁盘和网络io的隔离机制）。因我们主要做的事every thing on yarn 所以我们对yarn进行了修改。对yarn的修改和官方的解决方案类似利用cgroup来实现。对与服务进程间也要用cgroup做好隔离。如 datanode nodemanager在一台机器上的时候。

上图很好的说明了宜人贷数据平台的组成以及数据使用过程。先说数据使用流程，首先所有数据包括结构化和非结构化的都会在数据仓库中进行标准化 如：单位的统一，字典统一，数据格式统一，数据命名统一等等。统一规范的数据会直接或者间接的被数据集市使用，作为数据集市的入口。数据集市之间业务耦合性很低，所以数据耦合性也就低，这样可以很好的避免整体作业的耦合度。各个业务的数据应用也会直接使用自己的数据集市。