【硬刚大数据】Flink在实时在实时计算平台和实时数仓中的企业级应用小结

  欢迎关注博客主页：https://blog.csdn.net/u013411339
欢迎点赞、收藏、留言 ，欢迎留言交流！
本文由【王知无】原创，首发于 CSDN博客！
本文首发CSDN论坛，未经过官方和本人允许，严禁转载！

本文是对《【硬刚大数据之学习路线篇】从零到大数据专家的学习指南(全面升级版)》的面试部分补充。

大数据领域自 2010 年开始，以 Hadoop、Hive 为代表的离线计算开始进入各大公司的视野。大数据领域开始了如火如荼的发展。我个人在学校期间就开始关注大数据领域的技术迭代和更新，并且有幸在毕业后成为大数据领域的开发者。

在过去的这几年时间里，以 Storm、Spark、Flink 为代表的实时计算技术接踵而至。2019 年阿里巴巴内部 Flink 正式开源。整个实时计算领域风起云涌，一些普通的开发者因为业务需要或者个人兴趣开始接触Flink。

Apache Flink（以下简称 Flink）一改过去实时计算领域为人诟病的缺陷，以其强大的计算能力和先进的设计理念，迅速成为实时计算领域先进生产力的代表。各大小公司纷纷开始在 Flink 的应用上进行探索，其中最引人瞩目的两个方向便是：实时计算平台和实时数据仓库。

Flink 实时计算

如果你是一位大数据领域的开发人员或者你是一名后端的开发者，那么你对下面这些需求场景应该不会陌生：

我是抖音主播，我想看带货销售情况的排行？我是运营，我想看到我们公司销售商品的 TOP10？我是开发，我想看到我们公司所有生产环境中服务器的运行情况？...... 

在 Hadoop 时代，我们通常的做法是将数据批量存储到 HDFS 中，在用 Hive 产出离线的报表。或者我们使用类似 ClickHouse 或者 PostgreSQL 这样的数据库存储生产数据，用 SQL 直接进行汇总查看。

那么这样的方式有什么问题呢？

第一种，基于 Hive 的离线报表形式。大部分公司随着业务场景的不断丰富，同时在业界经过多年的实践检验，基于 Hadoop 的离线存储体系已经足够成熟。但是离线计算天然时效性不强，一般都是隔天级别的滞后，业务数据随着实践的推移，本身的价值就会逐渐减少。越来越多的场景需要使用实时计算，在这种背景下实时计算平台的需求应运而生。

第二种，基于 ClickHouse 或者 PostgreSQL 直接进行汇总查询。这种情况在一些小规模的公司使用非常常见，原因只有一个就是数据量不够大。在我们常用的具有 OLAP 特性的数据库的使用过程中，如果在一定的数据量下直接用复杂的 SQL 查询，一条复杂的 SQL 足以引起数据库的剧烈抖动，甚至直接宕机，对生产环境产生毁灭性的影响。这种查询在大公司是坚决不能进行的操作。

因此基于 Flink 强大实时计算能力消费实时数据的需求便应运而生。在实时数据平台中，Flink 会承担实时数据的采集、计算和发送到下游。

Flink 实时数据仓库

数据仓库最初是指的我们存储的 Hive 中的表的集合。按照业务需求一般会分为原始层、明细层、汇总层、业务层。各个公司根据实际业务需要会有更为细致的划分。

传统的离线数据仓库的做法一般是将数据按天离线集中存储后，按照固定的计算逻辑进行数据的清洗、转换和加载。最终在根据业务需求进行报表产出或者提供给其他的应用使用。我们很明显的可以看到，数据在这中间有了至少 T+1 天的延迟，数据的时效性大打折扣。

这时，实时数据仓库应运而生。一个典型的实时数据仓库架构图如下：

技术选型

这一部分作者结合自身在阿里巴巴这样的公司生产环境中的技术选择和实际应用的中一些经验，来讲解实时计算平台和实时数据仓库的各个部分是如何进行技术选型的。

实时计算引擎

我们在上面提到，实时计算解决的最重要的问题就是实时性和稳定性。

实时计算对数据有非常高的稳定性和精确性要求，特别是面向公众第三方的数据大屏，同时要求高吞吐、低延迟、极高的稳定性和绝对零误差。随时电商大促的成交记录一次次被刷新，背后是下单、支付、发货高达几万甚至十几万的峰值 QPS。

你可以想象这样的场景吗？天猫双十一，万众瞩目下的实时成交金额大屏突然卡住没有反应。我估计所有开发人员都要被开除了…

我们以一个最常见和经典的实时计算大屏幕来举例。

在面向实际运营的数据大屏中，需要提供高达几十种维度的数据，每秒的数据量高达千万甚至亿级别，这对于我们的实时计算架构提出了相当高的要求。那么我们的大屏背后的实时处理在这种数据量规模如何才能达到高吞吐、低延迟、极高的稳定性和绝对零误差的呢？

在上图的架构图中，涉及几个关键的技术选型，我们下面一一进行讲解。

业务库 Binlog 同步利器 - Canal

我们的实时计算架构一般是基于业务数据进行的，但无论是实时计算大屏还是常规的数据分析报表，都不能影响业务的正常进行，所以这里需要引入消息中间件或增量同步框架 Canal。

我们生产环境中的业务数据绝大多数都是基于 MySQL 的，所以需要一个能够实时监控 MySQL 业务数据变化的工具。Canal 是阿里巴巴开源的数据库 Binlog 日志解析框架，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。

Canal 的原理也非常简单，它会伪装成一个数据库的从库，来读取 Binlog 并进行解析。Canal 在阿里巴巴内部有大规模的应用，因为阿里有众多的业务是跨机房部署，大量业务需要进行业务同步，Canal 功能强大，性能也很稳定。

解耦和海量数据支持 - Kafka

在实时大屏的技术架构下，我们的数据源绝大多数情况下都是消息。我们需要一个强大的消息中间件来支撑高达几十万 QPS，同时支持海量数据存储。

首先，我们为什么需要引入消息中间件？主要是下面三个目的：

• 同步变异步

• 应用解耦

• 流量削峰

在我们的架构中，为了和业务数据互相隔离，需要使用消息中间件进行解耦从而互不影响。另外在双十一等大促场景下，交易峰值通常出现在某一个时间段，这个时间段系统压力陡增，数据量暴涨，消息中间件还起到了削峰的作用。

为什么选择 Kafka？

Kafka 是最初由 Linkedin 公司开发，是一个分布式、高吞吐、多分区的消息中间件。Kafka 经过长时间的迭代和实践检验，因为其独特的优点已经成为目前主流的分布式消息引擎，经常被用作企业的消息总线、实时数据存储等。

Kafka 从众多的消息中间件中脱颖而出，主要是因为高吞吐、低延迟的特点；另外基于 Kafka 的生态越来越完善，各个实时处理框架包括 Flink 在消息处理上都会优先进行支持。并且 Flink 和 Kafka 结合可以实现端到端精确一次语义的原理。

Kafka 作为大数据生态系统中已经必不可少的一员，主要的特性如下所示。

• 高吞吐：

  可以满足每秒百万级别消息的生产和消费，并且可以通过横向扩展，保证数据处理能力可以得到线性扩展。

• 低延迟：

  以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。

• 高容错：

  Kafka 允许集群的节点出现失败。

• 可靠性：

  消息可以根据策略进行磁盘的持久化，并且读写效率都很高。

• 生态丰富：

  Kafka 周边生态极其丰富，与各个实时处理框架结合紧密。

实时计算服务 - Flink

Flink 在当前的架构中主要承担了消息消费、维表关联、消息发送等。在实时计算领域，Flink 的优势主要包括：

• 强大的状态管理。

  Flink 使用 State 存储中间状态和结果，并且有强大的容错能力；

• 非常丰富的 API。

  Flink 提供了包含 DataSet API、DataStream API、Flink SQL 等等强大的API&