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

时间：2019-06-17 13:03:58 阅读：120 评论：0 收藏：0 [点我收藏+]

标签：查看 paas kafka hadoop 技术 proc 细节缩减信息

上篇：架构及组件

一、数据平台的发展

1.1 背景介绍

技术图片

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

降低数据处理成本
合理提高数据使用/计算效率
提供统一的编程范式

宜人贷的数据服务平台也是遵循这三个原则。本人有幸亲身经历了宜人贷数据平台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等。此时历史数据和实时数据结合数据仓库可以回答什么终将会发生（预测阶段）。

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

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

技术图片

1.2 数据平台定位

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

决策赋能

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

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

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

计算存储

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

效率

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

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

技术图片

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

1.3 初期架构的缺点

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

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

1.4 常见解决方案

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

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

这样做的好处是：

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

技术图片

二、宜人贷数据平台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：数据知识，用于血缘关系查询、数据指标管理。

三、总结

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

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

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

下篇：技术细节及功能

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

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

离线数据仓库是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 做存储索引的核心数据结构。

五、整体数据处理架构

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

技术图片

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

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