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

本次要分享的是360大数据中心数据处理平台Titan的架构演进，以及一些具体的实践过程。
 
一、背景介绍
 
在当今的大数据时代，大数据计算引擎已经从原先最早的Hadoop生态系统演变到了第三代甚至是第四代计算引擎，比如Spark以及Flink等；存储引擎也是呈现多样化的发展，如支持MPP的关系型存储、分布式存储、时序数据库等。大数据生态的多样性给大数据开发的学习成本造成了很大程度的提高。
 
然而，当前我们的主流开发模式还是基于脚本开发，业务人员无法参与到我们的计算中来，这种开发模式在很大程度上依赖开发人员的效率，数据的时效性会难以保证。同时，数据开发过程中的数据流转全程黑盒，这给开发维护人员带来了很大的维护困难。最后，缺乏统一的资源调度导致资源长时间被占用不释放，从而引起资源浪费。以上是大数据开发人员所面临的问题和挑战。
 
从平台的角度来看，以360公司为例，公司产品形态多样化，包括了PC产品、WEB产品、移动端产品等等，多样化的产品意味着数据处理平台面临着繁杂的数据类型，同时也必然面临了多样化的存储引擎及存储格式。
 
此外，在大数据时代，数据处理的场景已经不再停留在简单的ETL过程，不仅仅包括简单的指标计算，还需要涵盖数据解析、数据分析、机器挖掘等等。随着数据对产品的指导作用越来越重要，业务对数据的时效、规则生效的时效以及需求响应的时效有了非常高的要求。
 
从大数据开发人员和平台开发的角度分析了当前面临的问题和挑战之后，接下来我们来看看要如何通过平台来解决这些问题。

二、平台演进
 
Titan大数据处理平台是360集团内部的一站式大数据处理应用平台，提供了数据集成、 数据同步、数据计算、数据分析以及流式数据处理等大数据处理应用场景的功能。
 
既然是演进，那就要从前世讲到今生了。我们的平台化进程基本可以分为三个阶段：
 
第一阶段：Titan前
  
这个阶段的架构图如下图1所示：
 



图1 Titan前架构
 
这个时期分布式计算兴起，从传统单机计算过渡到了分布式计算，在分布式计算引擎的基础上抽象了各类脚本模板，基于此，我们的工作模式从纯手工劳作转变到了脚本模板的开发。
 
开发模式的转变使得我们的计算效率和开发效率得到了很大程度的提升。但随着产品爆发式的增长、场景的增多，脚本模板无法提供灵活的方式，依然需要铺大量的人力解决。
 
第二阶段：Titan 1.0
  
这个阶段的架构图如下图2所示：
 



图2 Titan 1.0架构
 
在这个架构里，基于分布式引擎及计算场景，抽象了各类型的模板库，通过模板库引用到我们的上层交互，以系统的方式将数据开发一定程度上交给业务。同时可以看到，这个阶段里，数据源相对丰富了，产品也比较丰富了，有计算平台、报表平台、在线查询系统以及经营分析平台。
 
一方面把数据运维交给业务，另一方面也一定程度上把数据开发交给业务，让业务具有自主开发的能力。
 
但随着产品的发展，这个架构也很快暴露出了一些问题：一方面没有实时流的接入；另一方面模板库从一定程度上也是定制开发，依然无法满足个性化场景；任务运维开放的不够，在一定程度上依赖平台开发人员，运维成了瓶颈。
 
第三阶段：Titan 2.0
  
这个阶段的架构图如下图3所示：
 



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



图4 一级功能视图
 
二级功能
  
 
数据源管理实现了多数据源归一化处理，同时也提供了对数据安全和质量约束的保证。抽取和加载通过对各个存储引擎处理的抽象，实现了同时支持流式数据抽取和加载以及批数据抽取和加载。
 
任务管理部分通过图源配置，达到给用户提供灵活配置的需求，同时辅以我们运维管理模块的规则配置、任务调测以及数据流查看，实现了可视化运维和实例运维的效果。
 
调度引擎在提供即时调度、指定周期调度、历史任务调度的同时，还支持了实时调度和监控的功能。此外，权限管理不仅实现了角色权限、操作权限、菜单权限，还实现了数据源权限管理，为数据提供安全保障。如图5视图所示：