【系统架构设计师】二十五、大数据架构设计理论与实践③

帅次

于 2024-08-09 08:00:00 发布

阅读量796

点赞数 24

分类专栏：系统架构设计师(新版) 文章标签：系统架构大数据系统架构设计师 big data 案例分析

本文链接：https://blog.csdn.net/g984160547/article/details/140946200

版权

系统架构设计师(新版) 专栏收录该内容

61 篇文章 8 订阅

订阅专栏

六、大数据架构设计案例分析

6.1 Lambda架构在某网奥运中的大数据应用

6.2 Lambda架构在某网广告平台的应用与演进

六、大数据架构设计案例分析

6.1 Lambda架构在某网奥运中的大数据应用

某网采用以 Lambda 架构搭建的大数据平台处理里约奥运会大规模视频网络观看数据，具体
平台架构设计如下图所示。

Lambda 架构实时处理层采用增量计算实时数据的方式，可以在集群规模不变的前提下，秒级分析出当日概览所需要的信息。赛事回顾模块需要展现自定义时间段内的历史最高在线人数、逐日播放走势、直播最高在线人数和点播视频排行等海量数据的统计信息，由于奥运期间产生的数据通常不需要被经常索引、更新，因此要求采用不可变方式存储所有的历史数据，以保证历史数据的准确性。
Lambda 架构的批处理层采用不可变存储模型，不断地往主数据集后追加新的数据，恰好可以满足对奥运数据的大规模统计分析要求。

数据计算层可以分为离线计算、实时计算、合并计算 3 个部分。

（1）离线计算部分：用于存储持续增长的批量离线数据，并且会周期性地使用 Spark 和Map/Reduce 进行批处理，将批处理结果更新到批视图之后使用 Impala 或者 Hive 建立数据仓库，将结果写入 HDFS 中。

（2）实时计算部分：采用 Spark Streaming，只处理实时增量数据，将处理后的结果更新到实时视图。

（3）合并计算部分：合并批视图和实时视图中的结果，生成最终数据集，将最终数据集写入HBase 数据库中用于响应用户的查询请求。

6.2 Lambda架构在某网广告平台的应用与演进

某网广告平台展示的数据指标包含两类：曝光类(包括曝光数、点击数、点击单价、花费)，转化类(包括转化下单数、转化下单金额、转化付款数、转化付款金额)。前一类的数据主要由流量方以接口的方式提供(比如对接的腾讯广点通平台)，后一类则是某网特有的数据，通过买家的浏览、下单、付款日志算出来。

6.2.1 第一版架构

第一版采用了典型的 Lambda 架构形式，架构图如下图所示。

        （1）批处理层：每天凌晨将 Kafka 中浏览、下单等消息同步到 HDFS 中，将 HDFS 中数据解析为 Hive 表，然后使用 HQL 或 Spark SQL 计算分区统计结果 Hive 表，将 Hive 表转储到MySQL中作为批视图。
        （2）加速层：使用 Spark Streaming 实时监听 Kafka 下单、付款等消息，计算每个追踪链接维度的实时数据，将实时计算结果存储在 Redis 中作为实时视图。
        （3）服务层：采用 Java Web 服务，对外提供 HTTP 接口，Java Web 服务读取 MySQL 批视图表和 Redis 实时视图表。

6.2.1 第二版架构

针对第一版的两个问题，在第二版对数据流的结构做了一些修改。在实时处理层做了一个常驻后台的Python脚本，不断调用第三方API的小时报表，更新当日的曝光数据表。

完成第二版改动之后， Java服务的计算压力明显下降。性能的瓶颈变成了查询redis数据。
由于redis里面的实时数据是业务无关的，仅统计了追踪链接维度的聚合数据。每次查询当日的转化数据，需要现在MySQL 中查询出广告和跟踪链接的关系，找出所有的跟踪链接，再查询出这些跟踪链接的统计数据做聚合。

另一方面，离线计算的过程中涉及多次MySQL 和 Hive之间的导表操作，离线任务依赖链
比较长，一旦出错，恢复离线任务的时间会比较久。

6.2.3 第三版架构

考虑到MySQL 方便聚合、方便服务层读取的优点，在第三版中对Lambda 架构做了一些改动，在数据层面只维护一张包含所有指标的 MySQL 表。MySQL 表的stday(统计日期)字段作为索引， stday= 当天的保存实时数据， st_day<当天的保存离线数据。

第三版只维护一张MySQL 数据统计表，每天的离线任务会生成两张hive表，分别包含转
化数据和曝光数据。这两张Hive表分别更新MySQL 表的st_day。

在实时数据这块，常驻后台的 Python脚本更新stday=当天的数据的曝光类字段。 spark streaming程序在处理kafka中的实时下单消息时，不再统计数据到redis,而是请求业务Java服务暴露出来的更新数据接口。在更新数据的接口中，找到当前下单的追踪链接所属的广告，更新MySQL 中 stday= 当天的数据的转化类字段。这样就把查询阶段的关联操作分散在了每条订单下单的处理过程中，解决了实时数据查询的瓶颈。最终的 Java服务层也只需要读取一个MySQL 表，非常简洁。

6.3 某证券公司大数据系统

实时日志分析平台基于Kappa 架构，使用统一的数据处理引擎Flink可实时处理全部数据，并将其存储到 Elastic-Search与 OpenTSDB 中。实时日志分析平台技术架构如下图所示。

        实时处理过程如下：
（1）日志采集，即在各应用系统部署采集组件Filebeat,实时采集日志数据并输出到 Kafka缓存。
        （2）日志清洗与解析，即基于大数据计算集群的Flink计算框架，实时读取Kafka 中的日志数据进行清洗和解析，提取日志关键内容并转换成指标，以及对指标进行二次加工形成衍生指标。
        （3）日志存储，即将解析后的日志数据分类存储于Elastic-Search日志库中，各类基于日志的指标存储于 OpenTSDB 指标库中，供前端组件搜索与查询。
        （4）日志监控，即通过单独的告警消息队列来保持监控消息的有序管理与实时推送。
        （5）日志应用，即在充分考虑日志搜索专业需求的基础上，平台支持搜索栏常用语句保存，选择日志变量自动形成搜索表达式，以及快速按时间排序过滤、查看日志上下文等功能。同时，基于可视化分析和全息场景监控可实时展现各种指标和趋势，并在预警中心查看各类告警的优先级和详细信息，进而结合告警信息关联查询系统日志内容来分析解决问题。此外，开发配置中心还提供了自定义日志解析开发功能，并支持告警规则、告警渠道配置。

6.4 某电商智能决策大数据系统

实时智能决策大数据平台基于Kappa 架构，使用统一的数据处理引擎Flink可实时处理流数据，并将其存储到Hive与 Tair中，以供后续决策服务的使用。智能决策大数据平台技术架构如下图所示。

实时处理的过程如下：
（1）数据采集，即B 端系统会实时收集用户的点击，下单以及广告的曝光和出价数据并输出到Kafka 缓存。
（2）数据的清洗与聚合，即基于大数据计算集群 Flink计算框架，实时读取Kafka 中的实时流数据，过滤出需要参与计算的字段，根据业务需求，聚合指定时间端的数据并转换成指标。
（3）数据存储，即将Flink计算得到数据存储到 Hive日志库中，需要参与模型计算计算的字段存储到 Tair分布式缓存中。当需要进行模型计算时，决策服务会从Tair中读取数据，进行模型的计算，得到新的决策参数和模型。决策服务基于微服务架构，客户端部署在业务方系统中，服务端主要用于计算决策参数和模型，当服务端计算得到新的参数，此时会通过Zookeeper通知部署到业务方系统的客户端，客户端此时会拉取新的参数并存储到本地，并且客户端提供了获取参数的接口，业务方可以无感知调用。