4.3 基础能力要求
大数据平台基础能力,作为大数据平台体系的核心部分,提供大数据平台存储框架、计算框架、管理框架,并将大数据能力开放,为各应用系统提供可调用的服务。
4.3.1 总体概述
1.体系架构
大数据平台基础能力,包括基础框架和能力开放两部分,为大数据平台提供存储、计算和平台管理相关能力组件,支撑大数据平台核心数据处理,并通过多形式的能力开放,实现对业务的快速响应。
基础框架,为大数据平台提供基础能力,包括存储框架、计算框架和管理框架。存储框架,实现对海量结构化和非结构化数据高效安全的长期存储,并实现简单快速的管理和维护;计算框架,通过多种开源、成熟、高效的计算组件,实现不同业务场景和数据格式的计算处理,主要分为实时计算、准实时计算和批处理计算;管理框架,提供对整个基础能力系统相关平台的资源管控、任务调度、监控告警、元数据管理等功能,以保障平台的安全运营。
能力开放,主要包括数据开放、服务开放和应用开放。
① 数据开放,数据的自由流通最为关键,必须打破数据孤岛。为此,在业务部门对数据安全进行授权许可的情况下,允许将整理后的基础数据,对数据需求方开放,支撑业务与数据服务。
② 服务开放,实现对企业内部的各类数据需求进行集约化,以提供高效、快速的数据服务响应能力,这是大数据平台实现对内数据支撑的主要通道。同时,通过统一封装的接口,对外部合作客户提供各类数据服务、查询功能。另一方面,可以在大数据平台通过数据沙箱的方式开放部分数据,同时提供常用的算法工具和分析工具,供用户通过程序算法进行数据挖掘分析。
③ 应用开放,通过统一、标准的接口封装,向合作伙伴和用户提供数据服务。对外接口需满足合作伙伴和用户对数据的要求,可向合作伙伴和客户按照实时、准实时、批量同步等数据传输策略提供接口。外部接口须保障企业数据、合作方数据的安全性,除已授权的用户、合作方、客户、应用外,不得对外泄露数据信息。
2.关键能力
企业大数据平台的基础能力是要在业务承载上支撑大数据平台核心处理能力及其相关应用。需要综合考虑移动互联网对企业业务运营的整体要求,以及海量数据的有效存储管理能力、多模式的高效数据处理能力和面向业务的灵活、开放的数据服务能力等要求。对大数据平台基础能力的相关技术组件的引用上,以互联网开源、成熟的IT技术为原型,在适当定制开发的基础上形成面向和适应企业业务运营支撑的关键技术组件,并在此基础上,构成企业大数据平台基础能力系统的关键能力视图。
(1)关键技术组件视图
大数据平台基础能力关键组件如图4-16所示,可分为存储框架、计算框架、管理框架和能力开放四大类。
图4-16 基础能力关键组件视图
① 存储框架类中,包括分布式文件系统HDFS、NoSQL数据库、内存数据库和管理非关系数据库元数据的MySQL。
② 计算框架类中,包括分布式计算组件、数据仓库组件、内存计算组件、流式处理组件和实时检索组件。
③ 管理框架类中,包括平台资源管理组件、分布式协同组件、安全认证组件、平台监控组件、任务调度管理组件以及元数据管理组件。
④ 能力开放类中,包括对平台内部数据、服务进行统一、标准化封装,并通过Web Service、JDBC和JSON对外提供的开放能力。
(2)关键能力目录
在大数据平台基础能力关键组件的基础上,大数据平台通过对关键技术组件进一步进行组合、封装或集成,进而在大数据平台面向业务和运营中分出不同角色权限的关键能力目录,如图4-17所示,具体可分为资源、数据、工具、服务四类能力。
图4-17 基础能力图
① 资源类,包括海量存储、分布式缓存、离线计算和实时计算等四类能力。
② 数据类,包括应用宽表、指标库、标签库等三类能力。
③ 工具类,包括报表工具、编辑器/设计器、调度工具、Web组件等四类能力。
④ 服务类,包括OpenAPI、数据地图、数据接入和数据共享等能力。
4.3.2 基础框架
如图4-18所示,大数据平台基础框架包括管理、计算、存储三个框架。
图4-18 基础能力框架图
① 存储框架,对数据存储提供基于HDFS的列式存储数据库(HBase),以及并行架构下的分布式数据库。
② 计算框架,部署多种计算引擎,支撑不同数据服务应用场景,具体为:
● MapReduce,支撑数据清洗、转换等ETL批处理类任务;
● Impala和Hive,支撑OLAP类简单数据统计的快速响应;
● Spark SQL、Spark Streaming、Storm,支撑实时、准实时数据计算;
● MapReduce、Spark,支撑机器学习类预测性数据挖掘分析;
● ESearch,支撑基于数据标签的快速信息检索等探索性数据分析。
② 管理框架,主要包括资源管理、分布式协同、调度管理、平台监控、元数据管理。其中,YARN、MESOS、Docker、ZooKeeper,实现对平台资源的管控;Kerberos、Hortonworks的Ranger、Cloudera的Sentry,支撑平台的数据安全。
1.存储框架
大数据平台,要求海量存储,采用分布式文件系统、NoSQL和关系数据库做支撑,实现海量数据高效、安全地长期存储,以及简单快速的管理和维护。
(1)分布式文件系统
分布式文件系统可以存储结构化数据和非结构化数据。大数据分布式文件系统应具有以下特性:
● 廉价存储,单位存储成本低;
● 易用,可提供方便的对外接口;
● 横向扩展能力,支持上万节点的分布式存储集群;
● 负载均衡,保持数据节点的存储平衡;
● 高容错,保证数据的安全不丢失,可自动将出现故障的服务器上的数据和服务迁移到集群中的其他服务器;
● 支持多种存储格式,如Text、LZO、Snappy、RCFile等;
● 高可用,主节点实现HA,主节点挂掉时自动切换到备用节点,服务不终止,提高稳定性。
① 性能指标
分布式文件系统正常情况下应在50ms内响应。分布式文件系统应具有动态的横向扩展能力。可以扩展到不少于1万个节点。
② 应用场景
分布式文件系统适用于提供低成本高效率的对象存储服务,包括云应用程序、内容分发、备份和归档、灾难恢复等。分布式文件系统可单独使用,也可以和分布式计算框架结合使用。它不适用于大量小文件以及响应要求高的场景,而适合存储企业DPI, AAA,各类详单,WAP网关等数据。分布式文件系统建议采用HDFS。
③ 文件压缩
LZO格式压缩和解压速度比较快,压缩率合理,支持Split,是Hadoop中最流行的压缩格式,支持Hadoop Native库,可以在Linux系统下安装lzop命令,使用方便。建议以LZO压缩格式为主,Snappy配合使用。
④ 文件大小
为避免存储浪费和提高效率,HDFS中应尽量避免小文件,对于大量小文件,建议通过合适的方式进行合并后存储。Block的大小建议设置为128MB或256MB,文件大小建议不小于1GB。
(2)NoSQL数据库
NoSQL数据库具有以下优点。
● 易扩展性:可以在最小化系统开销和不停机的情况下,线性增加系统的存储容量和计算能力,系统可以自动地进行负载均衡,同时能够利用新的硬件资源,适应数据的不断增长。
● 高效的随机读:虽然应用级Cache层被广泛使用在应用服务器和数据库之间,大数据规模应用的大量访问仍然无法命中Cache,需要访问后端存储系统,NoSQL可以解决这一问题。
● 写吞吐率高:大数据规模的应用需要很高的写吞吐率。
● 高效低延迟的强一致性:实现一个全局的分布式强一致性系统是很难的,但是一个至少能在单个数据中心内部提供这种强一致性的NoSQL数据库系统已经可以提供较好的用户体验。
● 高可用性和容灾恢复:可提供HA,能够容忍某个数据中心的失败并最小化数据丢失,同时能够在合理的时间窗口内通过另一个数据中心提供数据服务。
● 故障隔离性:能有效地对磁盘系统上的故障进行容错和隔离,单个磁盘的故障只会影响很小的一部分数据,同时系统可以很快地从故障中恢复。
● 大数据分析的支持:可利用分布式编程模型进行数据分析,无须做任何的数据迁移。
① 性能指标
正常情况下NoSQL可以实现10ms内响应。吞吐量和集群规模正相关。单台服务节点应提供不低于4万QPS的服务能力。
响应时间还取决于单次查询的数据量或者插入的数据量等。
② 应用场景
NoSQL适用于低延迟的数据访问应用,适合在线应用的场景,例如K-V(键值)查询。
常用的NoSQL数据库包括键值存储数据库、列式存储数据库、文档型数据库、图形数据库。
大数据平台的NoSQL建议采用HBase实现。
(3)列式存储数据库
列式存储数据库是以列相关存储架构进行数据存储的数据库,主要适合于批量数据处理和即时查询。相对应的是行存储数据库,数据以行相关的存储体系架构进行空间分配,主要适合于小批量的数据处理,常用于联机事务型数据处理。
列式存储数据库优点包括:
● 极高的装载速度(最高可以等于所有硬盘IO的总和);
● 适合大量的数据;
● 实时加载数据仅限于增加(删除和更新需要解压缩Block,然后计算,此后再重新压缩储存);
● 高效的压缩率,不仅节省储存空间也节省计算内存和CPU;
● 非常适合做聚合操作。
① 性能指标
统计类操作应在10s内响应,即时查询应在10ms内响应。
② 应用场景
批量数据统计分析和即时查询。
大数据平台的列式存储数据库推荐使用HBase。
(4)缓存数据库
分布式缓存能够处理大量的动态数据,因此比较适合互联网等大规模应用。从本地缓存扩展到分布式缓存后,关注重点从CPU、内存、缓存之间的数据传输速度差异扩展到了业务系统、数据库、分布式缓存之间的数据传输速度差异。分布式缓存有如下特性:
● 高效地读取数据;
● 能够动态地扩展缓存节点;
● 能够自动发现和切换故障节点;
● 能够自动均衡数据分区;
● 能提供图形化的管理界面,部署和维护都十分方便。
① 性能指标
分布式缓存应在0.1ms内响应,应提供不低于8万IOPS的吞吐量。
② 应用场景
分布式缓存由于是基于内存的,所以适用于小数据量的缓存。例如辅助数据库操作提升信息的查询速度的场景、社交网站等需要由用户生成内容的场景等。
大数据平台的分布式缓存推荐使用Redis、Memcached。
(5)关系数据库
关系数据库,是建立在关系模型基础上的数据库,借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。它目前还是数据存储的传统标准。
关系数据库具有以下优势:
● 可保持数据的一致性(事务处理);
● 由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处);
● 可以进行Join等复杂查询。
上述特性中,能够保持数据的一致性是关系数据库的最大优势。
① 性能指标
单个事务处理在50ms内完成,指定主键的Join查询在50ms内完成。
② 应用场景
关系数据库适合用户存储元数据、用户权限等数据。
大数据平台的关系数据库推荐使用MySQL。
2.计算框架
分布式计算分为实时计算、准实时计算、批处理。
(1)实时计算
实时计算一般分为三个阶段,数据的产生与收集阶段(实时收集)、传输与分析处理阶段(实时处理)、存储与对外提供服务阶段(实时查询)。实时计算应提供以下功能:
● 简单的编程模型;
● 多编程语言支持;
● 支持容错;
● 可管理工作进程和节点的故障;
● 支持水平扩展;
● 计算是在多个线程、进程和服务器之间并行进行的;
● 可靠的消息处理;
● 保证每个消息至少能得到一次完整处理,任务失败时,它会负责从消息源重试消息;
● 低延迟,高效消息处理;
● 系统的设计保证消息能得到快速的处理。
① 性能指标
实时计算应实现1秒内响应。单机能处理每秒不低于50万条记录。
② 应用场景
实时计算适用于低延迟的场景,例如实时统计报表、实时算法、实时机器学习等。适用于企业DPI、各类详单等数据的实时清洗、稽查等。
大数据平台的实时计算框架(流式计算)推荐使用Storm、Spark Streaming。
(2)准实时计算
为支撑准实时应用,需具备准实时数据接入能力。准实时接入能力需具备秒级响应,保证数据的安全性、一致性和准确性。准实时计算的基本特性如下。
● 高性能,能够以低资源消耗完成每秒数千交易的传送或者复制;
● 兼容性,开放的结构使客户适应各种异构数据平台;
● 可靠性,保证数据的连续可用;
● 一致性,支持断点,恢复后自动从断点续传;
● 安全性,数据传输过程中采用压缩和加密;
● 高可用性,保障业务近似零停机,降低业务中断带来的损失。
① 性能指标
准实时计算应在秒级到10分钟内返回。响应时间依赖于提交作业处理的数据量以及复杂度。
② 应用场景
准实时计算适用于大数据领域交互式、面向Ad-Hoc查询的SQL分析场景。适用于客户营销维系、自助评估分析等。
大数据平台的准实时计算框架推荐使用Spark SQL。
(3)批处理
大数据平台有很好的横向扩展能力,能提供针对TB/PB级别数据、实时性要求不高的批量处理能力,主要应用于大型数据仓库、日志分析、数据挖掘、商业智能等领域。批处理应具备以下功能:
● 具备跨集群数据共享能力,支持万级别的集群数,扩容不受限制;
● 提供功能强大易用的SQL、M/R引擎,兼容大部分标准SQL语法;
● 可轻易获得海量运算,用户不必关心数据规模增长带来的存储困难、运算时间延长等烦恼,大数据平台根据用户的数据规模自动扩展集群的存储和计算能力,使用户专心于数据分析和挖掘,最大化发挥数据的价值。
① 性能指标
● 横向扩展不低于1万个节点;
● 吞吐量与集群规模、作业复杂度有关,例如500台集群每天可处理不低于10万个作业。
② 应用场景
批处理适用于高延迟的计算服务,例如离线数据分析、搜索引擎建立索引等场景,适用于DPI等数据分析、推荐等应用;
大数据平台的批处理框架推荐使用MapReduce, Hive。
3.管理框架
(1)资源管理
① 资源分配
资源分配应具有以下功能。
● 支持多租户。弹性的存储和计算资源分配,租户可按需申请资源配额,独立管理自己的资源;租户独立管理自有的数据、权限、用户、角色,彼此隔离,以确保数据安全;租户间可通过数据授权来实现数据交换,提供多种形式的授权策略。
● 支持任务优先级。在资源使用高占比的情况下,能根据运行中的任务优先级,动态调整其在队列中的资源占比,保证高级别任务优先完成。
● 可以配置最小保证的资源和最大可以使用的资源。
● 可以配置最大同时可以运行的Job数量。
● 可以配置资源池的使用权限和管理权限,使用权限可以提交作业,管理权限可以Kill作业、修改资源。
② 资源调度
常用的资源调度器有FIFO, Fair Scheduler, Capacity Scheduler等,用户也可以按照接口规范要求编写自定义的资源调度器,并通过简单的配置使它运行起来。资源调度应具有以下功能。
● 资源表示模型。执行节点向主控节点注册,注册信息包含该节点可分配的CPU和内存总量等。
● 资源调度模型。为了提高可扩展性,可采用双层资源调度模型。双层调度器仍保留一个经简化的集中式资源调度器,但具体任务相关的调度策略则下放到各个应用程序调度器完成。
● 资源抢占模型。为了提高资源利用率,资源调度器会将负载较轻的队列的资源暂时分配给负载重的队列,仅当负载较轻队列突然收到新提交的应用程序时,调度器才进一步将本属于该队列的资源分配给它。考虑此时资源可能正被其他队列使用,因此调度器必须等待其他队列释放资源后,才能将这些资源“物归原主”,这通常需要一段不确定的等待时间。为了防止应用程序等待时间过长,调度器等待一段时间后若发现资源并未得到释放,则进行资源抢占。
● 层级队列管理:层级队列组织方式应具有以下特点。第一,子队列:队列可以嵌套,每个队列可以包含子队列。第二,最小资源:可以为队列设置一个最小容量,表示该队列能保证的最小资源。第三,最大资源:可以设置一个最大容量,这是资源的使用上限,任何时刻使用的资源总量都不能超过该值。第四,用户权限管理:可以配置资源池的使用权限和管理权限,使用权限可以提交作业,管理权限可以Kill作业、修改资源。
③ 资源隔离
目前主要支持内存和CPU两种资源。内存是一种“决定生死”的资源,CPU是一种“影响快慢”的资源。资源隔离包括:内存隔离和CPU隔离。
(2)任务调度
① 工作流
工作流是放置在控制依赖DAG图中的一组动作(例如,Hadoop的MapReduce作业、Pig作业等),其中指定了动作执行的顺序。工作流应具备以下功能:
提供工作流可视化配置能力,提供简易的图形化的界面,用户可直观地对工作流流程进行编辑,提供拖动功能,如想添加操作仅需拖动图标即可完成。
● 提供常用操作功能支持,如Hive脚本、Hive Server脚本、Pig脚本、Spark、Java程序、Sqoop脚本、MapReduce作业、Shell、SSH、HDFS、邮件、短信、数据流、DistCp支持。
● 提供常用操作功能中的常用配置项的支持,如MapReduce中Map数、Reduce数等。
● 提供工作流执行中遇到异常情况下,消息提示的能力。
● 提供在主工作流中嵌套子工作流的能力。
● 提供工作流保存、提交、分享能力。
② 触发器
触发器构建在工作流工作方式之上,提供定时运行和触发运行任务的功能。触发器本身不会去执行具体的Job,而是将Job相关的所有资源发送到真实的执行环境,如Hive Client、关系数据库系统等,自己仅仅记录并监视Job的执行状态,并对其状态的变化做出相应的动作,例如,Job失败可以重新运行,Job成功转到下一个节点。触发器应具备以下功能。
● 提供对已有工作设置计划任务的能力,包括设置执行频率、执行时间、执行周期等,支持Cron语法。
● 提供对已有工作流设置初始参数的能力,工作流作为模板,用户可根据自身情况自定义工作流执行条件。
● 提供对已有工作流超时时间的设定,精确到秒。超出时间的作业将被强制结束进程。
● 提供SLA配置能力。
③ 协处理器
协处理器将多个触发器管理起来,支持对多个触发器分别设置触发参数,如开始时间、结束时间等,支持自定义参数的设定,只有满足所有指定条件后触发器才开始作业执行。有时候一个作业执行必须依赖另一个作业执行完成的结果,可以在收集器中统一设定,这样只需要提供一个收集器提交即可。然后可以启动/停止/挂起/恢复任何协调者。
④ 作业浏览
常用的作业调度引擎有Oozie, Azkaban等,作业浏览应具备以下功能。
● 提供作业手动执行、停止、暂停、恢复能力,用户可以手动触发作业执行。
● 提供正在运行作业的查看能力,可以查看作业提交时间、状态、名称、进度、提交人等信息。
● 提供已完成历史作业的查看能力,通过列表可对历史作业的提交时间、完成事件、持续事件、名称、提交人等信息进行查看。
● 提供作业全文检索能力,输入框输入任意关键字可对作业进行筛选。
● 提供相同作业历史汇总能力,定时作业在时间范围内重复执行,可以比较每次作业的执行情况。
● 提供作业详细信息的查看能力,包括组、开始、创建、结束时间、应用程序路径、运行次数等。
● 提供作业运行时参数配置的查看能力,包括开始、结束时间、输入输出路径、执行用户等。
● 提供作业日志的查看能力,包括实时的程序日志、输入输出日志、任务诊断日志等。
● 提供作业元数据的查看能力,包括Node地址、执行节点、作业类型、状态、进度、输出大小等。
⑤ 性能指标
● 提供低于1秒的作业提交和响应速度。
● 提供单节点至少支持1万个作业每天的处理能力。
● 提供集群无状态水平扩展能力。
● 提供处理不低于2000个作业的并发能力。
● 提供7×24小时不间断服务。
(3)监控告警
监控告警实现平台多层级可视化监控,包括节点监控,集群监控。监控告警系统支持流程化、可视化。监控告警的目的是为了提高大数据基础能力的服务质量,及时发现异常情况并迅速修复故障。监控实现对关键指标的采集,告警则是利用采集到的指标数据根据告警策略以及告警类型通知运维人员。
① 监控管理
基础监控应具备以下功能:
● 需要提供整个集群基本的CPU、内存、硬盘利用率,I/O负载、网络流量情况的监控。
● 可以了解每个节点的基本运行情况分析。
● 将集群的主机等监控和功能组件自带的监控集成为统一的监控功能。
② 集群监控
集群监控功能是指对大数据的存储资源和计算资源的使用情况进行统一监控和统计的功能。维护人员需要查询多集群的存储资源和计算资源的使用情况,包括多集群的资源使用详细信息。
集群监控的内容包括集群容量、使用率、稳定性、请求响应速度、负载情况等。集群监控应具备以下功能。
a)存储资源监控
● 监控集群存储资源使用情况,应具备以下功能。
● 集群基本信息,包括存储容量、使用率等。
● 集群的负载情况,包括处理队列、等待队列情况。
● 读写请求响应速度监控,根据离线系统和实时系统设置不同的标准。
● 读写的成功率以及失败率。
● 可用性监控,当服务不可用时高优先级告警。
b)计算资源监控
监控各集群资源使用的详细信息,应具备以下功能。
● 对集群CPU使用总时长的监控。
● 对集群内存(物理内存、逻辑内存、堆)使用总容量的监控。
● 对集群主机系统文件的读、写总容量的监控。
● 对集群HDFS分布式文件的读、写容量的监控。
● 对集群任务运行用户的监控。
● 对集群任务运行状态的监控。
● 对集群任务运行过程信息(如MapReduce总数、重复运行次数、MapReduce平均运行时间等)的监控。
c)关键服务监控
大数据平台中有很多关键服务,对集群的稳定性以及可用性影响很大。关键服务监控包括NameNode, ResourceManager, Hive Metastore, Hive Server2等服务。
关键服务挂掉时,监控系统应该能尝试恢复,恢复后以邮件或短信告知集群管理员,如果无法恢复服务,则采取高级别告警。
③ 作业监控
作业监控集中监控各作业运行情况,能够快速反馈并定位作业运维问题,可取代系统运维由运维人员手动完成的现状,降低作业执行错误风险,降低作业运维人员的工作强度,提高企业投资回报率。在监控页面,开发者不仅可以查看当天每5分钟的实时数据,以及最近7天、15天、30天的历史数据,还可以查看任意一天每5分钟的历史数据。
a)作业调度监控
● 提供作业当前24小时调度任务监控。
● 提供作业成功率统计监控。
● 提供作业总数量统计监控。
● 提供作业历史执行结果统计监控。
● 提供作业状态统计监控,包括作业开始时间、成功率、未成功率、失败率、错误率、死亡率等。
b)作业运行监控
● 提供运行中作业类型数量监控能力,可以按作业状态、名称、提交人等信息聚合显示。
● 提供已完成历史作业类型数量监控能力,可以按历史作业的提交时间范围、完成时间范围、持续时间范围、名称、提交人等信息聚合显示。
● 提供自定义面板能力,可以选择自己关注的作业名称,绘图进行监控。
④ 服务监控
服务监控对已经上线的服务提供监控能力,开发者无须申请,服务监控能够帮助开发者及时发现服务中潜在或已经发生的问题。在监控页面,开发者不仅可以查看当天每5分钟的实时数据,以及最近7天、15天、30天的历史数据,还可以查看任意一天每5分钟的历史数据。
a)健康监控
● 提供服务的定期检测能力,检测服务是否能被使用者正常调用。服务开发者须按照平台定义的约定,提供健康检测接口。平台会根据服务重要程度进行定期访问,返回满足约定的视为检测成功。绘制健康检测时间曲线供开发者查看。
● 提供服务的定期Ping检测能力,按用户设定周期定期执行Ping操作,收集数据绘制图表。
● 提供健康评分能力,根据应用平均负载,应用平均访问延时,告警数量等指标进行综合评分后,计算出来反映应用健康程度的分值。
● 实时提供服务的网络入、出流量监控,默认显示2天。同时提供最近7天、15天、30天的网络流量使用情况监控图,还可以查看任意一天的网络流量情况是否与预期相符。
● 实时提供服务的已使用连接数、总连接数、空闲连接数使用情况监控。默认显示2天,同时提供历史数据比较,方便分析问题。
● 提供“导出半年数据”能力,将最近半年每日的网络流量数据导出到本地进行查看。
● 实时提供服务的总请求时间、总服务端响应时间、总平台开销时间监控。默认显示2天,同时提供历史数据比较,方便分析问题。
● 提供服务慢查询监控,将导致慢查询的访问汇总绘制图表。
● 提供服务调用异常监控,收集返回状态码不正常的请求信息汇总绘制图表。
● 提供服务调用超时的请求监控,收集请求源IP、目的IP、请求参数等维度信息汇总绘制图表。
b)请求量监控
● 提供服务总请求次数可视化图形监控。
● 提供基于各个浏览器类型的可视化图形监控。
● 提供基于客户端IP Top 10的可视化图形监控。
● 提供根据HTTP协议行为类别的可视化图形监控服务,如GET、PUT、POST。
● 提供根据协议类型的可视化图形监控服务,如Restful、Soap、SDK等。
⑤ 告警管理
告警是企业给服务开发者的监控告警服务中的一项功能,根据用户设置的阀值对生产中的服务异常情况进行告警,并提供告警信息查看、告警自定义阈值和告警订阅功能。
● 提供基础告警和自定义告警消息能力。
● 提供对已发生过的告警,用告警列表进行展示的能力。
● 提供自定义消息列表展示发生过的自定义消息的能力。
● 提供自定义告警策略能力,可设置一系列告警触发条件的集合。告警触发条件支持“或”关系,即一个条件满足,就会发送告警,也支持“与”关系,即所有条件满足,才会发送告警。
● 提供默认的基础告警策略能力,如健康检测连续失败、请求响应时间超时等。
● 提供配置告警接收组能力,开发者可以把关心相同告警的人聚合到一个组,只有告警接收组内成员才能收到告警信息。
● 提供配置告警接收方式的能力,告警接收方式支持邮件、短信。
● 提供设置告警聚合策略能力,对已发生的告警在一定时间段内的发生次数、类型等进行聚合配置。多次告警产生时,应用此规则,可以将同类型告警进行聚合,以减小告警次数。若数据采集为5分钟一个周期,用户选择持续10分钟,则表示连续2个周期都达到触发条件,才发送告警。
● 提供清楚详细的告警状态描述,包括未恢复、恢复、数据不足等。
● 提供清楚详细的术语定义,包括告警策略、告警触发条件、默认策略、策略类型、告警类型、策略类型与告警类型的关系等。
(4)元数据管理
元数据管理为数据质量管理、日常运行维护、数据安全管理和业务应用提供基础能力支持。元数据管理的建设目标是:开放元数据的基础能力,为灵活多变的元数据应用提供元数据基础服务支持;扩展元数据管理范围,为大数据平台运维和数据质量管理提供数据链路分析支持。元数据管理模块功能结构包括元数据获取层、元数据存储层、元数据功能层,如图4-19所示。
图4-19 元数据管理功能图
① 元数据获取层
元数据获取层位于整个体系架构的底层,元数据获取层抽象概括了元数据获取的各种途径,支持手工获取功能和自动获取功能。
● 手工获取功能支持采用以手工方式和批量半自动等方式(可使用Excel等工具)手动获取业务和管理元数据,以及数据源接口等其他技术元数据。
● 自动获取功能支持技术元数据(包括SQL脚本、数据库元数据、大数据平台元数据等),可采用自动方式获取。
② 元数据存储层
元数据存储层是整个元数据管理平台的核心功能层,定义和规范从元数据获取层得到的各类元数据的属性要求和存储格式要求,包括业务元数据、技术元数据和管理元数据。
● 业务元数据是描述业务领域相关概念、关系和规则的数据,主要包括业务术语、业务指标、业务规则等信息。
● 技术元数据是描述技术领域相关概念、关系和规则的数据,主要包括对数据结构、数据处理过程的特征描述,覆盖数据源接口、数据仓库与数据集市、ETL、OLAP、数据封装和前端展现等数据处理环节。
● 管理元数据是描述管理领域相关概念、关系和规则的数据,主要包括人员角色、岗位职责、管理流程等信息。
③ 元数据功能层
元数据功能层为前端元数据应用提供了基本的功能支撑,主要包括元数据查询和维护、元数据变更管理、元数据统计、全文检索、血缘分析、影响分析、一致性检查、健全性检查、权限管理等功能。元数据功能层包含的功能模块有:基础功能,分析功能,质量检查和其他功能。
a)元数据基础功能
元数据基础功能包括但不限于元数据查询、维护、变更管理、统计,以及全文检索等。
● 元数据查询,指对元数据库中的元数据基本信息进行查询的功能,通过该功能可以查询数据库表、维表、指标、过程及参与的输入输出实体信息,以及其他纳入管理的实体基本信息,查询的信息按处理的层次及业务主题进行组织,查询功能返回实体及其所属的相关信息。
● 元数据维护,元数据维护提供对元数据的增加、删除和修改等基本操作。对于元数据的增量维护,要求能保留历史版本信息。维护操作是原子操作,这些原子操作可通过服务封装的形式向系统的其他模块提供元数据维护接口。
● 元数据变更管理,包括变更通知和版本管理两个部分。变更通知是当元数据发生改变时,系统自动发送信息(邮件、短信)给订阅用户。用户可以主动订阅自己关心的元数据,帮助了解与自身工作相关的业务系统变更情况,提高工作的主动性,版本管理就是对元数据的变更过程进行版本快照。
● 元数据统计,用户可以按不同类别进行元数据个数的统计,方便用户全面了解元数据管理模块中的元数据分布,了解用户对元数据的使用情况,从而为元数据的使用状况做出一个全面的评价,也为元数据管理模块的元数据维护和管理提供参考。所有用户对元数据的访问和操作在元数据管理模块中都应有详细的记录。
● 全文检索,将元数据当中的重点关注数据(如表名及其含义、字段名及其含义、标签等)按照全文检索理论建立起来,提供一个全文检索服务。为用户提供丰富的检索结果展示,能够根据不同类型的元数据,展示不同风格的显示模板,方便用户对检索结果的浏览查看,提高用户对检索效果的满意度。
b)元数据分析功能
元数据分析功能模块是以图形化方式展示元数据的不同数据之间的依赖、关联等关系,以供用户进行直观查看及定位。包含有元数据血缘分析、影响分析、作业依赖分析、数据地图分析、作业运行状态图等。
● 血缘分析指从某一实体作为起点,往回追溯其数据处理过程,直到系统的数据源接口。对于任何指定的实体,首先获得该实体的所有前驱实体,然后对这些前驱实体递归地获得各自的前驱实体,结束条件是所有实体到达数据源接口或者是实体没有相应的前驱实体。
● 影响分析指从某一实体出发,寻找依赖该实体的处理过程实体或其他实体。如果需要可以采用递归方式寻找所有的依赖过程实体或其他实体。该功能支持当某些实体发生变化或者需要修改时,评估实体影响范围。影响分析功能的分析范围、输出结果和分析精度要求与血缘分析功能的相关要求一致。
● 作业依赖分析,描述不同作业之间的前后依赖关系。作业一般是对元数据中心的实体(如源接口、库表、应用报表等)的处理过程;此功能与调度系统当中的作业配置信息及作业依赖信息密切相关。
● 作业运行状态图,提供类似地铁运行路线图和地铁进站时间预告牌的功能,将出数过程各个环节的静态执行顺序和动态运行信息,以直观的图形形式展现出来,方便开发和业务人员了解出数过程的进展情况。作业运行状态图需要使用到调度系统的作业配置信息及作业的执行情况。
● 数据地图分析,是以拓扑图的形式对系统的各类数据实体、数据处理过程元数据进行分层次的图形化展现,并通过不同层次的图形展现粒度控制,满足开发、运维或业务上不同应用场景的图形查询和辅助分析需要。
c)元数据质量检查
元数据质量检查的主要目标是提高元数据自身的数据质量,建立有效的元数据质量检查机制。及时发现、报告和处理元数据的数据质量问题对元数据应用至关重要,元数据质量检查包含但不限于以下功能。
● 一致性检查,主要是指检查元数据中心的元数据是否有与其他系统的元数据保持元数据信息的一致性;避免其他系统的元数据发生变更(删除,修改等)时,元数据中心中的信息发生滞后等不一致现象。
● 健全性检查,元数据库中除个别类型元数据外,各类元数据之间都有着千丝万缕的联系,并且相互间的关联关系需要保持一致,不应出现空链或错链情况。元数据关系是否健全直接影响到维护人员的问题判断和处理结果,直接影响着开发者对数据流向的分析和判断,因此,元数据管理模块必须在元数据的关联关系健全性方面作好保障检查工作。
● 数据链路完整性检查,指元数据是否描述了数据链路的所有环节。完整的数据链路从数据源接口开始,经过一系列数据转换处理,以应用层业务指标等结束。链路完整性相对来说是数据健全性检查的更高级版本。
● 属性检查,是对元数据库中实体属性详细信息方面的检查,包括元数据属性填充率检查、元数据名称重复性检查和元数据关键属性值的唯一性检查等。
● 描述结构合法性检查,一般包括以下功能:元数据对象的属性取值合法性,元数据对象之间的关系合法性等。
d)元数据其他功能
元数据其他功能是除基础功能,分析功能,质量检查功能外的常用功能,其包括但不限于以下功能。
● 元数据权限管理,负责元数据管理功能的权限分派、审批以及访问日志记录,实现对元数据管理模块的数据访问和功能的使用进行有效监控。
● 指标元数据管理,指元数据库中与指标相关的元数据的集合,类别包括指标实体元数据和维度元数据。
④ 功能要求
元数据是大数据平台的核心数据之一,数据总量并不大,在物理存储层面,可采用主流的关系数据库做存储。所有内容需要定期或不定期地进行全量备份。下面从元数据抽取、元数据展示及分析和元数据维护三个方面给出元数据管理工具的功能要求。
a)元数据抽取
● 支持对主流BI产品中的元数据进行自动抽取(包括主流ETL工具、数据仓库、数据集市、OLAP服务器和前端展现工具等)。
● 支持将抽取出的元数据转化为Excel文件(或XML, JSON等),便于将元数据导入元数据库,也便于使用接口存储元数据。
● 如果无法自动抽取元数据,该工具应当能够提供灵活定制的模板,人工录入相应的元数据,并能自动转换为Excel文件(或XML, JSON等)。
b)元数据展示分析
● 支持按一定的层次结构显示元数据库中的元数据,且支持各大主题元数据的浏览功能。
● 支持元数据检索功能。
● 支持元数据关联分析功能,通过分析实体的用途和关联,图形化地跟踪和分析任何实体的变化带来的各种影响。
c)元数据维护
● 支持元数据的实时/定期自动更新功能,当元数据在源数据系统中发生变化(增加、删除、修改)时,元数据维护工具能够实现元数据的实时/定期自动更新。
● 对于需要人工修改(增加、删除、修改)的元数据,元数据维护工具应提供易用的用户界面来方便管理员操作。操作人员可以预览与该元数据相关的元数据,由此确定元数据修改后产生的影响。
● 支持元数据修改的回滚功能。
● 保留元数据修改历史记录。
4.3.3 能力开放
1.组件目录
(1)报表工具
报表工具是立足于大数据基础上的数据分析产品,简单易用,是能够帮助用户快速完成创建报表、查看报表的BI工具应用。
报表工具的结构大致可以分为二层,分别是客户端(应用展示)、数据存储与计算层。
● 客户端(应用展示):用户可以直接面对的操作界面。
● 数据存储与计算层:BI工具的数据存储和计算由基础架构支撑。
报表工具应具备以下功能。
● 报表单元格功能:远程交互编辑,多人协同设计报表模板。
● 定制个性化报表设计器:可定制个性化报表设计器,设计器的菜单、工具栏,包括页面结构等均可以根据不同类型的用户进行个性化定制。
● 多样式数据呈现方式:支持HTML、PDF、Excel、Word、TXT、Flash等格式。另外,还可生成内置的模板文件。
● 异构数据源的表关联:数据库数据源,包括了Oracle, SQL Server, MySQL, DB2等主流的关系数据库,支持SQL取数据表或视图,亦支持存储过程。
(2)编辑器/设计器
编辑器提供Hive、Impala、Spark、Pig等组件的查询服务。用户可以直接在页面上方便地使用上述几个组件。
设计器提供了图形化的界面,作业时只需要拖动控件就可以完成。控件包括Hive脚本、Hive Server 2脚本、Pig脚本、Spark、Java程序、Sqoop、MapReduce作业、Shell、SSH、HDFS、电子邮件、DistCp等。
(3)调度工具
作业调度工具,它能够管理逻辑复杂的多个作业,按照指定的顺序将其协同运行起来。
工作流调度工具则通过界面对作业进行配置、定时、实时的操作。同时支持Java、Shell、MapReduce、Hive、Sqoop、Mail等多种任务的重复调度,实现集群架构,突破单集群的容量限制,可轻松扩展规模。
报表、数据仓库、服务开放等业务底层处理都需要通过运行作业的方式来获取,而要想管理作业之间的相互依赖、定时、串/并行、分支判断、作业资源分配等是件很复杂的事。这时就需要作业调度引擎的支持。
为所有租户提供统一的生产作业调度系统,则租户可自主管理作业的部署、作业优先级,以及生产监控运维。如果租户间有数据交换,那么彼此的作业可形成依赖。
作业调度应提供以下功能。
● 执行框架采用分布式架构,并发作业数可线性扩展。
● 支持多种调度周期:分钟、小时、日、周、月、年。
● 支持节点暂停、一次性运行等特殊状态控制。
● 可视化展示调度任务DAG图,方便用户对线上任务进行运维管理。
● 支持任务运行状态监控,支持任务重跑、Kill、暂停等操作。
● 支持线上冒烟测试。
● 支持补数据。
(4)OpenAPI
所谓的OpenAPI是数据服务提供的一种方式,数据经过数据清洗、数据建模、数据融合最终将数据封装成一系列提供单一功能的API开放出去,供第三方开发者使用。服务种类提供包括但不限于:标签获取,特征识别,用户社交模型,流量经营模型,征信模型,渠道视图分析模型,流量监控,套餐质量评估模型,用户行为轨迹查询,IP溯源查询,分布式爬虫框架,KV引擎,多维数据可视化框架,搜索引擎,自然语言处理框架,语音识别,模型知识库等。
其服务能力则包括:
● 提供服务调用能力,确保任何时刻生成环境中的服务都能被正常执行。
● 提供服务快速检索能力,随着服务数量日益剧增,使用者找到自己想要的服务难度逐渐增加。应提供可根据服务实现定义的大类、子类逐一筛选使用者需要的服务。
● 提供服务文档管理能力,系统自动为用户根据服务定义规范生成服务文档,支持用户自定义文档操作,支持文档简单编辑功能。
● 提供服务测试能力,提供界面,用户可对自己须使用的服务进行简单的请求测试。允许使用者自定义请求参数(Header/Request Body),模拟请求,检验请求参数及返回结果是否与预期相符。
● 提供定义完整的公共状态码说明文档,异常发生时错误信息比较简要,用户可通过说明文档了解详细问题说明,以便快速定位问题。
(5)数据地图
数据地图是基于远程虚拟桌面的一站式数据探查和分析组件,用于数据观察、特征识别、口径识别、数据建模、模型评测等研究性质的工作。
远程虚拟桌面技术,为数据安全提供了有力的保障。在数据探索环境中允许你查看授权范围内全量的数据表,可以直接获取数据血缘关系,指标维度溯源,业务关键词联想识别,并可以选择业务人员熟悉的工具,进行灵活自由的数据观察与处理分析,提升业务开发效率。
(6)数据接入
用户登录到大数据平台后,通过图形化的界面,可以把自己的数据导入到平台中使用。
数据接入实现推拉模式的各种主流方式,并可按需升级为统一数据接入平台,实现各类接口数据的无缝可视化接入,如关系型和非关系型数据、各种主流非结构化数据等。
(7)数据共享
为发挥大数据的价值,数据共享包括对内提供的基础数据共享,整合层数据共享以及对外通过标准API封装方式的共享,对内支撑数据的分析与挖掘等应用,对外为企业内各种实时的业务运营提供信息支撑,并对外部系统提供统一的数据调用接口,具有实时、动态的信息交互能力。
(8)服务脱敏
服务脱敏保护了数据敏感信息(如信用卡号)、个人识别信息(如社会安全号码)的隐私性,使用屏蔽字符(例如,‘x')替代字符,保证敏感信息不落地,以满足安全性的规范要求,以及由管理/审计机关所要求的隐私标准。它包括:
● 提供企业敏感词库维护能力,根据规则引擎实现数据脱敏能力。
● 提供自定义脱敏规则设置能力,支持正则表达式匹配。
● 提供用户级别、服务级别规则设置能力。
(9)数据挖掘
Apache Spark MLlib是Apache Spark体系中重要的模块。MLlib是Spark对常用的机器学习算法的实现库,同时包括相关的测试和数据生成器。MLlib目前支持常见的机器学习问题:分类,协同过滤,回归,聚类,降维,数据统计以及评价,同时也包括一个底层的梯度下降优化基础算法,以及最小二乘法等,并且加入了常用的统计、评价功能模块。MLlib优势有:
● 易用性,继承了Spark Core Engine的优势。
● 高性能,高质量的机器学习算法,比MapReduce快100倍。
● 易部署,支持多种部署模式和多种数据源。
● 丰富性,众多的机器学习算法和工具。
2.应用场景
能力开放包括数据开放、服务开放、应用开放三类。数据开放是指通过各种协议方式提供原始或脱敏后的数据,服务开放是指提供标准化的服务调用,应用开放是指提供定制化的数据应用或数据产品。当用户需要某一块业务支持时,可以通过能力开放平台进行申请。管理人员可以在平台上对已提供的服务进行管理。
针对不同应用场景,采用不同的能力开放方式提供不同的服务。对于外部系统需要定时批量数据的情形,可以通过批量同步方式或者文件访问方式进行数据开放。对于外部系统需要的实时数据接口,可以采用服务调用方式进行服务开放。对于最终用户,可以采用提供应用功能方式进行应用开放。
(1)企业各部门应用开发支撑场景
如图4-20所示为企业网络指标评估应用开发示意图。
图4-20 企业网络指标评估应用开发示意图
企业网络指标评估应用开发场景中,数据存储分为共享数据区和私有数据区。在共享数据区,提供只读权限,各省处理后生成的结果数据分别保存在各自的私有数据区。在私有数据区,提供开发环境,供网运开发人员进行数据探索、编写处理程序、程序测试和部署等工作。A省NOC用户可以通过自助报表查询工具对关键质量指标进行查询。
在数据探索环节,可以通过“数据地图”组件,访问数据管理中心的元数据定义。
在程序测试与部署环节,可以通过“任务调度”组件,将程序部署在离线计算框架,通过访问共享数据区,计算处理后的数据,保存在A省私有数据区(HDFS)。
在数据同步任务部署环节,通过“数据交换”组件,完成处理结果数据(HDFS)同步到移动网络关键质量指标(DSQL)。
在关键指标程序部署环节,完成网络关键质量指标评估程序部署。
A省NOC用户可通过自助报表查询浏览报表,自助报表通过访问移动网络关键质量指标(DSQL),根据用户需求生成相应报表。
(2)省公司基于大数据平台的实时营销场景
随着大数据相关能力的上线,各省针对性营销活动的时效性将得到大幅提升。如图4-21所示为实时营销业务场景关键支撑环节示意图。
图4-21 实时营销业务场景关键支撑环节示意图
① 采集与消息队列数据封装
基于CRM用户业务办理增量接口表,大数据平台采集程序利用单线程方式抽取增量数据,并用多线程方式按照固定格式封装成报文(报文由包头和包体组成,包头用于区分场景类别,包体用于存放特定信息)送入大数据平台Kafka队列中;若省级CRM已部署对外消息服务的USB,则大数据平台直接通过Kafka与之对接,实现目标用户信息采集。
② 规则匹配
Storm集群中的数据处理程序实时接收从Kafka队列中送过来的报文,多线程处理接收的每一条报文,完成基于业务场景的业务规划匹配(如:营销活动目标用户清单的筛选、过滤、短信内容匹配等),同时将筛选、过滤清单及原因数据写入大数据平台HBase表,供后续活动分析使用。其中,HBase用于保存各类结果数据,Redis用于存储过程数据。Storm集群完成业务规则匹配后,再次将目标用户数据封装成报文送入Kafka队列。它主要完成以下任务。
● 目标用户数据推送:数据推送程序实时接收从Kafka队列中送过来的报文,解析报文并将营销活动目标用户及短信内容推送到短信发送平台。
● 活动评估:大数据平台根据CRM用户业务办理信息和营销活动目标用户,完成活动最终效果评估。
(3)省公司用户漫游DPI数据分享场景
如图4-22所示,省公司用户漫游DPI数据分享场景包括以下环节。
图4-22 省公司用户漫游DPI数据分享场景示意图
注:实线表示DPI数据流,虚线表示消息流向
① 采集与数据筛选
基于日志流程系统汇集的全网DPI数据由大数据平台进行采集,通过线程并发方式采集原始数据,并经协议转换写入HDFS,同时生成文件到达通知,推入Kafka队列,用于原始数据分享及业务处理准备。
② 用户归属筛选
Storm集群中的数据处理程序消费文件通知,实时抽取数据文件,多线程处理接收的每一条记录,完成DPI格式规则校验,协议识别与用户归属识别的工作,同时筛选用户漫游属性记录,旁路分发到写队列,重组数据格式并写下发文件。
③ 数据推送
漫游分发文件推送到数据共享服务接口,用于省公司获取支撑本省应用。
4.3.4 性能指标
整个大数据平台基于开源组件构建,基础组件性能与配置相关建议如表4-5所示。
表4-5 基础组件性能和配置表