数据中心相关技术与应用(大数据相关)39

1、数据中心相关技术与应用2013-12-02目录MPPMPP数据库在数据中心的应用数据库在数据中心的应用企业级数据中心定义企业级数据中心定义数据中心中的大数据数据中心中的大数据数据中心数据中心BIBI技术选型描述技术选型描述HadoopHadoop在数据中心的应用在数据中心的应用数据中心数据中心ESBESB技术研究技术研究大数据技术与传统数据中心的集成大数据技术与传统数据中心的集成传统的数据仓库的架构数据源抽取、转换、加载业务数据集市企业数据仓库ETL元数据前端分析展现工具查询工具、应用新一代数据中心定义p 企业数据中心是指建立在数据仓库与数据仓库之上的决策分析应用，应包括数据源、数据ETL、O

2、DS数据库、数据仓库、数据集市、商务智能应用、数据管理等功能。p 数据中心应该具备常见数据的处理与管理能力，具备对结构化、半结构化、非结构化等数据的处理能力，同时支持RDB、MPP、NoSQL，同时具备数据的通用管理能力，以数据为中心进行平台建设。p 数据中心数据平台在接口层要丰富又简单，可以提供各种应用所需接口，最大程度匹配已有接口，对应用对应用改动需求力求最低。改动需求力求最低。p 一个合理的数据平台，不能等同于Hadoop或者其他某项单一技术建设；整体数据中心的建设，从数据采集层、存储层、应用层都有完整的解决方案，同时具备平台运维管理、接口管理、数据管理功能；p 数据中心数据管理能力至少

3、应包含：1.元数据管理，2.数据质量管理，3.数据安全管理，4.数据可视化管理，5.数据生命周期管理。p 数据平台必须针对数据提供完整方案，同时兼顾应用接口、其他平台接入，系统管理、系统调度等功能。p 任何一种单一技术都难以适应数据中心数据采集、存储、处理和对外服务的需求，多种技术并存才多种技术并存才是发展是发展趋势趋势。RDB、MPP、Hadoop采集处理层数据抽取/加载/检查ETL调度数据交互、转换数据映射数据层数据存储数据聚合服务数据处理服务数据查询服务事件通知服务信息子层KPI报表统一视图知识库接口层服务管理资料类数据服务指标类数据服务配置类数据服务清单累数据服务日志类数据服务OPEN

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

5、A+ABIS应用无线网优综合监控系统信令监测系统日志上层应用其他应用新一代数据中心功能视图数据中心整体功能视图可以分为数据服务功能模块、平台管理功能模块，数据管理功能模块，共同数据中心的应用。采集处理层数据抽取/加载/检查ETL调度数据交互、转换数据映射数据层数据存储数据聚合服务数据处理服务数据查询服务数据集市、OLAP接口层服务管理资料类数据服务指标类数据服务配置类数据服务清单累数据服务日志类数据服务OPEN API数据管理功能数据生命周期管理数据可视化管理数据质量管理采集层数据质量管理数据质量规则、知识库数据质量稽核指标运维数据安全管理4A认证隐私信息保护权限管控、审计追踪元数据管理元数据

6、获取管理元数据存储与模型管理元数据分析、展现、服务技术、业务元数据管理DW-RDBDW-MPP分布式文件系统非关系数据库分布式计算数据分发同步处理数据服务功能用户管理权限管理备份与恢复日志管理设备监控指标资源池指标数据库指标分布式系统指标指标汇总存储管理资源池管理设备管理作业调度管理事件自动化规则配置执行引擎性能预警调度异常控制北向接口管理数据采集接口管理数据共享配置通用接口配置平台管理功能应用展示层企业数据中心元数据获取采集层数据质量定义、稽核存储库模型定义采集数据分发目录MPPMPP数据库在数据中心的应用数据库在数据中心的应用企业级数据中心定义企业级数据中心定义数据中心中的大数据数据中心中

7、的大数据数据中心数据中心BIBI技术选型描述技术选型描述HadoopHadoop在数据中心的应用在数据中心的应用数据中心数据中心ESBESB技术研究技术研究大数据技术与传统数据中心的集成大数据技术与传统数据中心的集成数据中心引入大数据的意义与原则n随着半结构化、非结构化数据、互联网数据等新型数据源的引入以及分析需求对分析深度和广度的增加，以移动运营商行业为例，越来越需要大数据。主要包括如下：1、数据规模方面：GPRS流量话单的条数和数据量已经超过了语音详单，而位置信令、Gn信令、客服语音、互联网外部数据等规模更大，且还处在不断增长的趋势。2、数据类型方面：逐步从OLTP系统中获得的结构化数据，

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

9、功能的迁移，可以先迁移非关键的应用。这些应用不涉及到关键生产任务，可以忍受数据处理延迟和故障修复时间较高等可能出现的风险。3、先简单后复杂。数据处理逻辑较简单的应用也可以首先尝试引入大数据处理技术，降低实施的复杂度，积累运维经验。通过在大数据处理技术的规划、实施及运维过程中积累经验及教训，不断提升和完善大数据技术的应用水平，逐步拓展大数据技术应用领域。大数据在数据中心的应用场景n大数据技术可以应用在以下场景（包括但不限于）：1、原数据仓库底层结构化数据处理（ETL或ELT）。底层结构化数据处理计算任务重但复杂性不高，不涉及多表关联，适合引入大数据技术实现高效低成本。例如：对运营商的清单（语音详

10、单、GPRS清单、WLAN清单等）的清洗、转换、汇总等。2、半结构和非结构数据处理与分析。例如对上网日志、网络信令、客服语音等数据的处理和分析，这些数据难以利用传统数据仓库技术进行处理和分析。3、数据集市。地数据集市应用较为独立，且对可靠性的要求并不是十分严格，适合作为引入大数据技术形成资源池，以移动运营商为例，可实现各地市、各部门数据集市的云化、池化和虚拟化，最终实现资源动态调配，达到高效低成本。4、数据仓库数据分级存储。对低价值的细节数据以及长周期的历史数据（冷数据）访问频率较低，也能容忍相对较长的响应时间，可以存储在成本更低的平台上。5、数据挖掘。某些数据挖掘设计长周期的数据，计算时间很

11、长（数天），占用很多数据仓库资源。还有一些数据挖掘算法超出了关系代数计算范畴，需要抽取数据到独立的计算平台（例如SAS统计分析系统）中进行计算。这些数据挖掘任务可以迁移到大数据平台之上进行计算。例如交往圈的计算，因其仅涉及单一数据，但数据量非常大，且需要多次迭代计算。6、对外查询。数据中心不仅仅是数据处理，也需要将数据处理的结果对外提供查询，而这些查询一部分是海量的OLAP性质的查询，另外还有一部分OLTP性质的查询，即数量众多但每次查询量较少的。比如数据中心前端库、与生产系统互动的数据库以及提供流量详单查询的数据库。这些查询任务不能很好地运行在OLAP类数据库之上，可以迁移到大数据平台上。针

12、对这些应用场景，可以看到，主要需要引入的是Hadoop和MPP技术，然后逐步考虑NoSQL、流计算和内存计算等技术的引入。Hadoop技术与MPP技术的比较HadoopMPP传统数据仓库传统数据仓库平台开放性平台开放性高低低运维复杂度运维复杂度高，与运维人员能力相关中中扩展能力扩展能力高中低拥有成本拥有成本低中高系统和数据管理成本系统和数据管理成本高中中应用开发维护成本应用开发维护成本高中中SQL支持支持低高高数据规模数据规模PB级别部分PBTB级别计算性能计算性能对非关系型操作效率高对关系型操作效率高对关系型操作效率中数据结构数据结构结构化、半结构化和非结构数据结构化数据结构化数据Hadoo

13、p 在处理非结构数据和半结构数据上具备优势，尤其适合海量数据批处理等应用需求。当然随着Hadoop技术的成熟，基于Hadoop的即席查询技术也逐渐崭露头角。比如仿照Dremel的开源项目Apache Drill以及Cloudera Impala。MPP适合替代现有关系数据结构下的大数据处理，具有较高的效率，但其在大规模集群（超过100个节点）下的可用性还有待试点证实。MPP数据库场景下经常需要扫描大量的数据，所以对磁盘存储系统的数据库场景下经常需要扫描大量的数据，所以对磁盘存储系统的I/O性能要求非性能要求非常高，在测试和日常运行中，常高，在测试和日常运行中，I/O多大情况下是瓶颈，这点与多大

14、情况下是瓶颈，这点与Hadoop平台可以明显区平台可以明显区分开来分开来。目录MPPMPP数据库在数据中心的应用数据库在数据中心的应用企业级数据中心定义企业级数据中心定义数据中心中的大数据数据中心中的大数据数据中心数据中心BIBI技术规划技术规划选型选型HadoopHadoop在数据中心的应用在数据中心的应用数据中心数据中心ESBESB技术技术研究研究大数据技术与传统数据中心的集成大数据技术与传统数据中心的集成MPP数据库在数据中心的应用场景MPP数据库适合结构化数据的深度分析、复杂查询以及多变的自助分析类应用。它提供了统一的标准访问接口（SQL），而无需像Hadoop一样需要定制开发。MPP

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

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

17、的需求。这部分的计算任务可以定位于数据仓库外的复杂数据加工、数据汇总任务，其源数据可以来自业务系统，也可以来自ETL（专业ETL工具或者Hadoop）清洗、转换后的话单或者经过ETL轻度汇总过的数据。其结果数据导入到基础数据仓库中供上层应用访问。MPP平台选型建议对比项目对比项目TeradataEMC南大通用南大通用IBMHPAster DataGreenPlumGBase 8ADB2 DPF Over GPFSVertica无共享无共享MPP架架构构-无主控节点无主控节点*无共享无共享MPP架架构构-有主控节点有主控节点支持行存储支持行存储支持列存储支持列存储（10.5版本发布后）当前构建在

18、X86平台上的新型MPP数据库产品众多，Garnter每年会发布一版数据仓库魔力象限可以供参考。在大陆地区可以获得技术支持的MPP产品及其特性如下（包括但不限于）：不同架构的数据仓库各有优缺点。比如带主控节点（Master）的数据库会存在单点故障，但各节点分工明确；无主控节点的数据库不存在单点故障，但可能某各节点承担的任务不平均。行存储装载数据快、压缩率低、查询速度稍慢；列存储装载数据满、压缩率高、查询速度快，但部分产品的列存储方式无法支持更新、删除数据。硬件平台的选型参考各厂家的指导文档。MPP数据分布规划得益于ShareNothing的架构，MPP数据库的所有表都是分布式存储的，所以在创建

19、表时都需要指定分布键，分布键可以是单一字段，也可以是复合字段，然后通过Hash方式去分布。合理的分布合理的分布键设计可以使得大部分的表关联操作在键设计可以使得大部分的表关联操作在一个节点内完成，不需要跨节点进行数一个节点内完成，不需要跨节点进行数据交互，这是据交互，这是MPP数据库产品（按行数据库产品（按行Hash分布）与分布）与Hadoop（选择按照块随（选择按照块随机分布）的根本差别机分布）的根本差别。注意：在某个节点发生故障无法为整个MPP数据库集群提供服务的情况下，数据库会自动切换到副本机制，利用副本所在的服务器来提供服务。但是副本所在的服务器本身就要承担自己正常的工作任务，这样一来相

20、当于负荷加重了一倍。所以故障情况下虽然整个数据库集群可用，但是理论上的性能将下降到原来的一半，而不是按照退但是理论上的性能将下降到原来的一半，而不是按照退服节点比例的性能下降服节点比例的性能下降。目录MPPMPP数据库在数据中心的应用数据库在数据中心的应用企业级数据中心定义企业级数据中心定义数据中心中的大数据数据中心中的大数据数据中心数据中心BIBI技术选型描述技术选型描述HadoopHadoop在数据中心的应用在数据中心的应用数据中心数据中心ESBESB技术研究技术研究大数据技术与传统数据中心的集成大数据技术与传统数据中心的集成Hadoop在数据中心的应用场景分析场景为什么采用Hadoop采

21、用的组件ETL1、降低原始数据存储压力2、降低数据仓库处理压力3、降低存储和处理成本Hive/MR/Pig清单查询1、快速响应海量数据查询2、降低查询成本HBase机器学习和数据挖掘1、降低海量数据挖掘成本2、缩短计算时间3、实现更加灵活的算法mahout/R/MR冷数据存储1.降低冷数据存储成本2.降低冷数据查询成本Hive Over HDFSHadoop在数据中心的应用场景-ETLHadoop平台负责从接口机采集数据入HDFS分布式文件系统，并进行清洗、关联、转换、汇总、逻辑增强等，实现原始数据、明细数据和汇总数据的处理加工工作。具体实现上可以采用Hive或Pig用脚本来实现数据处理，也可

22、以编写Java或其他语言的程序（用到Hadoop流的功能），直接利用MapReduce框架来进行处理。Hadoop在数据中心的应用场景-详单查询Oracle/DB2用户用户详单详单文件文件库库数据存储服务接口话单查询数据抽取数据解析数据翻译用户详单统计分析收入保障呼叫中心飞信短信彩信WAPEmail网厅统一接入网关平台用户账单HBase 分布式数据库（基于HDFS) Hive分布式数据仓库(基于HDFS) 前端查询业务服务器集群 ETL服务器集群 清账单数据抽取和转换计费数据库清账单数据装载入HBase历史清账单数据可从HBase导出装载入Hive (可选)负载均衡设备查询清单互联网用户n 清

23、单云平台采用基于大数据的Hadoop云架构，以PC服务器搭建大规模存储集群。n在数据处理方面：引入数据抽取、转换、加载工具ETL，在入库前对详单中的各个字段含义进行翻译，服务接口不再进行翻译，提升查询效率；n在分布式存储方面：引入基于x86服务器的分布式存储技术，主要由Hbase、Hive、数据库集成等功能组成，在提高系统的扩展性和弹性的同时，可以方便、快速地为应用增加或减少资源。某运营商省份的应用效果：n应用前数据导入性能指标1M/秒，应用后达到45M/秒，性能提升44倍。n应用前数据加载性能指标3万条/秒，应用后达到17万条/秒，性能提升4.67倍。n应用前用户查询性能指标30个并发查询/

24、秒，应用后达到100个并发查询/秒，性能提升233%。n应用前并发查询性能指标35.81毫秒/笔，应用后达到8.09毫秒/笔，性能提升77.4%。Hadoop在数据中心的应用场景-机器学习与数据挖掘、冷数据存储nHadoop可以承载数据量较大、需要多次迭代关联、涉及数据对象较为单一的数据挖掘计算。Hadoop上开源数据挖掘分析专题工具有mahout和R，也可通过MR接口编程实现所需的挖掘算法，可以实现以下数据挖掘：互联网内容分析专题：客户上网行为分析，关键词排序，爬虫，非结构化数据识别WLAN运营分析专题：WLAN终端分析，WLAN位置分析，WLAN与GPRS关联分析，WLAN用户群分析用户交

25、友圈分析专题：用户个人语音交友圈分析，用户个人短信交友圈分析，交友圈特征分析nHadoop可以承载历史性、访问频率较低的数据，存放在Hadoop上仍然能够实现通过Hive或者其他软件，实现类SQL或者其他API的数据访问。而在配置策略时，为了节省空间，可选择进行压缩、纠删码（HDFS Raid）或者降低副本个数，例如2。冷数据例如：超过一定周期的（12个月以上）的详单信息。上网日志信息和原始网页信息。其他价值低、优先级低、数据量大的数据。Hadoop选型建议产品包产品包基线版本基线版本产品包产品包基线版本基线版本Hadoop2.0.0HBase0.94.6Hive0.10.0Cloudera

26、Impala1.0ZooKeeper3.4.3 总体来看，目前总体来看，目前Apache Hadoop开源社区主要在开源社区主要在Hadoop 1.0和和2.0 两个版本上分别进行持续更新优化。两个版本上分别进行持续更新优化。而而Cloudera公司的公司的Hadoop版本版本CDH3和和CDH4也分别基于也分别基于Hadoop 1.0和和2.0版本进行封装版本进行封装。下图开源社区发布的各个版本以及与Cloudera发布的CDH软件包的对应关系如下图所示，以及对应CDH4.3版本的描述：Hadoop服务器配置建议项目项目主节点配置建议主节点配置建议数据处理数据处理（MR/hive）的数）的数

27、据节点据节点数据查询数据查询（HBase）的数）的数据节点，可以与据节点，可以与数据处理的数据数据处理的数据节点合设节点合设zk节点节点CPU个数及核心个数及核心数数2路8核以上2路8核以上，如果压缩数据或者处理比较复杂，可以考虑更多路多核的2路6核以上2路8核以上硬盘数硬盘数硬盘数可以不同太多，4-6块6、8或者12块，数据处理时IO一般不是瓶颈，但更多的磁盘可以存储更多的数据6、8或者12块，取决于存储量（主要靠缓存）硬盘数2-4块内存内存128G或更高48G或更高64G或更高，太高GC可能成为负担48G或更高网络网络双口万兆或千兆网卡双口万兆或千兆网卡，主要影响装载速度和节点间数据交换效

28、率双口千兆网卡双口万兆或千兆网卡，对网络延时有高要求，如果可以，建议单独设立奇数个集群，3-5个Hadoop被设计运行在大规模通用X86硬件平台之上，使用本地存储（DAS）来实现Scale Out。所以其对硬件的要求较低，一般的PC服务器也可以运行，只要满足发行版所要求的操作系统和JDK需求即可。但是在实际使用中需要根据Hadoop的应用环境来合理配置硬件，充分发挥每个部件的效率。在前期试点中，发现如果执行MapReduce，特别是在压缩文件上执行，其对CPU的消耗较高，CPU成为了瓶颈；而在运行Hbase的时候，更多的内存会缓存更多的数据，提高查询吞吐率并缩短响应时间。所以建议这两种情况下，

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

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

31、region划分风暴，大量的请求会使region server和name node的压力过大而导致region dead或者name node dead。nTTL设计：TTL（time to live），它一般可以用来控制数据的生存时间。一些数据比如客户几年以前的数据，几年以后已经不关心这些数据，可以使用TTL删除。如果数据没有这些要求，可以不使用。目录MPPMPP数据库在数据中心的应用数据库在数据中心的应用企业级数据中心定义企业级数据中心定义数据中心中的大数据数据中心中的大数据数据中心数据中心BIBI技术选型描述技术选型描述HadoopHadoop在数据中心的应用在数据中心的应用数据中心数据

32、中心ESBESB技术研究技术研究大数据技术与传统数据中心的集成大数据技术与传统数据中心的集成数据中心系统集成建议在引入Hadoop和MPP数据库后，数据中心建设将会在现有传统数据仓库平台与新技术之间形成混搭。经典数据仓库中的One Single View of Truth将难以维持。主要会面临如下的问题：数据互通：数据需要跨Hadoop和多个数据库进行交互，如何实现高效的数据同步或数据调用？透明访问：是否有必要对上层应用屏蔽底层不同数据平台的细节，提供统一的数据访问方式？统一管理：如何进行多套数据平台的元数据、数据质量管理，如何实现统一的调度和运维监控？数据互通机制是多个数据库与Hadoop之

33、间的桥梁。通过数据互通，我们可以将数据快速从一个平台迁移到另外一个平台或从一个平台方便地访问另外一个平台中的数据。数据互通机制的主要难点是要保障数据在两个平台间流转时的高效性和可靠性。数据中心系统互通的建议n实现数据互通机制有2种方法：数据同步、数据调用n数据同步：数据同步的主要是实现数据库与Hadoop之间双向数据复制功能，数据同步的目的包括这些的场景：不同系统上的数据需要进行关联分析、数据生命周期管理要求进行数据归档或备份、ETL分节点部署需要同步数据等。可以采取如下数据同步方案： 在Hadoop端发起的双向数据同步 在数据库端发起的双向数据同步 在第三方发起的双向数据同步n数据调用：数据

34、调用指的是：不移动数据，通过接口调用实现对另外一个平台上数据的访问，被调用平台承担运算任务。数据调用方法根据调用方的不同，又分为“从数据库侧调用Hadoop数据”及“从Hadoop侧调用数据库数据”两种情况。数据调用方法适用的场景原则：低频度（如：每月/季度/年一次）或临时（如：临时访问5次以下）需要使用其他平台中存储的数据。数据中心互通的技术实现n连接器方式通过设计专用的软件或硬件连接器模块，实现数据库与Hadoop之间高速的数据传输，其一般具备以下特点：p双向连接器p并行连接数据库节点到的Hadoop数据节点p支持UTF-8编码和常见的数据类型p通过动态工作负载管理的资源控制p融合系统中的

35、角色/用户提供认证p为数据库域提供的数据节点，主要实现以下按照源表进行任务分工，可以为表间并行以及表内并行p建立分区、索引及装载，根据分区原则以及索引等策略，装载节点将数据直接发送给相应的MPP数据库节点上p装载节点处理过程中数据不落地p装载节点可以是MPP数据库中的部分节点也可以独立设置p 通过连接器的方式，可以实现数据库与Hadoop系统之间的高速和可靠的数据互通，非常适合数据同步的计算场景。n外部表方式：数据库可以通过外部表的方式，直接访问存储在HDFS上的文件。在使用外部表时，数据库可以像访问内部数据一样，将文件当作表insert到数据库内其他表中，或将HDFS上的文件和数据库内的表进

36、行关联操作。同时也可以将RDBMS内的数据，通过外部表的形式，写入到HDFS上去。例如如下操作:Select count(*) from HDFS_data h, RDBMS_data g where h.key = g.key;Insert into HDFS_data select * from RDBMS_data;数据中心透明访问nHADOOP+MPP的混搭架构在解决大数据处理问题的同时也加大了上层应用的数据访问复杂度。主要问题体现在：多种数据实例：数据可能分布在关系型数据库、Hadoop分布式计算集群以及HBase库中。多种访问接口：不同类型的数据实例的技术实现方式差异大，如关系型数

37、据提供了标准SQL，Hadoop、HBase提供开放API或Hive方式访问，这同样对上层访问增加了难度。跨数据实例的数据计算：不同类型的数据实例的底层数据存储结构不同，如关系型数据库存储结构化数据，而Hadoop计算集群多存储半结构化数据，如果需要涉及到两种类型数据实例中的数据关联（join）计算，目前还难以直接实现，需要做一系列数据互通调度，然后在单实例上完成关联计算，整个过程复杂度高、工作量大。n针对目前出现的这些问题，可以考虑构建数据透明访问能力。也就是提供统一的数据访问接口，对上层屏蔽底层数据处理实现细节，提升上层应用的开发效率。主要需要解决两个方面的问题：1、通过统一的语言或服务接

38、口访问到不同的数据库实例，包括数据查询、数据处理操作等。2、针对跨数据实例的数据互通、关联操作等，可以通过统一的的语言、服务接口或管理工具等技术来实现。目录MPPMPP数据库在数据中心的应用数据库在数据中心的应用企业级数据中心定义企业级数据中心定义数据中心中的大数据数据中心中的大数据数据中心数据中心BIBI技术选型描述技术选型描述HadoopHadoop在数据中心的应用在数据中心的应用数据中心数据中心ESBESB技术研究技术研究大数据技术与传统数据中心的集成大数据技术与传统数据中心的集成BI集成工具选型问题n这些众多的BI项目从规模和对BI系统支撑的完善程度上来说，大体可以分为Framewor

39、k、Stand-alone Tools和BI Suite三种类型。Framework：开源框架，这是在商业BI系统中所没有的。我们可以使用它们来构建自己的BI工具，或者增强和扩展我们的BI解决方案。Stand-alone Tools：独立的BI工具，这是开源项目中数量最多的一类。很多工具只侧重BI系统中的某个环节和方面，如ETL、Report、OLAP和Database等等。BI Suite：在统一的架构下提供了多种BI系统的特性的工具集合。就目前的情况看，不管是商业软件还是开源软件，还没有任何一个套件提供了完整的端到端的BI解决方案。这些开源的BI Suit是通过连接多个其他的组件和工具的方

40、式形成套件的，由于BI系统涉及到的工具是非常多的，所以整合一套完整的BI解决方案是很困难的。n开源BI的重要项目：Pentaho、spagoBi是两个比较大的框架，集成了相当多的开源项目，JfreeReport、Mondrian、Kettle、Weka基本都使用。适合大型复杂项目的开发。Pentaho：是一个以工作流为核心的、强调面向解决方案而非工具组件的BI套件，整合了多个开源项目，目标是和商业BI相抗衡。SpagoBI 集成了OLAP ServerMondrain和OLAP展示JProvit，能够通过OpenLaszlo产生实时报表。SpagoBI使用java开发，不依赖于具体的操作系统，

41、有很强的扩展能力。开源BI工具之Spago BISpagoBI 集成了Mondrain和JProvit，能够通过OpenLaszlo产生实时报表。SpagoBI使用java开发，不依赖于具体的操作系统，有很强的扩展能力。它主要包括：1、 报表工具：JasperReports /Eclipse BIRT/ iReport2、 OLAP Server：Mondrian3、 OLAP展示：JPivot4、 数据挖掘组件：Weka5、 Map引擎：Geo6、 ETL：BIE7、 搜索引擎：Lucene8、 Dashboard：OpenLaszlo9、 Portal Server：JBoss/ Tomc

42、at/ JOnAS开源BI工具之PentahoPentaho是一个以工作流为核心的、强调面向解决方案而非工具组件的BI套件，整合了多个开源项目，目标是和商业BI相抗衡。它包括如下开源组件：1、 工作流引擎：Shark and JaWE2、 数据库：Firebird RDBMS3、 集成管理和开发环境：Eclipse4、 报表工具：Eclipse BIRT5、 ETL工具：Enhydra/Kettle6、 OLAP Server：Mondrian7、 OLAP展示：JPivot8、 数据挖掘组件：Weka9、 应用服务器和Portal服务器：JBoss10、 单点登陆服务及LDap认证：JOSS

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

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

45、中心的集成大数据技术与传统数据中心的集成企业应用集成EAI与ESBn企业应用集成（EAI）是集成应用之间数据和服务的一种应用技术。它解决无限的问题，解决方案也几乎没有穷尽。目前常见的四种集成风格：1.文件传输：两个系统生成文件，文件的有效负载就是由另一个系统处理的消息。该类风格的例子之一是针对文件轮询目录或FTP目录，并处理该文件。2.共享数据库：两个系统查询同一个数据库以获取要传递的数据。一个例子是你部署了两个EAR应用，它们的实体类（JPA、Hibernate等）共用同一个表。3.远程过程调用：两个系统都暴露另一个能调用的服务。该类例子有EJB服务，或SOAP和REST服务。4.消息：两个

46、系统连接到一个公用的消息系统，互相交换数据，并利用消息调用行为。该风格的例子就是众所周知的中心辐射式的（hub-and-spoke）JMS架构。这些风格迥然不同，因为没有一种解决办法能在任何情况下都良好运转。这导致整个中间件领域都在基于这些模式寻求可用的解决办法，通常被称为企业服务总线（ESB）。ESB是最终的中间人：它知道如何使用各种语言在各种协议上调解传递的消息。nESB定义与主要功能：ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。Invoc

47、ation同步和异步的传输协议的支持、服务的定位和绑定 Routing静态和动态路由、基于内容路由、基于策略路由、基于规则路由Mediation适配、协议转换、服务映射 Messaging 消息处理、转换、增强 Process choreography负责业务逻辑的实现 Service orchestration服务编排 Complex event processing事件解释、事件关联、模式适配 Other quality of service安全、可靠传输、事务 Management监视、audit、日志、计量、管理、BAMESB实施探讨n不推荐的实施：1、用ESB实现大数据传输：ESB并

48、不适合完成该项功能，虽然它可以实现这一功能，但这并非最佳实践。ESB作为企业级的服务联通、管理平台，需要穿透ESB的服务应该是企业内重用可能最大、价值最大的那些服务，应用程序对这类服务的访问应该非常频繁，因此同一时刻需要ESB支撑的业务可能非常繁重。所以，ESB产品的设计初衷是实现一个无状态、高吞吐的服务总线，为企业内重要的业务服务提供透明、标准、开放的接入能力。这种实践的原因是过分放大了ESB对数据的传输能力，如果在ESB传输巨大的信息，可能会导致ESB整体性能的下降，损害其他重要服务的QoS。2、挟ESB以令外围应用：ESB的架构师在ESB上设计一套标准的数据接口（通用的XML格式），规定

49、使用统一的协议（如Web Service/HTTP）。所有的ESB服务消费者和接入ESB的服务必须符合该标准。其目的是为了简化ESB上的开发工作。这就是一种“挟天子以令诸侯”的做法。ESB针对的是一个个功能各异的整合逻辑，服务之间的整合逻辑也是迥异的。所以，一劳永逸的ESB之上的架构是不存在的。3、用ESB实现业务流程：有些架构师看到ESB支持服务组合（Service Composition）模式，进而认为可用该模式来实现业务流程。因此，ESB产品就演变成了BPM产品。让ESB实现BPM，特别是长运行的流程时，虽然在技术上可以实现，但是这违背了ESB产品的设计理念，会大大影响其ESB运行时的整

50、体运行效率。n推荐的实施：1、服务要管理起来：ESB的一个重要功能是将企业内/合作伙伴处的服务以开放的、标准的服务方式暴露出来，使得服务消费者能够便利地查找到服务，以促进服务的重用、管理。2、复杂的动态路由规则应服务化：路由是ESB中非常重要的仲裁逻辑之一。路由场景是非常普遍的。譬如，针对不同的客户提供不同QoS的场景，执行时需根据客户的类型将其路由到不同执行能力的服务提供者；再比如当响应消息到达ESB时，总是需要将该响应消息送回最初的服务请求者处。对于复杂的路由，推荐将路由规则的逻辑外部化，并将它服务化。开源ESB之ServiceMix（SM）n产品简介：它是JBI规范的一种实现；包含很熟JBI组件。这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。同时也实现了EIP，规则和调度。SM也整合了其他的开源项目，比如Apache、ActiveMQ CXF,Apahe Camel