最近一年多都在大数据处理和数据可视化上探索，最初是接触了一些hadoop的数据处理，现在开始继续专注老本行web前端。但是也是不脱离数据这一块，主要研究数据可视化的方向。
其实就前端来说，数据可视化的系统除了图表相关比如svg，canvas一系列的技术以外其实和很多的webapp都有共通之处，也都可以和其他的web项目一样采用相同的技术架构，具体可以看看我之前写的：《服务于数据可视化的WEB前端架构探索》。所以这次我来谈谈关于后端数据架构这块的思考，其实从技术上来讲我也不是这方面的专家，我更多会从一个产品和前端所需要的支持的一个角度来探讨，结合我一点大数据处理的皮毛来扯几句。
问题描述
首先我们分析下提供给数据可视化系统的大数据处理架构的目标需求是什么？理想情况下我认为应该是：
能够快速（秒级甚至毫秒级别）的按照任意条件，任意细分去获取任意指标。
对于传统的一些数据查询系统，这样的需求可以说很简单。构建一个数据库提供一个对数据库中表的query的http接口即可，和普通的web系统的查询接口一样。但是当数据变成大数据之后，各种问题就纷纷暴露出来了，每天几百G甚至几十T的数据要想支持这样的接口几乎是不可能的。那怎么办？其实我们的数据可视化系统并不需要任意这两个限定，比如说很少有这样的需求：查询2015年4月4号15点和2014年10月9号2点的用户xxxxxx的广告观看行为，虽然也不是完全排除不会有这样的需求，但是至少对于数据可视化系统中常规的数据分析模块是不会出现这样的需求的。所以我们可以简单的将大数据处理的目标需求分为两类：
- 常规数据处理。这类需求通常都是有一定的模式，不会对数据要求到太细的粒度，也是数据可视化系统中的主要需求部分。
- 非常规数据处理。这类需求就是上面所举例的那种，通常对数据粒度要求比较高，接近甚至就是需要最原始的数据。
解决方案思考
先说第一类，针对第一类我们可以将最开始的需求目标调整为：
能够快速（秒级甚至毫秒级别）的按照限定条件，限定细分去获取限定指标。
和原来的目标相差的就是将_任意_修改为_限定_。党需求不再是任意而是限定之后那么需要实际解决的问题就变为：将海量的数据按照不同的纬度reduce，整理为轻量的具有分析价值的数据输出。
举两个需求例子：
历年每个月份的总收入；热门资源在不同平台不同城市的利用情况。
针对第一个需求我们可以将数据在时间纬度上reduce最后产出月度的数据，每年12个月，这样下来最终的数据不管是放在任何数据库形成小的数据集中都能够轻易实现性能要求。针对第二个需求除了在时间纬度上reduce，还能够去除大部分非热门资源。这样最终构建的数据就不再是大数据了，自然就大事化小。
但是这样必然带来另一个问题：种类繁多的需求最终会导致小数据集膨胀，一系列数据集的维护（尤其是数据的一致性和准确性）管理和新的数据集的支持都会导致成本的大幅提升。
先把这个问题放一放，说一说第二类需求，关于第二类需求通常都是小众需求，所以完全可以将这一类需求调整为：
能够在一定时间内（几个小时甚至到几天）的按照任意条件，任意细分去获取任意指标。
关于这一类的需求主要就是将响应时间的要求放开，通常实际中都是以异步数据任务的形式来提供给需求方。它的要求主要集中在数据的完整性上，只要数据完整，时间要求并不高。除此之外还需要一套自动化的系统来处理这类数据任务的建立和运行管理。
架构设计
分析完上面拆解的两类需求之后，得到了一个数据处理框架的一些基础目标功能点：
- 具备一个基础的数据完整的基本数据仓库。
- 可以基于基础数据仓库按照不同的纬度reduce，构建出一系列小数据集。而且要有一套有效的框架使得能够便捷的去创建删除或者重跑这些小数据集，能够保证数据的一致性，准确性。
- 提供一套自动化的系统能够从基础数据仓库中创建异步任务获取指定数据。
至于技术上的具体实现，目前也只是在探索之中，基本上从如下两个方面解决：
- 将原始数据存放在类似hadoop这样的大数据平台上，尽可能的保证数据结构清晰，保证数据完整。
- 搭建一套任务管理系统，自动化构建并维护一系列的小数据集并存储到mysql这一类的传统高性能数据库中。
最后说点
其实本文并没有太多技术上的探讨，没有针对技术上的细节铺开叙述。目前大数据处理火得不行，大数据处理的基础框架是都有了，什么hadoop，spark等。但是在偏向应用层这一块有很多问题也有待解决，可能搞过数据业务，给客户出过数据，开发过数据可视化系统后端的同学可能会深有体会。