做网站 域名如何要回,重庆网站公司制作价格,如何提高网站排名的方法,公司网站模板 免费文章目录 前言使用场景如何选择流式处理框架 前言
在之前的文章中我们介绍了如何进行流式处理——从一般性的概念和模式说起#xff0c;并列举了一些Streams的例子#xff1a;
流式处理相关概念总结说明流式处理设计模式总结说明Kafka Streams 架构概览
接下来的文章将介绍… 文章目录 前言使用场景如何选择流式处理框架 前言
在之前的文章中我们介绍了如何进行流式处理——从一般性的概念和模式说起并列举了一些Streams的例子
流式处理相关概念总结说明流式处理设计模式总结说明Kafka Streams 架构概览
接下来的文章将介绍一些流式处理的实际应用场景以及我们该从哪些方面考虑选择哪些流式处理框架目前比较流行的流式处理框架有很多比如说 Flink, Spark Streaming Kafka Streaming 等。
使用场景
客户服务 假设我们刚刚向一家大型连锁酒店预订了一个房间并希望收到电子邮件确认和收据。但是在预订了几分钟之后我们还没有收到确认邮件于是打电话向客服确认。 客服的回复是“我在我们的系统中看不到订单将数据从预订系统加载到客服系统的批处理作业每天只运行一次所以请明天再打电话过来。你应该可以在2~3个工作日之后收到确认邮件。”这样的服务质量有点儿糟糕而我们已经不止一次在一家大型连锁酒店遭遇过类似的问题。 我们希望连锁酒店的每一个系统在预订之后的几秒或几分钟之内都能发出通知包括客服中心、酒店、发送确认邮件的系统、网站等。我们还希望客服中心能够立即拉取到我们在这家连锁酒店的历史入住数据知道我们是忠实顾客从而为我们升级服务。 如果用流式处理应用程序来构建这些系统它们就可以几近实时地接收和处理事件带来更好的用户体验。有了这样的系统顾客就可以在几分钟之内收到确认邮件并及时从信用卡中扣除费用然后发送票据服务台就可以马上回答有关房间预订情况的问题了。 物联网 物联网包含了很多东西从可调节温度和订购洗衣剂的家居设备到制药行业的实时质量监控设备。 流式处理在这方面最为常见的应用是预测何时该进行设备维护。这与应用程序监控有点儿相似只是监控的对象是硬件这在很多行业中很常见包括制造业、通信识别故障基站、有线电视在用户投诉之前识别出故障机顶盒等。 每一种场景都有自己的模式但目标是一样的即处理大量来自设备的事件并识别出故障设备的模式比如交换机丢包、制造过程中需要更大的力气来拧紧螺丝或者用户频繁重启有线电视机顶盒。 欺诈检测 欺诈检测也叫异常检测是一个非常广泛的领域专注于捕获系统中的“作弊者”或不良分子。 欺诈检测的应用包括信用卡欺诈检测、股票交易欺诈检测、视频游戏欺诈检测和网络安全风险。在这些欺诈行为造成大规模破坏之前越早识别出它们越好。一个几近实时的可以快速对事件做出响应比如停止一个还没有通过审核的交易的系统比在3天之后才能检测出欺诈行为的批处理系统要好得多。这也是一个在大规模事件流中识别模式的问题。 在网络安全领域有一个被称为发信标(beacon)的欺诈手法。黑客在组织内部植入恶意软件恶意软件会时不时地连接到外部网络接收命令。由于恶意软件可以在任意时间以任意频率接收命令因此很难被检测到。 通常网络可以抵挡来自外部的攻击但难以阻止从内部到外部的突围。通过处理大量的网络连接事件流识别出不正常的通信模式例如检测出主机访问了平常不经常访问的某些IP地址我们可以在蒙受更大的损失之前向安全组织发出告警。
如何选择流式处理框架
在选择流式处理框架时需要着重考虑应用程序的类型。不同类型的应用程序需要不同的流式处理解决方案。 数据摄取
数据摄取的目的是将数据从一个系统移动到另一个系统并在传输过程中对数据做一些修改使其更适用于目标系统。
低延迟处理
任何要求立即得到响应的应用程序。有些欺诈检测系统就属于这一类。
异步微服务
这些微服务负责执行大型业务流程中的一些简单的操作比如更新库存信息。这些应用程序需要通过维护本地状态缓存来提升性能。
几近实时的数据分析
这些流式应用程序通过执行复杂的聚合和连接操作来对数据进行切分并生成有趣的业务见解。
选择什么样的流式处理系统在很大程度上取决于你要解决什么问题
如果你要解决数据摄取问题那么就要考虑是需要流式处理系统还是更简单的专注于数据摄取的系统比如Connect。如果你确定需要流式处理系统那么就要确保它和目标系统都有可用的连接器。如果你要进行低延迟处理那么就要考虑是否一定要使用流。一般来说请求与响应模式更适合用来处理这种任务。如果你确定需要流式处理系统那么就选择一种支持逐事件低延迟模型而不是微批次模型的流式处理系统。如果你要构建异步微服务那么就需要可以与消息总线希望是Kafka集成的流式处理系统它应该具备变更捕获能力可以将上游的变更更新到微服务的本地缓存里并且支持本地存储可以作为微服务数据的缓存和物化视图。如果你要构建复杂的数据分析引擎那么就需要支持本地存储的流式处理系统不过这次不是为了本地缓存和物化视图而是为了支持高级聚合、时间窗口和连接因为如果没有本地存储就很难实现这些特性。流式处理系统的API需要支持自定义聚合、时间窗口操作和多种连接类型。
除了具体的应用场景还需要从全局考虑如下事项。 系统的可操作性
它是否容易部署是否容易监控和调试是否容易扩展是否能够与已有的基础设施集成如果出现错误需要重新处理数据该怎么办
API的可用性和可调试性
用同一种框架的不同版本开发高质量的应用程序所耗费的时间可能千差万别。因为开发时间和发布时机太重要了所以需要选择一个高效的系统。
化繁为简
大部分系统声称它们支持基于时间窗口的高级聚合和本地缓存但问题是它们够简单吗它们是帮你处理了伸缩和故障恢复方面的问题还是只提供了脆弱的抽象并让你自己处理剩下的脏活系统提供的API越简洁封装的细节越多开发人员的效率就越高。
社区
大部分流式处理框架是开源的。对开源软件来说一个充满生机的社区是不可替代的。好的社区意味着用户可以定期获得新的功能特性而且质量相对较高没有人会使用糟糕的软件bug可以很快地得到修复用户的问题可以及时得到解答。如果你遇到一个奇怪的问题并在谷歌上搜索那么可以搜索到相关的信息因为其他人也在使用这个系统并遇到过同样的问题。
