python的性能分析工具line_profiler

浏览数：161 / 时间：2015年06月08日

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

核心技术

架构挑战：

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和异常处理简单的说明，这里不再细说明。如果用到，我想大家一定会有更深的调研。