写点什么

360 数据处理平台的架构演进及优化实践

  • 2019-11-24
  • 本文字数:3754 字

    阅读完需:约 12 分钟

360数据处理平台的架构演进及优化实践

背景介绍

在当今的大数据时代,大数据计算引擎已经从原先最早的 Hadoop 生态系统演变到了第三代甚至是第四代计算引擎,比如 Spark 以及 Flink 等;存储引擎也是呈现多样化的发展,如支持 MPP 的关系型存储、分布式存储、时序数据库等。大数据生态的多样性给大数据开发的学习成本造成了很大程度的提高。


然而,当前我们的主流开发模式还是基于脚本开发,业务人员无法参与到我们的计算中来,这种开发模式在很大程度上依赖开发人员的效率,数据的时效性会难以保证。同时,数据开发过程中的数据流转全程黑盒,这给开发维护人员带来了很大的维护困难。最后,缺乏统一的资源调度导致资源长时间被占用不释放,从而引起资源浪费。以上是大数据开发人员所面临的问题和挑战。


从平台的角度来看,以 360 公司为例,公司产品形态多样化,包括了 PC 产品、WEB 产品、移动端产品等等,多样化的产品意味着数据处理平台面临着繁杂的数据类型,同时也必然面临了多样化的存储引擎及存储格式。


此外,在大数据时代,数据处理的场景已经不再停留在简单的 ETL 过程,不仅仅包括简单的指标计算,还需要涵盖数据解析、数据分析、机器挖掘等等。随着数据对产品的指导作用越来越重要,业务对数据的时效、规则生效的时效以及需求响应的时效有了非常高的要求。


从大数据开发人员和平台开发的角度分析了当前面临的问题和挑战之后,接下来我们来看看要如何通过平台来解决这些问题。

平台演进

Titan 大数据处理平台是 360 集团内部的一站式大数据处理应用平台,提供了数据集成、 数据同步、数据计算、数据分析以及流式数据处理等大数据处理应用场景的功能。


既然是演进,那就要从前世讲到今生了。我们的平台化进程基本可以分为三个阶段:

1 Titan 前

这个阶段的架构图如下图 1 所示:



图 1 Titan 前架构


这个时期分布式计算兴起,从传统单机计算过渡到了分布式计算,在分布式计算引擎的基础上抽象了各类脚本模板,基于此,我们的工作模式从纯手工劳作转变到了脚本模板的开发。


开发模式的转变使得我们的计算效率和开发效率得到了很大程度的提升。但随着产品爆发式的增长、场景的增多,脚本模板无法提供灵活的方式,依然需要铺大量的人力解决。

2 Titan 1.0

这个阶段的架构图如下图 2 所示:



图 2 Titan 1.0 架构


在这个架构里,基于分布式引擎及计算场景,抽象了各类型的模板库,通过模板库引用到我们的上层交互,以系统的方式将数据开发一定程度上交给业务。同时可以看到,这个阶段里,数据源相对丰富了,产品也比较丰富了,有计算平台、报表平台、在线查询系统以及经营分析平台。


一方面把数据运维交给业务,另一方面也一定程度上把数据开发交给业务,让业务具有自主开发的能力。


但随着产品的发展,这个架构也很快暴露出了一些问题:一方面没有实时流的接入;另一方面模板库从一定程度上也是定制开发,依然无法满足个性化场景;任务运维开放的不够,在一定程度上依赖平台开发人员,运维成了瓶颈。

3 Titan 2.0

这个阶段的架构图如下图 3 所示:



图 3 Titan 2.0 架构


Titan 2.0 采用了第三代计算引擎。


众所周知,第三代计算引擎主要特点是支持 JOB 内部 DAG 以及强调实时计算。在第三代计算引擎基础上,自主研发了 DITTO 组件框架和规则引擎,基于组件及计算的抽象提供丰富的组件库,采用图元拖拽的方式实现数据处理的无码化操作。同时通过调度监控以及权限管理,实现系统的自助运维以及数据安全的保障,值得一提的是,支持多种数据源接入,极大程度上满足各种数据类型及存储类型。

Tian 2.0 功能模块

一级功能

从功能上,Tian 2.0 划分了以下几个功能模块,一级功能视图如下图 4 所示:



图 4 一级功能视图

二级功能

数据源管理实现了多数据源归一化处理,同时也提供了对数据安全和质量约束的保证。抽取和加载通过对各个存储引擎处理的抽象,实现了同时支持流式数据抽取和加载以及批数据抽取和加载。


任务管理部分通过图源配置,达到给用户提供灵活配置的需求,同时辅以我们运维管理模块的规则配置、任务调测以及数据流查看,实现了可视化运维和实例运维的效果。


调度引擎在提供即时调度、指定周期调度、历史任务调度的同时,还支持了实时调度和监控的功能。此外,权限管理不仅实现了角色权限、操作权限、菜单权限,还实现了数据源权限管理,为数据提供安全保障。如图 5 视图所示:



图 5 二级功能视图


Titan 2.0 从技术架构上来讲,采用的是第三代计算引擎,实现了跨引擎以及批处理和流处理的统一,这对上层用户是透明的;其次,它采用了 DAG 优化,提供了整个系统的处理能力以及计算效率,Titan 2.0 与数据资产系统结合实现了全链路的数据质量监控以及数据的安全性保障。


业务架构上的优势可以总结为 4 个词:


多源 :包含了对多应用的支持,以及对各类异构数据源存储系统柜的支持;

易用 :系统的易用性突出在无码化上,数据计算,比如一个 DAU 计算只需要拖拖拽拽就可以了;

自助、灵活 :自助化和灵活性体现在任务的配置修改、监控调度完全交给用户自己,不依赖于开发人员,想怎么玩就怎么玩,让用户真实的体验到玩转大数据。

实践案例

接下来分享一下平台的几个典型的实践:


首先是 DITTO 组件框架,DITTO 组件框架的设计是为了解决多数据源、多存储源以及满足多种计算场景的需求。我们采用统一入口的方式,实现了对异构异源数据的支持以及离线计算与实时计算的统一,并采用组件组装 DAG 后计算满足各类场景需求。


下图 6 为 DITTO 组件框架的基本架构图,从架构图中可以看到,DITTO 是搭建在 Spark、Flink 这类计算引擎之上的,上层可以支持离线计算、实时计算、机器学习、在线查询等图元化应用。



图 6 组件框架架构图


DITTO 采用了三层任务结构设计,如图 7 所示,分别是 Application、Job、Task,它们之间的关系是一对多的关系,也就是一个 App 对应多个 Job,一个 Job 对应多个 Task,App 在一次运行中负责了所有层次的初始化及所有事件的提交,DAG 会在 Job 层次进行编排,最后 Task 这里是真正的执行单元。



图 7 DITTO 组件框架设计


在 DITTO 中,组件是最小的执行单元,DITTO 的抽象大致可以分为组件计算逻辑抽象,组件计算引擎抽象和组件运行环境抽象这几个部分。


这里分享 DITTO 设计过程中如何对计算、组件、context 和规则引擎进行抽象:


首先计算抽象。不论是数据处理、数据分析还是数据挖掘,最终都是一个数据的输入到一个数据的输出,那么首先就会有一个数据源的概念。而数据处理又分为业务的处理逻辑以及计算单元,这样就产生了业务逻辑的抽象和计算逻辑的抽象。当然,在计算的时候,要根据业务场景或者需求需要来选择不同的计算引擎,所以基于这四个方面计算可以进行动态的拼装,随意拼接去形成一次数据处理的计划,满足一定场景,这就是我们计算抽象的过程。



图 8 计算抽象


其次是组件抽象,组件的执行需要做一个统一的入口或者说统一的标准,这个标准抽象为生命周期。标准定下来之后,数据如何进入到组件中,这里就会有一个数据采集。接下来数据在组件之间的流转需要定义一个元数据,元数据包括了数据类型和数据字段。对于数据依赖其实就是拓扑关系的维护。



图 9 计算组件抽象


下图 10 是关于组件的类图,通过一个高层次的抽象来达到计算引擎的无关性,同时从这个类图中也可以看到我们的组件周期大致分为了 prepare、execute、declare、clearup 等几个阶段,数据的依赖通过 dependencies 来维系。



图 10 组件的类图


而后是 context,在 DITTO 中 context 主要负责初始化过程及上下文传输,在一个 application 的初始阶段,首先由 context 进行初始化。它负责了组件的初始化、计算引擎的初始化、时间的初始化还有 DittoEnv 和调度器的初始化。上下文传输部分的话,由于对于组件来说只关注自己本身,context 来负责维系各个组件之间的数据流转。



图 11 context



图 12 context 初始化流程图


最后是规则引擎,规则引擎其实比较好理解,它最重要的功能就是实现业务规则从应用程序代码中分离,简单来说就是实现了集成代码与业务无关,也就是将字符串或者是代码块传到我们的解释器后直接给出结果。在 Titan 2.0 里,基于规则引擎主要抽象出了四个部分,分别包括了逻辑运算、内置运算、四则运算、文本处理。



图 13 规则引擎


在做 DITTO 初期,规则引擎是以一种 DSL 的方式接入到系统中的,随着场景的发展以及我们平台的扩展,规则引擎目前以独立的产品形态来提供服务。


图 14 为当前我们规则引擎的整体架构,从架构图中可以看到在提供常规规则处理的同时,我们规则引擎也提供了规则库和函数库的管理,方便我们业务以更加自主自助的方式来试用我们的规则引擎。



图 14 规则引擎架构


另外在实际场景中,我们还从组件粒度上对性能和场景进行了优化,包括防止数据倾斜处理、防止内存溢出处理、数据缓存处理小文件合并等等。

结尾

最后分享一下个人的一些心得体会。


我个人认为,在设计产品或者技术架构上,首先应该遵循化繁为简的原则,一定要避免过度设计,这个我们早期确实也踩过不少的坑;再者就是要一起从业务场景出发,做好需求分析,了解用户的核心痛点才能做到设计直击痛点、方便用户,因为平台的发展离不开业务的滋养,也正是业务场景的不断变化才带来了平台的不断进步;最后,平台的稳定是一切的基础,一切性能优化都需要找到那个平衡点。


本文转载自公众号 360 云计算(ID:hulktalk)。


原文链接:


https://mp.weixin.qq.com/s/5vLIqzDOL3HcISzUZgtvhA


2019-11-24 19:451598

评论

发布
暂无评论
发现更多内容

Docker镜像列表中的none:none是什么

程序员欣宸

Docker 9月月更

基于微信小程序的会议室预定平台开发笔记

CC同学

PipyJS - 函数式网络编程语言

Flomesh

Service Mesh 服务网格

成为优秀程序员的8种方法

小小怪下士

Java 程序员 职业发展

这样Debug,排查问题效率大大提升...

程序知音

【数据结构】利用Python手把手带你自定义矩阵

迷彩

数据结构 矩阵 矩阵运算 9月月更 自定义矩阵

开发者有话说|谈谈自己大学期间的收获,以及毕业的求职经历

芯动大师

个人成长 成长路上的思考 初心不变

Vue3-无限滚动的懒加载-模拟网络请求Mock版

Sam9029

Vue 前端 9月月更 无限滚动

【存疑】爬虫学习中decode问题

Sher10ck

存疑

为什么Java中有三种基础的类加载器?

小小怪下士

Java 编程 程序员 程序

英特尔Wi-Fi 7速率提升5倍,为多应用场景带来改变

科技之家

网安超基础一周目

吉师职业混子

9月月更

Java | extends关键字【面向对象的第二大特征——继承】

Fire_Shield

Java 9月月更 extends

35岁程序员自荐:我所掌握的架构技术

小小怪下士

Java 程序员 中年危机

Qt|制作简单的不规则窗体

中国好公民st

qt 事件 9月月更

设计模式和七大设计原则不难的

知识浅谈

设计模式 设计原则 9月月更

架构师成长之路——什么是架构师

小小怪下士

Java 程序员 架构 后端

Java基础科普

吉师职业混子

9月月更

netty原理分析

小小怪下士

Java 编程 程序员 后端 Netty

长安链ca 容器部署(解决无法访问Mysql问题)

长安链

经久不衰的设计定律是不要让我思考的设计

宇宙之一粟

读书笔记 设计 设计思维 设计原则 9月月更

Java 面试之技术框架

小小怪下士

Java spring 编程 程序员

前端面试哪些是必须要掌握的

loveX001

JavaScript 前端

汽车总线系统

不脱发的程序猿

汽车电子 CAN总线 汽车总线系统

Lua脚本在Redis事务中的应用实践

京东科技开发者

数据库 redis 事务 开发语言 Lua脚本

从0开始的计算机之路

吉师职业混子

9月月更

追光动画《杨戬》:水墨、石窟、洛神赋,中式美感背后有中国云计算

B Impact

Vue3-无限滚动的懒加载-本地数据操作版

Sam9029

Vue 前端 懒加载 9月月更

【网络安全】记一次简单渗透测试实战

网络安全学海

黑客 网络安全 信息安全 渗透测试 漏洞利用

大数据调度平台Airflow(六):Airflow Operators及案例

Lansonli

airflow 9月月更

数字化办公,企业OA软件技术该如何发力?

FinClip

360数据处理平台的架构演进及优化实践_文化 & 方法_王素梅_InfoQ精选文章