宜人贷PaaS数据服务平台Genie：技术架构及功能

时间 2019-12-06 标签宜人 paas 数据服务平台 genie 技术架构功能

上篇：架构及组件

1、数据平台的发展

1.1 背景介绍

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

下降数据处理成本java
合理提升数据使用/计算效率node
提供统一的编程范式python

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

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

答案是数据仓库。数据库

注：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快照方案，也就是说只有昨天的数据。api

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

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

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

其实预测和实时的发展顺序不一样的公司有所不一样，只用历史数据就能够作出预测。

1.2 数据平台定位

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

决策赋能

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

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

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

计算存储

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

效率

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

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

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

1.3 初期架构的缺点

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

当决策层使用报表时发现老是慢了一拍，总会有新的需求出来。缘由很简单：其实互联网公司的业务并不像传统行业（如银行、保险等）的业务那么稳定，由于互联网公司的发展比较快，业务更新迭代的也很快。
业务分析总有各类临时的需求，缘由和1相似。
数据仓库工程师累成狗。数据仓库庞大笨重，很难灵活的运做，老是牵一发而动全身。
集群做业运维困难，做业间耦合性太大，例如：A业务的表a 没跑出来直接影响了整个公司的全部做业。

1.4 常看法决方案

相信这些头疼的问题不少公司都遇到过，解决方式应该也是相似的。大致以下：

搭建产品化的数据服务平台。
数据仓库能量转移到更加基础更加底层的数据问题，如数据质量问题、数据使用规范、数据安全问题、模型架构设计等。
业务分析师直接利用平台搭建业务数据集市，提升敏捷性和专用性。
数据工程主要职责再也不是运维集群，而是搭建数据服务平台和构建业务数据产品。

这样作的好处是：

解决了数据仓库的瓶颈问题。
让最熟悉本身数据的人本身搭建数据集市，效率更高。
业务数据产品能够直接使用数据服务平台提升效率，缩减公司成本。

2、宜人贷数据平台Genie架构及特色

2.1 Genie架构

宜人贷属于互联网金融公司，因为带有金融属性，因此对平台的安全性、稳定性、数据质量等方面的要求要高于通常的互联网公司。目前在宜人贷的数据结构中，数据总量为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和内存上作一些轻度隔离（hadoop3.0的 yarn 已经加入了磁盘和网络io的隔离机制）。由于咱们的工做基本上是“everything on yarn”，因此咱们对yarn进行了修改。对yarn的修改和官方的解决方案相似利用cgroup来实现。对与服务进程间也要用cgroup作好隔离，如datanode nodemanager在一台机器上的时候。

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

2.2 Genie的功能模块

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

meta data: 元数据的管理是核心中的核心，元数据服务化是作数据平台的基础中的基础，几乎全部的需求功能都会依赖它来开展。
Authority: 统一权限切面，统一管理，灵活配置。此处权限包括数据的访问权限配置。
Monitor: 监控，按照租户维度统计集群使用状况等。

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

Data Dev: 上图是一个数据开发流程。数据开发平台—开发测试上线的一站式平台，安全、快捷、支持SQL, Python, Spark Shell。
Data Pipeline：数据管道，用于离线数据管道配置管理和实时数据管道配置管理。能够实现1分钟完成离线入仓配置和实时入仓配置。
Data Knowledge：数据知识，用于血缘关系查询、数据指标管理。

3、总结

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

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

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

下篇：技术细节及功能

导读：在上篇中，咱们已经简单了解了宜人贷数据平台Genie的特色，而且掌握了数据平台发展历程的一些信息。本文做为下篇，首先咱们会在其中重点讲解实时数据仓库的技术细节，以后介绍数据平台的功能。下面咱们一块儿来了解一下这些知识吧~

4、实时数据仓库技术细节

离线数据仓库是t+1的数据，也就是说数据时效性是处理前一天的数据。通常来讲离线方案同步数据的策略是天天定时同步一次数据，并且基本是同步一次全量数据，也就是说天天一个全量数据（业务库）的镜像。

除了时效性，还有一点就是镜像的数据状态只有一个，因此想知道某个值的历史变化过程，就须要走拉链表（很是耗时耗资源）。实时数据仓库的实现方式不少，可是大多都是异曲同工。

实时数仓有两点特色：第一访问实时数据；第二结果能近似实时的返回。固然离线仓库若是优化的好，完成第二点也是能够实现的。思考两个问题，为何要用实时数据？为何要有实时数据仓库？

近几年数据工程师们在如何提升数据时效性上作了很是多的努力和尝试。推进这些实时数据同步、处理技术发展的固然仍是场景与需求。中国的大互联网环境竞争很是激烈，如何提升用户转化率变得尤其关键。

用户画像、推荐系统、漏斗分析、智能营销等等数据相关的产品都离不开实时数据的处理与计算。

获取实时数据最直接的方式是直连业务库，优点明显，缺点也很明显,有些逻辑须要跨库多源查询关联的时候直接连业务库就行不通了。因此首先须要把多个源头的数据集中同步起来，这个同步过程就是一个很是具备挑战的地方，要考虑数据的时效性，对业务系统的侵入性，数据的安全性和数据的一致性等等诸多难题。

因此咱们须要一个同步数据的工具，它须要有如下几个特色：

可以近似实时的同步生产库的数据和日志数据
和生产库还有应用服务器彻底解耦
同步出来的数据能够分发到其余的存储
整个同步过程保证数据不丢失，或者说能够按照任意时间批量从新同步

宜信敏捷大数据团队开发的DBus和Wormhole能很好的知足以上4点。

DBus利用数据库的binlog进行数据抽取，binlog通常延迟是比较低的，这样既保证了实时的特性，也保证了对生产库的零侵入。

其实利用日志来构建一个健壮的数据系统是一个很常见的方案。Hbase利用wal来保证可靠性，MySQL主备同步使用binlog，分布式一致性算法Raft利用日志保证一致性，还有Apache Kafka也是利用了日志来实现的。

DBus很好的利用了数据库的binlog日志而且进行统一的schema转化，造成了本身日志标准，以便支持多种数据源。DBus的定义是一个商业级别的数据总线系统。它能够实时的将数据从数据源抽取发送给Kafka。

Wormhole负责将数据同步写入其余的存储之中。Kafka就成了一个真正意义上的数据总线，Wormhole支持sink端按照任意时间开始消费Kafka中的数据，这样也就能很好的进行数据回溯。

Genie的实时架构以下：

有了DBus和Wormhole咱们能够很轻松的把数据从生产备库实时的同步到咱们的Cassandra集群，而后再同步Presto，为用户提供SQL语言计算。

经过这个简单的架构咱们高效的完成了实时数据仓库的搭建，而且实现了公司的实时报表平台和一些实时营销类的数据产品。

对于为何会使用Presto我能够给出如下的答案：

Presto拥有交互级别的数据计算查询体验
Presto支持水平扩展，presto on yarn （slider）
支持标准SQL，而且方便扩展
facebook, uber, netflix生产使用
开源语言java符合咱们团队技术栈, 自定义函数
支持多数据源关联join 逻辑下推，Presto 能够接Cassandra, Hdfs等等
pipelined executions - 减小了没必要要的I/O开销

Presto 是m/s架构，总体细节很少说了。Presto有个数据存储抽象层，能够支持不一样的数据存储上执行SQL计算。Presto提供了meta data api，data location api， data stream api，支持自开发可插拔的connector。

在咱们的方案中是Presto on Cassandra的，由于Cassandra相对于Hbase来讲可用性更好一些，比较适合adhoc查询场景。Hbase CAP中偏向c，Cassandra CAP中偏向a。Cassandra是一个很是优秀的数据库，方便易用，底层使用Log-Structured Merge-Tree 作存储索引的核心数据结构。

5、总体数据处理架构

综上我大概的介绍了宜人贷的实时数据处理架构，下面咱们看一下总体的数据处理架构。

总体Lambda架构speed层利用DBus和Wormhole组装成了一套实时数据总线，speedlayer能够直接支撑实时数据产品。DataLake是一个抽象的概念实现方式，咱们主要是利用Hdfs + Cassandra存储数据，计算引擎主要以Hive 和Presto为主，再经过平台统一的metadata对元数据整合提供，这样就实现了一个完整的DataLake。DataLake主要的应用场景是高级灵活的分析，查询场景如 ml 。

DataLake和数据仓库的区别是，DataLake更加敏捷灵活，侧重数据的获取，数据仓库则侧重于标准、管理、安全和快速索引。