datacanvas张晓林：大规模分布式实时流处理技术分享！机不可失，速戳！公司资讯-九游会真人

12月5日，fintech创新论坛（第九期）暨金融分布式架构专业委员会第三次工作会议在上海交通银行会议中心召开。九章云极datacanvas作为深耕金融行业的数据科学平台提供商，受邀出席本次论坛，是此次论坛上唯一一家人工智能与大数据领域企业。

九章云极datacanvas副总裁王俊鹏、首席产品架构师张晓林代表公司出席。论坛上，张晓林发表题为“大规模分布式实时流处理技术分享”的精彩演讲，分享九章云极datacanvas自主研发的分布式流数据处理平台——datacanvas rt实时计算平台的实践经验，并同来自建设银行、交通银行、邮储银行、民生银行、平安银行、华为的重磅技术大咖们共话分布式架构在金融领域的前沿实践和发展前景。

以下为演讲实录：

感谢联盟组委会，感谢张总提供的机会介绍九章云极datacanvas在实时流处理技术方面的经验。当然，流处理本身在不断发展过程中，今天我也带着问题来，希望能和各位专家进行分享、请教、讨论，看看有没有可以更深层次推动技术在金融行业深入应用的地方。

我的题目起的比较大一些，但是我的意思是所有新上线的大数据系统都会涉及到分布式，今天的主题也是“分布式”,那么在分布式系统上怎么应用架构上的改进、创新，从而能够把数据、原本数据上的价值做到更加实时，把深入的价值挖掘出来？

九章云极datacanvas所沉淀、所积累的（技术）都会在产品里，后面希望能跟大家一起讨论怎么理解、应用新技术。

今天我要讲的是四部分，第一部分，基本技术背景介绍；第二部分，实时流处理技术架构演进线路，包括开源的架构、开源的方案是怎么解决问题的；第三部分，最佳实践和应用场景介绍，具体介绍如何落地，有哪些特点以及功能的局限性；第四部分，总结一下今天的要点。

实时流处理技术在市场上是逐渐升温的过程，在gartner最新报告里提到了随着大数据新技术被采集，数据量会越来越大。以往数据量小到一个人就可以维护数据库，但未来的数据呈指数级剧增。同时，实时流处理的市场也正在以每年15%的速度递增。

基于事件流的处理架构更偏向于分析的架构，主要解决的是大量的iot数据、银行交易数据、日志数据等。框架上会是比较大规模分布式框架，在此当中做数据的应用场景，像数据集成、数据变换、数据聚合等，从而落在某一个存储上。

另外一种思路上是在流上做纯粹的分析，这是一个ai、智能的时代，（我们）希望在原始粗糙的数据上挖掘出更多价值，甚至把价值发挥到近乎实时的过程，这当中包含了使用机器学习、传统规则的模型。

实时流处理系统毕竟也是一个分布式系统，在分布式系统里面临着怎么解决一致性、可用性等问题。流处理依然要面临cap的选择问题。我们会着重顺着流处理技术找一些经验以及值得讨论的地方，看一下是怎么应用的，怎么解决问题的，以及现在的局限性在什么地方。

我刚才听各位嘉宾演讲学习到一点，大家在处理业务时也会用内存计算、高性能数据库、nosql等技术解决实时的问题。今天我的演讲内容更加偏分析的场景。如果做分析路径的话，主要目标是把端到端的计算做得更快。所以架构上需要应用内存计算组件配合。

比较一下实时流处理架构和传统批量处理架构。流式处理是让数据在发生的那一时刻从主机的cdc镜像数据流进来，可以直接通过事件驱动的架构反应到实时大屏、决策引擎里。在架构思考里一方面是分布式计算架构，分析不会像业务一样要求非常强的一致性，有些场景也有可能接受近似算法，以比较低的代价，进行近似计算。

下面会顺着流处理框架说一下自己的经验或者走过的坑，我先讲一下自己的理解，接下来给大家分享一些实践，包括怎么处理大规模分布式系统、事件驱动的架构是什么样的、在流处理里怎么完成复杂事件处理？包括当今数据时代或多或少都要和机器学习、深度学习结合，那么在流处理框架里结合机器学习是怎么完成的？下面还会提到一些问题：事件出现以后只是包含事件本身的框架，从增量的计算的角度如何达到实时的计算、把数据的最终结果展示出来？还包括更底层的描述，比如说正确性如何在流框架里保证的，at-least once和exactly-once。

今天我着重说的是流处理框架，现在很多银行是通过批处理的过程完成数据挖掘和分析的，在这个过程中通过交易数据库进项，通过批处理任务调度写到另外一个集群里，卸下来以后再做计算分析。

批量调度会占据比较多的时间，如果是端到端的延时都是分钟级、小时级，甚至天级别。流处理需要考虑数据源在流式处理框架内计算出来（比如说某些统计值的累加，产生指标），然后将指标送到下游系统，延时可以控制在毫秒级内响应，以最快的端到端延时提现数据的价值。

大数据处理技术有一个经典架构：lambda架构。一方面是数据进来以后，一般通过t 1调度的形式，以批处理的形式进行全量数据的处理，处理之后把t 1之前的数据进行计算。另外一方面有实时处理层，进行实时的流数据处理。最后，通过流数据框架和批复框架进行结合返回服务层。服务层通过查询服务完成最终的结果，这个过程相对来说是比较成熟的框架。后面我会将它和其他框架比较差别。

lambda架构会把批处理和流处理明显分开。这种分离会导致开发、调试、维护上的成本相对来说都比较高。而且这时候有可能涉及到比较细的问题：可能2个team同时在写两套不同的代码，业务描述、业务逻辑的一致性问题也是比较大的问题。

随着lambda问题进行演进，业界提出可以使用kappa架构，用“流处理”去处理数据。无论是存量数据还是增量数据都是通过同一个平台完成的，这样能够保证系统复杂度是可控的。如果通过前后端的kappa架构解耦，下游可以做更多分析，甚至快速迭代各个业务场景的分析。

采用微服务架构的特点是在实践中会有上百个、上千个微服务，调用关系是非常复杂的架构。如果用kappa架构思路解决问题，可以把所有的数据都通过实时的数据总线完成特别集中式的管理，后面无论是接业务还是接分析都可以让架构变的易于维护和扩展。

本质上我们并不觉得这是特别完美的方案，但是这是迄今为止比较好的方向，我也相当与抛出一个问题看有没有更好的方法、思路可以把整体架构做得更简单、更易于维护。

九章云极datacanvas是基于开源架构基础的，前面有专家提到了开源本身也会有一定的代价。就我个人的观点来说，我觉得开源还是不可逆的过程，开源的代价比以前封闭系统的代价显然要低，我们仍然要基于开源的框架解决问题，因此最终看中基于apache flink逐渐升温的流处理框架做基础的框架。

如果大家比较关注这个领域的话，会注意到今年12月份有一个apache flink china在北京的会议，apache flink是在国内逐渐受到大家关注的新项目。

大型成功应用简单介绍一下，最大的是阿里去年顶峰时超过472个millions数据，几乎是亚秒级的延时。国外的uber以及国内的京东都在踊跃地使用平台解决流处理的问题。

说技术框架难免提到前身，flink和上一代storm的关系。flink最大的特点是状态管理更加“优雅”一些，如果用传统storm的话需要用户管理的状态，如果用flink的话是通过可以分区的rocksdb完成的嵌入式的数据，这必然要求能够分区进行更上层的管理。flink站在更高的角度管理所有的状态资源、性能资源，如果要做分析的话要考虑在什么样时间窗口内，这种支持在上一代storm里更弱一些。

从计算的语义上来说，即便是有状态的计算，flink仍然可以保证端到端的数据正确性。从fault tolerance的角度来说，flink使用的是基于rocksdb实现的增量状态checkpoint，一旦发生灾难，单个节点可以重新被分配到另外的计算资源上，再从增量机制上重新执行。这种情况下可以保证达成端到端的不丢不重的效果。如果要写业务的话，也是可以达到这种效果，但如果框架层提供这种机制，会让我们把更多的精力放在数据分析逻辑本身。

flink和spark的区别，我们内部做了非常详尽的分析比较。从我们的观点出发来介绍flink和spark技术的主要差异。near realtime是spark2.3之前的，这也说明了flink在流处理技术方面更前沿一些。无论是flink还是spark，两个社区都是比较大的社区，spark里的状态管理相对弱一些，flink通过rocksdb完成状态的管理。

high level的优化前面华为架构师也提到了一些技术，flink同样可以用cbo进行全局的优化。这一点spark和flink都可以做到，但是做的方向有差别。flink完全基于算子，每一个算子之间整体静态图的优化；spark基于rdd框架进行优化，这还是有细微差别的。flink是支持watermarks的事件处理模式。

最近有些业务系统有用kafka stream，flink和kafka stream都可以达到端到端的不丢不重，都latency比较小，kafka stream更轻量级一些。但是，kafka stream不能完成更high level的优化，整体来说kafka stream的成熟度还是低一些。

最终无论是katfa stream、samza、apache nifi等，相比而言apache flink都是在流处理框架里最好、也是特性最完整的框架。

简单总结一下flink框架比较大的优点，是完全从流的角度考虑streaming first思想，能够保证端到端的exactly-once，能够有横向扩容的能力，支持非常大的状态管理，能够进行增量式的checkpoint，保证在做checkpoint的时候对系统的性能latency比较小，可以达到非常低的延时同时非常高的吞吐率。

任何一个技术都会有自己的局限性，其中flink还是基于线程模型，资源调度是在jvm的线程池进行调度，这就会有资源隔离的潜在问题。未来flink基于k8s的调度框架，或许可以更加完美地解决资源隔离问题，让每一个flink task manager运行在一个容器内。从flink1.7之后，提供了新特性，进行状态的新旧演进特性，保证了新旧状态的平滑升级。

我们在实践中会不断探索一些问题，一方面要达到高性能、低延迟、横向扩容的能力，但完全基于开源和开发的实施成本也是比较高的，很多厂商基于开源的技术把框架做的更通用一些，解决用户的具体问题，完成最终递交给用户可用的产品。

另外一方面我们自己也遇到过开发和生产有很大差距，另外实时性的要求也是我们重点考虑的一方面，包括在金融业务里怎么保证数据的强一致性甚至一些批流如何统一。

我们自己是做数据分析的案例，所以datacanvas rt要专注于实时流框架里和数据科学的模型和应用打交道，完成流平台的实施性。我们也用到了一些内存计算，包含了基于新框架下的内存计算。

大概说一下流处理框架。我们做了简单的分层，目的是解决的是用户的具体问题，下面是开源的框架，包括集群的调度——像刚刚大家提到的容器化调度以及集群调度都是在此基础上完成的——还包括中间调度的算子怎么完成、窗口算子怎么完成，甚至做复杂规则管理、机器学习模型、复杂事件的处理。

我们的想法还是要让系统用起来，切实降低用户的使用门槛，所以产品中会设计拖拉拽式操作的可视化模型，从数据源开始、到数据处理、中间配置怎样的属性都是可以在框架里通过可视化界面拉出图来完成流框架的编写。

此外，还包含了可以重用的算子，比如说如果要进行时间窗口类的聚合、变换以及用户自己写算子机、二次开发以及和业务上紧密结合的规则引擎、简单的springel结合起来，都可以进行参数的配置得以完成。

第三，尽可能接入更多的数据源，包括消息队列、数据库cdc，其实用的是异地双活数据库进项的技术，可以把数据实时采集过来迅速地搭建复杂的分析应用，把实时的指标都展示出来。在实际中，“流”是7×24在跑，需要考虑热更新热部署，我们通过zookeeper/etcd一致性配置把热更新部署下去。

使用率比较高的部分是规则类的算子，用户可以直接拿过来灵活配置，包括基本的统计指标和需要调用的pmml模型，模型加载、即时生效都是偏分析类的，对数据统计、数据分析来说这是必不可少的算力。

基于flink基础架构完成自己dsl表述复杂的cep，因为来的都是事件，在事件里要挖出和前一事件时间的差别组成模式，重构成cep，检测cep的过程需要有一定的描述能力，比如a出现后接着又出现了b，几分钟内又出现了c，这个时候就是触发产生了新事件。

传统的开发定制会花一些时间，可以抽象成配置的语言完成定制cep的结构，规则包含了简单的springel、drools等，可以接收多种多样数据采集的机制，这里是解决数据乱序的问题。这是在实践中怎么完成taskslot进行共享，涉及到了如何进行全局资源的优化，如果把前后的taskslot放在同一节点的话，系统分布式的代价、通讯的代价就更小一些。

近期对产品也在进一步探索：一个是可以通过拖拽的形式描述任务流流失的业务，另一个是非标准的sql描述。在这当中拖拽dag形式有一定的灵活性；非标准的sql，和传统sql不太一样，是为了在流上描述更多的丰富性的变化，是类似的sql，但并不特别一样，这在业界是在逐渐发展过程中的。

flink里怎么做大规模分布式一致性呢？以往做单机一致性都是要和distributed做dag，flink里是通过增量式checkpoint完成的。我们的应用，比如做金融产品的推荐，在实时平台上就可以完成简单的开发并且迅速部署上线。

我们在交行卡中心完成的基于aiops分析的应用，从开发到最终部署上都在特别短的时间（3天内）完成，以往需要花很长时间才能看到的指标，现在都可以很快地看到。这是比较经典的案例。在实时报表统计种，报表里会涉及到比较多业务数据的正确性，所以我们做了一些增量计算的尝试。

总结一下，基于kappa架构和专家说的serverless、service mesh基于事件流的处理架构，在架构里和实时的流处理技术都配有互补的方面。在这里面包含各种各样的业务场景，我就不再一一赘述了。

我今天的分享就到这里，谢谢大家！