谈大数据-架构维度

本篇作为在构思大数据平台架构时候维度方面的简单点滴思考记录。

前面关于大数据平台架构的核心功能的时候谈到过，基本应该包括数据采集和集成，数据存储，数据处理，数据分析这些核心层面。我在前面谈大数据平台的时候也谈到过平台不仅仅是云和分布式相关技术的引入，其架构一方面和传统的BI相似，但是更加重要的则是对外部应用涉及到大数据的应用场景的支撑和大数据平台本身的大数据服务能力的开放问题。

最近我一直在看各大厂商的一些大数据解决方案和平台架构，发现比较大的一个问题点还是在于原有的大数据平台更多的是各个已有的产品的简单整合，原来的各个子产品本身也是针对实际的业务应用场景逐渐演变出来的，能够实际的解决业务问题，但是这种整合最大的问题就是各个产品基本都覆盖了前面将了大数据从采集和分析的多个层次，导致能力重复。

我们先看传统的由BI产品架构演化的大数据平台能力，其数据采集清理转换通过ETL工具支持，ETL本身也支撑类似excel式的文件的适配和结构化转换。其数据存储层则是标准的关系型数据库，数据分析层则根据实际的维度分析需要建立数据仓库单独建模，数据分析层可以是传统的关系型数据库，也有现在的基于MPP架构的列式压缩数据库等。在整个演化的过程中增加了类似hadoop的mapreduce的并行处理能力，加入了更多的对noSQL数据库的支持等。以解决数据规模和实时数据查询的问题。

对于基于Hive架构的数据分析工具，我们看到其基本有完善的一套数据采集，数据存储，数据处理和数据分析的框架。如数据采集引入了flume采集工具加强对非结构化文件和流数据采集，对于数据存储可使用mysql存储元数据，hbase存储实际业务数据，基于mapreduce实现并行处理，同时增加了hql语言实现常用的数据分析查询，基本又是完整的一套。

前段时间看实时流处理引擎，包括storm或s4等，又可以看到基本又是独立的一套，有自己的流数据采集和适配，有类似于mapreduce的并行处理能力和引擎，有自己的分布式集群拓展方式，完成对流数据的端到端管理。整个流处理引擎来说相对独成体系，感觉又很难和其它产品进行很好的融合。

根据上面谈到，在构建大数据平台的时候可以考虑两个核心的架构维度。一个就是横向的分层架构，即包括数据采集和集成，数据存储，数据处理，数据分析；一个就是纵向的子产品类维度，包括传统的BI，Hive类数据分析产品，实时流处理等。实际上我更加希望的是前面一种横向分层的架构维度，以实现各层能力的充分共享问题，在采用这种方式的时候就需要对已有的各个子产品的各层能力完全分层剥离，然后再根据纵向业务需求和应用场景的需求进行整合，这本身是否可行也需要进一步论证。

在整个过程中我们可以首先考虑的就是数据采集和适配的剥离，mapreduce并行处理框架和算法包能力的剥离，数据任务监控和调度的剥离，数据集成的剥离，共享数据能力层的构建；然后再来考虑进一步的能力组装和整合。否则很可能我们拿出来的大数据平台仅仅是各个子产品功能的堆砌，相当来说还是一盘散沙，无法整合。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密