宜信开源|Wormhole 大数据流式处理平台之设计思想

导读：互联网的迅猛发展使得数据再也不昂贵，而如何从数据中更快速获取价值变得日益重要，所以，数据实时化成为了一个大趋势。愈来愈多的业务场景须要实时分析，以极低的延迟来分析实时数据并给出分析结果，从而提升业务效率，带来更高价值。流式处理做为实时处理的一种重要手段，正在因数据实时化的发展而蓬勃发展。本文是敏捷大数据（Agile BigData）背景下的实时流式处理平台Wormhole的开篇介绍：Wormhole具体是一个怎样的平台？

开源地址：https://github.com/edp963/wor...

1、Wormhole背景介绍

在流式计算领域，愈来愈多成熟的技术框架出如今开源世界，如Storm、Heron、Spark、Samza、Flink、Beam等。流式技术也逐步进化发展，支持流上丰富计算语法（类SQL）、支持at least once或exactly once语义、支持高可靠高可用、支持高吞吐低延迟、支持基于事件时间计算、支持统一整合接入抽象等，这些都从不可能变为可能。

然而，虽然流式处理的技术已经很丰富，流式处理在企业中的实施仍然存在较大难度，主要缘由是成本高，需求上线周期长等，而产生这样问题的缘由又分两个方面，一是企业组织结构，二是技术。

传统数据仓库和BI的组织结构都是集中相关技术人员成立独立大数据部门，各个业务部门向其提需求，作定制化开发。

（企业组织结构）

如上图，大数据部门不只仅作大数据环境运维，还作定制化开发和线上业务维护。偏偏这两点会消耗大量的人力，也增长了管理和沟通成本。举一个需求开发的例子，以下图：

（需求开发流程）

上图是企业广泛使用的一个开发流程，这里边就反应出一些问题：

• 人力成本高

今后图能够看出，至少须要3个角色的人员才能完成一个需求，并且流式开发人员要花不少时间了解需求、业务、表结构等等。

• 上线周期长、效率低

全部需求都是由产品人员提出，由业务人员分析，而后与流式开发人员一块儿设计开发完成，且须要大量时间测试及验证结果。

• 复用低

在需求中，有不少业务是相似的，但因业务和定制化问题，因此没法很好的作到代码复用，致使重复开发比较多。

• 业务维护成本高

当上线的需求有变化时，就要在原有代码的基础上改造，流式处理开发人员也须要再一次了解业务流程、表结构等等，仍是须要不少的人力资源，而且周期也很长，同时改动会增长出问题的几率。

• 大量消耗资源

为了功能隔离和下降维护难度，每一个定制化功能都要启动一个流式应用，没法复用，须要占用大量硬件资源。

目前流式处理的种种问题很大的制约了企业实时大数据的发展，各个公司都在寻找一条更轻量的解决之道。咱们根据多年在实时大数据项目中的实践和经验积累，自主研发了流式处理平台——Wormhole，很大程度上解决了上述各种问题。下面咱们来介绍一下Wormhole的具体状况。

2、Wormhole是什么

Wormhole是一个面向实时大数据项目实施者的流式处理平台，致力于统一并简化大数据开发和管理，尤为针对典型流式实时/准实时数据处理应用场景，屏蔽了底层技术细节，提供了极低的开发门槛。项目实施者只需简单配置及编写SQL便可支持大部分业务场景，使得大数据业务系统开发和管理变得更加轻量、可控可靠。

（Wormhole数据处理样例）

Wormhole主要基于Spark技术，实现了基于SQL的流上数据处理和异构系统幂等写入等相关功能。如上图所示，Wormhole接入流上的数据，而后将数据中的出生日期经过用户编写的SQL处理为年龄，写入到另一个存储系统中。

Wormhole经过技术手段实现基于SQL的流式处理方案，大大下降了流式处理的技术门槛；同时经过平台化和可视化等实现了职能的变化，减小了整个需求生命周期的参与角色数量，精炼了整个开发过程，进而缩短了开发周期，也减小了开发和维护成本。

3、Wormhole设计目标

3.1 设计目标

基于敏捷大数据的思想，Wormhole的设计目标以下：

• 平台化/组件化

经过平台化支持，组件化组装实施，能够快速对原型进行验证，和需求方造成反馈闭环快速迭代

• 标准化

对数据格式进行标准化，达到通用效果，减小数据格式化和维护的成本

• 配置化/可视化

用户可视化配置、部署、管理、监控，下降大数据产品开发门槛，确保高质量产出

• 低延迟/高性能/高可用

根据实时性的要求，流式处理要求更低的延迟，而且要求更高的吞吐量，以及容错能力，保证系统7*24正常运行

• 自助化/自动化

让企业从数据中心化转型为平台服务化，让每一个数据从业者都可以有更多的自助服务，并释放数据处理能力，系统替代人工完成重复低级的工做，让从业者回归数据和业务本质

3.2 效果体现

Wormhole平台的建设带来的效果主要体如今如下几方面：

• 组织结构更合理：

以下图，大数据相关部门再也不作定制化开发和业务维护，而是更专一平台化和大数据环境的稳定，大大减小了人力资源的浪费。

（基于Wormhole的组织结构）

• 下降了流式处理开发的技术门槛：

流式处理的开发模式变为了业务人员经过可视化配置和编写SQL便可完成80%以上的业务场景，再也不须要对流式处理技术有很深的理解

• 缩短了需求上线周期：

以下图所示基于Wormhole的需求开发流程，一个需求从提出到上线只须要产品人员和业务人员，大幅下降了沟通和学习成本，进而大大缩短了需求开发上线周期。

4、Wormhole设计规范

（Wormhole流程设计图）

上图是Wormhole的一个设计介绍，体现了流式处理的从输入到输出的过程，在这个过程当中，Wormhole定义新的概念，将整个流式处理进行了标准化，将定制化的流式计算变为标准化的流式处理，并从三个纬度进行了高度抽象。

• 统一数据逻辑表命名空间——Namespace

Namespace：数据的“IP”，经过7层结构惟必定位数据对应的物理位置，即

[Data System].[Instance].[Database].[Table].[Table Version]. [Database Partition].[Table Partition]

1）统一通用流消息协议——UMS

• UMS是Wormhole定义的流消息协议规范
• UMS试图抽象统一全部结构化消息
• UMS自身携带结构化数据Schema信息，方便数据处理
• UMS支持每个消息中存在一份Schema信息及多条数据信息，这样，在存在多条数据时能够下降数据大小，提升处理效率

说明：

• protocol-type目前支持data_increment_data（增量数据）和data_initial_data（初始化全量数据）
• schema-namespace指定数据对应的namespace
• schema-fields描述每一个字段的名称、类型、是否可空。ums_id_表明记录id，要求保证递增；ums_op_表明数据操做（i：插入；u：更新；d：删除）；ums_ts_表明数据更新时间
• payload-tuple指一条记录的内容，与schema-fields一一对应

注：在Wormhole_v0.4.0版本后，应社区需求，支持用户自定义半结构化JSON格式

2）统一数据计算逻辑管道——Flow

• Flow是Wormhole抽象的流式处理逻辑管道
• Flow由Source Namespace、Sink Namespace和处理逻辑构成
• Flow支持UMS和自定义JSON两种消息协议
• Flow支持Event和Revision两种Sink写入模式
• Flow统一计算逻辑标准（SQL/UDF/接口扩展）

（Flow）

说明：上图中蓝色框和箭头组成了一个Flow，首先从TopicA中读取Namespace1 (SourceNamespace)的数据，数据协议为UMS或者自定义JSON，而后处理用户配置好的数据处理逻辑，输出到Namespace2 (SinkNameSpace)对应的数据系统中，写入支持insertOnly和幂等（对同key且不一样状态的数据保证最终一致性）。

做为一个实时大数据流式处理平台，Wormhole的设计目标和设计规范最终都是为流上处理数据而服务。本篇为Wormhole的具体功能作铺垫，下篇系列文章咱们将为你们介绍Wormhole的具体功能。

做者：赵平

来源：宜信技术学院