大数据技术主旨之ETL解析

　　这篇文章讲述了大数据技术主旨之ETL解析，跟数据有关，有许多小细节，所以请大家仔细阅读哦~

     前几篇文章都是根据自己所见所知，在前人的基础上加以整合，对大数据概念有了初步的了解。接下来的四篇文章，抛开大数据的概念与基本知识，进入核心。我们从：数据采集、数据存储、数据管理、数据分析与挖掘，四个方面讨论大数据在实际应用中涉及的技术与知识点。

　　核心技术

　　架构挑战：

　　1、对现有数据库管理技术的挑战。

　　2、经典数据库技术并没有考虑数据的多类别(variety)、SQL(结构化数据查询语言)，在设计的一开始是没有考虑到非结构化数据的存储问题。

　　3、实时性技术的挑战：一般而言，传统数据仓库系统，BI应用，对处理时间的要求并不高。因此这类应用通过建模，运行1-2天获得结果依然没什么问题。但实时处理的要求，是区别大数据应用和传统数据仓库技术、BI技术的关键差别之一。

　　4、网络架构、数据中心、运维的挑战：随着每天创建的数据量爆炸性的增长，就数据保存来说，我们能改进的技术却不大，而数据丢失的可能性却不断增加。如此庞大的数据量存储就是首先面临的非常严峻的问题，硬件的更新速速将是大数据发展的基石，但效果确实不甚理想。

　　分析技术：

　　1、数据处理：自然语言处理技术(NLP)

　　2、统计和分析：A/B test、top N排行榜、地域占比、文本情感分析

　　3、数据挖掘：关联规则分析、分类、聚类

　　4、模型预测：预测模型、机器学习、建模仿真

　　存储：

　　1、结构化数据：海量数据的查询、统计、更新等操作效率低

　　2、非结构化数据：图片、视频、word、PDF、PPT等文件存储、不利于检索，查询和存储

　　3、半结构化数据：转换为结构化数据存储、按照非结构化存储

　　解决方案：

　　1、存储：HDFS、HBASE、Hive、MongoDB等

　　2、并行计算：MapReduce技术

　　3、流计算：twitter的storm和yahoo的S4

　　大数据与云计算：

　　1、云计算的模式是业务模式，本质是数据处理技术

　　2、数据是资产，云为数据资产提供存储、访问和计算

　　3、当前云计算更偏重海量存储和计算，以及提供的云服务，运行云应用。但是缺乏盘活数据资产的能力，挖掘价值性信息和预测性分析，为国家、企业、个人提供决策方案和服务，是大数据核心议题，也是云计算的最终方向。

      大数据平台架构：

　　我想这幅架构图，对大数据处理的人来说，应该不是很陌生。

　　IaaS:：基础设施即服务。基于 Internet 的服务(如存储和数据库)。

　　PaaS：平台即服务。提供了用户可以访问的完整或部分的应用程序。

　　SaaS：软件即服务。则提供了完整的可直接使用的应用程序，比如通过 Internet管理企业资源。

　　这里也不多涉及这方面的概念，在接下来的几篇文章中，会对下图中相关的部分(主要介绍PaaS模块中涉及的部分)以及上面提及的技术挑战和相关技术的介绍。

　　提纲：

　　数据采集：ETL

　　数据存储：关系数据库、NoSql、SQL等

　　数据管理：(基础架构支持)云存储、分布式文件系统

　　数据分析与挖掘：(结果展现)数据的可视化

　　本文章的目的，不是为了让大家对ETL的详细过程有彻底的了解。只需要知道，这是数据处理的第一步，一切的开端。

　　大数据技术之数据采集ETL：

　　这里不过多的说数据采集的过程，可以简单的理解：有数据库就会有数据。

　　这里我们更关注数据的ETL过程，而ETL前期的过程，只需要了解其基本范畴就OK。

     在数据挖掘的范畴了，数据清洗的前期过程，可简单的认为就是ETL的过程。ETL的发展过程伴随着数据挖掘至今，其相关技术也已非常成熟。这里我们也不过多的探讨ETL过程，日后如有涉及，在细分。

　　概念：

　　ETL(extract提取、transform转换、load加载)。ETL负责将分散的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后，进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘提供决策支持的数据。

　　ETL是构建数据仓库的重要的一环，用户从数据源抽取所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中。其定义域来源也不下于十几年，技术发展也应相当成熟。可乍眼一看，似乎并没有什么技术可言，也没有什么深奥之处，但在实际的项目中，却常常在这个环节上耗费太多的人力，而在后期的维护上，往往更费脑筋。导致上面的原因，往往是在项目初期没有正确的估计ETL的工作，没有认真的考虑其与工具支撑有很大的关系。

　　在做ETL产品选型的时候，任然必不可少的要面临四点(成本、人员经验、案例和技术支持)来考量。在做ETL的过程中，也随之产生于一些ETL工具，如Datastage、Powercenter、ETLAutomation。而在实际ETL工具应用的对比上，对元数据的支持、对数据质量的支持、维护的方便性、定制开发功能的支持等方面是我们选择的切入点。一个项目，从数据源到最终目标表，多则达上百个ETL过程，少则也十几个。这些过程之间的依赖关系、出错控制以及恢复的流程处理，都是工具需要重点考虑。这里不再多讨论，具体应用再具体说明。

　　过程如下：

　　在整个数据仓库的构建中，ETL工作占整个工作的50%-70%。下面有人给出团队之间的ETL过程是如何实现的。在面临耗费绝大时间的分析过程中，要求第一点就是：团队协作性要好。ETL包含E，T，L还有日志的控制，数据模型，原数据验证，数据质量等等方面。

　　例如我们要整合一个企业亚太区的数据，但是每个国家都有自己的数据源，有的是ERP，有的是Access，而且数据库都不一样，好要考虑网络的性能问题， 如果直接用ODBC去连接两地的数据源，这样的做法很显然是不合理的，因为网络不好，经常连接，很容易数据库链接不能释放导致死机。如果我们在各地区的服 务器放置一个数据导出为access或者flat file的程序，这样文件就比较方便的通过FTP的方式进行传输。

　　下面我们指出上述案例需要的几项工作：

　　1、有人写一个通用的数据导出工具，可以用java，可以用脚本，或其他的工具，总之要通用，可以通过不同的脚本文件来控制，使各地区的不同数据库导出的文件格式是一样的。而且还可以实现并行操作。

　　2、有人写FTP的程序，可以用bat，可以用ETL工具，可以用其他的方式，总之要准确，而且方便调用和控制。

　　3、有人设计数据模型，包括在1之后导出的结构，还有ODS和DWH中的表结构。

　　4、有人写SP，包括ETL中需要用到的SP还有日常维护系统的SP，比如检查数据质量之类的。

　　5、有人分析原数据，包括表结构，数据质量，空值还有业务逻辑。

　　6、有人负责开发流程，包括实现各种功能，还有日志的记录等等。

　　7、有人测试真正好的ETL，都是团队来完成的，一个人的力量是有限的。

　　其实上述的7步，再给我们强调的是什么：一个人，很难成事。团队至上。

　　这里我们简述ETL的过程：主要从E、T、L和异常处理简单的说明，这里不再细说明。如果用到，我想大家一定会有更深的调研。

　　1、 数据清洗如下：

　　·数据补缺：对空数据、缺失数据进行数据补缺操作，无法处理的做标记。

　　·数据替换：对无效数据进行数据的替换。

　　·格式规范化：将源数据抽取的数据格式转换成为便于进入仓库处理的目标数据格式。

　　·主外键约束：通过建立主外键约束，对非法数据进行数据替换或导出到错误文件重新处理。

　　2、 数据转换如下：

　　·数据合并：多用表关联实现，大小表关联用lookup，大大表相交用join(每个字段家索引，保证关联查询的效率)

　　·数据拆分：按一定规则进行数据拆分

　　·行列互换、排序/修改序号、去除重复记录

　　·数据验证：loolup、sum、count

　　实现方式：

　　·在ETL引擎中进行(SQL无法实现的)

　　·在数据库中进行(SQL可以实现的)

　　3、 数据加载

　　方式：

　　·时间戳方式：在业务表中统一添加字段作为时间戳，当OLAP系统更新修改业务数据时，同时修改时间戳字段值。

　　·日志表方式：在OLAP系统中添加日志表，业务数据发生变化时，更新维护日志表内容。

　　· 全表对比方式：抽取所有源数据，在更新目标表之前先根据主键和字段进行数据比对，有更新的进行update或insert。

　　·全表删除插入方式：删除目标表数据，将源数据全部插入。

　　大数据技术中，关于用户行为分析方面的有哪些技术?

　　做用户行为分析的基础是获得用户行为数据，例如用户页面停留时间、跳转来源等等。这些信息有些能直接拿到，有些是需要做一些计算才能拿到的。一般来说用户访问时的一些信息都是以日志的形式打到web容器的日志空间中去，这其中包含了最通用的一些访问信息以及一些自定义的日志打点。

　　题主提到了大数据技术中对用户行为进行分析，那么可以假定网站或者App的访问量是比较傲多的。由于系统流量比较大，计算维度又比较多，后续数据消费者的需求增长比较快，所以对计算分析平台有了一定的要求。具体表现为：

　　1.负载能力。流量增大以后带来的压力是多方面的，比如网络带宽的压力、计算复杂度带来的压力、存储上的压力等等。一般来说这些都是比较显而易见的，会对产生比较直接的影响，比如计算实时性下降、消息出现了堆积、OOM等等。为了解决这一现象，一般来说会选择一些分布式的框架来解决这个问题，比如引入分布式计算框架storm、spark，分布式文件系统hdfs等。

　　2.实时性。在系统资源捉襟见肘时消息的实时性会立即受到严重影响，这使得部分算法失效(例如对计算和收集上来的数据进行行为分析后，反馈到推荐系统上，当整体响应时间过场时会严重影响推荐效果和准确度)。对于这个情况来说可能会选择storm这种具有高实时性的分布式流式计算框架来完成任务。

　　3.系统管理和平台化相关技术手段。在大数据情景下，企业内数据环境和应用环境都是比较复杂的，用户行为分析应用不是一成不变的，那么就要求用户行为分析这种多变的应用在复杂环境中能有效生存，这包括算法数据材料的获得、系统运维、系统任务调度、系统资源调度等等，相关的技术很多时候要求团队自研，但也有ganglia、yarn、mesos这类开源系统可以参考或者直接使用。

　　4.数据链路。企业技术环境一般来说是非常复杂的，一层一层交错在一起，远不是一句MVC三层架构能够概括得了的，为了避免消息流通呈复杂的网状结构，一般会考虑应用服务化、企业服务总线(ESB)及消息总线来做传输，有兴趣的话题主可以百度一下这几个方向的技术和开源工具。

　　5.应用快速生成工具。我个人认为在大数据环境下应用都摆脱不了一个快速开发的要求，用户行为分析也是如此，这时候要考虑对接一些开源的分布式数据分析算法库而不是通过自己去实现，比如像spark ml，mahout这类的库用得好能减少很多工作量。

     异常处理

　　在ETL的过程中，必不可少的要面临数据异常的问题，处理办法：

　　1、将错误信息单独输出，继续执行ETL，错误数据修改后再单独加载。中断ETL，修改后重新执行ETL。原则：最大限度接收数据。

　　2、对于网络中断等外部原因造成的异常，设定尝试次数或尝试时间，超数或超时后，由外部人员手工干预。

　　3、 例如源数据结构改变、接口改变等异常状况，应进行同步后，在装载数据。

　　在这里涉及到ETL中，我们只要有一个清晰的认识，它不是想象中的简单一蹴而就，在实际的过程，你可以会遇到各种各样的问题，甚至是部门之间沟通的问题。在给它定义到占据整个数据挖掘或分析的过程中50%-70%是不足为过的。

　　后期项目如有涉及ETL过程，会细细讨论

     小结：相信最后大家阅读完毕后，收获不小吧？当然大家如果还想了解更多内容请登录课课家教育平台咨询~