可将数据系统简单理解为：数据系统＝数据＋查询

一、大数据处理系统

大数据解决方案通常涉及一个或多个以下类型的工作负荷：

• 静态大数据源的批处理。

• 移动中的大数据的实时处理。

• 大数据的交互式浏览。

• 预测分析和机器学习。

需要解决以下难题时，可以考虑使用大数据架构：

• 存储和处理对传统数据库而言数量太大的数据。

• 转换非结构化数据以进行分析和报告。

• 实时或者以较低的延迟捕获、处理和分析无限的数据流。

大数据处理系统面临挑战

• 1. 如何利用信息技术等手段处理非结构化和半结构化数据

• 2. 如何探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模

• 3. 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响

1.1 数据收集

大数据处理的第一步是数据的收集。现在的中大型项目通常采用微服务架构进行分布式部署，所以数据的采集需要在多台服务器上进行，且采集过程不能影响正常业务的开展。基于这种需求，就衍生了多种日志收集工具，如 Flume 、Logstash、Kibana 等，它们都能通过简单的配置完成复杂的数据收集和数据聚合。

1.2 数据存储

收集到数据后，下一个问题就是：数据该如何进行存储？通常大家最为熟知是 MySQL、Oracle 等传统的关系型数据库，它们的优点是能够快速存储结构化的数据，并支持随机访问。但大数据的数据结构通常是半结构化（如日志数据）、甚至是非结构化的（如视频、音频数据），为了解决海量半结构化和非结构化数据的存储，衍生了 Hadoop HDFS 、KFS、GFS 等分布式文件系统，它们都能够支持结构化、半结构和非结构化数据的存储，并可以通过增加机器进行横向扩展。

分布式文件系统完美地解决了海量数据存储的问题，但是一个优秀的数据存储系统需要同时考虑数据存储和访问两方面的问题，比如你希望能够对数据进行随机访问，这是传统的关系型数据库所擅长的，但却不是分布式文件系统所擅长的，那么有没有一种存储方案能够同时兼具分布式文件系统和关系型数据库的优点，基于这种需求，就产生了 HBase、MongoDB。

1.3 数据分析

大数据处理最重要的环节就是数据分析，数据分析通常分为两种：批处理和流处理。

• - 批处理：对一段时间内海量的离线数据进行统一的处理，对应的处理框架有 Hadoop MapReduce、Spark、Flink 等；

• - 流处理：对运动中的数据进行处理，即在接收数据的同时就对其进行处理，对应的处理框架有 Storm、Spark Streaming、Flink Streaming 等。

批处理和流处理各有其适用的场景，时间不敏感或者硬件资源有限，可以采用批处理；时间敏感和及时性要求高就可以采用流处理。随着服务器硬件的价格越来越低和大家对及时性的要求越来越高，流处理越来越普遍，如股票价格预测和电商运营数据分析等。

1.4 数据应用

数据分析完成后，接下来就是数据应用的范畴，这取决于你实际的业务需求。比如你可以将数据进行可视化展现，或者将数据用于优化你的推荐算法，这种运用现在很普遍，比如短视频个性化推荐、电商商品推荐、头条新闻推荐等。当然你也可以将数据用于训练你的机器学习模型，这些都属于其他领域的范畴，都有着对应的框架和技术栈进行处理，这里就不一一赘述。

二、大数据处理系统架构特征

2.1 鲁棒性和容错性(Robust and Fault-tolerant)

对大规模分布式系统来说，机器是不可靠的，可能会宕机，但是系统需要是健壮、行为正确的，即使是遇到机器错误。除了机器错误，人更可能会犯错误。在软件开发中难免会有一些Bug,系统必须对有Bug的程序写入的错误数据有足够的适应能力，所以比机器容错性更加重要的容错性是人为操作容错性。对于大规模的分布式系统来说，人和机器的错误每天都可能会发生，如何应对人和机器的错误，让系统能够从错误中快速恢复尤其重要。

2.2 低延迟读取和更新能力(Low Latency Reads and Updates)

许多应用程序要求数据系统拥有几毫秒到几百毫秒的低延迟读取和更新能力。有的应用程序允许几个小时的延迟更新，但是只要有低延迟读取与更新的需求，系统就应该在保证鲁棒性的前提下实现。

2.3 横向扩容（Scalable)

当数据量／负载增大时，可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展，通常采用scale out（通过增加机器的个数）而不是scale up（通过增强机器的性能）。

2.4 通用性(General)

系统需要支持绝大多数应用程序，包括金融领域、社交网络、电子商务数据分析等。

2.5 延展性(Extensible)

在新的功能需求出现时，系统需要能够将新功能添加到系统中。同时，系统的大规模迁移能力是设计者需要考虑的因素之一，这也是可延展性的体现。

2.6 即席查询能力(Allows Ad Hoc Queries)

用户在使用系统时，应当可以按照自己的要求进行即席查询(Ad Hoc)。这使用户可以通过系统多样化数据处理，产生更高的应用价值。

2.7 最少维护能力(Minimal Maintenance)

系统需要在大多数时间下保待平稳运行。使用机制简单的组件和算法让系统底层拥有低复杂度，是减少系统维护次数的重要途径。Marz认为大数据系统设计不能再基千传统架构的增量更新设计，要通过减少复杂性以减少发生错误的几率、避免繁矗操作。

2.8 可调试性(Debuggable)

系统在运行中产生的每一个值，需要有可用途径进行追踪，并且要能够明确这些值是如何产生的。

三、Lambda架构

这个超市有两个账房来统计销售额:

1.批处理账房:

就像晚上闭店后，会计们会仔细核对全天每一笔销售单据，把所有的数据加起来算总账，得出最准确的全天销售额、最受欢迎的商品等统计数据。

这个工作慢一些，但是结果很可靠，而且能处理大量的历史数据。

2.实时账房:

在白天营业时，为了快速反应市场变化，超市还雇了另外一帮人实时盯着收银机，每当有新交易发生，他们立刻就做简易的加法，估算出最新的销售额。

这个过程很快，虽然可能会有点误差，但它满足了实时查询的需求，比如想知道现在这个小时卖得最好的商品。

最后，为了让经理随时都能得到准确且最新的销售数据，还有一个

3.查询台:

·查询台会把晚上批处理账房得出的详尽结果和白天实时账房的即时估算结合起来，对外提供统一的数据服务。

·当经理问起某个商品今天的销售状况时，查询台既能告诉他截止到现在为止大概卖了多少(实时数据)，也能告诉他今天结束时经过仔细核算后的最终准确数字(批处理数据)。

所以，Lambda架构就是这样一个结合了“慢工出细活”的批处理能力和“快枪手”的实时处理能力，让大数据系统既可以做到高效地实时响应，又能保证长期数据处理的完整性和准确性。

Lambda架构用于同时处理离线和实时数据，可容错，可扩展的分布式系统，具备强鲁棒性，提供低延迟和持续更新。

Lambda架构分为三层：批处理层、加速层、服务层

批处理层核心功能：存储数据集和生成Batch View

主数据集中数据必须具备以下三个属性：数据是原始的、数据是不可变的、数据永远是真实的

Lambda架构优缺点：

优点：容错性好，查询灵活度高，易伸缩、易扩展

缺点：全场景覆盖带来的编码开销，针对具体场景重新离线训练一遍益处不大，重新部署和迁移成本很高

四、Kappa架构

不同于Lambda同时计算流计算和批计算并合并视图，Kappa只会通过流计算一条的数据链路计算并产生视图。Kappa同样采用了重新处理事件的原则，对千历史数据分析类的需求，Kappa要求数据的长期存储能够以有序日志流的方式重新流入流计算引擎，重新产生历史数据的视图。本质上是通过改进Lambda架构中的Speed Layer,使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。

Kappa架构原理：在Lambda的基础上进行了优化，删除了Batch Layer的架构，将数据通道以消息队列进行替代。因此对千Kappa架构来说，依旧以流处理为主，但是数据却在数据湖层面进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可

输入数据直接由实时层的实时数据处理引擎对源源不断的源数据进行处理，再由服务层的服务后端进一步处理以提供上层的业务查询。而中间结果的数据都是需要存储的，这些数据包括历史数据与结果数据，统一存储在存储介质中。

五、Lambda架构和Kappa架构对比

从使用场景看，Kappa架构与Lambda架构的两点主要区别：

Kappa 不是Lambda的替代架构，是其简化版本，Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求，例如各种时序数据场景，天然存在时间窗口的概念，流式计算直接满足其实时计算和历史补偿任务需求

Lambda直接支持批处理，更适合对历史数据分析查询的场景，比如数据分析师需要按任意条件组合对历史数据进行探索性的分析，并且有一定的实时性需求，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求

Lambda架构的优势在于能够同时满足实时处理和批量处理的需求，对于需要高性能批处理（如大数据分析、离线计算）以及对实时性有一定要求的场景（如实时监控、实时预警），Lambda架构能够提供很好的支持。尤其在处理大规模历史数据方面，批处理层通常拥有更好的性能和扩展性。

Kappa架构通过单一流处理模型，大大简化了系统设计和运维，理论上能够在资源利用率和实时性上有更好的表现。Kappa架构下的流处理系统如果设计得当，能够实现实时数据的高效处理，并且在业务逻辑发生变化时，通过重放事件流就能快速获得更新后的结果，具有较高的灵活性。

在实际应用中，选择哪种架构取决于具体业务场景和需求。如果业务需求主要是实时性较强并且对历史数据重处理的需求相对较少，Kappa架构可能会有更好的性能表现。相反，如果业务中有大量复杂的批处理需求和频繁的历史数据重算，Lambda架构可能更为合适。

大数据架构的组件

下图显示了组成大数据架构的逻辑组件。单个解决方案可能不会包含此图中的每个项目。