本文分为四个章节介绍实时计算，第一节介绍实时计算出现的原因及概念；第二节介绍实时计算的应用场景；第三节介绍实时计算常见的架构；第四节是实时数仓解决方案。
一、实时计算
实时计算一般都是针对海量数据进行的，并且要求为秒级。由于大数据兴起之初，Hadoop并没有给出实时计算解决方案，随后Storm，SparkStreaming，Flink等实时计算框架应运而生，而Kafka，ES的兴起使得实时计算领域的技术越来越完善，而随着物联网，机器学习等技术的推广，实时流式计算将在这些领域得到充分的应用。
实时计算的三个特征：
- 无限数据：无限数据指的是一种不断增长的，基本上无限的数据集。这些通常被称为“流数据”，而与之相对的是有限的数据集。
- 无界数据处理：一种持续的数据处理模式,能够通过处理引擎重复的去处理上面的无限数据，是能够突破有限数据处理引擎的瓶颈的。
- 低延迟：延迟是多少并没有明确的定义。但我们都知道数据的价值将随着时间的流逝降低，时效性将是需要持续解决的问题。
现在大数据应用比较火爆的领域，比如推荐系统在实践之初受技术所限，可能要一分钟，一小时，甚至更久对用户进行推荐，这远远不能满足需要，我们需要更快的完成对数据的处理，而不是进行离线的批处理。
二、实时计算应用场景
随着实时技术发展趋于成熟，实时计算应用越来越广泛，以下仅列举常见的几种实时计算的应用常见：
1. 实时智能推荐
智能推荐会根据用户历史的购买或浏览行为，通过推荐算法训练模型，预测用户未来可能会购买的物品或喜爱的资讯。对个人来说，推荐系统起着信息过滤的作用，对Web/App服务端来说，推荐系统起着满足用户个性化需求，提升用户满意度的作用。推荐系统本身也在飞速发展，除了算法越来越完善，对时延的要求也越来越苛刻和实时化。利用Flink流计算帮助用户构建更加实时的智能推荐系统，对用户行为指标进行实时计算，对模型进行实时更新，对用户指标进行实时预测，并将预测的信息推送给Web/App端，帮助用户获取想要的商品信息，另一方面也帮助企业提升销售额，创造更大的商业价值。
2. 实时欺诈检测
在金融领域的业务中，常常出现各种类型的欺诈行为，例如信用卡欺诈，信贷申请欺诈等，而如何保证用户和公司的资金安全，是近年来许多金融公司及银行共同面对的挑战。随着不法分子欺诈手段的不断升级，传统的反欺诈手段已经不足以解决目前所面临的问题。以往可能需要几个小时才能通过交易数据计算出用户的行为指标，然后通过规则判别出具有欺诈行为嫌疑的用户，再进行案件调查处理，在这种情况下资金可能早已被不法分子转移，从而给企业和用户造成大量的经济损失。而运用Flink流式计算技术能够在毫秒内就完成对欺诈行为判断指标的计算，然后实时对交易流水进行实时拦截，避免因为处理不及时而导致的经济损失。
3. 舆情分析
有的客户需要做舆情分析，要求所有数据存放若干年，舆情数据每日数据量可能超百万，年数据量可达到几十亿的数据。而且爬虫爬过来的数据是舆情，通过大数据技术进行分词之后得到的可能是大段的网友评论，客户往往要求对舆情进行查询，做全文本搜索，并要求响应时间控制在秒级。爬虫将数据爬到大数据平台的Kafka里，在里面做Flink流处理，去重去噪做语音分析，写到ElasticSearch里。大数据的一个特点是多数据源，大数据平台能根据不同的场景选择不同的数据源。
4. 复杂事件处理
对于复杂事件处理，比较常见的集中于工业领域，例如对车载传感器，机械设备等实时故障检测，这些业务类型通常数据量都非常大，且对数据处理的时效性要求非常高。通过利用Flink提供的CEP进行时间模式的抽取，同时应用Flink的Sql进行事件数据的转换，在流式系统中构建实施规则引擎，一旦事件触发报警规则，便立即将告警结果通知至下游通知系统，从而实现对设备故障快速预警检测，车辆状态监控等目的。
5. 实时机器学习
实时机器学习是一个更宽泛的概念，传统静态的机器学习主要侧重于静态的模型和历史数据进行训练并提供预测。很多时候用户的短期行为，对模型有修正作用，或者说是对业务判断有预测作用。对系统来说，需要采集用户最近的行为并进行特征工程，然后给到实时机器学习系统进行机器学习。如果动态地实施新规则，或是推出新广告，就会有很大的参考价值。
三、实时计算架构
我们先来看一张大数据平台的实时架构图：
- 数据同步：
在上面这张架构图中，数据从Web平台中产生，通过数据同步系统导入到大数据平台，由于数据源不同，这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常用 Sqoop，日志同步可以选择 Flume等，不同的数据源产生的数据质量可能差别很大，数据库中的格式化数据直接导入大数据系统即可，而日志和爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。
- 数据存储：
该层对原始数据、清洗关联后的明细数据进行存储，基于统一的实时数据模型分层理念，将不同应用场景的数据分别存储在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存储中。
- 数据计算：
计算层主要使用 Flink、Spark、Presto 以及 ClickHouse 自带的计算能力等四种计算引擎，Flink 计算引擎主要用于实时数据同步、 流式 ETL、关键系统秒级实时指标计算场景，Spark SQL 主要用于复杂多维分析的准实时指标计算需求场景，Presto 和 ClickHouse 主要满足多维自助分析、对查询响应时间要求不太高的场景。
- 实时应用：
以统一查询服务对各个业务线数据场景进行支持，业务主要包括实时大屏、实时数据产品、实时 OLAP、实时特征等。
当然一个好的大数据平台不能缺少元数据管理及数据治理：
1. 元数据及指标管理：主要对实时的Kafka表、Kudu表、Clickhouse表、Hive表等进行统一管理，以数仓模型中表的命名方式规范表的命名，明确每张表的字段含义、使用方，指标管理则是尽量通过指标管理系统将所有的实时指标统一管理起来，明确计算口径，提供给不同的业务方使用；
2. 数据质量及血缘分析：数据质量分为平台监控和数据监控两个部分，血缘分析则主要是对实时数据依赖关系、实时任务的依赖关系进行分析。
以上架构只是大数据平台通用的数据模型，如果要具体的建设，需要考虑以下情况，业务需求需要实时还是准实时即可，数据时效性是秒级还是分钟级等。
- 在调度开销方面，准实时数据是批处理过程，因此仍然需要调度系统支持，调度频率较高，而实时数据却没有调度开销；
- 在业务灵活性方面，因为准实时数据是基于 ETL 或 OLAP 引擎实现，灵活性优于基于流计算的方式；
- 在对数据晚到的容忍度方面，因为准实时数据可以基于一个周期内的数据进行全量计算，因此对于数据晚到的容忍度也是比较高的，而实时数据使用的是增量计算，对于数据晚到的容忍度更低一些；
- 在适用场景方面，准实时数据主要用于有实时性要求但不太高、涉及多表关联和业务变更频繁的场景，如交易类型的实时分析，实时数据则更适用于实时性要求高、数据量大的场景，如实时特征、流量类型实时分析等场景。
