【大数据】魅族大数据之流平台设计部署实践

2017 年 10 月 16 日 产业智能官 msup

本篇文章内容来自第八期魅族开放日魅族数据架构师沈辉煌的现场分享，由IT大咖说提供现场速录，由msup整理编辑。

沈辉煌魅族数据架构师

2010年加入魅族，负责大数据、云服务相关设计与研发；

专注于分布式服务、分布式存储、海量数据下rdb与nosq融合等技术。

主要技术点：推荐算法、文本处理、ranking算法

导读：魅族大数据的流平台系统拥有自设计的采集SDK，自设计支持多种数据源采集的Agent组件，还结合了Flume、Spark、Metaq、Storm、Kafka、Hadoop等技术组件，本文就魅族流平台对大量数据的采集、实时计算、系统分析方法，全球多机房数据采集等问题进行介绍。

流平台是魅族大数据平台的重要部分，包括数据采集、数据处理、数据存储、数据计算等模块，流平台为大数据提供了强大的支撑能力。

文章还介绍了魅族大数据流平台的架构、设计方式、常用组件、核心技术框架等方面的内容，还原魅族大数据平台的搭建过程及遇到的问题。

一、魅族大数据平台架构

如图所示便是魅族的大数据平台架构。

左边是多样性的数据源接入；

右上是离线数据的采集；

下面是流平台（也是今天分享的主角）；

中间是集群的部署；

右边是ETL的数据挖掘、算法库和一些数据模型；

左上角是数据开发平台，比如webIDE可以使得开发人员更便捷地做一些数据查询和管理；

最右边的是一个数据产品门户，包括我们的用户画像、统计系统等，这里面包含大数据的很多组件，比如数据采集、数据处理、数据存储、数据挖掘等，最后产生大数据的雏形。

二、流平台介绍

流平台是大数据平台一个比较重要的部分，主要包括四个部分：数据采集、数据处理、数据存储、计算能力。

数据采集

“谁拥有了整个世界的数据，他就是最大的赢家”，这句话虽然有点夸张，但是却表达了数据采集的重要性。一个大数据平台数据的多样性、数据量的级别很大程度上决定了大数据的能力和丰富程度。

数据处理

这里讲的数据处理并不是像末端那么专业的数据清洗，更多的是为后续入库做一些简单处理，以及实时计算。

数据存储

计算能力，包括离线计算和实时计算

流平台为大数据提供非常强大的支撑，数据统计分析、数据挖掘、神经网络的图形计算等都可以依靠计算能力进行。

实时计算是指在一定单位的时间延迟范围内，基于增量的数据推算出结果，再结合历史数据得到期望的分析结果。这个时间是根据业务需求而定。

1、流平台架构

上图是我们的流平台架构图

左边是数据源，像NoSQL、RDB、文件类型；

最右边是集群，下面还有其他的一些Hadoop（存储）；

中间的框是核心，也就是流平台；

最上面的是AS-Manager（我们的流管理平台），承载了非常多的管理功能；

下面是Zookeeper，这是一个非常流行的集成管理中心，魅族的一些架构都会用到它，流平台也不例外，Zookeeper可以说贯穿了我们整个流平台的架构；

最下面是AS-Protocol，我们自己设计的流平台的数据对象协议，打通了整个流平台的数据链路；

中间四个框是核心的四个模块：采集模块、数据中转模块、缓存模块、实时计算模块，也叫合并层

2、具体架构介绍

这是我们的具体架构图。

业务规模：从这边采集数据到经过流平台最后经过实时计算或入库，它的数据量量级在千亿级别。

3、组件

数据源渠道

前面提到采集数据源渠道的多样性决定了大数据平台的相应能力和综合程度。我们这边首先会有一个文件类的业务数据，包括业务日志、业务数据、数据库文件，这些都会经过采集服务采集。

下面这一块包括一些网站的js访问、手机各APP埋点、特点的应用日志文件（它会通过手机端的一些埋点上访到我们的埋点服务）。

数据采集

数据采集分为两个部分：采集服务、独立部署的埋点服务。图中只显示了一个埋点服务，里面还会有很多的第三方业务，第三方业务通过这个红色的插件接入我们的采集。

数据中转

通过采集模块把数据流转到中转模块，中转模块采用的是目前比较流行的flume组件，红色sink是我们自己开发的。

Cache

sink把前面的数据转给缓存层，缓存层里有metaq和Kafka。

Streaming

实时计算模块上线了Spark和Storm，较早上线的是Spark，目前两个都在用的原因是它会适应不同的业务场景。

Store

最后面是我们提供给落地的store层，像HIVE、Hbase等等。

流管理平台

最下面是流管理平台，图中有四条线连着四个核心模块，对这四个模块进行非常重要且非常丰富的逻辑管理，包括数据管理、对各节点的监控、治理、实时命令的下发等。

三、流平台设计

1、概念解读

Message，就是一条消息，是最小的数据单位。业务方给的一条数据就是一个message；我们去采集文件的话，一行数据就是一个message。

AS-Protocol，是我们自己设计的流平台数据的对象，它会对一批量的message进行打包，然后再加上一些必要的变量做一个封装。

Evnet，会提供一个类似的标准接口，这个地方其实更多的是为了打通采集的流平台。它最重要的一个变量是Topic，就是说我拿到了我的AS-Protocol就可以根据对应的Topic发到相应的登录去缓存提取，因为我们的AS-Protocol除了起始端和结束端以外，中间层是不用解析协议的。

Type,数据格式目前是Json和Hive格式，可以根据业务去扩展。

Compress，Hive格式在空间上也是非常有优势的，非常适合于网络传输压缩。当压缩数据源质量没有达到一定量的程度的时候会越压越大，所以我们要判断是否需要压缩。我们压缩采用的是一个全系统

Data_timestamp，数据的时间是最上面的message，每一个message会携带一个数据时间.这个比较好理解，就是入库之后会用做数据统计和分析的。

Send_timestamp,发送时间会携带在我们的AS-Protocol里，它声明了每一个数据包发送的时间。

Unique Key，每一个数据包都有一个唯一的标识，这个也是非常重要的，它会跟着AS-Protocol和Event走通整个平台的数据链路，在做数据定位、问题定位的时候非常有用，可以明确查到每个数据包在哪个链路经历了什么事情。

Topic。这个不需多言。

Data_Group，数据分组是我们非常核心的一个设计思想，原则上我们是一个业务对应一个数据分组。

Protobuf序列化，我们会对Event数据做一个PT序列化，然后再往上面传，这是为了节省数据流量。

2、协议设计

如图所示为Event、As-Protocol和Message的关系。

最上层是Event，里面有一个Unique Key和Topic包括了我们的As-Protocol，然后是数据格式、发动时间是否压缩、用什么方式压缩，还携带一些额外的变量。最后面是一个Body，Body其实就是一个message的宿主，以字节流的方式存储。这个就是我们一个数据对象的协议设计。

接下来看数据在整个架构里是如何流转和传输的。

首先是数据源渠道，最左边的是message，任何业务方的数据过来都是一条message，经过数据采集把一批message打包封装成Event，再发给数据中转模块，也叫flume。把Event拆出来，有一个topic，最后把As-protocol放到相应位置缓存，消费对应的Topic，拿到对应的As-Protocol，并把这个数据包解析出来，得到一条一条的message，这时就可以进行处理、入库或实时计算。

需要特别注意的是message和Event。每个Message的业务量级是不一样的，有几十B、几百B、几千B的差别，打包成As-Protocol的时候要试试批量的数目有多少，原则上压缩后的数据有个建议值，这个建议值视业务而定，DataGroup打包的数量是可以配的。

3、数据分组设计

如图所示是我们的DataGroup设计。首先看最上面，一个Topic可以定义N个DataGroup。往下是Topic和streaming Job一比一的关系，就是说一个实时的Group只需要对应一个Topic，如果两个业务不相关就对应的两个Topic，用两个Job去处理，最后得到想要的关系。

从架构图可以看到DataGroup的扭转关系。最初数据采集每一个节点会声明它是属于哪一个DataGroup，上传数据会处于这个DataGroup，经过数据中转发给我们的分布式缓存也对应了Topic下面不同的分组数据。最后Streaming交给我Topic，我可以帅选出在最上面的关系，去配置DataGroup，可以非常灵活地组合。这就是DataGroup的设计思想。

四、采集组件Agent

1、概述

如图所示，这是完全由我们自己设计和实现的一款组件。右边是采集组件，分为两部分：一个是基于java环境的独立工作程序；另一个是jar插件。插件叫Agen-Stub.jar；独立层是Agent-File.zip，Agent-File有一个paresr支持不同的文件类型，目前支持的file和Binlog，可扩展。根据需要可以增加parser，也是接入Agent-stub，拥有Agent-stub的一些特性。

如上图右侧的示意图，Agent-stub接入多个Business，前面提到的一个埋点服务就是一个Business，它把数据交给Agent-stub，Agent-stub会往后发展，与file和mysQL相对应的是file parser，出来是Agent-stub，流程是一样的。

2、Agent-Stub.jar

接下来看Agent-Stub是如何设计的。

多线程、异步。这个毫无疑问，做插件化肯定是这样考虑的，不能阻塞上层业务。

内存小队列+磁盘压缩队列。这是我们改进最大的一个地方，早期版本中我们采用的是内存大队列，如果只有内存大队列缺点非常明显：

程序正常启动的时候大队列里的数据怎么办？要等他发完吗？还是不发完？当大队列塞满的时候，还有对上层业务的侵入性怎么办？程序遇到问题时怎么办？大队列可能是50万、100万甚至更多。

采用了内存小队列+磁盘压缩队列后可以解决正常程序的启停，保证数据没有问题，还可以解决空间的占用清空性的问题，以此同时，磁盘压缩队列还可以在程序出错的时候加速发送。

解释一下磁盘压缩队列，这次我们设计协议的思想很简单：压缩之后得到一个字节速度，存在磁盘的文件里，这个文件按照小时存储，这时对于二次发送带来的损耗并不大，不需要重新阻断数据也不需要解析和压缩，只需要读出来发出去。后面还有一个提升就是磁盘发送队列跟内存发送队列是单独分开的，这样更能提升二次数据的发送性能。

无损启停。正常的启动和停止，数据是不会停止不会丢失的。

Agent的版本号自动上报平台。这个非常重要，我们早期的版本是没有的，可以想象一下当你的Agent节点是几千上万，如果没有一个平台直观地管理，那将是一个怎样恐怖的局面。现在我们每一个Agent启动的时候都会创建一个node path，把版本号放到path里，在管理平台解析这个path，然后做分类，我们的版本就是这样上报的。

自动识别接入源，智能归类。这个其实和上面那点是一样的，在早期版本中我们做一个Agent的标识，其实就是一个IP+一个POD，就是说你有几千个IP+POD量表需要人工管理，工作量非常大且乏味。我们优化了一个自动识别，把DataGroup放到Agent的node path里，管理平台可以做到自动识别。

Agent的全面实时监控。包括内存队列数、磁盘队列数、运行状态、出错状态、qps等，都可以Agent上报，并且在管理平台直观地看到哪一个节点是什么样子的。其做法也依赖于zookeeper的实现和承载，这里其实就是对zk node的应用，我们有一个定时线程收集当前Agent必要的数据，然后传到node的data上去，管理平台会获取这些date，最后做一个平台化的展示。

支持实时命令。包括括限流，恢复限流、停止、调整心跳值等，大大提高了运维能力。其实现原理也是依赖于Agent，这里我们创建一个Data Group，通过管理平台操作之后把数据放到Data Group里，然后会有一个监听者去监听获取数据的变化并作出相应的逻辑。

兼容Docker。目前魅族在用Doker，Doker对我们这边的Agent来讲是一个挑战，它的启动和停止是非常态化的，就是你可能认为相同的Docker容器不会重启第二次。

3、Agent-File.zip

接入Agent-Stub。Agent-file首先是接入Agent-stub，拥有Agent-stub的一些特性。

兼容Docker。因为启动和停止的常态，假设我们刚刚一个业务接入了Agent-stub，那停止的时候它会通知我，Agent-stub会把小队列里的数据抓到磁盘压缩队列里去。但是这里需要注意的是：磁盘压缩队列不能放到Docker自己的文件系统里，不然它停了之后数据就没有人能够得到了。

当Agent-stub停的时候，会有一个标识说磁盘要做队列，我们的数据有没有发完，磁盘压缩队列里有一个评级的标识文件，这时要用到Agent-file，Agent-file有一个单独的扫描线程一个个地去扫描Docker目录，扫到这个文件的时候判断其数据有没有发完，如果没发完就只能当做一个发送者。

支持重发历史数据。做大数据的可能都知道这些名词，比如昨天的数据已经采集完了，但由于某些原因有可能数据有遗漏，需要再跑一次后端的补贴逻辑，或者上马训练，这时就要做数据重发。我们在管理平台上就会有一个支持这种特定文件或特定时间段的选择，Agent接收到这个命令的时候会把相应的数据发上去，当然前提是数据不要被清了。

管理平台自助升级。这个可以理解成软件升级，Agent可以说是非常常见的组件，但是我们重新设计时把自动升级考虑在内，这也是我们为什么设计自己做而不是用开源的组件。这样做带来的好处是非常大的，我们几千个Agent在平台里只需要一键就可以完成自动升级。

文件名正则表达式匹配。文件名的扫描是用自动表达式。

源目录定时扫描 and Jnotify。重点介绍文件扫描机制。早期的版本是基于Agent-fire和KO-F两者结合做的数据采集：Agent-file是加码里对文件变更的事件鉴定，包括重命名、删除、创建都有一个事件产生；KO-F是拿到文件下的最佳数据。假设源目录里有一千个文件，KO-F现场就是一千个，Agent-file对应的文件变革赋予的追加、重命名等都可能会产生一系列事件，逻辑复杂。

所以我们设计了源目录定时扫描的机制，首先有一个目标，就是我们的文件队列，包括为未读文件、已读文件做区别，区别之后扫描，当然还会有像文件摘要等的存在这里不细讲，扫描之后更新未读文件、已读文件列表。

之所以加Jnotify是因为我们发现只用定制扫描不能解决所有业务场景的问题，jootify在这里起到补充定制扫描的作用，解决文件风险和文件产程的问题。

单文件读取。早期版本中这一点依赖于文件列表，当文件非常多时程序变得非常不稳定，因为可能要开几百个或几千个线程。后来我们改成了单文件的读取，上文提到的扫描机制会产生一个文件队列，然后从文件队列里读取，这样一个个文件、一段段图，程序就非常稳定了。

文件方式存储offset，无损启停。早期采用切入式PTE做存储，衔接非常重，后来我们改成文件方式存储，设计非常简单就只有两个文件：一个是目录下面所有文件的offset；一个是正在读的文件的offset。这里涉及到无损启停和策略的问题，我们定了一个5次算法：就是每读了5次就会刷盘一次，但只刷在读文件，别的文件不会变化，所以可以想象得到，当这个程序被替换走的时候，最多也就是重复5条数据，大会导致数据丢失。

4、Agent示意图

如图是Agent示意图。上面是Agent-file和数据对象。Agent启动的时候要把里面的offset文件取来，就会产生未读文件和已读文件列表，扫描文件目录，然后更新文件队列，还有一个fileJNotify是相对应的文件队列。然后有一个比较重要的fileReader，我会先从文件队列里拿到再去读实际文件，读完刷盘之后这一块就成功了，我会根据我的刷盘去刷新offset。

上图左边有一个业务加了一个Agent-stub，最后变成flume，这里有一个QueueReceiver（队列接收者），filereader和业务方的DataSender会把message发过来，QueueReceiver接受的数据就是一条条的message，然后发送到内存小队列里，当这边的小队列满了怎么办呢？中间有一个额外的固定大小的性能提升的地方用于message归类，当这个fIieReader往这个内存小队列发的时候发现塞不进去了，就会在规定大小的队列里发，当一个固定大小的队列满了之后就会打包压缩，以字节处理的方式存到磁盘压缩队列。

再来说说我们为什么会提出二次数据的发送，其实就是多了一个countsender即压缩队列的发送者，直接的数据来源是磁盘压缩队列，与上面的并生没有任何冲突。Countsender的数据对账功能是我们整个平台的核心功能之一，基于这个统计的数据确保了其完整性，少一条数据我们都知道，在采集层有一个countsender，以另外一个渠道发出去，和真正的数据源渠道不一样，会更加的轻量化更加可靠，且数值非常小。

最后是前文提到的监控和命令的实现，一边是Agentnode，一边是数据管理。

5、Agent的坑

丢数据。如前文提到内存大队列带来的问题。

版本管理的问题。

tailf -f的问题。

网络原因导致zk删节点问题。网络不稳定的时候，ZK会有一个节点的心跳检测，不稳定的时候监测会以为节点已经不存在了而把节点删掉，这会导致管理平台的节点监控、文件下发全部都失效。解决办法就是在message加一层控制检查线程，发现节点不在了再创建一遍。

乱码的问题。可能会跟一些远程访问的软件相关，原则上我们假设第二次启动的时候没有配置我们的编码，默认与系统一致，但当远程软件启动的时候可能会发生不一样的地方，所以不要依赖于默认值，一定要在启动程序里设置希望的编码。

日志问题，在插件化的时候肯定要考虑到业务方的日志，我们把业务方的日志刷死了，当网络出现问题的时候每发送一条就失败一条，那是不是都要打印出来？我们的考虑是第一条不打印，后面可能十条打印一次，一百条打印一次，一千条打印一次，这个量取决于业务。补充一点，我们有一个统计线程，可以根据统计线程观察Agent的正常与否。

五、流管理平台

如图所示，我们的流管理平台界面比较简单，但功能非常丰富，包括：

接入业务的管理、发布、上线；

对Agent节点进行实时监测、管理、命令；

对Flume进行监测、管理；

对实时计算的job的管理；

对全链路的数据流量对帐，这是我们自检的功能；

智能监控报警，我们有一个非常人性化的报警阀值的建议。取一个平均值，比如一周或一天，设定一个阀值，比如一天的流量访问次数可能是一千次，我们设计的报警是2000次，当连续一周都是2000次的时候就得改进。

六、数据中转

1、背景

业务发展可能从1到100再到1000，或者当公司互联网发展到一定程度的时候业务可能遍布世界各地，魅族的云服务数据分为海外服务和国内服务，我们把业务拆分开来，大数据采集肯定也要跟着走，这就面临着数据中转的问题。

如图所示是我们两个案例的示意图。黑色的是内网的线，橙色的是跨界性的线，有公网的、云端的、专线的，各种各样的网络情况。

上面的是Agent集群，B-IDC也有一个Agent集群，直接访问我们登录的集群。

这里第一个问题是我们的连接非常多，访问Agent节点的时候有几千个Agent节点就得访问几千个节点，这是不太友好的事情。另一个问题是当我们做升级迁移的时候，Agent要做修改和配置，必须得重启，当整个B-IDC迁移到A-IDC，我们加了一个Flyme集群。同样是一个Agent集群，下面有一个Flume集群，这样的好处：一是里面的连接非常少，线上的Flume一个ID就三台；二是这边承载了所有的Agent，除了Agent还有其他的采集都在A-IDC里中转，当这个片区要做升级的时候上面的业务是透明的，灵活性非常高。

2、Flume介绍

Flume里有三个核心的部分：Source、Channel、Sink，Source是数据结构源；Channel相当于内存大队列，Sink是输出到不同的目标。官方提供了很多组件：Avro、HTTP、Thrift、Memory、File、Spillable Memory、Avro、Thrift、Hdfs、Hive。

3、Flume实践

无Group，采用Zookeeper做集群

Agent采用LB做负载均衡，动态感知。结合Zookeeper可以感知到Agent列表，这时会采用负载均衡的做法找到当前的那个Flume，到后端的Flume直接变化的时候可以感知到从而下线。

硬盘缓存、无损启停。采用memory可能会带来些不好的问题，如果内存队列改成文件就没有这个问题。因为内存速度快，存储强制刷新的时候就没有数据了，所以我们做了优化：还是采用memory，在Flume停的时候把数据采集下来，下一次启动的时候把数据发出去，这时就可以做到无损启停，但是有一点千万要注意：磁盘其实是固化在机器里面，当这台机器停下不再启动的时候，别忘了把数据移走发出去。

停止顺序优化。在做优化的时候遇到源码的修改，其实就是Flume停止顺序的优化。原生里好像先停止Channel，然后提高sink，这就会导致想要做这个功能的时候做不到。我们应该先把这个数据改掉再去停止sink最后停止Channel，这样就保证Channel里的数据可以全部固化到硬盘里。

多种转发方式。我们现在是全球的RBC，支持公网、内网、跨域性专线，我们提供一个非常好的功能：http sink，它也是一个安全的支持ssl的转换方式。

自定义Sink，多线程发送（channel的get只能单线程）。

4、停止顺序

如图是停止顺序的修改。这是一个sourceRunner、sink、channel。

5、Memory的capacity

选择内存之后，这个内存大小到底多少比较合适？如图所示，左边Flume是从500-1000，channel容量是5万、10万，还有Agent的个数、线程，我们发现在10万的时候它的fullGC是非常频繁的，所以我们最后定的大小是5万。当然不同的机器根据不同的测试得到自己的值，这个值不是恒定的。

包大小从10K到30K到50K有什么不一样呢？很明显TPS从1万多降到了2000多，因为包越大网卡就越慢了，这里看到其实已经到了200兆（双网卡），把网卡跑满了。我们做流平台设计的时候，不希望链路被跑满，所以我们给了个建议值，大小在5-10K。当然，线上我们采用的万兆网卡。

七、实时计算

1、实时计算集群

在SparkZK里直接写HA，可以减少不必要的MR提高IO，减少IO消耗。

Kafka+Strom (ZK)

2、Spark实践

直接写HDFS底层文件

自动创建不存在的Hive分区

相应Metaq的日志切割，这一点上现在的Kafka是没有问题的，当时的日志切割会导致网络连接超时，我们查看源代码发现确实会堵塞，我们的解决方法是把切割调成多色或分区调多。

不要定时的killJob。早期的Spark版本因为大批量的killJob导致一些不稳定的情况，某些job其实是没有被完全覆盖，假死在那里的。

延展阅读：魅族大数据运维平台实践

来源：msup

一、大数据平台介绍

1.1大数据平台架构演变

如图所示魅族大数据平台架构演变历程：

2013年底，我们开始实践大数据，并部署了测试集群。当时只有三个节点，因为我们起步比较晚，没有赶上Hadoop1.0，直接是用YARN来跑的大数据集群，而且默认就上了HA功能；

2014年9月节点增加到20个，数据日增30GB；

2015年6月上线Spark和Hbase，同时节点达到100个，数据日增10T；

2016年5月实现数据异地灾备；

现在我们主要在做大数据安全方面，包括用户认证和授权。目前规模已达到近千台服务器，存储30PB，日增60TB，每天跑2万个计算任务，业务包括搜索、广告、推荐、统计分析、用户画像、崩溃跟踪等等，今年还准备上线一个新机房，专门用来跑大数据业务。届时节点将达到2000个以上。

上图展示的是魅族大数据的整体架构，组件很多，组件之间相互关联，提供的应用也很多。

1.2 大数据运维的挑战

运维这样一个大规模的平台要面对哪些挑战呢？

首先来看大数据运维的特点。

l 集群规模、数据量大，且爆发式增长。大数据从字面上理解就是“大”，数据量大、规模大，而且是爆发式增长。

l 组件多，相互关联，关系复杂。

l 组件批量部署、上下线。部署上线的时候一般都是批量进行的，如果用传统方式（比如脚本工具）操作的话效率非常低，且容易出现问题。

大数据运维的特点决定了大数据运维的核心问题主要体现在两个方面：

l 一是如何管理好如何大规模的集群；

l 二是如何为用户提供高质量的服务。

因此，大数据运维的目标是：

l 以解决运维复杂度的自动化为首要目标。自动化能够提升稳定性，机器的操作比人要靠谱，固化的操作交给机器去做，可以降低人为造成的一些错误，提高线上的稳定性；；另一方面，自动化能够提高效率，把大部分操作交给机器之后，把运维人员从日常繁琐的操作中解放出来，我们就有更多的时间完成更加有意义、有价值的事情。

l 以预测和自动决策为目标的智能化。大数据运维的趋势正在从以解决运维复杂度为目标的自动化，向以预测和自动决策为目标的智能化转变，所以我们先要做好自动化才可以拥抱智能化。

1.3大数据运维存在的问题

大数据运维存在的问题包括：

l 部署及运维复杂。

l 重复监控、重复告警、监控分散。

l 权限控制、安全审计、任意跑任务。我们没有对用户的权限进行限制，一个用户拿一个账号就可以访问整个集群的数据，安全审计方面我们无法得知该用户是否访问敏感数据。另外，在Hadoop官网上也没有完善的用户管理体系和开箱即用的安全设置，需要我们摸索和实践。

l 无法查询业务资源使用、任意申请资源。在资源使用上，我们不知道业务每天用了多少存储、多少计算资源，业务要扩容也只是口头说资源不够了，而且运维他也没有足够的理由不给。

二、大数据运维平台建设

2.1 平台选型

首先要选择一个适合自己需求的平台进行开发。现在比较有代表性的平台选型是Cloudera和Hortonworks，当然我们也可以自己进行组件开发。基于公司的现状，用商业产品成本太大，完全照搬开源产品又不能满足我们的需求。

对比来看商业化产品和开源产品：

l 商业化产品，优点是安装部署非常简单，界面功能齐全；缺点是更新比较慢，因为它是非开源的，我们无法对其进行优化，而且一般商业化产品占用系统资源也比较高。

l 开源产品，优点是非常开放、自由，有强大的社区支持，安装部署方便；缺点是稳定性比较差，功能比较固定。

l 还有第三种选择，就是自研，我们独立研发产品，这样就可以实现定制化，功能灵活丰富，但同样存在缺点：耗时耗力，研发成本非常高。

我们的做法是集中三者的优点，在投入较低成本的情况下，获得功能丰富、可定制化、稳定迭代的管理平台，在出现问题的时候我们又可以依靠强大的社区得到快速解决。

2.2组件版本选型

基于业务发展需求，以及考虑到组件本身的稳定性和安全性，我们需要在不同阶段对组件的版本进行迭代和微调，由此可见商业方案和开源方案是走不通的，这些方案的版本都比较固定。

2.3运维规范制定

在平台化建设之前，我们做了很多技术规范，通过标准化来规范运维操作，平台化来落地标准化。

l 系统规范，主要是约束系统的版本、内核、系统账号等；

l 部署规范，主要是约束组件的版本、配置等；

l 扩容和升级规范，主要是用来制定扩容的窗口期等；

l 任务运行规范，比如说一个任务不能一天24小时跑下去；

l 监控标准，我们尽可能的避免规范造成的事故。

我们通过制定规范来约束人员操作，最大限度避免因不规范造成的运维事故。

2.4平台建设历程

上图是我们整个平台建设的历程。

l 首先通过平台将固化操作自动化，并通过平台化落地规范。

l 然后是建立统一的监控与告警平台。

l 第三是建立全面的安全防护。

l 最后是实现资源使用可视化、成本化。

2.4.1 平台化、自动化

如图，以一个集群的生命周期展示大数据运维是如何做到平台化和自动化的。

装机平台&云平台

第一步是初始化，也就是系统的安装。根据机器的不同，分为物理机和虚拟机。物理机有装机平台，在平台上可以批量安装物理机操作系统，规范系统版本和账号。虚拟机也有云平台，可以批量创建并初始化云主机，可用于跑一些临时任务或实验性的集群。

集群管理

集群管理方面，之前说到的商业化产品也好，开源产品也好，一般都是针对单个集群来进行管理的。如果有多个集群，就必须部署多套平台来进行管理，这在一定程度上增加了运维的复杂度。

我们的做法是将多套集群统一管理起来，它们又拥有各自独立的空间互不干扰。在产品层面上实现前群分组管理，降低了运维难度，提高了运维效率。

主机管理

在平台上可以查看主机状态、过滤主机列表、执行主机级操作，比如为一些主机进行开关机操作，还可以删除主机、添加主机做机架管理、机架展示等。

主机列表

在主机列表页面，可以方便地看到主机详情和组件状况，健康状态、使用状态，包括CPU、内存、磁盘等方面的情况。

主机的健康状态主要分为四种，如果图标是红色，表示主机上至少有一个master组件挂掉了；橙色表示至少有一个Stave组件是挂掉的；黄色表示主机三分钟没有上报心跳了；蓝色则表示主机运行状态正常。

组件运维

在组件运维方面，可以看到所有的组件概述和状态，也可以实施组件级别的启停操作、添加删除组件、修改组件配置、执行组件的操作。集群完整的生命周期应该包括下线，就是回收阶段，这部分也比较好理解，基本上就是把上面的四步倒过来操作就可以了。

通过平台化我们落地了标准化，自动化又大大降低了大数据集群部署的难度，提高了运维效率，保证了集群的稳定性。

2.4.2 统一监控和统一告警

监控数据收集架构（时序指标）

前面提到传统大数据监控是比较分散的。我们的方案是用AMBARI指标监控系统，它可以统一监控平台各类服务及主机的运行情况，提供各类服务及主机的相关指标，从而达到判断集群健康情况的目的。整个流程包括监控指标的采集、存储、聚合及指标获取。

数据的收集流程

首先是位于主机上的AMS Client会不断的收集集群相关的各项指标和性能数据发送到ams的 metric collector，metric collector会将收集到的数据分别存到两张表里面

一张是以主机为单位的指标信息表，一张是以集群为单位的指标聚合信息表。

然后是指标的获取，Ambari提供了两种方式：一种是通过指标获取中心获取；另一种是通过Ambari Server端获取，前一种方式更接近于原生的指标数据，后一种方式则是更为常用的方式，可以说Ambari上层指标的获取都是通过这种方式来获取的，但本质上还是调用的第一种方式，拿到库中的原生数据，再进行加工及逻辑处理，最后返回到WEB端。

统一告警平台：接收告警并根据规则发送给责任人

有监控的需求就有告警的需求，但告警不能仅仅是对信息的转发，不然会让告警接收人员淹没在茫茫告警信息里面，所有的告警信息必须要有一个统一的平台进行接管，平台对收到的信息进行必要的和按规则设定进行合并再发送。

我们开发统一告警平台的目的解决报警遗漏、对非值班人员的打扰以及减少告警疲劳，确保报警/故障/提醒通告等及时、准确、高效地通知到具体人员。通过优化现有报警处理流程，我们引入值班机制、告警升级机制、告警合并收敛规则，做到故障的准确通知。通过统一监控平台和统一告警平台，降低大数据告警设置的难度，同时也提高了运维人员对告警的敏感度。

2.4.3认证、授权、审计全面防护Hadoop

全面防护Hadoop。我们最早部署Hadoop集群时并没有考虑安全问题，随着集群的不断扩大，各部门对集群的使用需求增加，集群安全问题就显得颇为重要。通过上图来看从里到外的安全防护体系主要包括哪些方面。

l 最里面的是OS级别的安全，主要是一些账号设置等。

l 第二方面是权限控制，主要是对特定资源和特定访问用户进行授权或拒绝访问。权限控制是建立在安全认证基础上的。

l 第三层次是安全认证，安全认证是对用户的身份进行核对，确保用户是正确的用户，我们用的是Kerberos体系。

l 最后是网络边界安全体系，包括硬件防火墙，VLAN/子网隔离等等。

l 通过这四层，我们保证进来的用户都是通过安全认证的，而且是有权限去操作这个集群的。但用户操作是否合理、到底访问了哪些数据，或者说有没有尝试访问敏感数据，这就要交给审计来做了，安全审计对数据安全也是至关重要的。OS级别的安全和网络安全一般都是统一的，这里不做展开。

安全认证

Hadoop的安全认证是基于Kerberos来做的，Kerberos是一个网络身份验证协议，用户输入自己的验证信息来进行验证，如果验证通过，会获取到ticket，用户拿这些ticket去访问多个接入Kerberos的服务。

它主要解决了服务器到服务器的认证，解决了Client到服务器的认证，但对用户级别的认证没有实现，也就是说它无法限制用户提交作业。

Hadoop本身并不串接用户账号，它主要是通过Kerberos协议对用户的身份进行验证。我们从 YARN 上的 MR 任务提交过程简单说明一下。

在客户端执行任务之前，它会先跟KDC做自我验证，获取TGT，客户端通过TGT向KDC请求服务ticket，KDC 生成 session key 后一并发给客户端，客户端拿到ticket之后，向服务验证自己，完成身份验证。

权限控制

权限控制我们用的是Hadoop系统当中的安全管理框架Apache Ranger来实现，它是一种定义和管理安全策略的集中式组件，里面内置了一些通用的策略防护和策略模型，这些安全策略在Hadoop支持的组件上会被强制执行。

如上图，我们来看一下策略执行过程。

首先用户请求资源，匹配到该资源的所有权限，然后对所有资源进行检查，先看是不是在拒绝访问列表里，如果在就拒绝访问，如果不在就看是不是在允许列表里，如果在就允许访问，如果不在，就拒绝访问，或者做决策下放。Ranger可以选择将决策下放给系统本身的访问控制层。

Ranger架构

Ranger架构主要由三个部分组成：

第一部分是同步用户，它会定期加载用户，然后同步给管理中心；

第二部分是管理中心，管理中心提供接口，同时也执行用户设置的策略。

第三部分是客户端的插件。这些插件会被嵌入到组件执行流程当中，定期向管理中心拉取策略，用来执行这个策略的访问决策。当然它也会定期把这些访问的审计日志记录起来。

安全审计

安全防护的最后一环是审计。审计我们用的是Apache Eagle框架，它是一个高度可扩展的行为监控警报平台，采用了灵活的应用框架和经过实践考验的大数据技术，如 Kafka，Hbase和 Storm。提供了基于元数据驱动的告警引擎和高度可定制的告警策略来报告异常行为的发生，实时监控用户的操作行为，实时检测敏感数据访问和恶意数据操作。

Apache Eagle框架主要由三个部分组成：

l 首先是数据流的接收和存储。Eagle支持任何类型的数据流接收到它的策略引擎中。比如HDFS的审计机制可以通过Kafka将这些资质收集过来，发送到简单的策略执行当中进行处理。

l 第二部分是主机的实时数据处理引擎，Eagle提供一个独立于物理平台的高效流处理API，处理实时发过来的数据。

l 第三个是告警，它提供了灵活的告警框架。

Eagle的应用场景，主要是用来做数据行为监控。

l 监控Hadoop中的数据访问。

l 检测非法入侵和违反安全规则的行为。

l 检测敏感数据访问，防止数据丢失。

l 基于策略的实时检测和预警

l 基于用户行为的异常检测

安全是互联网产品的生命基线，我们通过认证、授权、审计全方位的防护Hadoop的安全，保障了大数据集群的稳定运行。而成本则是最终校验运维效率的标准，如人力成本的节约、业务资源使用的把控都是运维价值的直接体现。

2.4.4资源可视化、成本化

在进行资源可视化、成本化之前，我们常常不知道一个业务资源使用是否合理、资源扩容是否有必要。通过对业务资源的可视化、成本化，可以统计业务资源消费、展示业务消费明晰、任务详细信息，可以提供业务弹性依据，为推动业务优化计算任务提供有利依据。

在这个平台上我们直观给出每个业务系的CPU、内存、存储的占用情况、使用的时长，以及转换的成本，同时也可以通过消费曲线观察异常消费，进行成本优化。

我们还从用户的维度给出消费明细，做到有理有据，便于后面的一些反查。

同时还可以了解到任务详细运行情况。比如任务的类型，什么时候启动，什么时候结束，使用时长等。

以上所述是大数据运维平台建设过程当中所用的一些方法论和技术。

三、总结与展望

3.1 总结

l 在质量和效率上，阐述了大数据运维平台化和自动化的必要性，实现了集群、主机、组件自动化部署与管理；

l 在安全上，解决了谁有权限、有什么权限、做了什么的问题，保证了平台的安全；

l 在成本上，做到了有图有真相，伸缩有依据，优化有目标。

3.2 展望

l 大数据运维的总体目标是用尽可能低的成本来提供足够好的服务质量和用户体验。网络带宽、服务器、维护人力是大数据成本主要的来源，我们希望通过大数据分析技术，对硬件故障的预测和自动化进行管理，对机器的管理实现零投入，最大化利用资源，减少预算开销。

l 提供高质量业务运维服务，我们希望用户可以通过平台申请自动创建交付集群，开展业务运营。

l 同时我们也希望运维团队可以充分利用大数据分析技术提升预测、发现和自动检测的能力，预测分配资源，动态伸缩集群，实现智能预警，自动修复，推动运维向智能化方向发展。

11月9-12日，北京国家会议中心，第六届TOP100全球软件案例研究峰会，魅族科技主题桌面负责人谭林英将分享《手机厂商如何做互联网产品》。

人工智能赛博物理操作系统

AI-CPS OS

“人工智能赛博物理操作系统”（新一代技术+商业操作系统“AI-CPS OS”：云计算+大数据+物联网+区块链+人工智能）分支用来的今天，企业领导者必须了解如何将“技术”全面渗入整个公司、产品等“商业”场景中，利用AI-CPS OS形成数字化+智能化力量，实现行业的重新布局、企业的重新构建和自我的焕然新生。

AI-CPS OS的真正价值并不来自构成技术或功能，而是要以一种传递独特竞争优势的方式将自动化+信息化、智造+产品+服务和数据+分析一体化，这种整合方式能够释放新的业务和运营模式。如果不能实现跨功能的更大规模融合，没有颠覆现状的意愿，这些将不可能实现。

领导者无法依靠某种单一战略方法来应对多维度的数字化变革。面对新一代技术+商业操作系统AI-CPS OS颠覆性的数字化+智能化力量，领导者必须在行业、企业与个人这三个层面都保持领先地位：

重新行业布局：你的世界观要怎样改变才算足够？你必须对行业典范进行怎样的反思？
重新构建企业：你的企业需要做出什么样的变化？你准备如何重新定义你的公司？
重新打造自己：你需要成为怎样的人？要重塑自己并在数字化+智能化时代保有领先地位，你必须如何去做？

AI-CPS OS是数字化智能化创新平台，设计思路是将大数据、物联网、区块链和人工智能等无缝整合在云端，可以帮助企业将创新成果融入自身业务体系，实现各个前沿技术在云端的优势协同。AI-CPS OS形成的数字化+智能化力量与行业、企业及个人三个层面的交叉，形成了领导力模式，使数字化融入到领导者所在企业与领导方式的核心位置：

精细：这种力量能够使人在更加真实、细致的层面观察与感知现实世界和数字化世界正在发生的一切，进而理解和更加精细地进行产品个性化控制、微观业务场景事件和结果控制。
智能：模型随着时间（数据）的变化而变化，整个系统就具备了智能（自学习）的能力。
高效：企业需要建立实时或者准实时的数据采集传输、模型预测和响应决策能力，这样智能就从批量性、阶段性的行为变成一个可以实时触达的行为。
不确定性：数字化变更颠覆和改变了领导者曾经仰仗的思维方式、结构和实践经验，其结果就是形成了复合不确定性这种颠覆性力量。主要的不确定性蕴含于三个领域：技术、文化、制度。
边界模糊：数字世界与现实世界的不断融合成CPS不仅让人们所知行业的核心产品、经济学定理和可能性都产生了变化，还模糊了不同行业间的界限。这种效应正在向生态系统、企业、客户、产品快速蔓延。

AI-CPS OS形成的数字化+智能化力量通过三个方式激发经济增长：

创造虚拟劳动力，承担需要适应性和敏捷性的复杂任务，即“智能自动化”，以区别于传统的自动化解决方案；
对现有劳动力和实物资产进行有利的补充和提升，提高资本效率；
人工智能的普及，将推动多行业的相关创新，开辟崭新的经济增长空间。

给决策制定者和商业领袖的建议：

超越自动化，开启新创新模式：利用具有自主学习和自我控制能力的动态机器智能，为企业创造新商机；
迎接新一代信息技术，迎接人工智能：无缝整合人类智慧与机器智能，重新
评估未来的知识和技能类型；
制定道德规范：切实为人工智能生态系统制定道德准则，并在智能机器的开
发过程中确定更加明晰的标准和最佳实践；
重视再分配效应：对人工智能可能带来的冲击做好准备，制定战略帮助面临
较高失业风险的人群；
开发数字化+智能化企业所需新能力：员工团队需要积极掌握判断、沟通及想象力和创造力等人类所特有的重要能力。对于中国企业来说，创造兼具包容性和多样性的文化也非常重要。

子曰：“君子和而不同，小人同而不和。” 《论语·子路》云计算、大数据、物联网、区块链和人工智能，像君子一般融合，一起体现科技就是生产力。

如果说上一次哥伦布地理大发现，拓展的是人类的物理空间。那么这一次地理大发现，拓展的就是人们的数字空间。在数学空间，建立新的商业文明，从而发现新的创富模式，为人类社会带来新的财富空间。云计算，大数据、物联网和区块链，是进入这个数字空间的船，而人工智能就是那船上的帆，哥伦布之帆！

新一代技术+商业的人工智能赛博物理操作系统AI-CPS OS作为新一轮产业变革的核心驱动力，将进一步释放历次科技革命和产业变革积蓄的巨大能量，并创造新的强大引擎。重构生产、分配、交换、消费等经济活动各环节，形成从宏观到微观各领域的智能化新需求，催生新技术、新产品、新产业、新业态、新模式。引发经济结构重大变革，深刻改变人类生产生活方式和思维模式，实现社会生产力的整体跃升。