0 概论

1. 数据采集和传输层

• Flume
  Flume一个分布式、可靠的、高可用的用于数据采集、聚合和传输的系统。常用于日志采集系统中，支持定制各类数据发送方用于收集数据、通过自定义拦截器对数据进行简单的预处理并传输到各种数据接收方如HDFS、HBase、Kafka中。之前由Cloudera开发，后纳入Apache
• Logstash
  ELK工作栈的一员，也常用于数据采集，是开源的服务器端数据处理管道
• Sqoop
  Sqoop主要通过一组命令进行数据导入导出的工具，底层引擎依赖于MapReduce，主要用于Hadoop（如HDFS、Hive、HBase）和RDBMS（如mysql、oracle）之间的数据导入导出
• Kafka
  分布式消息系统。生产者（producer）——消费者（consumer）模型。提供了类似于JMS的特性，但设计上完全不同，不遵循JMS规范。如kafka允许多个消费者主动拉取数据，而JMS中只有点对点模式消费者才会主动拉取数据。主要应用在数据缓冲、异步通信、汇集数据、系统接偶等方面
• Pulsar
  pub-sub模式的分布式消息平台，拥有灵活的消息模型和直观的客户端API。类似于Kafka，但Pulsar支持多租户，有着资产和命名空间的概念，资产代表系统里的租户。假设有一个Pulsar集群用于支持多个应用程序，集群里的每个资产可以代表一个组织的团队、一个核心的功能或一个产品线。一个资产可以包含多个命名空间，一个命名空间可以包含任意个主题

2. 数据存储层

• HBase
  基于Google Bigtable的开源实现，是一个具有高可靠性、高性能、面向列、可伸缩性、典型的key/value分布式存储的nosql数据库系统，主要用于海量结构化和半结构化数据存储。它介于nosql和RDBMS之间，仅能通过行键（row key）和行键的range来检索数据，行数据存储是原子性的，仅支持单行事务（可通过hive支持来实现多表join等复杂操作）。HBase查询数据功能很简单，不支持join等复杂操作，不支持跨行和跨表事务
• Kudu
  介于HDFS和HBase之间的基于列式存储的分布式数据库。兼具了HBase的实时性、HDFS的高吞吐，以及传统数据库的sql支持
• HDFS
  分布式文件存储系统，具有高容错（high fault-tolerant）、高吞吐（high throughput）、高可用（high available）的特性。HDFS非常适合大规模数据集上的应用，提供高吞吐量的数据访问，可部署在廉价的机器上。它放宽了POSIX的要求，这样可以实现流的形式访问（文件系统中的数据。主要为各类分布式计算框架如Spark、MapReduce等提供海量数据存储服务，同时HDFS和HBase底层数据存储也依赖于HDFS

3. 数据分析层

• Spark
  Spark是一个快速、通用、可扩展、可容错的、内存迭代式计算的大数据分析引擎。目前生态体系主要包括用于批数据处理的SparkRDD、SparkSQL，用于流数据处理的SparkStreaming、Structured-Streaming，用于机器学习的Spark MLLib，用于图计算的Graphx以及用于统计分析的SparkR，支持Java、Scala、Python、R多种数据语言
• Flink
  分布式的大数据处理引擎，可以对有限数据流和无线数据流进行有状态的计算。Flink在设计之初就是以流为基础发展的，然后再进入批处理领域，相对于spark而言，它是一个真正意义上的实时计算引擎
• Storm
  由Twitter开源后归于Apache管理的分布式实时计算系统。Storm是一个没有批处理能力的数据流处理计算引擎，storm提供了偏底层的API，用户需要自己实现很多复杂的逻辑。
• MapReduce
  分布式运算程序的编程框架，适用于离线数据处理场景，内部处理流程主要划分map和reduce两个阶段
• Hive
  Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供HQL语句（类SQL语言）查询功能，存储依赖于HDFS。支持多种计算引擎，如Spark、MapReduce（默认）、Tez；支持多种存储格式，如TextFile、SequenceFile、RCFile、ORC、Parquet（常用）；支持多种压缩格式，如gzip、lzo、snappy（常用）、bzip2
• Tez
  支持DAG作业的开源计算框架。相对于MapReduce性能更好，主要原因在于其将作业描述为DAG（有向无环图），这一点与Spark类似
• Pig
  基于Hadoop的大规模数据分析平台，它包含了一种名为Pig Latin的脚本语言来描述数据流，并行地执行数据流处理的引擎，为复杂的海量数据并行计算提供了一个简单的操作和编程接口。Pig Latin本身提供了许多传统的数据操作，同时允许用户自己开发一些自定义函数用来读取、处理和写数据，该语言的编译器会把类SQL的数据分析请求转换为一系列经过优化处理的MapReduce运算
• Mahout
  提供一些可扩展的机器学习领域经典算法的实现，Mahout包含许多实现，包括聚类、分类、推荐过滤、频繁子项挖掘。通过使用Apache Hadoop 库，可以将Mahout扩展到云中
• Phoenix
  构建在HBase之上的一个SQL层，能让我们通过标准的JDBC API操作HBase中的数据。Phoenix完全使用Java编写，作为HBase内嵌的JDBC驱动。Phoenix查询引擎会将SQL查询转换为一个或多个HBase scan，并编排执行以生成标准JDBC结果集

4. OLAP引擎

• Druid
  开源的、基于列存储的、分布式的，适用于实时数据分析的存储系统，能够快速聚合、灵活过滤、毫秒级查询和低延迟数据导入。通过使用Bitmap indexing加速列存储的查询速度，并使用CONCISE算法来对bitmap indexing进行压缩，使得生成的segments比原始文本文件小很多，并且它的各个组成部分之间耦合性低，如果不需要实时数据完全可以忽略实时节点
• Kylin
  最初由eBayInc.开发并贡献至开源社区的分布式分析引擎。提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，它能在亚秒内查询巨大的Hive表。需要使用者对数仓模型有深度了解，并需构建cube。能够与多种可视化工具，如Tableau，PowerBI等，令用户可以使用BI工具对Hadoop数据进行分析
• Impala提供对HDFS、HBase等数据的高性能、低延迟的交互式SQL查询功能的大数据查询分析引擎，由Cloudera开源。它基于Hive，使用Hive的元数据在内存中计算，具有实时、批处理、高并发等优点
• Presto
  开源的分布式大数据SQL查询引擎，适用于交互式分析查询。可以将多个数据源的数据进行合并，并且可以直接从HDFS读取数据，在使用前不需要大量的ETL操作

5. 资源管理层

• Yarn
  Yarn是一个资源调度平台，负责为运算程序分配资源和调度，不参与用户程序内部工作。核心组件包括：ResourceManager（全局资源管理器，负责整个系统的资源管理和分配）、NodeManager（每个节点上的资源和任务管理器）
• Kubernetes
  又称K8s，为容器化的应用提供资源调度、部署运行、均衡容灾、服务注册、扩容缩容等功能的自动化容器操作的开源平台。具体体现在：自动化容器的部署和复制、随时扩展或收缩容器规模、将容器组织成组，并且提供容器间的负载均衡等。Kubernetes支持docker和Rocket，可以将Docker看成Kubernetes内部使用的低级别组件
• Mesos
  类似于Yarn，也是一个分布式资源管理平台，为MPI、Spark作业在统一资源管理环境下运行。它对Hadoop2.0支持很好，但国内用的不多

6. 工作流调度器

• Oozie
  基于工作流引擎的任务调度框架，能够提供能够提供对MapReduce和Pig 任务的调度与协调
• Azkaban
  由LinkedIn开源，相对Oozie更轻量级。用于在一个工作流内以一个特定顺序运行一组任务，通过一种kv文件格式来建立任务之间的依赖关系并为用户提供了易于使用的web界面来维护和跟踪允许任务的工作流

7. 其他

• Ambari
  基于web的安装部署工具，支持对大多数的Hadoop组件，如HDFS、MapReduce、Hive、Pig、HBase等的管理和监控
• Zookeeper
  分布式协调服务即为用户的分布式应用程序提供协调服务，如主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁等，它本身也是一个分布式程序（部署奇数台，只要由半数以上zookeeper节点存活，zookeeper集群就能正常提供服务），它是Google Chubby一个开源实现

如今，有许多可用的开源流框架。有趣的是，几乎所有它们都是相当新的，仅在最近几年才开发出来。因此，对于新手来说，很容易混淆流框架之间的理解和区分。在本文中，我将首先大致讨论流处理的类型和方面，然后比较最受欢迎的开源流框架：Flink，SparkStreaming，Storm，KafkaStream。我将尝试（简要地）解释它们的工作原理，它们的用例，优势，局限性，异同。
什么是流/流处理：
流处理的最优雅的定义是：一种数据处理引擎，其设计时考虑了无限的数据集。
与批处理不同，批处理以工作中的开始和结束为界，而工作是在处理有限数据之后完成的，而流处理则是指连续不断地处理天，月，年和永久到来的无边界数据。因此，流媒体应用程序始终需要启动和运行，因此难以实现且难以维护。
流处理的重要方面：
为了理解任何Streaming框架的优点和局限性，我们应该了解与Stream处理相关的一些重要特征和术语：
交付保证：这意味着无论如何，流引擎中的特定传入记录都将得到处理的保证。可以是at least once（至少一次）（即使发生故障也至少处理一次），at most once : 至多一次（如果发生故障则可能不处理）或Exactly-once（即使失败在这种情况下也只能处理一次））。显然，只处理一次是最好的，但是很难在分布式系统中实现，并且需要权衡性能。容错：如果发生诸如节点故障，网络故障等故障，框架应该能够恢复，并且应该从其离开的位置开始重新处理。这是通过不时检查流向某些持久性存储的状态来实现的。例如，从Kafka获取记录并对其进行处理后，将Kafka检查点偏移给Zookeeper。状态管理：在有状态处理需求的情况下，我们需要保持某种状态（例如，记录中每个不重复单词的计数），框架应该能够提供某种机制来保存和更新状态信息。性能：这包括延迟（可以多久处理一条记录），吞吐量（每秒处理的记录数）和可伸缩性。延迟应尽可能小，而吞吐量应尽可能大。很难同时获得两者。高级功能：事件时间处理，水印，窗口化如果流处理要求很复杂，这些是必需的功能。例如，根据在源中生成记录的时间来处理记录（事件时间处理）。成熟度：从采用的角度来看很重要，如果框架已经过大公司的验证和大规模测试，那就太好了。更有可能获得良好的社区支持并在堆栈溢出方面提供帮助。流处理的两种类型：
现在了解了我们刚刚讨论的术语，现在很容易理解，有两种方法可以实现Streaming框架：
原生流处理：这意味着每条到达的记录都会在到达后立即处理，而无需等待其他记录。有一些连续运行的过程（根据框架，我们称之为操作员/任务/螺栓），这些过程将永远运行，每条记录都将通过这些过程进行处理。示例：Storm，Flink，Kafka Streams，Samza。
微批处理：也称为快速批处理。这意味着每隔几秒钟就会将传入的记录分批处理，然后以单个小批处理的方式处理，延迟几秒钟。例如：Spark Streaming, Storm-Trident。
两种方法都有其优点和缺点。原生流传输感觉很自然，因为每条记录都会在到达记录后立即进行处理，从而使框架能够实现最小的延迟。但这也意味着在不影响吞吐量的情况下很难实现容错，因为对于每条记录，我们都需要在处理后跟踪和检查点。而且，状态管理很容易，因为有长时间运行的进程可以轻松维护所需的状态。
另一方面，微批处理则完全相反。容错是免费提供的，因为它本质上是一个批处理，吞吐量也很高，因为处理和检查点将在一组记录中一次性完成。但这会花费一定的等待时间，并且感觉不自然。高效的状态管理也将是维持的挑战。
流框架对比：
Storm :

Strom是一个老牌的实时数据处理框架，在Spark Streaming流行前，Storm统治者整个流式计算的江湖。

更详细的说，Storm是一个实时数据处理框架，具有低延迟/高可用/易扩展/数据不丢失等特点，同时，Storm还提供流类似与MapReduce的简单编程模型，便于开发

Storm是流处理世界的强者。它是最古老的开源流框架，也是最成熟和可靠的框架之一。这是真正的流传输，适合基于简单事件的用例。
优点：
极低的延迟，真正的流，成熟和高吞吐量非常适合简单的流媒体用例缺点
没有状态管理没有高级功能，例如事件时间处理，聚合，开窗，会话，水印等一次保证Spark Streaming :
Spark已成为批处理中hadoop的真正继任者，并且是第一个完全支持Lambda架构的框架（在该框架中，实现了批处理和流传输；实现了正确性的批处理；实现了流传输的速度）。它非常受欢迎，成熟并被广泛采用。Spark Streaming是随Spark免费提供的，它使用微批处理进行流媒体处理。在2.0版本之前，Spark Streaming有一些严重的性能限制，但是在新版本2.0+中，它被称为结构化流，并具有许多良好的功能，例如自定义内存管理（类似flink），水印，事件时间处理支持等。另外，结构化流媒体更加抽象，在2.3.0版本以后，可以选择在微批量和连续流媒体模式之间进行切换。连续流模式有望带来像Storm和Flink这样的子延迟，但是它仍处于起步阶段，操作上有很多限制。
优点：
支持Lambda架构，Spark免费提供高吞吐量，适用于不需要亚延迟的许多使用情况由于微批量性质，默认情况下具有容错能力简单易用的高级API庞大的社区和积极的改进恰好一次缺点
不是真正的流，不适合低延迟要求要调整的参数太多。很难做到正确。天生无国籍在许多高级功能方面落后于FlinkFlink :
Flink也来自类似Spark这样的学术背景。Spark来自加州大学伯克利分校，而Flink来自柏林工业大学。像Spark一样，它也支持Lambda架构。但是实现与Spark完全相反。虽然Spark本质上是一个批处理，其中Spark流是微批处理，并且是Spark Batch的特例，但Flink本质上是一个真正的流引擎，将批处理视为带边界数据流的特例。尽管这两个框架中的API都是相似的，但是它们在实现上没有任何相似性。在Flink中，诸如map，filter，reduce等的每个函数都实现为长时间运行的运算符（类似于Storm中的Bolt）
Flink看起来像是Storm的真正继承者，就像Spark批量继承了hadoop一样。
优点：
开源流媒体领域创新的领导者具有所有高级功能（例如事件时间处理，水印等）的第一个True流框架低延迟，高吞吐量，可根据要求进行配置自动调整，无需调整太多参数恰好一次被Uber，阿里巴巴等大型公司广泛接受。缺点
起步较晚，最初缺乏采用社区不如Spark大，但现在正在快速发展Kafka Streams :
与其他流框架不同，Kafka Streams是一个轻量级的库。对于从Kafka流式传输数据，进行转换然后发送回kafka很有用。我们可以将其理解为类似于Java Executor服务线程池的库，但具有对Kafka的内置支持。它可以与任何应用程序很好地集成，并且可以立即使用。
由于其重量轻的特性，可用于微服务类型的体系结构。Flink在性能方面没有匹配之处，而且不需要运行单独的集群，非常方便并且易于部署和开始工作。
Kafka Streams的一个主要优点是它的处理是完全精确的端到端。可能是因为来源和目的地均为Kafka以及从2017年6月左右发布的Kafka 0.11版本开始，仅支持一次。要启用此功能，我们只需要启用一个标志即可使用。
优点：
重量很轻的库，适合微服务，IOT应用不需要专用集群继承卡夫卡的所有优良特性支持流连接，内部使用rocksDb维护状态。恰好一次（从Kafka 0.11开始）。缺点
与卡夫卡紧密结合，在没有卡夫卡的情况下无法使用婴儿期还很新，尚待大公司测试不适用于繁重的工作，例如Spark Streaming，Flink。Samza :
简短介绍一下Samza。（Samza）看上去就像是（Kafka Streams）。有很多相似之处。这两个框架都是由同一位开发人员开发的，这些开发人员在LinkedIn上实现了Samza，然后在他们创建Kafka Streams的地方成立了Confluent。这两种技术都与Kafka紧密结合，从Kafka获取原始数据，然后将处理后的数据放回Kafka。使用相同的Kafka Log哲学。Samza是Kafka Streams的缩放版本。Kafka Streams是一个用于微服务的库，而Samza是在Yarn上运行的完整框架集群处理。优点 ：
使用rocksDb和kafka日志可以很好地维护大量信息状态（适合于连接流的用例）。使用Kafka属性的容错和高性能如果已在处理管道中使用Yarn和Kafka，则要考虑的选项之一。低延迟，高吞吐量，成熟并经过大规模测试缺点：
与Kafka和Yarn紧密结合。如果这些都不在您的处理管道中，则不容易使用。至少一次加工保证。我不确定它是否像Kafka 0.11之后的Kafka Streams现在完全支持一次缺少高级流功能，例如水印，会话，触发器等流框架比较：
我们只能将技术与类似产品进行比较。尽管Storm，Kafka Streams和Samza现在对于更简单的用例很有用，但具有最新功能的重量级产品之间的真正竞争显而易见：Spark vs Flink
当我们谈论比较时，我们通常会问：给我看数字
基准测试是仅当第三方进行比较时比较的好方法。
例如，但这是在Spark Streaming 2.0之前的某个时期，当时它受RDD的限制。现在，随着Structured Streaming 2.0版本的发布，Spark Streaming试图赶上很多潮流，而且似乎还会面临艰巨的挑战。
最近，基准测试已成为Spark和Flink之间的一场激烈争吵。
最好不要相信这些天的基准测试，因为即使很小的调整也可以完全改变数字。没有什么比决定之前尝试和测试自己更好。到目前为止，很明显，Flink在流分析领域处于领先地位，它具有大多数所需的方面，例如精确一次，吞吐量，延迟，状态管理，容错，高级功能等。
Flink的一个重要问题是成熟度和采用水平，直到一段时间之前，但是现在像Uber，Alibaba，CapitalOne这样的公司正在大规模使用Flink流传输，证明了Flink Streaming的潜力。
最近，Uber开源了其最新的流分析框架AthenaX，该框架基于Flink引擎构建。
如果您已经注意到，需要注意的重要一点是，所有支持状态管理的原生流框架（例如Flink，Kafka Streams，Samza）在内部都使用RocksDb。RocksDb从某种意义上说是独一无二的，它在每个节点上本地保持持久状态，并且性能很高。它已成为新流系统的关键部分。
如何选择最佳的流媒体框架：
这是最重要的部分。诚实的答案是：这取决于:
必须牢记，对于每个用例，没有一个单一的处理框架可以成为万灵丹。每个框架都有其优点和局限性。尽管如此，根据一些经验，他们仍然会分享一些有助于做出决定的建议：
取决于用例：如果用例很简单，那么如果学习和实现起来很复杂，则无需寻求最新，最好的框架。在很大程度上取决于我们愿意投资多少来换取我们想要的回报。例如，如果它是基于事件的简单IOT事件警报系统，那么Storm或Kafka Streams非常适合使用。未来考虑因素：同时，我们还需要对未来可能的用例进行自觉考虑。将来可能会出现对诸如事件时间处理，聚合，流加入等高级功能的需求吗？如果答案是肯定的，则最好继续使用高级流框架（例如Spark Streaming或Flink）。一旦对一项技术进行了投资和实施，其变更的困难和巨大成本将在以后改变。例如，在之前的公司中，从过去的两年开始，Storm管道就已经启动并运行，并且在要求统一输入事件并仅报告唯一事件之前，它一直运行良好。现在，这需要状态管理，而Storm本身并不支持这种状态管理。虽然我使用基于时间的内存哈希表实现，但是在重启时状态会消失是有限制的。我要提出的观点是，如果我们尝试自行实现框架未明确提供的某些内容，则势必会遇到未知问题。现有技术堆栈：另一重要点是考虑现有技术堆栈。如果现有堆栈的首尾相连是Kafka，则Kafka Streams或Samza可能更容易安装。同样，如果处理管道基于Lambda架构，并且Spark Batch或Flink Batch已经到位，则考虑使用Spark Streaming或Flink Streaming是有意义的。例如，在我以前的项目中，我已经在管道中添加了Spark Batch，因此，当流需求到来时，选择需要几乎相同的技能和代码库的Spark Streaming非常容易。简而言之，如果我们很好地了解框架的优点和局限性以及用例，那么选择或至少过滤掉可用的选项就更加容易。最后，一旦选择了几个选项。毕竟每个人都有不同的选择。
Streaming的发展速度如此之快，以至于在信息方面，此帖子可能在几年后已经过时。目前，Spark和Flink在开发方面是领先的重量级人物，但仍有一些新手可以加入比赛。Apache Apex是其中之一。还有一些我没有介绍的专有流解决方案，例如Google Dataflow。我的这篇文章的目的是帮助刚接触流技术的人以最少的术语理解流技术的一些核心概念，以及流行的开源流框架的优点，局限性和用例。希望该文章对您有所帮助。

https://blog.csdn.net/zgpeace/article/details/108521759

大数据平台架构