大数据技术生态

大数据技术生态

离线计算

Hadoop只是一套工具的总称，它包含三部分：HDFS，Yarn，MapReduce，功能分别是分布式文件存储、资源调度和计算。

这一套相当于用Yarn调度资源，读取HDFS文件内容进行MR计算。这一套的问题是使用比较麻烦，要写java代码。

所以Hive相当于这一套标准流程的SQL化。Hive可以简单理解为，Hadoop之上添加了自己的SQL解析和优化器，写一段SQL，解析为Java代码，然后去执行MR，底层数据还是在HDFS上。它的问题是运行速度慢，原因是MR，它需要频繁写读文件。

这时基于内存的Spark出现了，Spark是替代MR的，它会为SQL生成有向无环图，加上各种算子和宽窄依赖的优化，使得计算速度达到了新的高度。

以上是静态数据的处理流程。

实时的数据产生了该怎么拿到呢？

实时计算

实时数据的来源

实时怎么理解？来一批处理一批，再细一点儿，来一条，处理一条。

比如，你买一件东西，平台数据库中会多一条订单数据，app会产生行为日志数据。订单数据插入数据库时一般会有binlog，即记录插入、更新或删除的数据，我们只要能实时拿到这一条binlog，就相当于拿到了实时数据。

binlog怎么拿呢？这就要说到数据库的主从备份机制，一般本身就是拿主库的binlog同步到备份库，刚好有一个叫canal的工具可以把自己伪装成备份库，来拉取主库的binlog，再解析、包装最后抛出，就相当于实时拿到数据了！

canal拿到了binlog就能直接处理了吗？可以，但有件事儿大家想一想。马上五一了，加入一下子超级多人下单消费，canal抛出的消息我们下游一下子消费不完咋办呢？

消息队列，Kafka 就是起这样的作用：异步、解耦、消峰。canal的数据一般会抛到kafka或RocketMQ，可以保存一段时间。然后下游程序再去实时拉取消息来计算。

实时数据的处理

Spark Streaming

Spark Streaming 就是用来微批地处理流式数据的。

具体而言，离线数据我们是等半夜数据都抽到 Hive 中再计算，而 Spark Streaming 则是实时数据来一小批，它就处理一小批。所以本质上讲，Spark Streaming 还是批处理，只不过是每一批数据很少，并且处理很及时，从而达到实时计算的目的。

这一套有什么逻辑缺陷吗？

实时数据和离线数据最大的差异，是时效性。离线数据像湖水，该多少就多少，就在那里；实时数据像水流，绵绵不绝。时间，便是非常重要的一个特质。当一条数据来的时候，我们需要知道这条数据是什么时候产生的，这便是业务时间。但我们拿到这条数据时往往是业务时间之后的一小会，这边是处理时间。真正世界里的实时数据肯定不是像 Spark Streaming 那样一批一批来的，而是一个一个的事件。对此，Flink 帮助我们解决了这些问题。

没有很好的反压机制，当数据激增时，内存激增，Spark集群很容易crash。

Flink

无论是业务数据还是日志数据，往往都有相应的时间标志字段，代表着这条消息的业务时间。你可以让 Flink 选择这个时间，这样，Flink 就知道当前处理到哪个时间点了。

Flink 不同于 Spark Streaming 的微批次处理，它是一条一条数据处理的。这样的数据一般是先来后到的，但难免会有些数据沿途受阻晚来了几秒钟，这就会导致两个问题：数据延迟和乱序数据。这也是做实时数据的非常关注的问题。

如何防止数据延迟？如果是上游数据迟了，就加大上游资源；如果是数据突然激增，导致 Flink 处理不过来导致任务出现延迟，就加大 Flink 的资源，比如并发。

数据乱序呢？
同样的，我们一般也通过上游和 Flink 本身来分别保证。

我们如何去认识乱序或延迟数据呢？
既然这种情况是偶发性的，那么一般可以这么做，在实时的流数据中，如果想要拿到 T 时刻的数据，只要等一小会儿比如 1s，就能保证在 T+1s 的时刻拿到 T 时刻的所有数据。在 Flink 中，这种机制就叫做 watermark。