许颖:基于Hadoop的企业级大数据平台

推荐会员: 点金大数据 所属分类: 行业精选 发布时间: 2015-07-18 03:56

怎么看待企业级hadoop平台市场的需求?

首先我们先看一个案例。我们服务的一个客户-某运营商采用的以Hadoop平台为核心的大数据基础平台.该运营商目前已经拥有了海量详单(语音、短信、GPRS等)、信令、账单等数据,其中个大部分都为结构化数据仅有上部分来自于互联网的非结构化数据,并且随着企业和业务的发展,这些数据还在不断增长。

13

该平台以hadoop和spark技术为核心实现了按照统一的规范和标准,聚合各域(O域、B域、M域)IT系统中的运营数据的企业级数据中心,统一接入、管理、运算后,统一对外提供开放数据服务,并对数据的访问进行安全控制。

这样的技术架构虽然在互联网公司非常普通,但在传统企业里的采用却很少.传统企业做大数据项目或者商业智能项目传统上以构建数据仓库和上层应用或者在数据仓库基础上提供数据分析工具为主. 在上面这个案例我们可以看到Hadoop虽然起源于非结构化数据处理但在企业级应用中却更多用在结构化数据场景下,在这种场景下使用Hadoop的关键原因是其拥有良好的扩展性,随着业务和数据的增长可以通过快速扩张X86服务器达到计算能力和存储能力的线性增长,同时相比与过去的小型机+商业数据库+高端存储的方案可以极大的节省投资成本。传统企业采用Hadoop的步伐不如互联网企业那么快的原因,我们认为一个是Hadoop软件还处在发展过程中;另一个认为Hadoop软件的核心都是开源的,无论是cloudra,hortonworks还是MapR,而且这些厂家的平台软件的核心部分大都都是开源。如果直接购买这些国外厂家的企业版本,其按年按节点收服务费的模式还是比较昂贵,如果企业自己直接采用开源软件,出了问题找谁负责解决。毕竟传统企业缺少如大型互联网公司一样的技术实力,这两个因素一直是阻碍传统企业使用Hadoop的因素。

企业级hadoop市场发展分为4个阶段

1、导入期:客户关注平台是否可以稳定运行, 多用于某类特定场景(电信详单查询,上网日志分析,银行交易查询与分析)

2、平台开放期:客户关注是否可以将平台和数据开放,共享给多个应用提供商,业务用户访问和进行数据处理,其中 安全,资源调度,开放性是比较多考量的维度(类似于数据处理系统-Data Hub或者Data Lake的概念),我们认为目前企业级市场在这里

3、应用扩展期:客户关注随着应用的深入, 进一步提升数据的分析/数据处理能力(统一的SQL处理能力和机器学习能力的支持),进一步降低TCO,稳定性和大集群运维能力,大型互联网公司处于这一阶段

4、成熟期:Hadoop平台成为整个企业分析市场的核心,一统结构化数据处理和非结构化数据处理的领域,成为真正的企业级数据中心的关键基础设施

我们觉得Hadoop软件虽然是开源的,但是有全世界几千名开发人员在为Hadoop生态开源系统进行设计和开发,其发展速度是惊人的。这从Hadoop 这几年的发展历程中可以得到佐证。另一方面Hadoop的开源特性也保证了不同行业可以在开源的基础上进行更深次的定制。当然开源不等于免费,企业级的Hadoop产品方案确实要具备企业级的关键特性,同时企业要选择具备企业级平台能力及优化能力的产品和服务提供商。

开源软件的使用包括四个层次:

1、应用能力:可以应用开源软件开发各类应用并成功上线运行,并对应用业务逻辑负责

2、平台级优化/故障处理 :可以根据平台运行的应用特点对平台进行参数调优,并在平台层面解决遇到的各类故障

3、代码级优化/修复 :可以在代码级别修复遇到的故障及性能问题,并贡献社区

4、系统级重构 :可以完成开源软件的主要模块实现及系统级重构,并贡献社区

我们从2009开始从事Hadoop相关领域的开发和研究工作,平台团队现在处于从第三个阶段向第四个阶段迈进过程中,通过对社区源码的不断研究和修复,逐渐深入到核心组件。

二、企业级Hadoop平台的所需要具有的功能和技术特点究竟应该是什么?

企业级hadoop平台的几个核心需求:高性能的数据处理能力, 可扩展的资源管理能力,可靠的安全管理机制, 灵活的数据处理及作业调度能力,提供高度自动化系统运维的支持能力及开放的外部接口。

1、高性能的数据处理:目前企业市场上90%以上的数据处理依赖于SQL,通过标准化sql实现各类业务处理需要求,如果比较MPP数据库与Hadoop的Map Reduce机制,可以认为在技术理论上,在非海量数据的处理上,MPP数据库提供的索引,分布式处理的优化性能要Hadoop要更强。但Hadoop平台可以提供的可扩展性要比MPP类型的数据库更好。可以看到Hadoop集群上千台的实战规模。而MP类型的可以看到的大集群案例不多。在未来随着技术的融合趋势,我们一定可以看到Hadoop与MPP类型的数据技术的殊途同归。在企业市场上,我们希望看到一个增强型SQL解决方案可以One size fits all,另一方面长远看搜索也将会成为数据探索一种重要的工具和手段。

2、资源管理:多租户管理包括前台应用和底层资源;资源包括计算资源和存储资源,网络资源的租户管理。不同厂商可以基于同一个大数据平台进行应用开发和数据应用。

3、权限安全:通过安全策略保障整个大数据平台的安全性,防止非法用户以及非法主机的访问。通过权限管理保证不同用户对数据对象的读、写权限划分。

4、灵活地数据处理及调度模式:平台需要支持种脚本语言以及标准SQL或是类SQL语言,编写的数据处理任务,并且需要提供图形化的界面,使用户可以通过拖拽的方式完成数据处理流程的编排。

5、运维监控:大数据平台上包括hadoop、spark等多个计算框架以及众多的数据处理任务,平台建立从底层硬件到平台应用的全面监控体系,实现问题及时发现,快速定位保障系统安全稳定运行。

6、企业级平台还要提供开放性好的Restful或者web service接口给上层应用,同时易于外部系统的集成。

-首先来谈谈高性能的数据处理,高性能的数据处理目前可以看到的几个趋势:

1.基于内存的计算

2.更优化的并行处理技术

3.基于软硬件一体的优化技术

基于内存的计算正是目前Spark非常火的原因。上周田毅分享了Spark技术以及我们的一些实践。在这里我就不详细介绍Spark技术本身。Spark技术本身也在高速发展过程中,我们也一直在致力于与开源社区一道提高Spark的处理性能及SQL的支持度。我们为社区贡献了50+Patch,截至目前正式被社区接纳的有30+Patch,其中包括一些非常重要的特性,如Spark shuffle的优化及一些SQL的重要能力等等。

Shuffle机制是Hadoop里面非常核心的技术机制,在Map与Reduce之间提供数据的Merge,Group等主要的桥梁作用. 但是由于Hadoop中的shuffle需要经过Map端的一次磁盘写(可能会涉及到网络),Reduce端的一次磁盘读(可能也会涉及到网络),这种中间的“落地”过程是Hadoop整个数据处理机制中性能损耗非常大的部分。很多优化都是围绕Shuffle展开。在Spark SQL使用场景中, 缺省情况下把shuffle的结果写到内存,因此Map端与Reduce端通过内存交互而不经过磁盘I/O或者网络I/O, 因此极大地提高了性能。然而在海量数据处理情况下,存在数据无法全部装载到内存的情况。所以我们优化了Spark shuffle支持这种数据在内存装不下时,Spill到磁盘以及内存与磁盘数据的交换。

Spark SQL也是处在发展过程中。很多传统数据库支持的能力开始Spark SQL都不支持。如动态分区,像电信客户的详单,如果不支持动态分区,很多partition的方案很难实现。例如按时间partition.我们也是修改了Spark SQL支持了动态分区。除了动态分区,我们也向社区提交了代码支持Broadcast Outer Join, HashOuterJoin的性能优化,多个DDL语句支持,开窗函数支持等等。

还有两种优化技术我们也非常关注,一种是优化的并行处理;另一种是利用网络硬件提供更强的机制的优化。

Hadoop的HDFS, Map Reduce机制很好地支持了海量数据的分布式数据处理,尤其是HDFS,利用本地盘及Map Reduce的数据处理就近原则。其设计的核心思想是尽可能利用本地盘。然而硬件技术的发展也为软件技术提供另一种可能。网络I/O快还是磁盘I/O快。现在有不少研究认为网络I/O也很快。所以可以利用并行文件系统取代HDFS, 这样在HDFS write时,就不再是节点serial write,而是Parallel replication; HDFS read时也可以利用并行文件系统parallel read, 经测试表明基于并行文件系统的Map reduce比基于HDFS要快30%.当然还有利用MPI并行计算模式的。

基于软硬件一体的优化技术最早可以追溯到Teradata,后来的Nettezza及 Exadata. 都是利用特殊的硬件板卡,将磁盘I/O降低或者提高整体网络的I/O吞吐。在Hadoop方向上这方面的优化,也是基于这样的理解网络I/O性能会越来越好。现在有种趋势就是利用网络RDMA技术提升Hadoop shuffle性能。Hadoop shuffle涉及Reduce 端从Map 端的数据“Pull”的过程,涉及大量的网络I/O.

一般的网卡技术是把数据从用户态copy到系统态,数据再从系统态经由网络分层协议,到网卡,通过网卡再发送到对端,对端再由网卡的数据包拆包到应用层进入系统态,再从系统态copy到用户态。性能损耗比较大。RDMA (Remote Data Memory Access)就是数据直接从用户态到达网卡,省去了中间的数据拷贝,比以前的数据通信方式有很大的提高。当然这需要Hadoop要基于RDMA实现网络通信。

企业级的平台特性的第二点–可扩展的资源管理部分对于目前的企业应用非常关键。尤其是我们看到现在讲数据运营和数据交易。数据运营和交易通常出于安全可控的考虑,目前一般是由数据的拥有方同时提供计算环境给数据消费方和使用方。也就是整个运营环境是一个平台提供给多个数据使用方/消费方进行数据处理。设想如果没有资源的管理和合理的调度,就会出现多个使用方对数据资源,系统计算和存储资源的争抢,更不要说数据拥有方未来商业模式可以由对数据的使用,系统资源的使用的计费管理。

 

我们利用YARN做资源管理。通过YARN将JobTracker的两个主要功能(资源管理和作业调度/监控)分离。资源的表示可以细化到cpu和内存,比之前以剩余 slot 数目更合理。当然YARN目前只能对于cpu和内存进行管理。

我们除了YARN之外,还利用Linux提供的cgroup机制,对于cpu, 内存,网络input/output量对资源进行隔离和资源控制,同时也增加了对于硬盘资源的控制和管理。也扩展了YARN对于特定集群(入IP段)的特定调度管理功能。

Hadoop平台企业级需求的第三点就是安全能力。Hadoop本身默认集群内所有的节点都是可靠的,值得信赖的。用户与HDFS或者M/R进行交互时并不需要进行验证。导致存在恶意用户伪装成真正的用户或者服务器入侵到hadoop集群上,恶意的提交作业,修改JobTracker状态,篡改HDFS上的数据,伪装成NameNode 或者TaskTracker接受任务。此外Hadoop平台也缺少真正的RBACL,基于角色的授权。例如对HDFS,对HIVE表等。当大数据平台以多租户的形式开放给众多厂商或是不同部门使用时,保障平台的安全性就变得尤为重要。

集成kerbose,对于集群间服务的认证我们通过网络安全认证协议Kerbose实现,kerberos会对集群里的所有机器分发keytab,节点可以从KDC上获得与目标节点通信的密钥,进而被目标节点所认证,提供相应的服务,防止了被冒充的可能性。

其他安全增强的特性:当业务,开发,测试等不同人员登陆到统一的大数据平台后,需要对其进行更加细致的权限设置,以保证平台数据的安全性。例如开发人员可以众多数据模型进行加工处理操作,而测试人员只能拥有指定模型的读权限,以便编写脚本进行数据质量稽核。

我们利用Sentry,同时扩展Sentry支持HBASE,在认证接口方面不仅支持OpenLDAP,还支持restful接口和行业安全接口,如运营商的4A认证接口规范。此外为提高Hadoop的整体安全性。使用安全日志来监控集群中服务对数据的访问操作,用作审计报告和分析等,管理员可用此判断集群的健康、安全状态,更直观展示集群的活动和数据的访问。

日志范围包括访问操作HDFS、HBase、Hive及Hive元数据变化,记录了谁在什么时间对哪个数据做了什么操作,他的ip地址以及使用的服务等。

上面介绍的是基于Hadoop基础平台上的企业级的核心需求和功能点。企业级基于Hadoop的数据平台除了基础的数据处理能力,资源管理及安全审计能力外,还要支持上层面向业务,IT人员,运维人员的工具。如数据处理/调度工具;运维管理工具,外部集成接口。数据处理的模式,我们看到目前分为两种:1.传统ETL模式 2.数据的及用及得模式。

当组成一个ETL模式的数据流之后,就可以调用作业调度,执行这个数据流。这种批量模式的数据处理本质上就是一个DAG(有向无环图)的作业,可以使用DAG作为数据处理流程的驱动,优势是逻辑清晰,执行效率高;缺点是如果其中一个节点执行错误,错误定位和回退比较难。也可以使用较为传统的作业调度模式(可以支持按事件的或者按照时间。)

在传统的ETL模式的数据处理之外,最近几年又有一种比较新的数据处理和数据分析模式。传统的ETL模式是要把数据从源系统抽取,转换,加载到一个新的数据仓库中,然后在数据仓库中利用数据处理工具或者数据分析工具进行大数据分析。但是这种模式有一个成本比较高的问题,数据要经过源系统到数据仓库,然后数据仓库经过分层模型提供给业务开发或者分析人员使用,成本较高,灵活性有限。如果数据就是留在源系统,只有当分析人员要使用的时候再取过来怎么样? 这种场景相信对于大数据分析场会越来越多。大数据分析讲求多方数据融合,关联分析,对于某个企业来讲,他需要的数据可能只能从其他企业获得,其他企业的数据很难让你直接放到你的数据库里,可能只能是需要用的时候调用,同时数据拥有方对于数据有控制权。支持这样一种模式的平台,被称做DDP(Data Delivery Platform),一般的功能架构如下:

功能分为四层。物理数据层,逻辑数据定义和服务层,接口层,Paas数据处理层。

物理数据层是数据实际存放的地方,可以就是交易型生产系统的备份系统。这些数据可以是企业不同部门的,也可以是企业外部的。逻辑数据层是从企业的视角或者一个企业联盟的视角定义的逻辑数据。比方说客户数据在多个交易型的系统中都存在,而且很可能描述客户数据的元数据在不同的交易系统中不一样,在DDP数据处理模式中,在逻辑数据定义层定义一个标准客户元数据,可以对应多个物理数据层的数据实体。所以在逻辑数据层的核心功能有:逻辑数据定义,数据影射的管理,数据请求解析,数据实时获取服务以及数据拥有方对数据的授权管理,当然还需要有数据请求的CACHE管理,以利于提高数据存取性能。

PAAS数据处理服务层就是数据的实时计算分析的平台服务层。在这一层中看到的数据不是物理存放的数据,而是逻辑数据层定义的数据。在这一层上业务开发人员或者业务分析人员可以利用逻辑层数据进行数据处理,拼接和调度;PAAS数据处理层利用逻辑数据定义和服务层提供的接口(restful, JDBC)接口访问逻辑数据。这一层上可以同时访问历史数据和实时更新的数据。

从中可以看出,传统ETL模式数据整合是预先完成的,而在DDP模式中,数据整合是实时完成的,灵活性和及时性都很好。看看在政府大数据场景中的应用,数据是存在很多个委办局和部门中的,医疗的实时病例数据如何和人口数据关联。医疗数据在各个医院,人口数据在市一级的统计局,人口数据的不同维度在卫生局也有一份,这两个数据的口径可能还不太一样。怎么做?在DDP模式下可以定义一个人口的逻辑数据元数据横跨市一级统计局和卫生局,同时定义卫生局的医疗实时数据然后利用PAAS数据处理平台引入人口逻辑数据和实时医疗病例数据做归并,在逻辑数据定义和服务层上会将逻辑数据表达解析成实际的物理数据进行访问。这里面涉及到:

•逻辑数据与物理数据的映射

•数据请求解码,并将逻辑请求转换为物理请求

•大数据量的数据实时并行传输

•大数据量数据实时并行加载(内存)

•基于内存的大数据量数据实时计算

关键点是PAAS层上采用基于Spark的内存处理机制。利用Spark的可扩展RDD数据处理机制,Spark SQL统一数据处理引擎处理,Spark Streaming的流式数据处理机制构建这种实时地数据分析平台。

上面谈了数据处理,下面主要谈企业级平台对自动化的运维能力的支持。

首先是平台安装和部署。

过去企业通过小型机对数据集中存储和处理,现在通过hadoop集群运算和处理数据,集群规模往往是几十、数百甚至上千台,而且随着数据量和计算任务的增加,集群规模还在不断扩大,这也带来了部署实施工作的成倍增长。 所以安装部署要采用自动化模式,配置文件、软件包自动发布 ,远程控制直接部署 ,服务启动/停止 集中控制 ,HBASE Region设置 ,HDFS自动回收站设置 ,同时要根据硬件的cpu及内存预先设置各种参数。

大数据平台中往往运行着包括批处理、流处理、交互式查询等各类计算任务,对于运维人员来讲需要时刻关注着平台的运行以及资源的使用情况。平台通过集成Ganglia(信息采集)和Nagios(监控及告警)实现对集群从作业到底层硬件到应用系统的全流程监控,通过图形化的方式直观的展现系统实时运行情况例如集群各服务器是否正常运行,CPU、内存、硬盘的使用情况,还可以对历史指标信息进行查询分析。

平台通过类SQL的hive语句实现的数据处理逻辑时,对于复杂的HQL如果不进行优化很容易出现数据倾斜,对于 jobs数比较多的作业运行效率相对比较低。自动优化检测工具能极大简化应用开发和调优工作,部分优化检查原则如下:

1)Left join是否有数据倾斜

2)维度表是否使用mapjoin

3)mapjion缓存的记录数目是否不足

4)Reducer设置数据量是否过小

5)关联字段类型是否一致

6)单个job多次group by 优化参数

最后谈谈企业级基于Hadoop的大数据平台对外的接口:

对于开放的大数据平台除了会有不同角色不同部门的人员之间在平台上进行数据操作,也会和其他系统进行交互,平台通过一系列接口将大数据平台的存储资源和计算资源开放出来,方便和各类系统进行融合。接口采用rest方式,通过http进行调用,返回结果为JSON格式的数据包。

最后简单介绍一下亚信的橘云大数据平台产品及一些案例:

亚信的橘云大数据平台战略,起步于2009年。利用开源,增强开源,构建低成本,可扩展的企业级平台亚信橘云hadoop目标是在开源Hadoop的基础上为客户构建低成本的企业级分布式数据处理分析平台,使客户在享受海量数据存储与高效运算的同时,大幅降低投资成本。在Hadoop生态系统上,我们坚决贯彻技术开放与共享的原则,来源社区,贡献于社区。

OCDC橘云分布式计算平台,提供企业级大数据平台所需要的高性能,可扩展的资源管理,安全管理,灵活的数据处理及任务调度机制。包含两大部分。下层OCHadoop(开源)是基于Apache Hadoop版本,通过集成/优化/封装开源社区的代码,提供集数据批处理, 流处理及即席查询的分布式Hadoop平台。上层是建立在我们封装的OChadoop之上的大数据处理平台(自有知识产权)-通过图形化的界面提供便捷的灵活的数据处理(支持传统ETL模式及DDP模式),自动化运维工具,开放的接口等功能。 OCDC可以作为企业级大数据平台的基础部件,也可以和亚信其他产品线如DACP, ETL工具构成完整的数据中心解决方案。

下面与大家分享几个平台案例。

第一个是在某移动实施的流量经营项目。流量经营已是运营商战略转型的重点。为了支撑流量经营的发展,引入了DPI、互联网日志和位置信令等多种网络数据源。流量数据每日接入大小约8T、170亿条左右,是每日2.8亿条语音话单的近60倍,是每日5.8亿条gprs话单的29倍。传统小机+陈列计算和存储方式,无法适应海量数据计算和存储,甚至根本处理不了,IT建设运维和成本压力日趋凸显,急需寻求系统架构上去IOE的解决方案。

第二个是某移动的详单云化项目,目前运营商的数据仓库的60%-70%的数据处理是计费详单处理。而传统上详单的处理在商用数据仓库上进行。每年的软硬件扩容成本非常高。所以利用OCDC将原先在数据仓库上进行的详单处理移到Hadoop平台上。平台从接口机接入包括语言、短信、GPRS等在内的18类详单数据,每个5分钟获取一批数据文件,从数据仓库获取用户、账单等数据。在大数据平台对这些数据进行清洗、转换以及根据业务模型进行初步的汇总,汇总后的小数据量模型加载到仓库做进一步处理形成统一视图供应用系统访问。

第二个场景:在大数据平台上轻度汇总层:每日数据量为400-500G,凌晨2:00开始进行数据处理,在轻度汇总层进行关联分析,然后按天汇总,历时不到2个小时。 临时汇总层:月末按照分析模型进行数据计算,大约需要1-2个小时,同步到DB2仓库中,仅需几分钟。

第三个案例是某移动的详单查询系统, 以前的详单查询系统大多是在计费系统上基于oracle实现。一方面用户量和话单量增长非常快,另一方面终端用户利用互联网查询计费详单的业务量越来越大,Oracle已经支持不了。而基于HBASE的NOSQL的出现为解决这个问题带来了低成本的方案。

由大数据平台对批价后的详单数据进行处理包括统一编码、长度截取、格式转换等操作,处理后的数据加载入HBASE,应用系统通过我们封装的接口直接通过标准sql对海量数据进行高速查询。

每日话单数据量:700G以上;

实时话单:实时从计费系统中导入,从话单落地到可提供查询的时间是5分钟以内。

历史话单:系统上线前导入,大约每天600G左右,由于计费侧传输话单有瓶颈,导入速度大约是每分钟1-2G。每日历史话单导入时长约是4-5小时。

以今年年初为例,详单日查询量:94565次 , 94.85%请求响应时间小于1秒,4.87%在1-4秒,只有0.28%相应时间超过4秒,平均查询时长:223.51ms,每笔查询的平均条数:310.677条。整个平台通过38台刀片式服务器替代了原有系统的两个HP小型机,在节约成本的同时大幅提升数据查询效率。

我今天分享的内容就是这些,比较技术化,代表一般企业的技术演进思路

来源:http://www.ppvke.com/Blog/archives/13147

分享&收藏
关键词:

版权声明:本站原创和会员推荐转载文章,仅供学习交流使用,不会用于任何商业用途,转载本站文章请注明来源、原文链接和作者,否则产生的任何版权纠纷与本站无关,如果有文章侵犯到原作者的权益,请您与我们联系删除或者进行授权,联系邮箱:service@datagold.com.cn。

发表评论

电子邮件地址不会被公开。 必填项已用*标注