从这一课时开始我们进入实战课程的学习。本项目是一个模拟实时电商数据大屏，本课时先介绍该项目的背景、架构设计和技术选型。

背景

我们在第 01 课时“Flink 的应用场景和架构模型”中提到过，Flink 应用最广的一个场景便是实时计算大屏。每年的双十一、618 电商大促等，各大公司的实时数据战报和数据大屏是一道亮丽的风景线。

01.jpeg

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

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

技术选型和整体架构

image (2).png
　　典型的实时计算大屏服务的背后技术架构图

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

业务库 Binlog 同步利器——Canal

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

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

image (3).png

Canal 的原理也非常简单，它会伪装成一个数据库的从库，来读取 Binlog 并进行解析。关于 Canal 的更多资料，你可以参考这里。

解耦和海量数据支持——Kafka

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

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

  • 同步变异步

  • 应用解耦

  • 流量削峰

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

为什么选择 Kafka？

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

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

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

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

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

  • 高容错：Kafka 允许集群的节点出现失败。

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

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

实时计算服务——Flink

Flink 在当前的架构中主要承担了消息消费、维表关联、消息发送等，我们在之前的课程中多次提到过 Flink 的优势，主要包括：

  • 状态管理，实时数仓里面会进行很多的聚合计算，这些都需要对状态进行访问和管理，Flink 支持强大的状态管理；

  • 丰富的 API，Flink 提供极为丰富的多层次 API，包括 Stream API、Table API 及 Flink SQL；

  • 生态完善，实时数仓的用途广泛，Flink 支持多种存储（HDFS、ES 等）；

  • 批流一体，Flink 已经在将流计算和批计算的 API 进行统一。

对于 Flink 的一些特点我们不做过多展开了。这里需要注意的是，Flink 在消费完成后一般会把计算结果数据发往三个方向：

  • 高度汇总，高度汇总指标一般存储在 Redis、HBase 中供前端直接查询使用；

  • 明细数据，在一些场景下，我们的运营和业务人员需要查询明细数据，有一些明细数据极其重要，比如双十一派送的包裹中会有一些丢失和破损；

  • 实时消息，Flink 在计算完成后，有一个下游是发往消息系统，这里的作用主要是提供给其他业务复用；另外，在一些情况下，我们计算好明细数据也需要再次经过消息系统才能落库，将原来直接落库拆成两步，方便我们进行问题定位和排查。

百花齐放——OLAP 数据库选择

OLAP 的选择是当前实时架构中最有争议和最困难的。目前市面上主流的开源 OLAP 引擎包含但不限于：Hive、Hawq、Presto、Kylin、Impala、SparkSQL、Druid、Clickhouse、Greeplum 等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。

我个人曾经在之前写过的博客中用了两万字分析了目前市面上主流的 OLAP 数据库的选型问题，这里直接给出结论：

  • Hive、Hawq、Impala：基于 SQL on Hadoop

  • Presto 和 Spark SQL 类似：基于内存解析 SQL 生成执行计划

  • Kylin：用空间换时间、预计算

  • Druid：数据实时摄入加实时计算

  • ClickHouse：OLAP 领域的 HBase，单表查询性能优势巨大

  • Greenpulm：OLAP 领域的 PostgreSQL

如果你的场景是基于 HDFS 的离线计算任务，那么 Hive、Hawq 和 Imapla 就是你的调研目标。

如果你的场景解决分布式查询问题，有一定的实时性要求，那么 Presto 和 SparkSQL 可能更符合你的期望。

如果你的汇总维度比较固定，实时性要求较高，可以通过用户配置的维度 + 指标进行预计算，那么不妨尝试 Kylin 和 Druid。

ClickHouse 则在单表查询性能上独领风骚，远超过其他的 OLAP 数据库。

Greenpulm 作为关系型数据库产品，性能可以随着集群的扩展线性增长，更加适合进行数据分析。

实时大屏方案和指标

在我们本次的案例中，将针对实时大屏中几个重要的指标进行计算，其中包括实时交易额、销售额排名 TOPN 等指标。

整个课程的设计包含以下几个部分：

  • 实时数据的模拟

  • Flink 消费 Kafka 数据开发

  • Flink 中的业务逻辑开发

  • Flink 计算结果写入 Redis 等

  • 其他

在这个案例中，我们还会从原理和源码层面讲解 Flink 消费 Kafka 的方式和注意事项等。

点击这里下载本课程源码。

总结

这一课时我们讲解了 Flink 实时大屏的架构设计和技术选型，其中涉及 Binlog 增量同步、消息中间件 Kafka 的优点、OLAP 的技术选型等。在接下来的课程中，我们会一一讲解这些知识点。通过本课时，你将学习实时数据处理和大屏展示背后的技术架构和实现，在面对相似的业务场景时也可以根据我们本课时的技术选型和架构进行灵活处理。

精选评论

**用户6015：

tidb怎么样

    讲师回复：

    也可以用，兼具OLAP和OLTP的特性

*杰：

很经典的入门demo，期待老师的更新