大数据-数据采集和集成

标签: IT咨询 | 发表时间:2016-04-13 16:07 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
最近在对已有的大数据采集和数据集成工具进行梳理,并考虑进行相关的产品整合工作,经过对已有的产品的测试和验证,已经实际需要的业务场景,初步考虑清楚后续需要进行新增和完善部分的内容。

数据库实时同步和复制

对于数据库实时同步和复制一定会谈到的两款商用产品就是Oracle GoldenGate和Quest SharePlex,具体的介绍网上也比较多,其核心特点就是支持异构数据库之间的实时数据同步和负责,而且对源数据库本身侵入性很小。两个商用产品基本都是对各种数据库的Log日志文件进行分析,然后进行复制。

那对于这块如果要自研来实现有无可能,对于Mysql来说由于采用Binlog日志方式,类似淘宝的Otter已经可以完整的实现数据库的实体同步复制。如果单纯是Oracle-Oracle数据库之间,我们也可以采用Oracle DataGuard或者Oracle Stream流复制技术进行复制,还有就是基于Oracle LogMiner进行redo log日志分析后进行两个数据库之间的同步。因此关键问题还是在异构数据库之间的同步复制上。

对于数据库复制,Oracle当前常用的解决方案主要有:

oracle日志文件,比如LogMiner,OGG,SharePlex
oracle CDC(Change Data Capture)
oracle trigger机制,比如DataBus , SymmetricDS
oracle 物化视图(materialized view)比如淘宝的yugong开源

在这些解决方案里面可以看到有开源的SymmetricDS解决方案,但是是基于触发器机制,侵入性还是相对较大。也有淘宝的yugong可以实现Oracle->mysql的全量或增量复制,但是基于增量物化视图方式,本身会影响到源库数据表的CUD操作。

而实际上最佳的解决方案仍然是基于log日志的实时同步复制,其核心思路包括三个步骤

1. 在源库设置为记录日志或归档模式,源库首先能够记录下日志信息。
2. 实时的能够读取到日志信息,并对日志信息进行解析或适当转换映射,包括和目标库的适配。
3. 在目标数据库直接运行相应解析后的日志SQL语句,实现同步更新。

由于Mysql本身提供可读性很强的Binlog日志,因此可以看到Mysql->Mysql,Mysql->Oracle的实时同步日志问题是可以得到很好解决的。而对于Oracle->Oracle也可以解决,较难的就是Oracle->Mysql或其它异构数据库,这里需要分析Oracle本身的redo log日志(当前Oracle提供有logminer工具),如果我们自己写一个解析包的话就需要对Oracle redo log结构有完整的了解。

而结合Oracle 流复制技术,我们可以考虑Oracle首先将变更信息写入到自己的AQ,然后我们从AQ订阅消息后直接处理或者写入到我们自己的消息队列或流处理软件,然后在流处理软件中完成相关的映射转换后写入到目标异构数据库中。

数据库采集同步

对于数据库采集同步,当前谈到比较多的工具主要有Sqoop和结构化数据库间的ETL工具,当然当前对于开源的Kettle和Talend本身也集成了大数据集成内容,可以实现和hdfs,hbase和主流Nosq数据库之间的数据同步和集成。而淘宝的DataX则主要可以实现常见主流的结构化数据库(Oracle, Mysql,SqlServer)和hdfs之间的数据集成和同步。

对于Sqoop和DataX等当前也支持基于Key关键字段或时间戳的数据增量导入。即我们可以将导入命令行语句或Shell脚本通过任务或调度管理平台(类似开源的Chronos)配置为定时的调度作业,来实现对数据库的定时增量采集。

而对于常规的数据库包括大数据存储之间的采集和集成,再充分考虑性能的情况下,核心思路为:

1. 将源数据库数据进行导出,使用Sql或DB原生的导出命令直接导出为txt文件,字段以分隔符进行分隔。
    1.1 可以部署多个代理端,对数据库数据启用多个线程进行导出
    1.2 支持基于key值或时间戳的增量数据导出
2. 对导出的数据进行压缩后进行传输(特别是在源和目标库不在同一个数据中心时)
3. 在目标库端基于数据库原生的load命令对数据进行bulk批量导入。

在整个实现里面有两个核心,一个就是可以启用多个代理端和多线程机制并行导出数据库,其次就是导出数据压缩传输,然后在通过load data原生命令进行数据库的bulk批量装载提升性能。

如果基于以上思路我们可以看到数据采集的重点还是在性能上面,不会去实现ETL工具本身复杂的数据映射和转化,数据聚合等操作。核心只是做异构数据库和Hdfs文件存储之间的数据搬移。而我们完全自己研发的DataPipe产品基本参考上述思路实现,其测试性能对于结构化数据库之间采集和集成是Sqoop或DataX的2-3倍左右,而对于hdfs之间的集成则在5-10倍左右的性能提升。

对于这种采集存在的约束就是不要去处理数据变更的问题,仅仅是做数据的全量同步或者是数据库表数据的简单Append处理,否则性能本身会下降很多。如果有大量数据更新需要同步,最好的方式还是首先Truncate掉目标数据库表,然后再进行全量同步。简单验证对于Mysql数据库间100万数据,180M左右数据量的全量同步整体同步时间在14秒左右即全部完成。

文件采集

对于文件的采集大家谈的比较多的还是flume进行实时的文件采集和处理,当然对于ELK(Elasticsearch、Logstash、Kibana三者的组合)虽然是处理日志,但是也有基于模板配置的完整增量实时文件采集实现。如果是仅仅是做日志的采集和分析,那么用ELK解决方案就完全够用的。

我们谈的文件采集还是是采集文件后进行预处理,然后将采集的文件导入到hdfs库进行存储。对于这种方式即需要实现flume和hdfs的集成。同时我们看到如果对采集的数据要进行实时的处理和分析,则还需要结合kafka和storm来共同完成。这是一个完整的组合,网上也有完整的例子可以参考。

对于文件采集,其核心的实现思路可以概括为如下几个步骤来完成:

1. 实现对服务器源目录的实时监听,同时对文件流实时采集。
2. 实现对采集的文件流进行预处理,如通过flume 定制sink或其它相应插件。
3. 对采集的文件流输出到txt文件再导入到hdfs或者直接通过hdfs api接口增量导入hdfs文件系统。
4. 对于流处理模式则需要将flume接到kafa+storm上,实现流处理,storm处理结果可以存到redis库。

 

相关 [大数据 数据] 推荐:

谈大数据(2)

- - 人月神话的BLOG
对于大数据,后面会作为一个系列来谈,大数据涉及的方面特别多,包括主数据,数据中心和ODS,SOA,云计算,业务BI等很多方面的内容. 前面看到一个提法,即大数据会让我们更加关注业务方面的内容,而云平台则更多是技术层面的内容. 对于大数据会先把各个理解的关键点谈完了,再系统来看大数据的完整解决方案和体系化.

大数据之惑

- - 互联网分析
算起来,接触大数据、和互联网之外的客户谈大数据也有快2年了. 也该是时候整理下一些感受,和大家分享下我看到的国内大数据应用的一些困惑了. 云和大数据,应该是近几年IT炒的最热的两个话题了. 在我看来,这两者之间的不同就是: 云是做新的瓶,装旧的酒; 大数据是找合适的瓶,酿新的酒. 云说到底是一种基础架构的革命.

白话大数据

- - 互联网分析
这个时代,你在外面混,无论是技术还是产品还是运营还是商务,如果嘴里说不出“大数据”“云存储”“云计算”,真不好意思在同行面前抬头. 是千万级别的用户信息还是动辄XXXTB的数据量. 其实,大数据在我的眼里,不是一门技术,而是一种技能,从数据中去发现价值挖掘价值的技能. ”当我掷地有声用这句话开场时,正好一个妹子推门而入,听到这句话,微微一怔,低头坐下.

交通大数据

- - 人月神话的BLOG
本文简单谈下智慧交通场景下可能出现的大数据需求和具体应用价值. 对于公交线路规划和设计是一个大数据潜在的应用场景,传统的公交线路规划往往需要在前期投入大量的人力进行OD调查和数据收集. 特别是在公交卡普及后可以看到,对于OD流量数据完全可以从公交一卡通中采集到相关的交通流量和流向数据,包括同一张卡每天的行走路线和换乘次数等详细信息.

有关大数据的误区:数据统计≠大数据

- - 钛媒体网
钛媒体注: 大数据太火了,被广泛应用到各行各业,而近阶段又有着明显的过热迹象. 大数据到底是一个营销词汇,还是一个方法论. 本文作者老李正是一家大数据服务提供商的资深员工,他所做的项目就是针对不同行业进行大数据分析. 他认为,关于大数据你首先必须有一个基本认识,那就是“大量的数据并非一定具有价值”.

全球10大数据库

- - 译言-电脑/网络/数码科技
原文: Fiorenttini   译者: julie20098. [非商业性转载必须注明译者julie20098和相关链接. ,否则视为侵权,追究转载责任. 世界气候数据中心:气候全球数据中心, 220TB 的网络数据, 6PB 的其它数据. 国家能源研究科学计算中心,有 2.8PB 容量.

谈大数据分析

- - 人月神话的BLOG
对于数据分析层,我们可以看到,其核心重点是针对海量数据形成一个分布式可弹性伸缩的,高查询性能的,支持标准sql语法的一个ODS库. 我们看到对于Hive,impala,InfoBright更多的都是解决这个层面的问题,即解决数据采集问题,解决采集后数据行列混合存储和压缩的问题,然后形成一个支撑标准sql预防的数据分析库.

大数据的一致性

- - 阳振坤的博客
看到了一篇关于数据一致性的文章:下一代NoSQL:最终一致性的末日. (  http://www.csdn.net/article/2013-11-07/2817420 ),其中说到: 相比关系型数据库,NoSQL解决方案提供了shared-nothing、容错和可扩展的分布式架构等特性,同时也放弃了关系型数据库的强数据一致性和隔离性,美其名曰:“最终一致性”.

大数据Lambda架构

- - CSDN博客云计算推荐文章
1 Lambda架构介绍.          Lambda架构划分为三层,分别是批处理层,服务层,和加速层. 最终实现的效果,可以使用下面的表达式来说明. 1.1 批处理层(Batch Layer, Apache Hadoop).          批处理层主用由Hadoop来实现,负责数据的存储和产生任意的视图数据.

大数据公司Amazon

- - 36氪 | 关注互联网创业
说到 Amazon,它通常给人的印象是一家典型的电商公司——创办于1995年,靠在线书籍销售业务起家,发展至今也已颇具规模. 近日,TechCrunch作者Alex Williams撰文称,Amazon其实并非一家贸易公司,而是一家大数据公司. 联想到Amazon CEO Jeff Bezos曾说过的一句话:“企业家应该愿意在很长一段时间内承受误解的目光.