大数据平台的数据源
大数据平台是一个整体的生态系统，内容涵盖非常丰富，涉及到大数据处理过程的诸多技术。在这些技术中，除了一些最基础的平台框架之外，针对不同的需求场景，也有不同的技术选择。这其中，显然有共性与差异性的特征。若从整个开发生命周期的角度看，无论是需求、架构，还是开发、测试到最后的部署与运维，各种技术都会牵扯其中，不同的角色关注点自然也有不同。
大数据平台的核心功能
从大数据平台工程师的角度看，决定整个大数据平台关键质量的不外三方面：
- 数据采集
- 数据存储
- 数据处理
至于系统监控、资源协调、部署运维及其他管理功能都是大数据平台整个生态环境中不可缺少的拼图，但对于面向数据的架构，核心还是与数据打交道的一部分。如下图所示：
根据我在大数据项目中的经验，我发现，无论是数据采集、存储还是分析，在技术选型与方案设计上，似乎又与数据源的特征息息相关，甚至在某种程度上，可以认为是数据源的特点决定了整个大数据平台架构的设计。
数据源的特点
于是，我将关注点首要放在了数据源上。分析数据源的数据特征，我从四个不同的维度对数据源进行了分类：
来源
数据的来源不同，意味着我们对数据的掌控也就不同，更意味着我们对数据的访问机制也有所不同。
企业的内部数据通常与具体业务紧密相关，且多数来自我们可以掌控（或者通过兄弟团队）的软件系统，如CRM、ERP或者HR系统。从企业架构的角度考虑，我们本身就应该避免企业系统出现所谓的“烟囱系统”，规避“信息孤岛”。设计良好的系统应该提供相关的接口允许其他系统有限度地访问该系统的内部数据，又或者主动地将内部数据写入到一个完全解耦合的组件中。例如，一个常见的做法是将内部系统实时产生的输入写入到Kafka中。
通常，我们会尽量避免直接将内部系统的数据库公开给大数据平台。因为这种方式不仅会带来潜在的安全威胁，还可能会因为资源占用的缘故影响到业务系统。
外部数据的获取方式不外乎两种：
- API调用
- 通过网络爬虫抓取
与内部数据不同，外部数据不可能听指挥地“召之即来挥之即去”，我们需要定期或不定期地去获取数据，好处是我们可以根据业务场景和数据的特点自主地选择数据存储。
结构
只要了解过大数据项目，都知道数据结构直接影响了存储与处理技术的选择。RDB之于结构型数据，NoSQL之于非结构数据，这是司空见惯的配对了。相当而言，RDB的选择比较简单，NoSQL则有更复杂的分类。Pramod J·Sadalage与Martin Fowler在NoSQL Distilled一书中将NoSQL分为四类：
- 键值数据库
- 文档数据库
- 列族数据库
- 图数据库
针对不同结构类型的数据，我们可以借鉴这一分类作为选型的参考。
可变性
Datomic数据库的设计哲学是将所有过去发生的事情（或事件）认为是一个“fact（事实）”，基于事实不能篡改的本质，则数据库中存储的数据也当是不变的。无论是添加、删除还是修改，在数据库层面都是增加一条记录，而非直接更改。
然而，多数数据库并未添加这种不变性的约束，虽然这种不变性带来的好处是明显的，不过也会给业务系统的设计与实现带来不必要的复杂度。然而，作为大数据平台的数据源而言，情况则相反，若数据允许更改，数据采集过程就会变得更复杂。
一种简单的应对办法是采用直连的形式。由于数据分析可能会基于不同的数据场景对数据存储提出不同的要求，直连的数据源未必满足这种要求。例如，假设我们的分析场景是要做基于关键字的全文本搜索，在大数据量高性能的要求下，选择ElasticSearch或者Solr会表现更好，若直连的数据源是MySQL，事情就会变得较为棘手。
数据量
数据量小，则一切都可迎刃而解，这里不再赘述。
针对大数据量，实则是两个不同的场景。一种是批处理方式，典型地算法是MapReduce，主要针对非实时需求场景，我们可以编写定期以及批量执行的任务来完成数据的采集。需要费心的是对Job的监控、管理与调度。另一种则是流处理方式，（准）实时对产生的数据进行处理，这种场景对数据源的限制更多，最常见的方案就是将源源不断产生的数据写入到Kafka中。
在真实场景下，批处理与流处理方式可能共存。Lambda架构提出创新的三层架构方式，将此二者有机地融合起来，分别为：
- Batch Layer：针对批处理场景
- Speed Layer：针对流处理场景
- Serving Layer：由流处理场景提供实时数据模型，再对批处理的大数据进行预计算，从而提供批处理数据模型（聚合计算后），合并后提供给Serving Layer。
Lambda架构图如下所示：
OLAP分析平台druid就采用了Lambda架构。