数据中心相关技术与应用39.ppt

1、数据中心相关技术与应用,2013-12-02,目录,MPP数据库在数据中心的应用,企业级数据中心定义,数据中心中的大数据,数据中心BI技术选型描述,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,传统的数据仓库的架构,数据源,抽取、转换、加载,业务数据集市,企业数据仓库,ETL,元数据,前端分析展现工具,查询工具、应用,新一代数据中心定义,企业数据中心是指建立在数据仓库与数据仓库之上的决策分析应用，应包括数据源、数据ETL、ODS数据库、数据仓库、数据集市、商务智能应用、数据管理等功能。 数据中心应该具备常见数据的处理与管理能力，具备对结构化、半结构化、非

2、结构化等数据的处理能力，同时支持RDB、MPP、NoSQL，同时具备数据的通用管理能力，以数据为中心进行平台建设。 数据中心数据平台在接口层要丰富又简单，可以提供各种应用所需接口，最大程度匹配已有接口，对应用改动需求力求最低。,一个合理的数据平台，不能等同于Hadoop或者其他某项单一技术建设；整体数据中心的建设，从数据采集层、存储层、应用层都有完整的解决方案，同时具备平台运维管理、接口管理、数据管理功能； 数据中心数据管理能力至少应包含：1.元数据管理，2.数据质量管理，3.数据安全管理，4.数据可视化管理，5.数据生命周期管理。 数据平台必须针对数据提供完整方案，同时兼顾应用接口、其他平台

3、接入，系统管理、系统调度等功能。 任何一种单一技术都难以适应数据中心数据采集、存储、处理和对外服务的需求，多种技术并存才是发展趋势。RDB、MPP、Hadoop,新一代数据中心功能视图,数据中心整体功能视图可以分为数据服务功能模块、平台管理功能模块，数据管理功能模块，共同数据中心的应用。,采集 处理层,数据抽取/加载/检查,ETL调度,数据交互、转换,数据映射,数据层,数据 存储,数据聚合服务,数据处理服务,数据查询服务,数据集市、OLAP,接口层,服务管理,资料类数据服务,指标类数据服务,配置类数据服务,清单累数据服务,日志类数据服务,OPEN API,数据管理功能,数据生命周期管理,数据可

4、视化管理,数据质量管理,采集层数据质量管理,数据质量规则、知识库,数据质量稽核指标运维,数据安全管理,4A认证,隐私信息保护,权限管控、审计追踪,元数据管理,元数据获取管理,元数据存储与模型管理,元数据分析、展现、服务,技术、业务元数据管理,DW-RDB,DW-MPP,分布式文件系统,非关系数据库,分布式计算,数据分发同步处理,数据服务功能,用户管理,权限管理,备份与恢复,日志管理,设备监控指标,资源池指标,数据库指标,分布式系统指标,指标汇总,存储管理,资源池管理,设备管理,作业调度管理,事件自动化,规则配置,执行引擎,性能预警,调度异常控制,北向接口管理,数据采集接口管理,数据共享配置,通

5、用接口配置,平台管理功能,应用展示层,企业数据中心,元数据获取,采集层数据质量定义、稽核,存储库模型定义,采集数据分发,目录,MPP数据库在数据中心的应用,企业级数据中心定义,数据中心中的大数据,数据中心BI技术选型描述,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,数据中心引入大数据的意义与原则,随着半结构化、非结构化数据、互联网数据等新型数据源的引入以及分析需求对分析深度和广度的增加，以移动运营商行业为例，越来越需要大数据。主要包括如下： 1、数据规模方面：GPRS流量话单的条数和数据量已经超过了语音详单，而位置信令、Gn信令、客服语音、互联网外部数

6、据等规模更大，且还处在不断增长的趋势。 2、数据类型方面：逐步从OLTP系统中获得的结构化数据，过渡到结构化数据和互联网网页、上网日志等非结构化数据和半结构化数据共存。 3、对数据的使用方面：不仅有批量的数据加工和前台界面的访问，临时统计、数据挖掘等访问需求也逐步增多。对历史明细数据的访问增多。对数据访问的及时性增强。 随着数据中心越来越具备大数据平台的特征，利用传统的单一数据仓库技术就难以满足高效低成本的需求，需要引入相应的大数据技术。 新技术的引入不能影响原有的使用感知，需要按照分阶段逐步引入的方式。可以参考如下的几个引入原则： 1、先增量后存量。现有的数据处理系统引入大数据处理技术，面临

7、着模型改造、流程改造等一系列的问题，可以首先在新上线应用引入大数据处理技术。 2、先边缘后核心。对于原有功能的迁移，可以先迁移非关键的应用。这些应用不涉及到关键生产任务，可以忍受数据处理延迟和故障修复时间较高等可能出现的风险。 3、先简单后复杂。数据处理逻辑较简单的应用也可以首先尝试引入大数据处理技术，降低实施的复杂度，积累运维经验。 通过在大数据处理技术的规划、实施及运维过程中积累经验及教训，不断提升和完善大数据技术的应用水平，逐步拓展大数据技术应用领域。,大数据在数据中心的应用场景,大数据技术可以应用在以下场景（包括但不限于）： 1、原数据仓库底层结构化数据处理（ETL或ELT）。底层结构

8、化数据处理计算任务重但复杂性不高，不涉及多表关联，适合引入大数据技术实现高效低成本。例如：对运营商的清单（语音详单、GPRS清单、WLAN清单等）的清洗、转换、汇总等。 2、半结构和非结构数据处理与分析。例如对上网日志、网络信令、客服语音等数据的处理和分析，这些数据难以利用传统数据仓库技术进行处理和分析。 3、数据集市。地数据集市应用较为独立，且对可靠性的要求并不是十分严格，适合作为引入大数据技术形成资源池，以移动运营商为例，可实现各地市、各部门数据集市的云化、池化和虚拟化，最终实现资源动态调配，达到高效低成本。 4、数据仓库数据分级存储。对低价值的细节数据以及长周期的历史数据（冷数据）访问频

9、率较低，也能容忍相对较长的响应时间，可以存储在成本更低的平台上。 5、数据挖掘。某些数据挖掘设计长周期的数据，计算时间很长（数天），占用很多数据仓库资源。还有一些数据挖掘算法超出了关系代数计算范畴，需要抽取数据到独立的计算平台（例如SAS统计分析系统）中进行计算。这些数据挖掘任务可以迁移到大数据平台之上进行计算。例如交往圈的计算，因其仅涉及单一数据，但数据量非常大，且需要多次迭代计算。 6、对外查询。数据中心不仅仅是数据处理，也需要将数据处理的结果对外提供查询，而这些查询一部分是海量的OLAP性质的查询，另外还有一部分OLTP性质的查询，即数量众多但每次查询量较少的。比如数据中心前端库、与生产

10、系统互动的数据库以及提供流量详单查询的数据库。这些查询任务不能很好地运行在OLAP类数据库之上，可以迁移到大数据平台上。 针对这些应用场景，可以看到，主要需要引入的是Hadoop和MPP技术，然后逐步考虑NoSQL、流计算和内存计算等技术的引入。,Hadoop技术与MPP技术的比较,Hadoop 在处理非结构数据和半结构数据上具备优势，尤其适合海量数据批处理等应用需求。当然随着Hadoop技术的成熟，基于Hadoop的即席查询技术也逐渐崭露头角。比如仿照Dremel的开源项目Apache Drill以及Cloudera Impala。 MPP适合替代现有关系数据结构下的大数据处理，具有较高的效

11、率，但其在大规模集群（超过100个节点）下的可用性还有待试点证实。 MPP数据库场景下经常需要扫描大量的数据，所以对磁盘存储系统的I/O性能要求非常高，在测试和日常运行中，I/O多大情况下是瓶颈，这点与Hadoop平台可以明显区分开来。,目录,MPP数据库在数据中心的应用,企业级数据中心定义,数据中心中的大数据,数据中心BI技术规划选型,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,MPP数据库在数据中心的应用场景,MPP数据库适合结构化数据的深度分析、复杂查询以及多变的自助分析类应用。它提供了统一的标准访问接口（SQL），而无需像Hadoop一样需要定

12、制开发。MPP数据库一般构建在X86平台上，并使用本地盘而不用阵列，而且产品众多，因为可以降低拥有成本。 MPP数据库产品在数据中心中可以用于以下场景（包括但不限于）： 数据集市： 数据集市定位于以企业数据仓库数据为基础，结合其他相关数据，支撑特定业务场景或者业务部门需求的IT平台。 目前运营商数据中心中已经存在地市数据集市和部门数据集市。随着新业务平台分析需求的出现、不同分析特征的需求的出现，还有一些分析需求可以通过数据集市的方式进行承载，比如深度分析（Advanced Analysis）和自助分析（Self-Service Analysis）。 数据分级存储（历史库或者明细库）： 数据中心

13、中数据存储周期分为在线数据、近线数据、归档数据。目前在线数据及近线数据存放在数据仓库，归档数据使用磁带库存放。带来的问题是在线数据中不常访问的数据占据数据仓库宝贵的资源，针对归档数据的数据分析需求增加，而数据从磁带库恢复的时间无法满足需求。 数据中心数据仓库的数据在完成近期数据支撑任务后，转移到历史库中进行长周期存储，支持后续数据访问和长周期数据分析需求，同时可作为核心数据仓库的备份，提升整体架构及数据的高可用性。MPP架构基于x86平台构建，可高效低成本的实现历史库的建设需求。 ETL： 通过将数据的关联汇总卸载到MPP数据库上，可降低数据仓库的负载，提高数据关联汇总的性能，同时可以满足后续

14、数据量增长情况下的平滑扩容的需求。 这部分的计算任务可以定位于数据仓库外的复杂数据加工、数据汇总任务，其源数据可以来自业务系统，也可以来自ETL（专业ETL工具或者Hadoop）清洗、转换后的话单或者经过ETL轻度汇总过的数据。其结果数据导入到基础数据仓库中供上层应用访问。,MPP平台选型建议,当前构建在X86平台上的新型MPP数据库产品众多，Garnter每年会发布一版数据仓库魔力象限可以供参考。在大陆地区可以获得技术支持的MPP产品及其特性如下（包括但不限于）：,不同架构的数据仓库各有优缺点。比如带主控节点（Master）的数据库会存在单点故障，但各节点分工明确；无主控节点的数据库不存在单

15、点故障，但可能某各节点承担的任务不平均。行存储装载数据快、压缩率低、查询速度稍慢；列存储装载数据满、压缩率高、查询速度快，但部分产品的列存储方式无法支持更新、删除数据。 硬件平台的选型参考各厂家的指导文档。,MPP数据分布规划,得益于ShareNothing的架构，MPP数据库的所有表都是分布式存储的，所以在创建表时都需要指定分布键，分布键可以是单一字段，也可以是复合字段，然后通过Hash方式去分布。合理的分布键设计可以使得大部分的表关联操作在一个节点内完成，不需要跨节点进行数据交互，这是MPP数据库产品（按行Hash分布）与Hadoop（选择按照块随机分布）的根本差别。,注意： 在某个节点发

16、生故障无法为整个MPP数据库集群提供服务的情况下，数据库会自动切换到副本机制，利用副本所在的服务器来提供服务。但是副本所在的服务器本身就要承担自己正常的工作任务，这样一来相当于负荷加重了一倍。所以故障情况下虽然整个数据库集群可用，但是理论上的性能将下降到原来的一半，而不是按照退服节点比例的性能下降。,目录,MPP数据库在数据中心的应用,企业级数据中心定义,数据中心中的大数据,数据中心BI技术选型描述,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,Hadoop在数据中心的应用场景分析,Hadoop在数据中心的应用场景-ETL,Hadoop平台负责从接口机采

17、集数据入HDFS分布式文件系统，并进行清洗、关联、转换、汇总、逻辑增强等，实现原始数据、明细数据和汇总数据的处理加工工作。具体实现上可以采用Hive或Pig用脚本来实现数据处理，也可以编写Java或其他语言的程序（用到Hadoop流的功能），直接利用MapReduce框架来进行处理。,Hadoop在数据中心的应用场景-详单查询,清单云平台采用基于大数据的Hadoop云架构，以PC服务器搭建大规模存储集群。 在数据处理方面：引入数据抽取、转换、加载工具ETL，在入库前对详单中的各个字段含义进行翻译，服务接口不再进行翻译，提升查询效率； 在分布式存储方面：引入基于x86服务器的分布式存储技术，主要

18、由Hbase、Hive、数据库集成等功能组成，在提高系统的扩展性和弹性的同时，可以方便、快速地为应用增加或减少资源。,某运营商省份的应用效果： 应用前数据导入性能指标1M/秒，应用后达到45M/秒，性能提升44倍。 应用前数据加载性能指标3万条/秒，应用后达到17万条/秒，性能提升4.67倍。 应用前用户查询性能指标30个并发查询/秒，应用后达到100个并发查询/秒，性能提升233%。 应用前并发查询性能指标35.81毫秒/笔，应用后达到8.09毫秒/笔，性能提升77.4%。,Hadoop在数据中心的应用场景-机器学习与数据挖掘、冷数据存储,Hadoop可以承载数据量较大、需要多次迭代关联、涉

19、及数据对象较为单一的数据挖掘计算。Hadoop上开源数据挖掘分析专题工具有mahout和R，也可通过MR接口编程实现所需的挖掘算法，可以实现以下数据挖掘： 互联网内容分析专题：客户上网行为分析，关键词排序，爬虫，非结构化数据识别 WLAN运营分析专题：WLAN终端分析，WLAN位置分析，WLAN与GPRS关联分析，WLAN用户群分析 用户交友圈分析专题：用户个人语音交友圈分析，用户个人短信交友圈分析，交友圈特征分析 Hadoop可以承载历史性、访问频率较低的数据，存放在Hadoop上仍然能够实现通过Hive或者其他软件，实现类SQL或者其他API的数据访问。而在配置策略时，为了节省空间，可选择

20、进行压缩、纠删码（HDFS Raid）或者降低副本个数，例如2。冷数据例如： 超过一定周期的（12个月以上）的详单信息。 上网日志信息和原始网页信息。 其他价值低、优先级低、数据量大的数据。,Hadoop选型建议,总体来看，目前Apache Hadoop开源社区主要在Hadoop 1.0和2.0 两个版本上分别进行持续更新优化。而Cloudera公司的Hadoop版本CDH3和CDH4也分别基于Hadoop 1.0和2.0版本进行封装。下图开源社区发布的各个版本以及与Cloudera发布的CDH软件包的对应关系如下图所示，以及对应CDH4.3版本的描述：,Hadoop服务器配置建议,Hadoo

21、p被设计运行在大规模通用X86硬件平台之上，使用本地存储（DAS）来实现Scale Out。所以其对硬件的要求较低，一般的PC服务器也可以运行，只要满足发行版所要求的操作系统和JDK需求即可。 但是在实际使用中需要根据Hadoop的应用环境来合理配置硬件，充分发挥每个部件的效率。在前期试点中，发现如果执行MapReduce，特别是在压缩文件上执行，其对CPU的消耗较高，CPU成为了瓶颈；而在运行Hbase的时候，更多的内存会缓存更多的数据，提高查询吞吐率并缩短响应时间。所以建议这两种情况下，可以考虑按照如右表格配比来配置硬件：,Hbase配置建议,Rowkey设计： HBase表的rowkey

22、设计，一般是将关系数据库中的候选key拼接形成。但是要注意热点问题，比如rowkey开始的几位是时间排序，那么在插入的时候，最近几天的数据很可能是热点数据，这样所有的查询可能都指向了一个region server导致了HBase的性能瓶颈。尽量避免使用单调递增的rowkey，因为在添加数据的时候，所有的新数据都添加到最后一个region，前面的region没有或者很少有请求，也是热点问题。 热点问题的处理方式一般是加盐，即在rowkey前面添加hash数，来对数据进行hash划分。 列簇设计： HBase表的Column Family最好少于4，一般少于3，对于一般数据放入一个列簇中即可。对于

23、一些强关联，频繁访问的数据可以放一列，这样在取数据时，热点访问只用取这一列数据，可以节省IO。多个列簇有各自memstore，memstore 开销大，而且flush一个列簇，其他的类簇也会flush，会造成不必要的开销。 Region划分： HBase在导入大量数据前最好预先划分region，这样可以加快导入效率。同时也要避免使用HBase自动划分region，在一种情况下，HBase面临大量写入或者scan请求，同时它的region中的数据又达到了阀值，那么它会启动自动划分region，有可能导致region划分风暴，大量的请求会使region server和name node的压力过大而

24、导致region dead或者name node dead。 TTL设计： TTL（time to live），它一般可以用来控制数据的生存时间。一些数据比如客户几年以前的数据，几年以后已经不关心这些数据，可以使用TTL删除。如果数据没有这些要求，可以不使用。,目录,MPP数据库在数据中心的应用,企业级数据中心定义,数据中心中的大数据,数据中心BI技术选型描述,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,数据中心系统集成建议,在引入Hadoop和MPP数据库后，数据中心建设将会在现有传统数据仓库平台与新技术之间形成混搭。经典数据仓库中的One Sing

25、le View of Truth将难以维持。主要会面临如下的问题： 数据互通：数据需要跨Hadoop和多个数据库进行交互，如何实现高效的数据同步或数据调用？ 透明访问：是否有必要对上层应用屏蔽底层不同数据平台的细节，提供统一的数据访问方式？ 统一管理：如何进行多套数据平台的元数据、数据质量管理，如何实现统一的调度和运维监控？ 数据互通机制是多个数据库与Hadoop之间的桥梁。通过数据互通，我们可以将数据快速从一个平台迁移到另外一个平台或从一个平台方便地访问另外一个平台中的数据。 数据互通机制的主要难点是要保障数据在两个平台间流转时的高效性和可靠性。,数据中心系统互通的建议,实现数据互通机制有2

26、种方法：数据同步、数据调用 数据同步： 数据同步的主要是实现数据库与Hadoop之间双向数据复制功能，数据同步的目的包括这些的场景：不同系统上的数据需要进行关联分析、数据生命周期管理要求进行数据归档或备份、ETL分节点部署需要同步数据等。 可以采取如下数据同步方案： 在Hadoop端发起的双向数据同步 在数据库端发起的双向数据同步 在第三方发起的双向数据同步 数据调用： 数据调用指的是：不移动数据，通过接口调用实现对另外一个平台上数据的访问，被调用平台承担运算任务。数据调用方法根据调用方的不同，又分为“从数据库侧调用Hadoop数据”及“从Hadoop侧调用数据库数据”两种情况。 数据调用方法

27、适用的场景原则：低频度（如：每月/季度/年一次）或临时（如：临时访问5次以下）需要使用其他平台中存储的数据。,数据中心互通的技术实现,连接器方式 通过设计专用的软件或硬件连接器模块，实现数据库与Hadoop之间高速的数据传输，其一般具备以下特点： 双向连接器 并行连接数据库节点到的Hadoop数据节点 支持UTF-8编码和常见的数据类型 通过动态工作负载管理的资源控制 融合系统中的角色/用户提供认证 为数据库域提供的数据节点，主要实现以下按照源表进行任务分工，可以为表间并行以及表内并行 建立分区、索引及装载，根据分区原则以及索引等策略，装载节点将数据直接发送给相应的MPP数据库节点上 装载节点

28、处理过程中数据不落地 装载节点可以是MPP数据库中的部分节点也可以独立设置 通过连接器的方式，可以实现数据库与Hadoop系统之间的高速和可靠的数据互通，非常适合数据同步的计算场景。 外部表方式： 数据库可以通过外部表的方式，直接访问存储在HDFS上的文件。在使用外部表时，数据库可以像访问内部数据一样，将文件当作表insert到数据库内其他表中，或将HDFS上的文件和数据库内的表进行关联操作。同时也可以将RDBMS内的数据，通过外部表的形式，写入到HDFS上去。例如如下操作: Select count(*) from HDFS_data h, RDBMS_data g where h.key

29、= g.key; Insert into HDFS_data select * from RDBMS_data;,数据中心透明访问,HADOOP+MPP的混搭架构在解决大数据处理问题的同时也加大了上层应用的数据访问复杂度。主要问题体现在： 多种数据实例：数据可能分布在关系型数据库、Hadoop分布式计算集群以及HBase库中。 多种访问接口：不同类型的数据实例的技术实现方式差异大，如关系型数据提供了标准SQL，Hadoop、HBase提供开放API或Hive方式访问，这同样对上层访问增加了难度。 跨数据实例的数据计算：不同类型的数据实例的底层数据存储结构不同，如关系型数据库存储结构化数据，而H

30、adoop计算集群多存储半结构化数据，如果需要涉及到两种类型数据实例中的数据关联（join）计算，目前还难以直接实现，需要做一系列数据互通调度，然后在单实例上完成关联计算，整个过程复杂度高、工作量大。 针对目前出现的这些问题，可以考虑构建数据透明访问能力。也就是提供统一的数据访问接口，对上层屏蔽底层数据处理实现细节，提升上层应用的开发效率。主要需要解决两个方面的问题： 1、通过统一的语言或服务接口访问到不同的数据库实例，包括数据查询、数据处理操作等。 2、针对跨数据实例的数据互通、关联操作等，可以通过统一的的语言、服务接口或管理工具等技术来实现。,目录,MPP数据库在数据中心的应用,企业级数据

31、中心定义,数据中心中的大数据,数据中心BI技术选型描述,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,BI集成工具选型问题,这些众多的BI项目从规模和对BI系统支撑的完善程度上来说，大体可以分为Framework、Stand-alone Tools和BI Suite三种类型。 Framework：开源框架，这是在商业BI系统中所没有的。我们可以使用它们来构建自己的BI工具，或者增强和扩展我们的BI解决方案。 Stand-alone Tools：独立的BI工具，这是开源项目中数量最多的一类。很多工具只侧重BI系统中的某个环节和方面，如ETL、Report、

32、OLAP和Database等等。 BI Suite：在统一的架构下提供了多种BI系统的特性的工具集合。就目前的情况看，不管是商业软件还是开源软件，还没有任何一个套件提供了完整的端到端的BI解决方案。这些开源的BI Suit是通过连接多个其他的组件和工具的方式形成套件的，由于BI系统涉及到的工具是非常多的，所以整合一套完整的BI解决方案是很困难的。 开源BI的重要项目： Pentaho、spagoBi是两个比较大的框架，集成了相当多的开源项目，JfreeReport、Mondrian、Kettle、Weka基本都使用。适合大型复杂项目的开发。 Pentaho：是一个以工作流为核心的、强调面向解决

33、方案而非工具组件的BI套件，整合了多个开源项目，目标是和商业BI相抗衡。 SpagoBI 集成了OLAP ServerMondrain和OLAP展示JProvit，能够通过OpenLaszlo产生实时报表。SpagoBI使用java开发，不依赖于具体的操作系统，有很强的扩展能力。,开源BI工具之Spago BI,SpagoBI 集成了Mondrain和JProvit，能够通过OpenLaszlo产生实时报表。SpagoBI使用java开发，不依赖于具体的操作系统，有很强的扩展能力。它主要包括： 1、 报表工具：JasperReports /Eclipse BIRT/ iReport 2、 OL

34、AP Server：Mondrian 3、 OLAP展示：JPivot 4、 数据挖掘组件：Weka 5、 Map引擎：Geo 6、 ETL：BIE 7、 搜索引擎：Lucene 8、 Dashboard：OpenLaszlo 9、 Portal Server：JBoss/ Tomcat/ JOnAS,Spago BI展现层也使用了AJAX特性，另外它在DashBoard也使用了openlaszlo，（一个用Java code 生成Flash的框架，主页是/。新版的4.0好像也要支持生成DHTML) 所以spagoBI的DashBoard界面很友

35、好。,开源BI工具之Pentaho,Pentaho是一个以工作流为核心的、强调面向解决方案而非工具组件的BI套件，整合了多个开源项目，目标是和商业BI相抗衡。它包括如下开源组件： 1、 工作流引擎：Shark and JaWE 2、 数据库：Firebird RDBMS 3、 集成管理和开发环境：Eclipse 4、 报表工具：Eclipse BIRT 5、 ETL工具：Enhydra/Kettle 6、 OLAP Server：Mondrian 7、 OLAP展示：JPivot 8、 数据挖掘组件：Weka 9、 应用服务器和Portal服务器：JBoss 10、 单点登陆服务及LDap认证

36、：JOSSO 11、 自定义脚本支持：Mozilla Rhino Javascript脚本处理器,Pentaho是一个很完善的BI解决方案。Pentaho偏向于与业务流程相结合的BI解决方案，侧重于大中型企业应用。,Pentaho与Spago对比,From张轶总：目前看Pentaho基本符合我们对数据平台功能的要求。其中，Pentaho Data Intergration （PDI）可以用作我们的数据平台集成，并且其支持与Hadoop及周边软件集成。同时也支持绝大多数NoSQL。还有，对于Map/Reduce job也有很好支持。Pentaho Business Analytics （PBA）

37、是一个数据分析、展示平台，可以生成报表，做数据可视化，具有数据挖掘功能。Pentaho集成了很多第三方开源项目，这种集成是无缝的。Pentaho也有很好的Metadata管理功能。总之，它是一个很好的BI系统框架且完全开源。相信通过Pentaho，我们可以搭出一个PoC演示环境。后续我们还会做更进一步的研究。,目录,MPP数据库在数据中心的应用,企业级数据中心定义,数据中心中的大数据,数据中心BI技术选型描述,Hadoop在数据中心的应用,数据中心ESB技术研究,大数据技术与传统数据中心的集成,企业应用集成EAI与ESB,企业应用集成（EAI）是集成应用之间数据和服务的一种应用技术。它解决无限

38、的问题，解决方案也几乎没有穷尽。目前常见的四种集成风格： 1.文件传输：两个系统生成文件，文件的有效负载就是由另一个系统处理的消息。该类风格的例子之一是针对文件轮询目录或FTP目录，并处理该文件。 2.共享数据库：两个系统查询同一个数据库以获取要传递的数据。一个例子是你部署了两个EAR应用，它们的实体类（JPA、Hibernate等）共用同一个表。 3.远程过程调用：两个系统都暴露另一个能调用的服务。该类例子有EJB服务，或SOAP和REST服务。 4.消息：两个系统连接到一个公用的消息系统，互相交换数据，并利用消息调用行为。该风格的例子就是众所周知的中心辐射式的（hub-and-spoke）

39、JMS架构。 这些风格迥然不同，因为没有一种解决办法能在任何情况下都良好运转。这导致整个中间件领域都在基于这些模式寻求可用的解决办法，通常被称为企业服务总线（ESB）。ESB是最终的中间人：它知道如何使用各种语言在各种协议上调解传递的消息。 ESB定义与主要功能： ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。 Invocation同步和异步的传输协议的支持、服务的定位和绑定 Routing静态和动态路由、基于内容路由、基于策略路由、基于规则路由

40、 Mediation适配、协议转换、服务映射 Messaging 消息处理、转换、增强 Process choreography负责业务逻辑的实现 Service orchestration服务编排 Complex event processing事件解释、事件关联、模式适配 Other quality of service安全、可靠传输、事务 Management监视、audit、日志、计量、管理、BAM,ESB实施探讨,不推荐的实施： 1、用ESB实现大数据传输：ESB并不适合完成该项功能，虽然它可以实现这一功能，但这并非最佳实践。ESB作为企业级的服务联通、管理平台，需要穿透ESB的服务

41、应该是企业内重用可能最大、价值最大的那些服务，应用程序对这类服务的访问应该非常频繁，因此同一时刻需要ESB支撑的业务可能非常繁重。所以，ESB产品的设计初衷是实现一个无状态、高吞吐的服务总线，为企业内重要的业务服务提供透明、标准、开放的接入能力。这种实践的原因是过分放大了ESB对数据的传输能力，如果在ESB传输巨大的信息，可能会导致ESB整体性能的下降，损害其他重要服务的QoS。 2、挟ESB以令外围应用：ESB的架构师在ESB上设计一套标准的数据接口（通用的XML格式），规定使用统一的协议（如Web Service/HTTP）。所有的ESB服务消费者和接入ESB的服务必须符合该标准。其目的是

42、为了简化ESB上的开发工作。这就是一种“挟天子以令诸侯”的做法。ESB针对的是一个个功能各异的整合逻辑，服务之间的整合逻辑也是迥异的。所以，一劳永逸的ESB之上的架构是不存在的。 3、用ESB实现业务流程：有些架构师看到ESB支持服务组合（Service Composition）模式，进而认为可用该模式来实现业务流程。因此，ESB产品就演变成了BPM产品。让ESB实现BPM，特别是长运行的流程时，虽然在技术上可以实现，但是这违背了ESB产品的设计理念，会大大影响其ESB运行时的整体运行效率。 推荐的实施： 1、服务要管理起来：ESB的一个重要功能是将企业内/合作伙伴处的服务以开放的、标准的服务

43、方式暴露出来，使得服务消费者能够便利地查找到服务，以促进服务的重用、管理。 2、复杂的动态路由规则应服务化：路由是ESB中非常重要的仲裁逻辑之一。路由场景是非常普遍的。譬如，针对不同的客户提供不同QoS的场景，执行时需根据客户的类型将其路由到不同执行能力的服务提供者；再比如当响应消息到达ESB时，总是需要将该响应消息送回最初的服务请求者处。对于复杂的路由，推荐将路由规则的逻辑外部化，并将它服务化。,开源ESB之ServiceMix（SM）,产品简介：它是JBI规范的一种实现；包含很熟JBI组件。这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。同时也实现了EIP，规则和调度。SM也整合了其他的开源项目，比如Apache、ActiveMQ CXF,Apahe Camel,Apache ODE以及Apache Geronimo。 优点： 1、无缝集成CXF,ActiveMQ,Camel和ODE，因为ServiceMix,ActiveMQ,CXF,Camel都是FUSE的开源产品 2、JBI的优势，组件BC,SE可以在任何JBI容器中直接运行，复用性强 3、基于OSGi，具备OSGi的优势：模块化，热部署，易扩展 缺点： 1、基于JBI但JBI规范太复杂，已被主流中间件厂商抛弃,没有受到业界的青睐，前途未卜。 2、架构复杂，由于JBI的复杂性所致，其架构并非