应用依赖于实时流数据, 以下是管理它们的方法

几乎每个行业部门都在经历对实时数据处理的日益增长的需求。事实上, idc 的一份白皮书预测, 到 2025年, 将生成25% 的数据, 需要实时处理。

同时, 大规模运行实时应用的能力, 以及使用易于获得的开源技术, 正在为新一代实时应用提供动力。此外, 无论是用于收集数据的简单应用、可提供客户行为洞察的机器学习应用, 还是提供物联网和设备数据视图的应用, 都可以快速构建实时应用。

到目前为止, 这很好, 对吧？嗯, 是的, 但现在是时候退一步, 根据流媒体和实时应用如何提高大数据操作的性能来考虑管理流媒体和实时应用的挑战了。此功能非常关键, 因为比系统性能面临的风险要大得多: 许多应用 (包括流媒体应用) 都是关键任务, 如果失败, 个人安全、系统安全或整个组织的生存能力可能会受到威胁。处于危险之中。

一切都依赖于数据

如果说企业网络上曾经有过一种普遍的、不可阻挡的力量, 那就是数据。每年流入组织的是数据的看似量子化的增加。而即使从现在开始, 即使能衡量本周摄入了多少数据, 也没有人能够了解到一周后会有多少数据流入该组织。来自越来越多外部来源和设备的数据不断流入越来越多的平台, 需要对其进行分析。这些数据为数据库供电, 或发送到存储或 nosql 系统, 或者可以放入队列以驱动工作流。仅举几个例子:

在物联网中, 异常检测和预防是关键任务需求, 使网络人员能够在网络上发现故障设备。
来自医疗保健设备的信息可以快速识别一个人的健康, 并允许专业人员在正确的时间服用正确的药物。
在制造过程中, 实时异常检测可识别流程何时出现故障, 并可能导致数百万美元的损失。
在安全方面, 欺诈检测可以使用来自群集中所有计算机的日志和其他安全信息实时发现入侵。
在电子商务中, 关于客户情绪的最新建议可以显著提高转化率。

流数据体系结构

任何应用程序性能管理 (apm) 的体系结构都需要具有应用程序、用户、服务、计算、处理和存储级别的可见性。因此, 来自传感器或数据库事件的所有数据都流入流存储区。一个著名的流存储示例是 apache kafka, 这是一个开源流处理软件平台。

流式交互存储的一个示例是 apache hbase (一个开源的、非关系的分布式数据库) 或 apache kudu (面向开源的列的数据存储区)。这些存储使数据能够实时存储和访问–不是以连续的方式, 而是更多的是在 “输入和放置” 模型方面。其他系统 (如开源集群计算框架 spark 流和 flink (开源流处理框架) 等系统则非常受欢迎, 可以实时收集数据并对其进行分析。数据可以发送到仪表板、新数据库或新生态系统。

但请注意: 当您创建一个结合了存储和计算系统的流应用程序时, 很快就会发现这些都是由应用程序连接的单独分布式系统

对于大多数实际用途, 这意味着应用程序应该生成的结果需要很长的时间才能派生–因此, 您设计的实时应用程序实际上并不是实时的!了解这些问题的原因可能是一个挑战, 尤其是在分布式系统中, 如卡夫卡或 spark 流。可能数据的分区很差, 或者已经分区了, 以利用并行处理。

配置参数是另一个问题。这些系统中有许多配置参数, 特别是影响一个系统与另一个系统交互的参数。由于缺乏更好的术语, 所有配置都必须 “调优”。创建应用程序时, 随着时间的推移,此应用程序的规模不断扩大, 调优可能会变得极具挑战性。更改一个参数可能会影响另一个参数。这也是一种虚拟的保证, 因为涉及大量资源和不同类型的资源–从磁盘和存储到网络带宽, 再到计算和内存–会发生资源争用和瓶颈。

通过另一个镜头查看问题, 您会发现没有一个工具能够从这些单独的系统 (与实时流应用程序相关的指标和日志) 中引入所有指标和日志, 从而获得以应用程序为中心的自上而下的视图。例如, 为什么数据没有实时生成, 为什么应用程序会停止, 或者发生数据丢失的地方。

而踢球者: 如果在大数据堆栈上没有高级分析或机器学习, 几乎不可能得到问题根本原因所在的建议。

全堆栈智能

应用程序、数据和 devops 团队需要的是完全自动化的解决方案, 可以发现这些问题, 甚至实时修复这些问题。简而言之, 他们需要对整个大数据堆栈进行应用程序性能管理, 这是提供全堆栈智能的引擎。借助全堆栈智能, 操作人员可以快速找出问题的根本原因, 并指导操作人员找到解决这些问题的方法。它允许您回答这样一个问题: “计算、存储或两者的交互中的问题是问题吗？”如果你不知道, 就不可能采取补救措施, 比如对个别系统实施政策。

派生完整堆栈智能涉及从大数据堆栈的每个级别收集监视信息指标、日志、sql 执行计划和其他信息。可以围绕卡夫卡构建一个用于数据采集的完整堆栈智能平台, 用于实时计算的 spark 流, 以及用于实时管理应用程序状态的 cassandra kudu。

在操作中, 这些系统中的所有指标和日志都可以连续流式传输到 apm 平台, 在该平台中, 它将获取此性能数据, 实时关联数据点, 并在数据上应用机器学习和人工智能算法帮助大数据和 devops 团队优化故障排除, 以及进行容量规划。

但这种架构的关键是一个单一的、整合的堆栈视图, 所有数据都进入一个平台。这正是确保全堆栈智能的基础。另一种选择–登录到多个系统并查看多个视图 (其中指标之间不相关)-从一开始就是徒劳的。

这就是为什么 apm (尤其是流式或实时数据) 需要在数据流上部署机器学习算法和人工智能, 以自动查明错误的根本原因并确定如何修复错误。

apm 的体系结构如果使用 “自动操作” 获得额外的信任–之所以这样调用, 是因为它们使平台能够根据运营团队设置策略的方式自动执行操作

因此, 在决定为大数据堆栈或群集上的实时和流式传输应用程序 “构建或购买” apm 平台时, 请再次考虑该平台必须提供的内容:

完整的堆栈管理, 它超越了单纯的基础结构监视图和日志。
智能, 基于集成的机器学习和预测分析构建, 用于解决问题。
自动化, 使我们能够超越无故障票证升级和主动操作。

这就是宏观观点的良方。但是, 为了衡量您的平台如何有效地实现 apm 的愿景, 特别是对于流媒体和实时应用程序, 以下是 apm 平台必须提供的需求的微观视图:

流式应用故障的自动根本原因分析。
异常检测, 可快速检测和诊断不可预知的行为。
使流应用更快、更节省资源的智能建议。
对流媒体应用引起的群集问题的主动警报和修正, 以及对 sla 影响的识别。
用于统一应用和运营管理的单一玻璃视图。

如果您的 apm 平台提供了这些功能, 您将能够管理在平台上接收的越来越多的数据。这就是为什么, 当 apm 的原则被定义时, 创新者知道, 该技术在管理不可预见的数据增长、提供持续的高性能以满足内部或外部 sla 以及提供近乎实时的性能方面不能动摇响应能力, 以防止灾难性的系统故障。