你好，我是周爽，相熟的人都叫我“爽哥”。

我曾任职于华为 2012 实验室高斯部门，负责实时分析型内存数据库 RTANA、华为公有云 RDS 服务的研发工作。目前，我专注于移动反欺诈解决方案的研发。针对公司业务需求，我开发了一个实时流计算系统，并在此基础上完成了风控系统的研发。最终，这个系统被一个独角兽收购。

最近这两年，越来越多的业务和数据分析对实时性提出更高的要求，与之对应解决实时计算问题的流计算框架，也开始流行起来。

因为工作原因，常有人问我有关实时流计算系统的问题。整体观察下来我发现：很多时候，他们并非不知道这些框架 ，也并非不熟悉这些框架的 API 和工作原理，而是不清楚如何将框架，运用到实时业务中去，也就不能很好地解决落地问题。

业务功能要求实时，我该怎么落地？

在此之前，我想先说一点：如果你的业务相对简单，通过查数据库的方式，就能够做到毫秒级返回，那也没有必要去研究更复杂的技术。正所谓，“如无必要，勿增实体”，保持一切简单就好。

但是当请求非常多、数据量非常大，并且对请求时延要求非常严格时，比如，必须在毫秒甚至微秒级返回，那么问题就变得复杂了。比如这些场景：

实时检测异常的反欺诈或风控系统；实时展示业务报表的大屏系统；实时计算用户兴趣偏好的推荐系统；实时统计过车流量的智能交通系统。

面对以上业务场景，如果按照传统数据库增删查改的方法，需要将数据全部记录在数据库中，然后在查询时，再即时遍历和计算。很明显，这种方案不管是存储空间，还是计算时间，成本都非常高，已经不能有效地进行实时计算了。

因此，原本习惯了做增删查改业务逻辑开发的人员，在初次接触实时流计算业务场景时，不可避免地会遇到种种难题，比如以下几点。

需要统计的时间窗口很长，数据量也很大。比如“相同设备在 3 个月内注册事件的次数”，此时，如果你想实时计算获得结果，就不能够通过遍历数据库的方式来实现了。

需要统计的变量，其值域非常大。比如“同一用户在 6 个月内使用不同 IP 个数”，如果是数亿用户和数亿 IP，你还能够用集合来记录这些不同的值吗？更何况，还需要在指定的时间范围内进行计算。

一次完整的业务，可能需要计算数十个甚至数百个特征。比如，实时风控系统中，风控模型的输入便是如此。为了保证用户体验，风控系统必须在数秒甚至数百毫秒内返回。

有些问题的算法，天然就很复杂，数据量又很大，如何做到实时计算呢？比如，社交网络的二度关联分析，还有许多复杂的统计学习和机器学习模型。

甚至有些时候，产品和开发人员都不清楚，是否需要或者能够，使用实时流计算技术。或许难以置信，但这样的公司和开发人员，真的不在少数。

如果想切实解决这些难题，就需要透过现象看本质。我认为，之所以会出现上面的种种难题，主要是因为以下五种原因：

一是，缺乏对实时流计算技术以及它的适用场景的整体认识；

二是，不知道如何用“流”来实现各种业务逻辑的异步和高并发计算；

三是，不知道如何针对“流”这种独特的数据模式，设计实时算法；

四是，对各种流计算框架的认识只停留在 API 调用层面，而没有理解其背后的设计原理，也就是“流”这种计算模式的，核心概念和关键技术点；

五是，缺少对一些已有案例的借鉴和思考。

如何解决实时流计算问题？

既然明确了问题，接下来我们应该怎样克服呢？我认为可以从系统架构和实时算法两个方面来突破。

系统架构

从架构师的角度看，要为产品设计一个好的实现方案，既要有足够的技术储备，也要充分理解具体的业务问题。通过分析各类实时业务场景，我们可以发现，大多数方案都是基于“流计算”技术的。

“流计算”本质上是一种“异步”编程方法。业务数据像“流水”一样，通过“管道”，也就是“队列”，持续不断地流到各个环节的子系统中，然后由各个环节的子系统独立处理。所以，为了更快地处理“流”，可以通过增加管道的数量，来提高流计算系统的并行处理能力。

目前，开源的流计算框架虽然有许多（比如 Storm、Spark Streaming、Samza 和 Flink），但其实这些主流框架背后，都有着一套类似的设计思路和架构模式。它们都涉及流数据状态、流信息状态、反向压力、消息可靠性等概念。先行理解这套设计思路和架构模式，可以帮助你快速掌握，所有主流流计算框架的工作原理。

实时算法

系统架构提供了整体的计算框架，但要实现具体的业务功能，还需要针对“流数据”设计合适的算法。 毕竟，与传统“块数据”相比，“流数据”需要连续不断并且实时地进行处理。

对于实时流计算中的算法，最最核心的问题，在于解决“大数据量”和“实时计算”之间的矛盾。数据量一大，几乎所有事情都会变得复杂和缓慢。“大数据量”的问题，集中在四个方面：时间窗口很长、业务请求量很大、内存受限、数据跨网络访问。

为了实现“实时计算”的效果，需要你针对算法做非常精心的设计。所幸的是，这些算法的设计和实现也是有规律可循的。 你只需要掌握几种特定类型的算法，比如计数、求和、均值、方差、直方图、分位数、HyperLogLog 等。而对于更加复杂的算法，如果不能直接进行实时计算，那我们可以通过 Lambda 架构来解决！

课程设计思路

本课程就是从“系统架构”和“实时算法”这两个方面，来带你理解实时流计算系统。为此，我为你设计了以下学习路径。（注意，模块三为“实时算法”部分，其余模块为“系统架构”相关。）

模块一，实时流计算入门。我将介绍流计算系统的整体架构和使用场景，以及入门流计算前，需掌握的编程基础，比如 NIO 和异步编程，以及异步系统中的 OOM 和反向压力问题。

借此，你会对实时流计算系统有个整体的认识，并对“流”的本质有个初步理解。

模块二，自己动手做一个流计算框架。 我将介绍如何从 JDK 里最基础的工具类，一步步开发出一个分布式流计算框架。

通过这种自己动手的方式，希望帮助你理解流计算系统的核心概念及实现原理。

模块三，核心技术篇。我将详细讲解流计算能够解决哪些类型的问题，包括流数据操作、时间维度聚合计算、关联图谱分析、事件序列分析、模型学习和预测等。此外，还将讨论流计算过程中非常重要的状态管理问题，并带你思考如何最终将前面的流计算框架扩展为分布式系统。

借此，你会掌握实时流计算中涉及的各种算法，这些算法会有助于你解决各种实时业务场景中的问题。

模块四，开源流计算框架原理解析及实战。 我将详细对比和分析，各种开源流计算框架的具体实现，来巩固你对流计算核心概念和技术的理解，并带你正确理解这些框架的 API 设计，以便你在各种业务场景下，能够灵活地使用它们，最终实现各种复杂的业务逻辑。

此外，我还会通过两个案例，也就是实时风控和实时数据同步，来带你理解如何将开源流计算框架，运用到具体的业务场景中。

讲师寄语

本课程对实时流计算技术的关键点，做了提纲挈领的分析和讲解，期望你能够从点到面而知全局，迅速领悟大多数流计算框架的本质，在方案选型和软件开发时，做到胸有成竹。

在流计算技术尚未在国内兴起之前，我就根据公司业务需要，从头开始设计并实现了自己的流计算框架。这是我的实战经验总结，它经得起事实验证。

未来，实时流计算技术必然会成为大数据的主流模式，数据不仅以“流”的方式被处理，还以“流”的方式被存储。希望这个课，给你切实的帮助。

PB 级企业大数据项目实战 + 拉勾硬核内推，5 个月全面掌握大数据核心技能。点击链接，全面赋能！

-– ### 精选评论 ##### 周爽： > 小伙伴们，我设计这门课程可以帮你们达到三个目标。一是，借助于流计算帮助你掌握 Java 异步和高并发编程。二是，让你掌握流计算底层原理、业务场景和使用方法。三是，希望你能够通过这种自底向上、从业务到技术、从 Java 到大数据的全方面讨论，体验作为一名架构师应该具备的自我修养。让我们一起学习成长吧！ ##### **一： > 老师这门课是教我们如何造出轮子吗？因为工作中好像直接调flink, spark之类的就可以了 ######     讲师回复： >     造轮子仅仅是一个小点，但更重要的是为了解决具体的实时业务问题，我们自底向上来构建一个实时流计算系统，在其中我们会遇到哪些问题，以及为了解决这些问题，我们想了哪些方法，用了哪些技术，最后总结出了哪些共性的东西，包括概念、算法和架构模式等。最后当我们将自己总结出的这些概念、算法和架构模式，放在各种流计算系统中进行分析比较时，会惊奇地发现很多相通的地方。所以，这个课程最终的目的，是帮助你理解“流”这种计算模式，弄懂自己使用的各种开源流计算框架为什么会创造那些概念和组件，以及怎么将这些流计算框架合理地运用到业务场景中去。 ##### **就问： > 一般的 Java 开发需要学流计算吗？ ######     讲师回复： >     我想说的是，如果你是一个有所追求的程序员的话，流计算是必须学习的内容。原因有三点。首先，从单纯的编程来看，“流”这种计算模式本身就是当前 Java 最佳的异步和高并发编程模式，甚至可以说没有之一。比如 Java 8 引入的 CompletableFuture 类，就是一种异步和流式编程的框架。然后，从系统架构的角度看，以 Kafka 消息中间件为代表的流数据系统，已经在高并发业务场景使用得越来越广泛，如果你还将自己的视野局限在传统的微服务架构，就有些坐井观天了。最后，如今以 Flink 为代表的大数据流处理框架，已经开始从传统的大数据领域，向微服务领域渗透，这其中原因无它，Flink 提供了一种类似于分布式 JVM 的架构模式，天然就简化了低延迟、高并发、分布式系统的设计。所以，综合以上三种原因，我觉得现如今掌握流计算已经是 Java 程序员必备的职业技能了。 ##### **人： > 流计算和实时流计算有啥区别? ######     讲师回复： >     俗话说“天下武功，无坚不摧，唯快不破”。任何事情，想要做得快都是件比较困难的事情。流计算也一样。流计算本身，只是一种处理数据的方式，它比较的对象是传统的“批处理”计算方式。换言之，你可以用“流”的模式来处理数据，这并没有时间的限制要求。但是，我们为什么要在“流计算”前面加上“实时”的限制呢？这主要是针对业务场景而说的。因为现在越来越多的业务对数据处理的时效性，提出更高的要求。这种情况下，我们必须设计高吞吐、低时延的系统，而流计算技术是非常适合设计这种高吞吐、低时延的系统的。所以，实时流计算其实是暗含了两层意思，一是我们是针对实时业务场景的设计，二是我们采用的是流计算技术。 ##### *域： > 老师好，您说的正是我现在说面临的困境，如果您看见了我的留言，希望您先为我解惑一下。sparkstreaming在消费kafka（数据量在每天TB级别）时总是跟不上消息生产速度（个人分析原因架构选型不正确），主要业务逻辑为数据聚合操作，涉及到历史数据的更新。这种业务您会采用什么架构，做什么技术选型呢？ 望回复 ######     讲师回复： >     毫无疑问，我还是会kafka + Spark Streaming或Flink 这种架构，然后是在 Spark Streaming 和 Flink 之间，我会选择 Flink。 至于你说的跟不上消息生产速度，我觉得可以从两个方面检查下：一是，本身Kafka的配置是否合理，比如kafka topic的partition数量是否足够大，kafka consumer的数量是否和partition数量一致，然后kafka consumer的fetch.min.bytes的设置，checkpoint也就是提交read offset的时间间隔。这些因素都会影响Kafka consumer读取的性能。二是，你说的数据聚合操作，其实关于数据聚合有两种方式，一种直接使用基于窗口函数的聚合计算，第二种是使用状态接口然后自己来实现聚合计算。根据你说的信息，我不能判断你目前采用的是哪种方案。但是不管是哪一种，你都可以通过将流数据通过keyby或者groupby分组的方式，分成分区流来进行处理，然后分区流的数量要和你Kafka topic分区数的数量保持一致。比如，按照用户id对你的数据进行分组。当分成分区流之后，你就可以近乎无限地水平扩展你的处理能力了，增加服务器数量就行。总结下，解决这类问题的思路，就是通过将数据流分成很多分区流来处理，同时要保证你系统真正具备水平扩展的能力。另外，你还说到历史数据更新的问题，根据我的经验，就是尽量不要一边计算一边往数据库里写数据，最好是先将一批数据处理完，然后将结果统一写入数据库。并且数据处理的逻辑，和数据写入数据库的逻辑，不要放在相同的线程中，这样会急剧地降低数据处理的性能的。 ##### *信： > 我刚买过老师的书《实时流计算系统设计与实现》，写得特别好，巧的是我最近才关注拉勾教育（性价比这么高的平台才知道有点落后），这也太巧了吧！ ######     编辑回复： >     书写得好，专栏写得也很好！！ ##### **7324： > 一看就是好东西，必须学起来 ##### *靖： > 学起来 今年涨薪5k ######     编辑回复： >     那必须！ ##### *儿： > 传统Java开发中最困难的部分，确实全都融汇在实时流计算技术中。 ##### **文： > 用python做开发可以吗 ######     讲师回复： >     本课程的主要语言用的是Java，本课程主要想讲清楚的是“流”这种计算模式的核心概念、关键技术、常用工具、以及使用场景。计算机的语言是相通的，比如我们的课时中有时候为了更加清楚的说明问题，也会借用JavaScript、Golang、Python语言的代码或概念。所以，如果你需要的是理解流计算技术的话，不必太在意自己使用的语言哦。 ##### **提： > 首先感谢作者，看了前面几章挺不错的，对流计算有了新认识，就是更新太慢了呀 ######     编辑回复： >     现在更新到11讲了呢，每周一、三也会更新一讲喔。老师也正加速写呢~ ##### **3961： > 实时流计算技术必然会成为大数据的主流模式，数据不仅以“流”的方式被处理，还以“流”的方式被存储 ##### **青： > 对高并发，实时流只是处于知道一些概念和工具的API层面，根本不懂怎么用，需要学习的内容还很多，跟老师学起来 ######     讲师回复： >     嗯，是的！先掌握模块一和模块二的编程基础和核心概念，后面模块三和模块四就是解决具体业务问题的算法和流计算工具框架。让我们一起学习成长，成为大牛！ ##### *阁： > 老师写的真好，像优秀的人学习 ##### **健： > 想请教下老师，目前实时数仓开发人员需要掌握哪些知识、技能？相对于离线数仓有哪些区别？实在对离线数仓无感😂😂😂😂 ######     讲师回复： >     首先，数仓本身属于大数据的技术范畴。所以，理解大数据系统是你过不去的坎。而最好的大数据基础知识入门，我认为还是Hadoop，包括HDFS、YARN 和 MapReduce 的基本原理。之后，就是你想从事的实时数据仓库了。数仓技术，其实也是包括两个部分，一是数据的处理，二是数据的存储。在数据处理部分，目前看来 Flink 无疑是最佳的工具。主要是有三个方面的原因，一是Flink虽是流计算工具，但是它也是支持批处理的，二是Flink提供了SQL功能，可以方便地提升数据处理的效率，三是如今已经有趋势是数据不仅会按流的方式计算，也会按照流的方式存储，比如在Flink + Pravega方案中，Flink相当于CPU和内存的角色，Pravega则相当于磁盘存储的角色，我认为这种这种流计算+流存储的模式，会是大数据的未来。然后在数据存储部分，虽然你想从事的是实时数仓，但实际工作中还是会不可避免地用到诸如Hive，HBase这类的方案，原因无它，就是它们有时候解决问题也很方便的。总的来书，数据处理部分，我建议你把Flink用到炉火纯青的地步，数据存储部分，则可以多关注一些构建于Hadoop上的生态软件。 ##### **样的人： > 流处理是趋势，实时计算是个难题。借鉴经验，少走弯路。 ######     编辑回复： >     搞起来！