最近在做一个数据图表化实时展示的系统，从构思到基本完成，虽遇到了无数的坑，但通过该项目的研发，让我对数据分析与建模有了更进一步的认识，更重要的是让我对之前自己的构思像接口聚合，僵尸应用的数据重组，核心价值信息的获取，数据模型分类的实现有了完整的实现方案。
为什么要进行数据分析
正规的项目开发，一般我们会先有需求，然后根绝用户需求进行需求评估，接着编写需求文档，最后根据已经规范化的需求文档，抽象分析，创建合适的关系型数据库表格（ER图原理）。也就是说常规的项目，数据都是在我们进行开发之前规范设计好的，后续的前后台都是按照已经规范好的数据模型进行数据通信。而数据分析则不然，之所以要分析，是因为数据源种类繁多，数据内容杂乱无章，这些数据之间可能有潜在的联系，但这种联系需要我们对已有的数据进行统计，分类，发掘，钻研，然后提取有价值的信息进行建模，最后根据具体的场景实现应用。所以数据分析区别于“需求建模”，前者是愚公移山，大海捞针的行为，我们是在大量的数据中找寻有价值有关联的信息，我们不是数据源，而是数据加工厂。而后者则不同，我们在直接设计数据诞生时的样子。所以理解数据分析首先要明白我们扮演的角色，以及为什么要进行分析。
如何提取有价值信息
前不久看过一篇文章说的是Docker这类容器化技术正在破坏像Hadoop这种老牌的大数据生态，个人感觉有点危言耸听，编程界没有取代关系，有的只是合适不合适，任何一门技术即便他是老掉牙的东西无论在任何时代也都有他存在的价值，鄙视链这种逻辑不应该出现在技术圈。好了回归主题，既然要进行数据分析，那么我们该如何从数据中找寻有价值的信息呢，没错Hadoop，有些不懂技术的人将Hadoop神化，其实在我来看他就是一个工具，了解其历史的大概就知道Hadoop的诞生离不开Google开源的GFS以及MapReduce，有人会说我们找寻有价值的数据为什么要用这个玩意呢，用我前面的话来说就是应用场景，数据分析往往面对的是海量的数据，而对这些数据的分析整合必须要有一个稳定的，安全的容器，面对这种情况Hadoop的HDFS（分布式文件系统类似硬件的虚拟化）便是“不二人选”。而构建廉价的用来处理大数据的服务器引擎的最佳方案便是服务器的集群化，应用的分布式部署，这样针对分布式运算的MapReduce便有了用武之地，MapReduce中的Map函数会根据输入生成若干组键值对，Reduce函数则以Map生成的键值对列表为输入，根据列表的键更改其对应的值，达到去重并减少数据总量的效果，在此基础之上配合Hadoop提供的接口和抽象类以及Java固有的逻辑运算接口，我们可以对数据进行更快速，更有效的分析处理。
数据分类与建模
数据的分类与建模我更想用面向对象的思想来解释，其实在业务分析项目构建的过程中针对不同的应用场景，我们早就具备了数据分类与建模的能力。举个简单的例子，比如在开发Web项目的过程中，我们通常会写若干没有业务逻辑的实体类，实体类通常会分为POJO,DTO,VO等等，其实项目实体类的构建过程就是数据分类建模的过程，二者的思想基本差不多。数据的分类建模一般是建立在对现有的数据有了充分认识之后才进行的，分类与建模往往是同步进行，互为关联，完成这一步往往需要对实际的应用开发有一定预期，我们可以根据实际的业务逻辑进行数据分类建模，也可以根据数据呈现方式进行有效数据的规范整理。分类建模的最终目的是整合有效数据，过滤无用信息，让数据根据业务场景实现有效组合，进而体现数据本身的价值。
发掘数据模型的联系
在我开发当前的数据实时展示系统的过程中，面临一个问题，就是如何实现数据的有效整合，领导给我的是若干个存储过程（数据库层的接口），而我需要的是找到这些数据的共性，并把不同的数据关联起来，比如我通过在线离心机的数量可以找出其实时产量，通过实时产量的进展情况可以提前对库房入库情况进行推演。发现数据模型之间联系的能力需要拥有一定水平的逻辑抽象能力，举个简单例子，现在流行的推荐算法，我们从用户的购买行为中根据特定商品信息进行数据发掘，可以找到针对特定用户的虚拟数据模型，例如百度的百度大脑，通过对用户搜索行为产生的数据进行统计分析，量化之后可以对不同年龄层，不同地区进行统计定位，生成针对不同地域，不同人群产品推广的有价值信息。模型的建立很重要，但只有真正找到数据模型之间的联系，找到打通模型数据与实际应用场景之间的钥匙，才算有意义的数据分析。相信不久的将来，在5G步入正轨，万物互联时代到来之后，我们定能对数据如金这句话有深刻的认识。