大数跨境
首页
>
BBD技术控 | BBD数据平台演化之路
>
0
0

BBD技术控 | BBD数据平台演化之路

BBD技术控 | BBD数据平台演化之路 BBD Data
2020-01-07
3
导读：​BBD数据平台是以数据为核心，通过组织和管理数据，让其产生最大价值的一个基础服务平台。
文 | 吕司君



吕司君，BBD高级软件开发工程师，数据平台负责人，在海量系统、大数据领域的架构设计、稳定运行、数据开放方面有丰富实战经验。




01.
前言
  • 简介
BBD数据平台（DataPlatform）成立于2016年7月，它是以数据为核心，通过组织和管理数据，让其产生最大价值的一个基础服务平台。它是为了解决公司越来越广泛的实时业务需求，而推出的一整套技术解决方案，包括数据的实时接入、实时清洗、实时解析、实时传输、实时计算和实时查询等技术环节。通过数据平台来解决实时业务开发中各环节的技术难点，在流程上统一业务开发需求，使业务方只专注于业务开发，不用过多关心技术上的问题，极大地降低了实时业务开发的技术难度。
  • 背景
为了解决在大数据转换过程中的时效性、准确性、关联性，BBD数据团队早在2015年10月开始尝试了实时相关业务需求的开发。由于接入的数据大多为通过抓取互联网HTML解析而来原始数据，所以数据中充满了不确定性，而最终如何让数据变得可靠、易用、规范，便是我们数据平台全体同事努力的目标。
面对互联网中的海量多源异构数据，如何高效挖掘其中丰富的内容、对用户产生可靠的价值，一直是当前大数据处理的核心难点。在这种背景下，我们迫切需要一个集数据接入、数据计算、数据管理、数据开放为一体的大数据服务平台。针对跟数据相关的不同业务场景，有的放矢地选择相应功能，既可以在同一个平台下完成数据分析、可视化的无缝对接，又可以对数据集中管理、提升数据处理效率。
  • 目标
随着公司业务的不断拓展，数据平台要支持公司的HIGGS（浩格）、HOLO（浩睿）、INDEX（指数）、RegTech（金融监管科技）等所有产品线的数据服务。同时，我们也依托数据采集部、人工智能中心、大数据技术部、中后台部、测试部、运维部等其它技术部门的帮助与支持，逐步提升我们技术能力与业务水平，将BBD数据平台打造成国内一流的数据产品。

02.

架构演化
数据平台是BBD在处理海量复杂数据经验基础上，沉淀出的一套完整的大数据平台解决方案。其主要定位为解决以下问题：
（1）对海量多源异构数据进行统一归集接入处理；
（2）高并发，准实时进行数据清洗、解析、拆表、入库处理；
（3）通过多重校验规则，真实反应数据问题，保障数据质量；
（4）数据处理流程工具化，通过配置服务和API等方式轻松管理数据；
（5）数据可视化管理，通过数据监控和日志记录及时直观反应数据情况；
（6）构建本体、实体模型，进行集中管理，提高数据管理和提供效率；
（7）形成知识图谱，汇集各类数据问题、需求和解决方案，进行全生命周期数据管理。
数据平台三年多的时间经历了无数次迭代升级，架构上从集中式到分布式，功能上从单一到多样，部署上从单机到集群，按平台架构成熟度可以划分为三个版本：数据平台1.0、数据平台2.0和数据平台3.0。
  • 数据平台1.0 

Spider：基于Python开发的爬虫应用，每个爬虫部署成一个或多个进程，可以分布在不同机器上，抓取的数据为半结构化JSON数据，最后发送到SSDB队列。
SSDB：一个高性能的支持丰富数据结构的NoSQL数据库，用于替代Redis的消息队列，基于它很容易就可以实现生产者消费者模式。
ETL：基于Java开发的ETL应用，实现了数据实时抽取、实时清洗和实时入库的功能，支持水平扩展，可以通过多进程多节点部署，来提升数据处理效率。
MongoDB：它是一个高性能、可扩展的NoSQL文档数据库，非常适合存储爬虫采集的半结构化JSON数据。
数据平台1.0是一个典型的实时数据ETL架构，那个时候还不能把它称作数据平台，甚至连雏形都不算上，充其量是一个应用或服务，以现在的眼光来看那就是太过“简陋”了，但麻雀虽小五脏俱全，在当时这个架构已很好的满足了数据业务的需求。当然设计成这么简单的架构也是有原因的：
 1、数据源少，数据量小（每日百万级增量数据）；
 2、机器资源少，还没有大数据计算集群；
 3、数据业务简单，只有浩格一个应用。
这个架构设计虽然简单，但是数据的实时性却很高，可以达到毫秒级延迟，原因就是它足够简单，没有过度的设计。除了这个优点外，还有就是爬虫端（Spider）和数据处理端（ETL）可以无限水平扩展，在资源足够的情况下理论上不会存在性能瓶颈。
随着数据量和数据需求的不断增加，此架构也逐渐暴露出了以下问题：
1、SSDB是单机数据库，并发量大的情况下，非常容易出现单点故障；
2、ETL程序毕竟是单机应用，非分布式应用，开发、管理和维护成本太高；
3、MongoDB不支持事务；
4、没有考虑数据的一致性，一旦某个ETL程序挂了，就会导致数据丢失；
5、没有保留爬虫原始数据，无法溯源。
  • 数据平台2.0

数据平台2.0是在公司业务爆发式增长，技术团队不断壮大和大数据技术应用日趋成熟的背景下产生的。它是在不断地踩坑、填坑的过程中发展和完善起来的，经过一年多时间的打磨，最终形成了一套基于Spark大数据技术体系的OLTP解决方案，实现了海量异构数据接入、数据处理、数据存储、数据服务和数据管理的功能。它主要采用了以下组件/技术：
Flume：它是一个分布式、可靠和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方（Source）和数据接受方（Sink）。flume的核心就是Agent，Agent本身是一个java进程，运行在日志收集节点（服务器节点），这个Agent对外有两个进行交互的地方，一个是接收数据的输入（Source），一个是数据的输出（Sink），Sink负责将数据发送到外部指定的目的地（如Kafka、HDFS）。其运行机制如下：Source接收到数据后，将数据发送给Channel，Channel作为一个数据缓冲区会临时存放这些数据，随后Sink会将Channel中的数据发送到指定的地方。只有在Sink将Channel中的数据成功发出去以后，Channel才会将临时数据进行删除，这种机制保证了数据传输的可靠性与安全性。Flume的使用不仅限于日志的数据聚合，由于数据源是可定制的，Flume可以用于传输大量的事件数据，包括但不限于网络流量数据、数字媒体生成的数据，所以也非常适合用来接收爬虫端（Spider）发送过来的半结构化的JSON字符串数据。在这里我们选择使用Thrift Source来接收爬虫数据，原因有两点：第一，相对于HTTP来说，RPC系统开销更小（连接池），性能更高（高并发），并且能更好的支持批量数据传输；第二，thrift跨语言，基于这个特性我们开发了Java和Python SDK，可以应对几乎所有类型的爬虫客户端。
Spark：基于内存计算的分布式大数据并行计算框架。由于是基于内存计算，提高了在大数据环境下数据处理的实时性，同时保证了高容错性和高可伸缩性。Spark是MapReduce的替代方案，而且兼容HDFS、Hive等分布式存储层，可融入Hadoop的生态系统，以弥补MapReduce的不足。相比于传统的MapReduce大数据分析，Spark效率更高、运行时速度更快。它还具有Java、Scala、Python、R四种编程语言的API编程接口。Spark生态系统非常丰富，除了支持离线计算外，还提供了实时计算的能力（Spark Streaming），Spark Streaming允许程序能够像普通RDD一样处理实时数据，利用这个特性，我们可以使用同一套代码来实现实时计算和离线计算，这也是我们选择使用Spark的主要原因之一。
kafka：是一个基于分布式的消息发布-订阅系统，它被设计成快速、可扩展的、持久的。Kafka在Topic（主题）当中保存消息的信息，生产者向Topic写入数据，消费者从Topic中读取数据。由于Kafka的特性是支持分布式，所以Topic也是可以在多个节点上被分区和覆盖的。Kafka设计中将每一个Topic分区（partition）当作一个具有顺序排列的日志，同处于一个分区中的消息都被设置了一个唯一的偏移量。Kafka只会保持跟踪未读消息，一旦消息被置为已读状态，Kafka 就不会再去管理它了。Kafka的生产者负责在消息队列中对生产出来的消息保证一定时间的占有，消费者负责追踪每一个Topic（可以理解为一个日志通道）的消息并及时获取它们。基于这样的设计，Kafka可以在消息队列中保存大量的开销很小的数据，并且支持大量的消费者订阅。Kafka 的这几个特性非常满足数据平台的需求：可扩展性、数据分区、低延迟、处理大量不同消费者的能力。还有最重要的一点就是主流的大数据组件基本都原生支持Kafka，这样大大降低了我们的开发成本。
es-hbase二级索引：HBase是一个构建在HDFS之上，用于海量数据存储分布式列存储系统。HBase作为列式存储数据库，为数据流的数据存储提供了高效的写入性能和灵活的存储方式。在其存储结构上，HBase按照字典顺序进行排序，行键（RowKey）直接作为其中的一级索引，为其良好的读写性能提供了基础。HBase里面只有RowKey作为一级索引， 如果要对库里的非RowKey字段进行数据检索和查询， 往往要通过MapReduce/Spark等分布式计算框架进行，硬件资源消耗和时间延迟都会比较高。为了HBase的数据查询更高效、适应更多的场景， 诸如使用非RowKey字段检索也能做到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 因此需要在HBase上面构建二级索引， 以满足现实中更复杂多样的业务需求。数据平台使用ES（Elasticsearch全文搜索引擎）实现二级索引：把需要查询的字段和HBase RowKey存储到ES，数据本身存储到HBase。由于数据会写到两个不同的数据库中，这样会存在数据不一致的情况。我们可以使用协处理器（Coprocessor）来解决数据不一致的问题。数据平台在构建索引数据表基础上同步构建ES及缓存索引数据。当负责写入的线程进行写入操作时，通过协处理器同步处理索引表数据，然后通过观察者模式（Observer）同步索引数据到ES中，并且根据多源数据特性，将实时查询的数据添加到内存索引缓冲区。当发起数据读取过程时，首先进行查询。当数据读取时，首先访问ElasticSearch，根据查找到的索引表中的结果，调用协处理器进行数据实际行键查找，访问数据表，从而得到数据，从协处理器返回给客户端。通过该模式进行改进，数据查询效率大幅度增加。
异常处理：
异常数据都会保存到待定库（MongoDB），异常数据来源有两类：

  • 不同模块之间数据交互时发生网络异常或程序异常产生的数据；

  • 没有通过数据校验规则的数据。待定库提供数据查询和数据导出功能。产品可以统计分析待定库异常原因，从而可以加强或修改数据校验规则，进一步提高数据质量。待定库也会定时重跑异常数据，保证数据的完整性；

数据平台2.0虽然功能上已经很完善了，也能满足各种业务需求，但还是存在一些不足，主要有以下几个问题：

1、无法在不中断在线服务的前提下实时动态更新Streaming程序。数据处理的业务逻辑代码都是直接嵌入到Spark Streaming Job程序中，所以每次更新代码都要先打包上传，然后kill原有Job，最后再提交新任务，这样不仅效率低下，而且严重影响数据的实时性。
2、无法解决不同数据库之间的数据一致性问题。比如业务库数据我们会同步写入到MYSQL、ES和HBase这三个不同的数据库，如有其中有一个库数据写入失败，那么就会出现数据不一致的情况；
3、无法解决数据的时序性问题。由于数据是分布在不同节点上，而且Kafka消费是乱序的，所以会存在旧数据覆盖新数据的情况。
4、Spark存在木桶效应（系统的最终性能取决于系统中性能表现最差的组件）。Spark会把一批数据切分成多个Task，只有在所有Task完成后才能处理下一批数据，如果某些Task去执行读写数据库操作，那么很有可能会导致整个Job阻塞。
  • 数据平台3.0    
数据平台3.0在架构设计上，采用了分层设计的思想，根据平台对数据处理流向与功能服务逻辑划分成不同的模块层次，每一模块层次只与上层或下层的模块层次进行交互（通过层次边界的接口），避免跨层之间的交互。这种设计的好处是：各功能模块的内部是高内聚的，而模块与模块之间是松散耦合的。这种分层架构有利于实现数据平台的高可靠性、高扩展性以及易维护性。
上图是数据平台的六层架构。根据数据流向从下至上分别为数据接入层、数据处理层、数据存储层和数据服务层，外加相对独立的基础服务层和平台管理层。
数据接入层：主要负责数据的收集和数据的分发。它提供整个平台唯一的数据入口，也就是说任何数据要想进入平台，必须先通过此入口。这样做的好处是便于进行统一的数据接入管理和权限控制，避免出现因为多入口导致数据质量降低和维护成本升高的问题。接入层接收的数据源包括内部数据和外部数据，其中内部数据主要是系统内部应用产生的数据如日志、用户数据等等，而外部数据主要是来自爬虫采集系统和第三方数据。从数据类型来看，可以分为结构化数据（Database）、半结构化数据（JSON）、非结构化数据（文件/图片）。接入的数据将分发到Kafka消息总线和HDFS分布式文件系统中供数据处理层使用。
数据处理层：主要负责数据的处理，即数据加工和数据挖掘。数据处理层使用Spark分布式大数据计算引擎，分为实时计算和离线计算两个环节。实时计算环节从数据接入层传输过来的Kafka消息总线中获取数据，而离线计算环节的数据来源为HDFS分布式文件系统的离线文件。不管是实时计算还是离线计算，它们共用同一套数据处理服务（由基础服务层提供），这些服务相互独立，职责和功能单一明确，以数据流向从左到右分别是数据字段映射、数据清洗、数据清洗校验、数据基础入库、数据解析、数据解析校验、数据拆表和数据业务入库。数据字段映射主要负责把同类不同来源的数据进行格式化处理，包括字段统一、添加内部字段等；数据清洗就是把“脏”的“洗掉”，它是发现并纠正数据中可识别的错误的一个模块，包括检查数据一致性、处理无效值和缺失值等；数据校验（数据清洗校验和数据解析校验）根据指定的校验规则对清洗/解析后的数据进行验证，如果通过则继续下一步操作，否则数据就进入待定库（MongoDB）；数据基础入库是指将数据清洗后的数据进行持久化存储，这样做的目的是由于整个数据处理流程很长，保存中间状态的数据也是很有必要的，如果后续流程出现问题，那么可以直接从基础库开始恢复数据即可，而不需要从数据源头开始重跑，可节省大量时间和计算资源；数据解析就是对数据的深加工，即进一步挖掘数据的价值，此服务会依赖算法服务（比如NER服务、NLP服务等）；数据拆表主要是把一条数据记录拆分成多条记录，如一条关于企业的数据可以拆分成股东数据、高管数据、变更数据等，便于后续按照业务的需要将拆分后的数据存入不同的数据库表中；数据业务入库负责把数据异步发送到数据中间层服务（由基础服务层提供），不再同步写数据库，采用这种异步设计模式好处就是能够有效地避免发生木桶效应。数据处理采用了微服务架构（系统中的各个微服务可被独立部署，各个微服务之间是松耦合的）， 也就是所有的业务需求（数据处理需求）都是通过微服务方式实现，不再把代码直接嵌入到Spark程序中，因此支持Streaming应用在不中断服务的情况下获得更新。
数据存储层：其主要职责是数据的存储备份，它接收来自数据计算层的结构化数据和非结构化数据，并为上层应用提供数据支撑。由于数据量大，数据类型多样化，采用的数据存储引擎包括关系型数据库、NOSQL、分布式存储系统等。数据存储入库是由数据中间层服务统一负责，数据中间层旨在统一数据平台存储的入口，保证数据平台业务存储多种数据库的数据一致性和时序性。1、一致性保证：记录数据入库的状态（处理到哪一步了，入库成功or失败），如果入库成功则继续，否则回滚上一步操作（如：删除数据），如果程序异常退出了，下次会根据状态继续进行未完成的操作；2、时序性保证：利用Kafka每个partition的数据是有序的这个特性，我们把相同的数据put到同一个partition中，这样只要能做到数据中间层每个进程的每个线程都处理不同的数据就能保证数据的时效性，不会存在老数据覆盖新数据的情况。
数据服务层：主要负责提供数据服务。它有两种方式对外提供数据，一种是通过订阅推送系统，另一种是提供数据API服务。订阅推送服务是根据用户发起的订阅信息，这些信息包括表名、字段名等，主动地推送给用户，用户可以通过客户端接收数据也可以直接接收数据离线文件。数据API服务它是一个REST服务，提供HTTP接口，用户通过申请的appkey就可以获取自己所需的数据。
基础服务层：为整个数据平台提供基础组件和关键服务，包括配置中心、监控中心、唯一ID服务、数据中间层服务和分布式RPC框架等。配置中心能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。监控中心负责监控整个平台运行情况，对收集的结果进行管理，对阈值进行判断与实施报警。唯一ID服务是一个通用的唯一号产生器，它具有全局唯一、粗略有序、可反解和可制造等特性，它支持三种发布模式：嵌入发布模式、中心服务器发布模式、REST发布模式，根据业务的性能需求，它可以产生最大峰值型和最小粒度型两种类型的ID，它的实现架构使其具有高性能、高可用和可伸缩等互联网产品需要的质量属性，是一个通用的高性能的发号器。数据中间层服务是整个平台数据入库的唯一接口，它保证了数据在不同数据库之间的一致性，并产生同步消息为订阅推送系统提供源数据。分布式RPC框架应用于整个平台的内部交互，它主要提供服务注册，服务发现和服务治理等功能。
平台管理层：
1、数据管理平台：针对不同业务场景下的数据，数据平台提供一整套完整的数据管理解决方案，主要是提供元数据管理功能，包括元数据的定义与维护、元数据快速查询与检索、元数据版本管理等功能。提供针对数据元标准的规则配置功能，包括类型，长度，值域，正则表达式，数据范围等。提供自动生成元数据的功能，并能对元数据与规则进行人工核验与调整。提供元数据统一视图功能，支持物理库和物理表结构、组成元素的展示，提供元数据血缘关系分析和追溯功能，支持数据血缘关系展示。
2、数据开放平台：该平台旨在为数据用户提供使用平台数据的一个桥梁，它主要提供了以下四个功能：
1）数据接口注册：提供数据服务接口的注册管理功能，主要包括接口服务的注册、更新、删除、查询、发布和接口与服务的启动、停用等管理功能；
2）数据接口订阅申请：建立数据服务接口的订阅与审批流程，按照流程管理对数据服务的订阅申请和使用，对注册到系统内的数据服务接口，用户必须申请并获得审核通过后，方可发布供使用；
3）数据接口授权管理：对已注册发布的数据接口开放权限管理，包括可视化界面的访问权限管理、功能操作权限管理等功能。提供分级授权和批量授权等功能；
4）数据接口监控管理：对数据服务接口提供运行状态的监控，可以查询数据接口的读写记录、输入输出记录以及更新和错误记录，对接口与服务的异常状态进行报警，制定报警规则，对报警信息采用专用页面进行动态显示，并面向这些报警信息数据实现查询、统计及打印等功能。系统可以提供页面、邮件和短信等多种形式的告警。
03.
总结
BBD数据平台搭建了一套以Spark和Kafka为核心的流式数据管理、实时计算与分析平台，该平台能将以往低效、离线的ETL操作转变为高效、快速的在线处理操作。数据平台以事件为驱动，任何一条数据都可以触发整条链路上的各种业务操作，最后实时地将数据写入业务数据库中，为前端业务或应用提供在线查询与实时分析。流式计算是数据平台的主要数据处理模式，所涉及的数据处理模块包括映射、清洗、解析、验证、拆表等模块。数据平台通过Spark Streaming流式计算框架，并依托Kafka数据总线，将各个相对独立的处理模块进行串联，从而形成一个流式的数据处理Pipeline，最终处理完成的结果数据可以存储到MYSQL、HBase、ElasticSearch、MongoDB等数据库或继续写入Kafka数据总线等待下游系统进一步处理。这种通过以Kafka分布式消息系统作为数据总线，将各个相互独立的数据处理模块服务化并通过Spark Streaming流处理框架进行Pipeline式串联处理的技术架构，不仅大大提高了平台的数据接入及处理的开发效率，降低了平台的维护成本，同时也有助于提升平台整体的可扩展性和可靠性。

/ END / 
点击图片，查看往期精彩


【声明】内容源于网络
0
0
BBD Data
大数观天下，微言解疑难
内容 748
粉丝 0
BBD Data 大数观天下，微言解疑难
总阅读367
粉丝0
内容748