1. Kafka比对其它MQ中间件
- kafka对比其他MQ的优点
| 可扩展 | Kafka集群可以透明的扩展，增加新的服务器进集群。 |
|---|---|
| 高性能 | Kafka性能远超过传统的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。 |
| 容错性 | Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时，Zookeeper将通知生产者和消费者从而使用其他的Broker。 |
- kafka对比其他MQ的缺点
| 重复消息 | Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。 |
|---|---|
| 消息乱序 | Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。 |
| 复杂性 | Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。 |
- kafka对比其他MQ的使用场景
| Kafka | 主要用于处理活跃的流式数据,大数据量的数据处理上 |
|---|---|
| 其他MQ | 用在对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量还在其次，更适合于企业级的开发 |
- 总结
| 数据可靠性 | 延迟 | 单机吞吐 | 社区 | 客户端 | |
|---|---|---|---|---|---|
| ActiveMQ | 中 | / | 万级 | 不太活跃 | 支持全面 |
| RabbitMQ | 高 | 微秒级 | 万级 | 活跃 | 支持全面 |
| Kafka | 高 | 毫秒级 | 十万级 | 活跃 | 支持全面 |
| RocketMQ | 高 | 毫秒级 | 十万级 | 有待加强 | 有待加强 |
2. 分布式计算比对
- 如果对延迟要求不高的情况下，可以使用 Spark Streaming，它拥有丰富的高级 API，使用简单，并且 Spark 生态也比较成熟，吞吐量大，部署简单，社区活跃度较高，从 GitHub 的 star 数量也可以看得出来现在公司用 Spark 还是居多的，并且在新版本还引入了 Structured Streaming，这也会让 Spark 的体系更加完善。
- 如果对延迟性要求非常高的话，可以使用当下最火的流处理框架 Flink，采用原生的流处理系统，保证了低延迟性，在 API 和容错性方面做的也比较完善，使用和部署相对来说也是比较简单的，加上国内阿里贡献的 Blink，相信接下来 Flink 的功能将会更加完善，发展也会更加好，社区问题的响应速度也是非常快的，另外还有专门的钉钉大群和中文列表供大家提问，每周还会有专家进行直播讲解和答疑。
3. 海量数据存储比对
- Kudu对比其他列式存储（Hbase、HDFS）
| HDFS | 使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条纪录级别的update操作，随机读写性能差 |
|---|---|
| HBASE | 可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。 |
| KUDU | KUDU较好的解决了HDFS与HBASE的这些缺点，它不及HDFS批处理快，也不及HBase随机读写能力强，但是反过来它比HBase批处理快（适用于OLAP的分析场景），而且比HDFS随机读写能力强（适用于实时写入或者更新的场景），这就是它能解决的问题。 |
4. ClickHouse与其他的OLAP框架的比较
| 商业OLAP数据库 | 例如：HP Vertica, Actian the Vector。区别：ClickHouse是开源而且免费的。 |
|---|---|
| 云解决方案 | 例如：亚马逊RedShift和谷歌的BigQuery 区别：ClickHouse可以使用自己机器部署，无需为云付费 |
| Hadoop生态软件 | 例如：Cloudera Impala, Spark SQL, Facebook Presto , Apache Drill 区别： ClickHouse支持实时的高并发系统\ClickHouse不依赖于Hadoop生态软件和基础、ClickHouse支持分布式机房的部署 |
| 开源OLAP数据库 | 例如：InfiniDB, MonetDB, LucidDB 区别：这些项目的应用的规模较小，并没有应用在大型的互联网服务当中，相比之下，ClickHouse的成熟度和稳定性远远超过这些软件 |
| 开源分析 | 例如：Druid , Apache Kylin 区别：ClickHouse可以支持从原始数据的直接查询，ClickHouse支持类SQL语言，提供了传统关系型数据的便利 |
5. 任务调度比对
| Azkaban | cpu和内存要求不高，主从配置支持的不算太好，适用于小集群，以job的文件实现，配置简单 |
|---|---|
| Oozie | 通常使用hue集成的WEB界面进行操作；单独的使用oozie的情况下，配置及其复杂，不推荐；所有的任务是以mr的形式进行的，可支持复杂的依赖调度 |
| NiFi | NiFi就是为了解决不同系统间数据自动流通问题而建立的，它使用高度可配置的指示图来管理数据路由、转换和系统中介逻辑，支持从多种数据源动态拉取数据。纯英文可视化界面，处理器较多，门槛稍高。 |
| Airflow | 使用于大集群，阿里的调度系统就是根据airflow二次开发，配置复杂，python脚本实现 |
| JobX | cpu使用高，bug还没修复，配置简单，只支持依赖调度，并行调度不支持 |
| Crontab | 一般用于每分钟调度一次的任务，不支持依赖调度、并行调度（配置复杂，通过脚本自定义控制），没有可视化界面，不能准确的判断任务是否成功或者是失败 |
6. 数据分析比对
| hive | 适用于分析一些离线大数据（基于磁盘IO分析） |
|---|---|
| impala | 适用于分析一些准实时日志（要求快速出数据，基于内存分析） |
| es | 分析一些log |
| spark core+spark sql | 适用于分析一些离线数据，自定义解析规则 |
| spark streaming | 适用于分析一些近实时（不是完全实时）数据 |
| flink、jstorm | 进行分析完全实时的数据 |
7. 数据存储比对
| hdfs | 用于存储离线大数据量 |
|---|---|
| kudu | 用于更新更及时的基础上实现更快的数据分析，不够成熟应用较少 |
| es | 存储一些log日志，比如说我们需要快速的定位某一个业务的log情况 |
| kafka | 作为消息中间件，存储nifi或者是flume采集的日志 |
8. 数据采集比对
| flume | 适用于日志文件实时采集，有自己内部机制确保数据不会丢失，所以可以用于一些更重要的业务日志场景下。 |
|---|---|
| Sqoop | 适用于大数据集群与关系数据库间的大批量数据传输。 |
| Logstash | 用途和flume类似，有比flume丰富的多的插件可选。在异常情况下，是可能出现数据丢失的问题。 |
| Kettle | 适用于数据量及增量不大，业务规则变化较快，要求可视化操作，对技术人员的技术门槛要求低的场景。 |
| NiFi | NiFi就是为了解决不同系统间数据自动流通问题而建立的，它使用高度可配置的指示图来管理数据路由、转换和系统中介逻辑，支持从多种数据源动态拉取数据。纯英文可视化界面，处理器较多，门槛稍高。 |
9. 工作流调度工具之间对比
| 特性 | Hamake | Oozie | Azkaban | Cascading |
|---|---|---|---|---|
| 工作流描述语言 | XML | XML (xPDL based) | text file with key/value pairs | Java API |
| 依赖机制 | data-driven | explicit | explicit | explicit |
| 是否要web容器 | No | Yes | Yes | No |
| 进度跟踪 | console/log messages | web page | web page | Java API |
| Hadoop job调度支持 | no | yes | yes | yes |
| 运行模式 | command line utility | daemon | daemon | API |
| Pig支持 | yes | yes | yes | yes |
| 事件通知 | no | no | no | yes |
| 需要安装 | no | yes | yes | no |
| 支持的hadoop版本 | 0.18+ | 0.20+ | currently unknown | 0.18+ |
| 重试支持 | no | workflownode evel | yes | yes |
| 运行任意命令 | yes | yes | yes | yes |
| Amazon EMR支持 | yes | no | currently unknown | yes |
开源OLAP引擎
| 框架 | 描述 |
|---|---|
| Hive | Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。缺点是慢 |
| Spark SQL | SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。SparkSQL作为Spark生态的一员继续发展，而不再受限于Hive，只是兼容Hive。 |
| Presto | Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，适用于交互式分析查询，可支持众多的数据源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口开发数据源连接器。Presto由于是基于内存的，而hive是在磁盘上读写的，因此presto比hive快很多，但是由于是基于内存的计算当多张大表关联操作时易引起内存溢出错误。 |
| Kylin | Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。所以适合Kylin的场景包括：1）用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上2）每天有数G甚至数十G的数据增量导入3）有10个以内较为固定的分析维度 |
| Impala | Impala不提供任何对序列化和反序列化的支持。Impala只能读取文本文件，而不能读取自定义二进制文件。每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。这个缺点会导致正在执行的查询sql遇到刷新会挂起，查询不动。 |
| Druid | Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。与其他的时序数据库类似，Druid在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏Join、子查询等。 |
| Greeplum | Greenplum是一个开源的大规模并行数据分析引擎。借助MPP（大规模并行处理）架构，在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。Greenplum基于Postgresql，也就是说GreenPulm和TiDB的定位类似，想要在OLTP和OLAP上进行统一。 |
| ClickHouse | Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。Yandex是俄罗斯搜索引擎公司。官方提供的文档表名，ClickHouse 日处理记录数"十亿级"。特性:采用列式存储；数据压缩；支持分片，并且同一个计算任务会在不同分片上并行执行，计算完成后会将结果汇总；支持SQL；支持联表查询；支持实时更新；自动多副本同步；支持索引；分布式存储查询。大家对Nginx应该不陌生，战斗民族开源的软件普遍的特点包括：轻量级，快。ClickHouse最大的特点就是快，快，快，重要的话说三遍！与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级 |
1215
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
