1.3 实时分析——神话与现实

实时分析的最大真相是实际上没有什么东西是真正实时的，这仅仅是一个神话。实际上，只能说它接近于实时。通过分析可以得到这样的结论：只有提高解决方案的性能和减少操作延时，分析才能接近于实时。由于实际中计算、操作和网络的延迟，实际上不可能消除实时和近实时之间的差距。

在进一步讨论之前，我们带领读者快速了解一下这些所谓的实时分析解决方案的高层次需求。图1-2展现了满足高层次需求的一个系统，该系统可以使用各种结构化和非结构化数据集处理数百万个事务。首先，程序引擎应该超快，并能够处理非常复杂的连接操作和多样化的业务逻辑；其次，可以准确产生令人叹为观止的报告，在一瞬间恢复即席查询（AdHoc查询），并在没有延迟的情况下渲染可视化的仪表面板。

以前对实时解决方案的要求是不够的，如果把它们推广到生产环境中，即在当今的数据生成和零停机时代，最基本的要求是，系统应该能够以最小的代价实现自我管理或被管理，并且以容错和自动恢复的方式来构建，以处理大多数情况（即便不是所有情况）。它还应该能够提供类似于基本SQL的接口。

尽管前面对实时分析的要求听起来有些极端可笑，但是它们都是当今大数据解决方案最正常和最基本的要求。然而，回到实时分析这个主题，既然已经简要地谈到了数据、处理和输出方面的系统级要求，这些正在设计和已被设计的系统用于处理数以万计的事务并动态应用复杂的数据科学和机器学习算法，以尽可能接近实时地计算结果。图1-3描述了计算时间、上下文的概念以及最终见解的重要意义。

如图1-3所示，在有限时间背景下，存在以下问题。

●对泽字节（ZB）数据的即席查询占用了小时级的时间，因此这通常被称为批处理。图1-3中圆的大小比喻的是以图形式处理的数据的大小。

●广告展示次数/标签广告趋势/确定性工作流程/推文：这些大多被称为在线时间和计算时间的用例通常为500ms/1s。虽然与以前的用例相比，计算时间大大减少了，但是处理的数据量也显著减少了。它可以非常迅速处理几吉字节大小（GB）的数据流。

●财务跟踪/关键任务应用程序：典型特点是数据量很低，数据率非常高，处理非常快，并且在几毫秒的时间窗口中产生低延迟计算结果。

除了计算时间，批处理、实时处理以及解决方案设计之间还有一些显著的差异，见表1-2。

在本节，我们想强调的是近实时（NRT）解决方案是接近真正实时的，因为它实际上是可能实现的。所以，如上所述，RT实际上是一个神话（或假设），而NRT是一个现实。每天处理和查看的NRT应用程序，包括车联网、预测和推荐引擎、医疗保健和可穿戴设备。

有一些关键的环节实际上会引入延迟到总周转时间，或者称之为TAT。实际上，事件发生与产生可行的措施之间的时间间隔是由它产生的。

数据/事件通常通过有线（互联网/电信信道）从不同的地理位置传输到处理中心。这项活动已经过了一段时间。其处理如下。

●数据着陆：由于安全方面的原因，数据通常落在边缘节点上，然后被提取到集群中。

●数据清理：需要满足数据准确性方面的要求，在处理之前消除错误/不正确的数据。

●数据修改和丰富：使用维度数据来绑定和丰富交易数据。

●实际处理。

●存储结果。这里，所有以前的处理过程都会产生：CPU周期、磁盘I/O、网络I/O、数据序列化方面的主动编组和解组。

既然已经了解了实时分析的实际情况，接下来我们将更深入地了解这些解决方案的架构。