不知从什么时候开始，大数据这个词开始流行，似乎现在不谈点大数据，都不好意思说自己是搞IT的。当然这是玩笑之谈。但是我们确实生活在这样一个时代，特别是对于互联网公司而言，数据就是生命，如果不能从庞大繁杂的数据中发现价值将会失去很多机会。大数据是如何在互联网公司中发挥它强大的能力，似乎没有多少人谈，这里我就说下自己的一点看法和感受。
1，原始数据
何谓原始数据?直接由用户行为或状态而获取到的数据，就是我们的原始数据.
一般来说原始数据数量都非常巨大，而且比较杂乱且无模式(schema-less)，数据一般是以日志文件等方式存储，比如用户每次点击访问。
原始数据另外一个来源就是存储在传统关系型数据库中的用户数据，这些数据都是规整而易于使用，并且和上面相反，它们是有模式的(schema)。但是这里就引出了一个问题，这两种截然不同的数据如何结合起来?
初看，我们有两种思路可选。
第一，我们将无模式的数据通过程序进行某种处理，得到某种固定格式的数据，然后导出到传统的关系型数据库，然后再利用强大的SQL等方式进行数据分析处理。
第二，我们将关系型数据库的内容导出，然后利用hadoop之类的工具进行分析。
这两种方法都有一定局限性，第一种方法在数据量较小的时候可以用用，一旦数据量上去了，关系型数据库将不堪重负。第二种方法实施起来难度非常大，因为数据库本身每时每刻都是在变化的，换句话说，每次导出的数据，实际上是导出那一刻数据库的一个快照。为了实现持续的数据分析，就必须按时间在hadoop集群上维护大量的快照。
因此我们将两种方案结合起来使用。首先日志数据会经过一个简单的初步处理，过滤掉无效数据，然后直接采集到hadoop集群(淘宝现在用的采集工具是timetunnel，已在taocode上开源)，并利用hadoop的hive工具，对它们建立表结构以便可用用hiveql进行处理。
对于关系型数据库的数据，则利用一套特别的机制(如现在阿里云梯的数据生命周期)，实现存储空间上的最大优化，避免集群的快递膨胀。
这样一来，我们所有的数据都在hadoop集群上了。
2，数据分析
有了原始数据，我们就可以开始玩它们了。hadoop现在拥有很多高级的分析平台如hive。关于hive的使用，本文就不再赘述了。
说点别的，hive可以很方便的结合脚本语言，如我前两篇博文介绍的python，它们都是基于hadoop streaming技术。
当然，hive现在还是存在很多缺点和不足，例如很多sql的特性就不支持，调试也不好调试，出错了也令人一头雾水。相信随着hive版本的不断更新，会越来越完善。
这一节的重点不在于如何去分析数据，而是分析出来的结果如何使用。如果仅仅是给运营人员或者产品经理看看，那也便罢，简单的把结果拷贝到excel表格再稍修饰美化一下即可。
但是如果要实现自动化的数据分析并和产品无缝集成，那就是另外一个问题了。
一般来说，线上系统不能也不应该直接依赖hadoop这种离线数据处理工具。所以在hadoop集群上跑出来的数据，得再次导入到关系型数据库比如mysql;为了实现这种功能一般可以自行开发相应的程序，将结果以文件方式发送到运行该程序的服务器上，然后在服务器上读取并解析文件，利用JDBC写入数据库。淘宝自己也有一套工具即dataX，可直接在hadoop集群和数据库之间进行相互导出导入。
3，数据集成
仅仅将数据放在数据库是远远不够的;因为业务的发展是不断变化的，如果初期数据集成方面做得不够，一旦业务出现变化，整个数据系统都必须一起变动，开发周期会相应变得很长，可能在传统企业中这不是大问题，但是对于互联网公司，这是大忌。如果不能在变幻莫测的互联网浪潮中抓住机会，那么离被淘汰也不远了。
要做到数据系统高度可扩性是很困难的，它跟企业本身的业务特点紧密相关。但是有几个基本原则是不变的。
A：原始数据的处理尽量分而治之;例如不要用一个非常庞大的Hive程序+N多个复杂脚本+各种自定义UDF来实现。将其分成一个个的子任务 ，每个任务仅处理很小的一部分，然后最后再作一个数据合并。
B：存入数据库的数据是半成品。数据加工的次数越多，它本身的可扩展性越低，所以hadoop集群跑出来的数据，不应该是直接展示给用户的，这中间至少还需要一个二次处理，虽然看起来流程多了一个步骤，但是对于系统而言是大有好处。一方面增强了系统扩展性，另一方面可以利用传统数据库强大的数据分析能力(SQL能做的事情，我就不用说了，特别是主流数据库都拥有标准SQL之外的很多额外功能，更是如虎添翼)。
--EOF
本文出自 “Kevx's Blog” 博客
