卡特 阿里技术嘉年华
上集回顾：
什么是大数据？【回复071查看】
层次、维度与主题【回复072查看】
?
????在前面的章节中，我们提到，本文最终的目的，是带领大家构造设计一个“全民信息数据挖掘系统”。而在上一节中，我们得知，数据仓库的特性之一便是其的“集成性”：不同的数据来源、不同的形式的数据集中在一处，在数据仓库系统中进行分析。这便是一个数据仓库系统的ETL的第一个步骤。所谓的ETL，便是Extraction-Transformation-Loading， 数据的提取、转换和装载到数据仓库的过程。数据从前端的业务系统中，装载到数据仓库中。在这个过程中，我们从数据源抽取出所需的数据，经过数据清洗,最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。 当然，随着数据量的愈发庞大，ETL的工作步骤越来越向ELT方向发展，暨先将各式各样的数据装载入数据仓库中，然后再利用数据仓库系统的强大的计算能力，对数据进行转换和清洗。
????说到数据源，当然指的便是业务系统中的各个数据来源，例如我们的各个网站或者C/S（客户端/服务器）系统中后台的各种数据库，如MySQL、SQLServer、Oracle、DB2等，如果再考虑到“全民信息挖掘系统”的特性，我国不少政府部门的业务数据库还在使用M$的FoxPro和Access， 这也是数据源的一种。上述提到的数据源，都是指的是业务系统使用的数据库系统，便是所谓的“第一类数据源”，具有高结构化（被软件系统辨识和处理的容易程度极高）、查询容易等的特点。?
????还有一类数据源，结构化程度相对较低，计算机处理起来相对困难，例如web服务器产生的日志（这个还是相对容易处理的），用户上传的图片等等。在这里，日志数据是比较特殊的一类数据源，一般来讲，日志是直接以文本文件记录在文件系统中的，日志记录了用户在网站上的全部访问情况，对数据挖掘至关重要，所以在各大互联网的企业中，对日志数据的传输，都做了大量特殊的处理。?
????总体来讲，在构建数据的传输和同步系统时，主要需要考虑两个方面，便是数据的结构类型，和对数据的时效性的要求。对于结构类型，主要分为数据库存储的高度结构化数据、日志等的半结构化文本数据、和图片等完全非结构化数据三种；在时效性方面，主要有（准）实时（数据产生后在短时间，一般是几分钟内便要同步到数据仓库）和定时传输（每天、周传输一次）两种情况。?
????我们先来看定时的数据库结构化数据传输的情况。数据库有很多种，每一种数据库的数据类型都略有不同，而我们的数据仓库系统，由于其的集中性，数据类型肯定是统一的、一致的。那么，要从各种数据库同步数据到数据仓库的过程中，我们需要进行数据的转换。不过，由于各种数据库均支持SQL语言，在SQL查询出的数据中，全部数据都可以转换为字符串（block或buffer一类除外，不过，这类数据我们一般也不会在数据仓库中分析），所以，我们通过字符串的转换方式，便可以达到数据源转换的效果。?
????更进一步的，由于我们一般不会直接让数据产品的最终用户直接通过数据仓库来查询数据（至于为什么我们后文会介绍），我们往往还需要在数据仓库分析处理数据之后将结果导入业务数据库，所以我们需要一个多方向的高自由度的结构化数据同步服务。在这里，我们可以采用阿里巴巴集团开发的开源产品DataX（ http://code.taobao.org/p/datax/wiki/index/ ） 。 DataX可以在任意的异构数据源之间交换数据。数据在DataX的传输过程中以一种中间形态存在，DataX会管理好数据的传输、缓存等工作，而对于不同的数据源，DataX通过插件的形式来提供支持，插件的作用是将数据从数据源中读出并转换为中间形态，以及将中间形态的数据转换为目标数据源的数据格式而写入目标数据源。?
????就好似一个交通枢纽，核心是一个巨型的立交桥，而插件则相当于立交桥的入口和出口，在从港口来的行人，在港口-立交桥入口中从轮船上下来，乘车进入立交桥，再通过收费站来到公路，可以进入机场入口，再从汽车上下来登上飞机等等。。。这样就达到了任意类型的交通工具（数据源）的自由转换的目的。?
????DataX可以让我们在任意格式的结构化数据源间定时交换数据，而如果要在各个数据源间实时的交换数据，我们需要另一种方法。实时的数据传输的主要问题在于对业务数据库的性能上的压力，目前对于业务数据库实时同步到数据仓库中，最简单的方案是给业务数据库增加一个从(Slave)数据库，从数据库一般通过读取主数据库的OpLog（记录了每一次数据变化的操作），来和主(Master)数据库来保持数据的一致性，并且不会对主数据库造成很大的性能影响。最简单的，我们可以通过每分钟对从数据库的新增数据进行一次扫描读取，来传输到数据仓库中，因为业务系统是不连接从数据库的，所以这不会对业务系统造成影响。?
????但是，聪明的读者一定会想到，既然读取主数据库的OpLog便可以在不大影响性能的情况下保持数据的准实时同步，那么我们为什么还需要一个从数据库呢？这确实是解决问题的一个思路，不过解析OpLog相对于直接SQL查询从数据库来说更加困难，开发成本较高。腾讯的TDBank数据仓库系统中，采用了类似的方案，他们开发了MyDbSync软件，通过解析MySQL的binlog（也就是OpLog）来同步数据，取得了良好的使用效果。 我们公司内部，也有类似的项目，叫做shrek。
????我们再来看日志数据的同步，对于日志数据，我们在实践中以准实时的同步为主，因为每天的日志是源源不断的产生的，并且经常分布在成百上千台服务器的硬盘中，如果每天一次性的读取日志，在性能上得不偿失，所以应该在日志产生之后尽快以流的形式源源不断的同步到数据仓库中。一般来讲，我们通过消息订阅的模型来进行日志的准实时同步。我们建立一个日志数据交换中心，每台服务器的日志都由在这台服务器上的专门的软件源源不断的同步到日志交换中心上，然后需要存储这些日志的数据仓库们来订阅这些日志，就好像我们订阅报纸一样，一旦有新的日志数据到达，日志交换中心立刻通知数据仓库系统来取这些日志数据。在全部订阅者取完了这份日志数据之后，这份日志从日志交换中心的存储上删除，腾出空间来装载下一份日志。?
????阿里巴巴集团数据平台部门开发的TimeTunnel （ http://code.taobao.org/p/TimeTunnel/wiki/index/ ）， 便是可以用来建立日志数据交换中心的系统。TimeTunnel 部署的日志交换中心，只要一台服务器便可以实现2KB大小的日志数据的每秒钟4万条的实时传输，只要数十台服务器组成的日志中心集群，便足够承载我们的全民数据挖掘系统所需要的实时的数据如银行刷卡日志的同步工作了。?
????通过结构化数据库的数据实时/定时同步，以及日志数据的准实时同步，我们便可以把我们所需要的全民数据从全国各地同步到我们的数据仓库中心中，接下来，我们将对这些数据进行分析和清洗。对这样大规模的数据进行清洗，我们便要涉及大规模离线计算（如Hadoop/Hive）的使用，这便是我们下一章节的内容。
--
微信名称：阿里技术嘉年华
微信号：alibabatech
简介：传播原创高质量的技术内容
