后边可能会用到的大数据相关框架

• Debezium

Debezium是一个开源项目，为捕获数据更改(Capture Data Change，CDC)提供了一个低延迟的流式处理平台，通过安装配置Debezium监控数据库，可以实时消费行级别(row-level)的更改。身为一个分布式系统，Debezium也拥有良好的容错性。

Debezium的源端(即支持监控哪些数据库) : MySQL，MongoDB，PostgreSQL，Oracle，SQL Server
Debezium的目标端(即可以数据导入端) : Kafka

Debezium的应用 : 实时同步数据，实时消费数据

 

•  Apache Kylin

开源领域，Apache Kylin 是预聚合模式 OLAP 代表，支持从 HIVE、Kafka、HDFS 等数据源加载原始表数据，并通过 Spark/MR 来完成 CUBE 构建和更新。

 

• Druid

是另一类预聚合 OLAP 的代表。在 Druid 的表结构模型中，分为时间列、维度列和指标列，允许对任意指标列进行聚合计算而无需定义维度数量。Druid 在数据存储时便可对数据进行聚合操作，这使得其更新延迟可以做到很低。在这些方面，Baidu 开源的 Palo 和 Druid 有类似之处。 

 

选型过程中有几点值得特别关注：
 1. 延迟性
Spark 对流的支持是 MicroBatch，提供的是亚秒级的延迟，相较于 Flink 和 Kafka Streams 在实时性上要差一些。
 2. 应用模式
Spark 和 Flink 都是将作业提交到计算集群上运行，需要搭建专属的运行环境。
Kafka Streams 的作业是以普通 Java 程序方式运行，本质上是一个调用 Kafka Streaming API 的 Kafka Consumer，可以方便地嵌入各种应用。
但相应的，用户需要自己解决作业程序在不同服务器上的分发问题，例如通过 K8s 集群方案进行应用的容器化部署。如果使用 KSQL，还需要部署 KSQL 的集群。
 3. SQL 支持
三者都提供 Streaming SQL，但 Flink 的 SQL 支持要更为强大些，可以运行更加复杂的分组聚合操作。
 4. EOS
Flink 对于数据进出计算集群提供了框架级别的支持，这是通过结合 CheckPoint 机制和 Sink Connector 接口封装的二阶段提交协议实现的。
Kafka Streams 利用 Kafka 事务性消息，可以实现“消费 - 计算 - 写入 Kafka“的 EOS，但当结果需要输出到 Kafka 以外的目的地时，还需要利用 Kafka Connect 的 Sink Connector。
遗憾的是，Kafka Connect 不提供 Kafka 到其它类型 Sink 的 EOS 保证，需要用户自己实现。

Spark Streaming 与 Kafka Streams 类似，在读取和计算过程中可以保证 EOS，但将结果输出到外部时，依然需要额外做一些工作来确保数据一致性。常见的方式包括：利用数据库的事务写入机制将 Offset 持久化到外部、利用主键保证幂等写入、参考二阶段提交协议做分布式事务等。