1. 什么是实时计算？

通过实时计算引擎对海量数据的实时增量计算。

实时增量数据源：消息队列、Binlog、数据湖 分布式实时计算引擎：Storm、JStorm、Spark Streaming、Struct Streaming、Flink、Blink、Beam

特征： 无界数据流：无界数据流指的是没有时间边界，不断增长的数据集。 无界数据处理：持续的数据处理模式,能够通过处理引擎不断处理上面的无界数据流。 低延迟：数据从读取到结果产出，时效基本可以达到亚秒级

大数据计算引擎发展史：

  1. 实时计算架构演进？ 从两个维度：计算层、存储层来看实时计算数据架构演变，大致经历了四个阶段：传统数据基础架构、微服务架构、大数据数据架构、有状态流式架构。

传统数据基础架构

常见于传统业务系统：Web 业务系统、订单系统、CRM 系统，ERP 系统、监控系统等 存储：数据库 计算：数据库 优点：

  • 效率高
  • 迭代快
  • 数据统一

缺点：

  • 随着业务越来越复杂、系统难以维护
  • 数据库是唯一准确的数据源、数据库变更对模块影响比较大

微服务架构&分库分表

常见于复杂业务平台：电商、大 ERP、微博、社交、支付、直播、游戏类平台场景 存储：数据库 计算：数据库

垂直拆分(业务分库) 业务解耦，将单一数据库拆分成多个数据库

优点：

  • 解决业务系统层面的耦合，业务清晰
  • 由单库单表拆分成多库多表，降低了数据库增删改查压力
  • 高并发场景下，垂直切分一定程度的提升 IO、数据库连接数、单机硬件资源的瓶颈

缺点：

  • 部分表无法 join，只能通过接口聚合方式解决，提升了开发的复杂度
  • 分布式事务处理复杂
  • 依然存在单表数据量过大的问题（需要水平切分）
  • 业务数据过于分散在不同的系统中，很难将数据集中化管理。

水平拆分(分库分表)

常用于单业务线数据量猛增，单表数据库遇到存储瓶颈活计算瓶颈的时候

优点：

  • 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
  • 应用端改造较小，不需要拆分业务模块 缺点：
  • 跨分片的事务一致性难以保证
  • 跨库的 join 关联查询性能较差
  • 数据多次扩展难度和维护量极大

大数据架构-Lambda

对于企业内部数据仓库，数据挖掘之类的应用，需要把各个业务系统数据库数据抽取到数据仓库之中，在数据仓库中进行数据的抽取、转换、加载（ETL），从而构建不同的数据集市应用，提供给业务系统用。

起初，数据是构建在关系型数据库之上，但随着企业数据量的暴增，关系型数据库已经无法支撑起大规模数据集的存储和分析，于是基于 Hadoop 构建企业级大数据平台便成为了共识。

后来，离线的高延迟渐渐的无法满足企业需求，例如一些时间要求比较高的应用，实时报表统计，需要非常低的延时展示结果。为此业界提出一套 lambda 架构方案来处理不同类型的数据。

包含了批量计算的 Batch Layer 和实时计算的 Speed Layer，通过在一套平台中，将批计算和流计算结合在一起。

大数据架构-Kappa 相当于在 Lambda 架构上去掉了批处理层（Batch Layer），只留下单独的流处理层（Speed Layer）。通过消息队列的数据保留功能，来实现上游重放（回溯）能力。

当流任务发生代码变动时，或者需要回溯计算时，原先的 Job N 保持不动，先新启动一个作业 Job N+1，从消息队列中获取历史数据，进行计算，计算结果存储到新的数据表中。

当计算进度赶上之前的 Job N 时，Job N+1 替换 Job N，成为最新的流处理任务。然后程序切换为从新的数据表中读取数据，停止历史作业 Job N，并删除旧的数据表。

  1. 实时计算数据处理流？

大数据编程模型:Map→Shuffle→Reduce 真实处理过程分解为六个离散阶段（MapRead，Map，MapWrite，ReduceRead，Reduce，ReduceWrite）

今日已付款订单趋势图

统计类时间关键词

  • 统计窗口(当日)
  • 最小粒度(分钟)
  • 更新频率(事件频率)
  1. 实时计算场景？

  • 实时监控：黑标拦截、异常预警等 case：

    • 法外狂徒张三买火车票被拒绝
    • 法外狂徒刷广告点击被拦截

  • 实时统计：实时 pv、uv、实时大屏等

  • 实时风控：交易反欺诈、全链路风控、薅羊毛等

  • 实时模型：驾驶行为模型、交通拥堵指数模型等

  • 实时推荐：商品关联推荐、用户行为推荐等

  1. 实时计算案例？ 实时大屏：测试商家大屏