一、数据平台的发展简介

1534415299765076794.png

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

• 降低数据处理成本

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

• 提供统一的编程范式

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

Google 的三大论文和 Apache Hadoop 开源生态圈的发布应该是大数据处理技术走进“寻常百姓家”的起点。Hadoop 的组件均可在普通的廉价机器上运行，加上其代码是开源的，因此得到了众多公司的热捧。那么一开始这些公司都用它来做什么呢？

答案是数据仓库。

注：Google 三大论文：Bigtable: A Distributed Storage System for Structured Data；The Google File System；MapReduce: Simplefied Data Processing on Large Clusters

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

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

由于离线数据处理流程（如：Sqoop+HDFS+Hive）和实时数据处理流程（如：Binlog+Spark Steaming+Hbase）两套流程计算逻辑耦合较大，并且通过组合才能支持实时全量的数据分析，所以就产生了很多架构，如早期的 Lambda，Kappa 等。此时历史数据和实时数据结合数据仓库可以回答什么终将会发生（预测阶段）。

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

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

1534415384730087066.png

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

• 决策赋能

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

• 业务数据分析/业务数据产品

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

• 计算存储

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

• 效率

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

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

1534415475938033039.png

运营、营销以及决策层直接使用平台，大部分就是直接查看 BI 报表。业务分析师梳理完业务需求会把需求提供给数据仓库工程师，然后专业的数据仓库工程师会把新的需求加入已存在的公司级别的数据仓库之中。数据工程团队主要负责运维集群。

初期为什么是这样的架构这里就不做过多描述了，我们直接说一下它的缺点。

1. 当决策层使用报表时发现总是慢了一拍，总会有新的需求出来。原因很简单：其实互联网公司的业务并不像传统行业（如银行、保险等）的业务那么稳定，因为互联网公司的发展比较快，业务更新迭代的也很快。

2. 业务分析总有各种临时的需求，原因和 1 类似。

3. 数据仓库工程师累成狗。数据仓库庞大笨重，很难灵活的运作，总是牵一发而动全身。

4. 集群作业运维困难，作业间耦合性太大，例如：A 业务的表 a 没跑出来直接影响了整个公司的所有作业。

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

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

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

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

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

这样做的好处是：

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

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

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

1534415525675058581.png

二、宜人贷数据平台 Genie 特点介绍

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

1534415561003018396.png

以上是平台底层技术架构图，整体是一个 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 架构有些许差异（此处不做过多表述）。

要知道集群资源是有限的，把离线和实时等计算架构放在一个集群内必然会出现资源抢占的问题。因为每个公司的计算存储方案可能不一样，我在这里仅仅以我们的方案为例，希望能起到抛砖引玉的作用。

1534415589660067112.png

要解决抢占问题，首先让我们清晰的认识一下抢占。从用户使用维度上来说，如果平台是多租户的，那么租户之间便存在抢占的可能性；从数据架构上来说，如果离线计算和实时计算没有分开部署，那么也存在抢占的可能性。需要强调的是抢占不仅仅是指 cpu 和内存资源的抢占，网络 io 磁盘的 io 也是会抢占的。目前开源市场上的资源调度系统，如 yarn，mesos 等资源隔离做的都不是很成熟，只能在 cpu 和内存上做一些轻度隔离（hadoop3.0 的 yarn 已经加入了磁盘和网络 io 的隔离机制）。因为我们的工作基本上是“everything on yarn”，所以我们对 yarn 进行了修改。对 yarn 的修改和官方的解决方案类似利用 cgroup 来实现。对与服务进程间也要用 cgroup 做好隔离，如 datanode nodemanager 在一台机器上的时候。

1534415609578022630.png

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

再说 Genie 的组成，Genie 整体分七个子系统。

• meta data: 元数据的管理是核心中的核心，元数据服务化是做数据平台的基础中的基础，几乎所有的需求功能都会依赖它来开展。

• Authority: 统一权限切面，统一管理，灵活配置。此处权限包括数据的访问权限配置。

• Monitor: 监控，按照租户维度统计集群使用情况等。

1534415627420019714.png

• Triangle: 自研发调度系统，分布式、服务化、高可用、使用友好。如上图是 Triangle 调度系统的架构图。整体是一个 Master Slave 的架构，Job Runtime Dir 概念是指当前 Job 的运行所需要的环境完整打包提供，如 Python 环境。

1534415694604068093.png

• Data Dev: 上图是一个数据开发流程。数据开发平台—开发测试上线的一站式平台，安全、快捷、支持 SQL, Python, Spark Shell。

• Data Pipeline：数据管道，用于离线数据管道配置管理和实时数据管道配置管理。可以实现 1 分钟完成离线入仓配置和实时入仓配置。

• Data Knowledge：数据知识，用于血缘关系查询、数据指标管理。

没有最好的架构，只有更适合的架构 。每个公司的情况不一样，业务模式不一样，虽然都是 ETL 数据处理，都是数据仓库，都是机器学习，但是有多少需求是数据仓库？机器学习的应用场景是什么？ETL 实时性要求是怎么样的？这些细节都有很多复杂的客观条件约束。

在技术架构的选型中有两个至关重要的因素，即场景和成本。简单来说，场景就是要做什么，要低成本的方式实现，不要过度设计。如果场景复杂，那么可以从多维度抽象细分，比如：时间维度（历史待解决问题，目前的问题，未来可能面临的问题）。同理，就成本而言，应该考虑的维度也很多，如：开发周期、运维复杂度、稳定性、现有人员的技术栈等等。

在下篇中，我们会从“实时数据仓库技术细节”和“数据平台功能简介”两方面继续为大家解读宜人贷的 PaaS 数据服务平台 Genie，敬请大家持续关注。

本文转载自宜信技术学院网站。

原文链接：http://college.creditease.cn/detail/165