作为大数据平台的第一公里，数据集成必须考虑这些因素

大数据数据库数据集成

大数据杂谈 | 2016-07-15 17:18

【数据猿导读】很多大数据平台本身不是数据的来源，而是数据的存储和处理平台。随着这些技术的发展，大数据平台的吞吐能力越来越大，运算效率越来越高，各大厂商都在强调自己的大数据实时处理能力，但是如果获得的数据不是实时，那么实时运算也就失去了它的意义。所以作为大数据平台的第一公里，数据集...

各位朋友大家好，我是顾全，目前就职于HVR中国公司担任大中华区技术总监一职。非常高兴今天能够有机会和大家做个分享和交流。

先简单自我介绍一下。我是98年毕业于中国科学技术大学，专业是计算机科学。毕业后先去AMD做了2年的数据库应用开发，然后又做了2年的Oracle ERP技术顾问，2003年我加入了Quest公司。主要负责APM和数据库实时复制产品。应该算是国内最早接触这种基于数据库日志的复制技术的。在Quest工作的10年里也亲手实施了大量的行业标杆项目。

2013年我加入了SAP，主要负责的还是数据库和BI产品，包括内存计算技术，预测分析技术等大数据解决方案。

今天是我第一次参加大数据杂谈的活动，既然我们这是个大数据技术主题的群，我想我就还是从大数据谈起。

大数据分析与传统BI的区别

这个片子的内容，我相信大家应该都不陌生了。大数据的4个V(数据量，数据复杂性，数据产生速度和价值)最终能够体现为价值，本质上也是以分析为核心的，帮助企业提升业务洞察力，从而提高组织内部甚至组织之间的协同能力。

大数据分析与传统BI的最大的区别，我的理解有下面几个方面：

1. 预测性。各个大公司在推他们的大数据解决方案的时候都在强调他们的预测分析能力。

2. 综合性。传统BI往往是主题分析，大数据分析往往是综合性，跨域跨业务的分析。往往表现在不同数据之间发现内含的相关性，从而总结提炼出新的知识和方法。

3. 实现更高层次的资源整合，实现协同效应。

这里我讲个例子可能会更加容易理解。

我们以航空产业为例。根据GE说法，早在2013年他们生产的航空发动机每天就会产生超过1TB的数据，这是典型的物联网数据，也就是机器产生数据。这些装配在航空发动机上的各种传感器无时无刻地产生海量的数据。

通过对这些数据的收集和分析，我们可以对飞机的“健康”状况做出评估。这是实现预测性维护的基础，相比于规定每飞行多少小时或里程就必须进行全面检修一次来说，我想大家很容易理解这种预测性维护大大提高维护工作的精准性同时也大幅度降低了维护成本。

我们现在假设一架飞机在北京飞往上海的过程中，我们的大数据分析给出警告说左侧的发动机虽然仍在正常工作，但数据表明有潜在的风险，这有可能是由于某个或某几个零部件老化造成，那么接下来该怎么办呢?立刻飞往修理厂进行全面的检查和维修么?如果这样做的话可能成本还不如定期检修来的低。

理想的做法是根据飞机的飞行计划(下一站是上海，接下来可能是深圳…), 上海或者深圳附近是否有相应的零部件库存以及技术人员信息(技能，时间安排)，甚至还要考虑天气和航空管制信息计算飞机晚点的风险来生成一个检修计划; 然后根据计划向相关供应商，服务商下达采购订单。服务商接到订单后立刻安排工单派出技术人员带着零部件在指定时间到指定地点提供飞机的检修服务。对于航空公司来说提高了飞行的安全性的同时，降低了整体的成本，故障在潜伏初期被发现并解决;对供应商和服务商提升可客户满意度也降低了自己的维修成本。

这个故事是不是很棒?我认为这将是其中一个大数据的未来发展方向，这里我们可以看到预测分析技术被多次运用，分析的数据也呈现多元化态势，有些是自己的业务数据(航空公司内部ERP数据，飞行计划数据，航空班组和地勤人员信息)，有些是外部数据(天气信息，航空管制信息，运营商库存和技术服务人员信息)，这些数据有些是物联网产生的半结构化甚至非结构化数据。

通过这样一套大数据应用，飞机、机场、航空公司以及供应商服务商被有机的整合到了一起，实现了更高层面的协同。

在数据集成上面临的挑战

为了实现上面的目标，各个公司在数据分析方面有各种各样的技术创新我这里就不多谈了，我主要想从数据集成角度来看看我们当前还面临着哪些挑战。

首先就是数据的来源，这些数据根据其属性我们可以分成以下4大类：

1. 企业内部业务系统数据，这些数据往往是由OLTP业务系统产生，是存放在传统的数据库内，属于结构化数据;

2. 物联网数据，由机器产生，往往是定时生产一系列文件的方式，例如交通卡口的摄像头拍的照片，飞机上传感器采集到的运行信息等。这些数据大部分是半结构化甚至是非结构化的数据;

3. 互联网数据，网站，微博，bbs等产生的数据，以半结构化和非结构化数据为主;

4. 其它组织的数据，包括供应商，客户，相关政府部门等等。这些以结构化数据库为主。

其次是数据的分析平台，现在各种新技术层出不穷，各大厂商都给出自己的大数据解决方案，例如以Hadoop为核心的，或者内存计算技术为核心(如SAP的HANA)以及MPP架构数据库技术(如Teradata，Greenplum)。

这些技术各有其优缺点，越来越多的客户在构建自己的大数据解决方案时候往往也会综合采用上述多种解决方案，而不是仅仅依赖单一的技术。我在这里就不展开了。

但是需要注意的是这些大数据平台本身不是数据的来源，而是数据的存储和处理平台。随着这些技术的发展，大数据平台的吞吐能力越来越大，运算效率越来越高，各大厂商都在强调自己的大数据实时处理能力，但是如果获得的数据不是实时，那么实时运算也就失去了它的意义。所以作为大数据平台的第一公里，数据集成技术也越来越受到业界的重视。

数据集成需要考虑的因素在这样一个综合性的环境里，数据集成需要考虑哪些方面的因素呢?

1. 数据的实时捕获

目前基于事务日志的数据捕获已经变得非常成熟，Oracle有OGG，DB2有CDC，SAP Sybase有SRS，当然也包括我们自己的HVR。

这种技术最大的好处就是对源数据库系统影响较低，是一种非侵入式的数据捕获方式。基本原理就是所有的关系型数据库基本上都会提供事务日志，并且事务日志会记录所有的数据变化信息，数据库的事务提交也往往以写入事务日志为标志(此时数据库可能只完成了buffer的修改，数据文件还未完成写入)，通过分析日志我们客户获得全部的数据变化信息，并且这些信息天然就是增量的，按时间排序的，保证读一致性和事务前后顺序的。

2. 异构平台支持

数据复制软件不但要能够支持传统的关系型数据库和各种大数据平台，还应当支持文件系统复制，支持云环境的部署。上面这个图是目前我们的HVR可以支持的平台。

3. 数据压缩

数据产生的源越来越复杂，企业可能需要在不同地点的数据中心之间，或者在本地系统和云上的系统之间进行数据复制;有些数据可能由遍布全国的设备产生，例如移动通讯基站，输变电设施，石油钻井平台等;甚至数据产生的地点都不是固定的，例如上面例子里说的飞机，船舶;

数据压缩能力可以帮助企业极大的节约运营过程中的网络成本。目前我们HVR的压缩算法对字符型数据可以实现超过95%倍以上的压缩能力，对其它结构化数据类型也可以达到50%至80%的压缩率。

打个比方，一个oracle数据库产生1GB的redo log，需要复制的信息最多通常在30%左右，我们按照90%的综合压缩率来计算，实际需要占用网络传输的数据量仅仅有30M!

4. 数据加密

远程数据复制场景尤其应当重视数据的安全性，防止数据在传输过程被窃取。

5. 可管理性

这里涵盖的内容就比较广泛了。

一个方面是架构上：目前类似的软件绝大多都采用的点对点部署模式。一个典型的场景可能会是类似下面的这个架构图。大家可以看到这种网站的数据复制模式逻辑上非常复杂，对安装，部署，管理都带来很大的难度。

为了解决这个问题，HVR提供一个hub-spoken的架构，类似下图：

这样的架构使得软件的部署和管理维护非常简单，在每个数据节点上只需要安装启动hvr-listener服务即可，所有的配置，管理和监控工作都在hub服务器上进行，listener的工作行为由hub上的作业进程调度和管理。

可管理性的另外一个方面就是监控和历史报表。

同样得益于HVR精炼的架构设计，HVR可以方便地提供丰富的历史数据报表，例如复制的延迟信息，复制的数据量，增改删的记录数等。HVR还提供了完善的监控功能，当有故障发生的时候可以自动发送告警email到DBA的邮箱或者通过SNMP方式发送消息到监控告警平台上。

6. 数据的转换能力

上图是传统的商业智能领域通常使用的ETL方法。传统的商业智能由于主要面向的是已知的问题(主题)，通常在数据仓库建设阶段非常重要的就是数据模型设计，从业务系统取得的数据需要经过抽取(E)，转换(T)和加载(L)来完成。由于转换的工作量有的时候相当大，还会需要有个专门的数据库来支撑，所以有的厂商提出了ELT的解决方案。不论是ETL还是ELT，一般的工作特点都是定时抽取，批量转换和加载。数据仓库得到的数据是非实时的。

而大数据BI由于往往面对的是未知的问题，需要通过更加广泛的数据去探索和发现其中内涵的相关性，大部分情况下难以实现预先的数据仓库模型定义。

但对数据依然需要做一些转换工作。

例如1：数据的行级转换

例如2：数据的软删除和时间戳转换

大数据BI需要的不仅仅需要的是业务数据的结果，业务数据的变化过程可能更重要。

例如对于已经删除的数据，生产系统可能不在需要这部分内容，但是大数据分析依然需要，但是要通过标记列来识别。甚至更进一步，对所有的增改删，大数据分析都需要保留其变化的每一步过程，并通过时间戳和操作类型给予表示，当然在此基础上可能还会需要保留其它的相关信息，例如数据来源，业务发起用户信息等等。

这种数据转换其实不仅仅大数据BI需要，传统的商业智能也能从中受益。一些简单的场景，数据的行级转换已经可以满足业务要求。在一些大型的BI项目中，时间戳转换结合ETL工具的方案可以帮助企业避免ETL工具在数据抽取时对生产造成的性能影响，也避免了对生产系统为了实现数据的增量抽取而不得不进行的时间戳改造。

我的分享结束了，谢谢大家!

Q&A

Q1：对于异地双活数据中心有什么好的建议吗? 数据实时速度有多快?

顾全：先回答上面这俩个问题。正常情况下(也就是没有明显的系统瓶颈)，数据的同步延迟时间是在秒级，这可能受到网络延迟，事务的大小，目标数据库性能的影响。对于两地双中心，我们也有成功的案例。根本的原则是避免两地业务数据的冲突。例如，主键值的范围划分，使得正常情况下每个中心支撑的业务是被分区的。

Q2：传统BI和大数据肯定是未来企业发展的两方面，不能断言到底大数据会不会替代传统BI。那么问题在这里，传统BI肯定是企业着手做了很长时间的工程了，培养的分析人员，数据仓库开发员必然对企业的自有业务很精通，那么这些业务人员是否会有继续往大数据项目上发展的可能呢，还是公司会另聘咨询公司来做大数据项目?两者的比例，依你的经验会有多少分配? 现在的大数据市场工具眼花缭乱，各有千秋，肯定不是每个工具都能适应所有的项目工程。那么我们怎么选择才能更快切入大数据领域。是否可以推荐系统的书或者您的博客?

顾全：这个问题其实蛮大的，我不认为大数据BI会完全取代传统BI。传统BI和大数据BI会有不同的侧重点，解决的问题也是不完全相同的。但我相信，大数据的目标是提高企业的业务洞察力，这个洞察力最终是要落在企业员工身上的。所以业务人员的培养是非常重要的。咨询公司主要是扮演顾问的角色，在大数据项目落地的过程中，可能根据企业具体情况，依然会需要系统集成商，方案供应商，甚至软件开发商等多种伙伴的帮助。

Q3：基于行的复制，对批量更新和表更新操作有着天然的缺陷。你们的产品如何缓和批量更新的缺陷?DDL操作是否透明?

顾全：这个朋友说的很对。这种复制技术应该说主要面对的是源端OLTP类型的业务。但是批处理往往也是不可避免的。当批处理的量较大的时候，往往目标端数据入库可能会产生一定的延迟，业务对这个延迟的忍受情况是不同的，数据规模也差异很大，对策可能也会不一样。这个需要具体问题具体分析了。

Q4：基于数据库日志的大数据采集，更新和删除往往怎么处理?

顾全：通常来说可以采用我演讲中提到的转换示例2，也就是软删除或者时间戳转换的方式来处理。

来源：大数据杂谈

收藏分享

声明：数据猿尊重媒体行业规范，相关内容都会注明来源与作者；转载我们原创内容时，也请务必注明“来源：数据猿”与作者名称，否则将会受到数据猿追责。