0. 前言

大数据技术发展到今天为止，各种技术组件层出不穷，有的【昙花一现】，有的则【基业长青】，有的【风光一时】，而有的则【日渐衰落】。其根本原因无外乎3点：生态是否健全、功能是否好用、跟其他组件是否适配。

任何一个大数据系统的功能都是紧紧围绕：把原始数据进行分析、挖掘，最后得到我们想要的结果。

我们把这个需求进行关键字拆解，就是：【原始数据】、【分析挖掘】、【计算结果】这3个部分。那需求对应的是3个部分，那我们的系统功能是不是也应该对应3大部分呢？答案是肯定的。

因此，一个完整的大数据系统也必须紧紧围绕：【如何获取原始数据？】、【如何分析挖掘？】、和【如何安置处理结果？】这3个模块来展开。

1. 如何获取原始数据？

这是一个大数据系统应该解决的第一步，如何把数据源的数据引入到大数据平台，也叫：【数据接入】。

数据接入需要两个步骤：第一步就是【接】；第二步则是【入】。

1.1 如何理解【接】？

一般而言，数据源跟大数据系统分属两个完全不同的系统，有着不同的技术栈和管理方式。数据源一般属于业务系统，比如线上支付、线上购物、日志收集系统等，需要把这些系统中产生的数据给【接】到大数据处理系统中。

如何【接】？考虑到数据源安全、产生频率、接入数据量大小等因素，接入方式又可以分为【推】和【拉】两种。

推：主动权在数据源端，可能处于安全需要，大数据系统不能直接访问数据源，数据源会以对自己业务友好的方式进行数据推送到大数据系统；

拉：主动权在大数据系统端，以大数据系统的数据处理频率、数据处理量为中心，以一种对大数据系统端友好的方式对数据源进行拉取；

1.2 如何理解【入】？

既然把数据通过【推】或者【拉】的方式【接】到大数据系统了，那么接下来就是考虑如何【入】这些数据了，即如何把接进来的数据给【存】起来？也叫数据落地。

对于如何【落地】，我们通常的指导思想无外乎3种：1，文件系统；2，消息队列；3，数据库；

什么时候用文件系统？

文件系统是最简单的数据落地手段，特点是：离线、简单、无schema、IO效率高。

因为存储时是以文件为单位，因此在后续数据计算处理时，也必须以文件为单位来进行，数据处理粒度相对受限，并且在每次数据处理时，需要处理程序主动识别当前应该处理哪些文件，以及忽略哪些文件。

一般常用的文件系统有：本地磁盘、分布式文件系统HDFS、S3、NFS等等。

什么时候用消息队列？

既然文件系统代表了【离线】，那消息队列就是【在线、实时】的代名词。如果一个大数据系统相要实现【实时】处理数据，那消息队列绝对是个少不了的工具。

其特点是：实时、相对简单、7x24小时不间断、流式处理、IO效率高。数据可以通过【主题】进行业务归类，并且每一条数据在写入消息队列后会给予编号（offset）。因此在后续数据计算处理时，可以根据业务需要选择特定的【主题】和offset，数据处理粒度很细。

一般常用的消息队列有：kafka、rabbitmq、rocketmq等等。

什么时候用数据库？

相比文件系统和消息队列，数据落地到数据库是最为麻烦的方式。因为任何数据想要存到数据库，就必须要提前建表，确定好数据的schema、key(主键)、索引字段等等。

其特点是：离线、步骤繁琐、含schema、IO效率偏低。数据选择落地到数据库最大的一个原因在于可以提前分配schema，这样最大的好处在于，后续数据计算处理时，只需要提取业务所需的字段，或者利用SQL只筛选业务需要的数据进行处理即可，减少了数据计算过程中无关字段带来的额外内存压力。

一般常用的数据库有：MySQL、PostreSQL、Hive、MongoDB等。

2. 如何分析挖掘？

在大数据系统里，有个专门的技术组件叫【计算引擎】，它区别于传统数据库的计算引擎(传统数据库的计算引擎无法独立于数据库单独使用)，是一个独立的软件系统，不依赖其他任何的存储系统而存在，可以单独使用。

我认为，【计算引擎】是大数据技术中最为伟大的发明之一，有了它，可以将原本必须杂糅在一起的数据处理步骤进行解耦，大大增强了一个数据系统的可用性。

因为独立，且提供了非常丰富和实用的脚手架方法、接口，可以适配市面上几乎所有的算法和计算模型。并且，因为开源生态的活跃，计算引擎既能兼容市面上主流的数据接入工具，又可以兼容主流的数据存储组件。

常用的计算引擎有：MapReduce、Tez、Storm、Spark、Flink等。

3. 如何安置数据处理结果？

作为计算引擎计算处理后的结果，通常的做法就是给存起来。

说到存储，其实思路跟第1步中如何将数据源【落地】是一样的，只不过目标不太一样。

计算引擎计算处理后的结果数据，一般其用途有2：

1. 作为最终结果输出，展示；
2. 作为下一个业务计算的数据输入；

3.1 结果用于展示

最常见的做法就是将其存入到数据库中，因为是展示，因此必须要考虑数据获取的及时性。如果让想看到数据的人等待很长时间，这将是一个非常糟糕的体验。

因此，选择一个适合的数据库就显得尤为重要，数据库之所以区别于一般的文件系统，根本原因在于它可以提供【基于业务需求的数据结构】，能按照业务需要的方式进行数据存储，通过高效的索引机制来满足数据快速被读取的目的。

常用的数据库有：MySQL、HBASE、Elasticsearch、Redis等。

3.2 结果用于另一个计算的输入

在有些情况下，通过计算引擎计算的结果可能还不能直接作为结果进行展示，它仅仅只是给另一个业务场景的计算提供了数据源。

这个时候，需要将其作为数据源写入到数据接入系统中，这就回到1.2中讨论的内容。

4. 总结

这篇文章讨论了一个大数据系统应该包含的3个核心模块：数据接入、数据计算、结果存储。

这是任何一个大数据系统都应该遵守的规范，也是任何一个大数据系统必须具备的最小功能。之所以说【最小】，因为随着业务的拓展，数据量的激增，系统承载的使命只会越来越重，要处理的数据任务也会越来越多，那么毫无疑问，系统的复杂度也一定会随之增加。

比如，数据源的多样性导致的数据接入方式可能有多种；为了满足业务场景需要，用于数据计算的计算引擎可能采用多个(离线+实时)；为了加速计算结果的读取效率，加入中间缓存层，采用数据的冷热分离等手段。

但不管系统的复杂度如何变化，最终都是围绕以上3大模块进行展开和延伸...

（PS：可能有人会说，一个完整的大数据系统不应该包括数据展示吗？确实应该有，但是因为跟大数据技术关系不大，所以这里暂不做讨论）