网站建设预期效果,如何搜索网页关键词,惠州有没有做网站,太原网站seo外包本文分为四个章节介绍实时计算#xff0c;第一节介绍实时计算出现的原因及概念#xff1b;第二节介绍实时计算的应用场景#xff1b;第三节介绍实时计算常见的架构#xff1b;第四节是实时数仓解决方案。
一、实时计算
实时计算一般都是针对海量数据进行的#xff0c;并…本文分为四个章节介绍实时计算第一节介绍实时计算出现的原因及概念第二节介绍实时计算的应用场景第三节介绍实时计算常见的架构第四节是实时数仓解决方案。
一、实时计算
实时计算一般都是针对海量数据进行的并且要求为秒级。由于大数据兴起之初Hadoop并没有给出实时计算解决方案随后StormSparkStreamingFlink等实时计算框架应运而生而KafkaES的兴起使得实时计算领域的技术越来越完善而随着物联网机器学习等技术的推广实时流式计算将在这些领域得到充分的应用。
一、实时计算的三个特征
无限数据无限数据指的是一种不断增长的基本上无限的数据集。这些通常被称为“流数据”而与之相对的是有限的数据集。
无界数据处理一种持续的数据处理模式,能够通过处理引擎重复的去处理上面的无限数据是能够突破有限数据处理引擎的瓶颈的。
低延迟延迟是多少并没有明确的定义。但我们都知道数据的价值将随着时间的流逝降低时效性将是需要持续解决的问题。
现在大数据应用比较火爆的领域比如推荐系统在实践之初受技术所限可能要一分钟一小时甚至更久对用户进行推荐这远远不能满足需要我们需要更快的完成对数据的处理而不是进行离线的批处理。
二、实时计算应用场景
随着实时技术发展趋于成熟实时计算应用越来越广泛以下仅列举常见的几种实时计算的应用常见
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 引擎实现灵活性优于基于流计算的方式
在对数据晚到的容忍度方面因为准实时数据可以基于一个周期内的数据进行全量计算因此对于数据晚到的容忍度也是比较高的而实时数据使用的是增量计算对于数据晚到的容忍度更低一些
在适用场景方面准实时数据主要用于有实时性要求但不太高、涉及多表关联和业务变更频繁的场景如交易类型的实时分析实时数据则更适用于实时性要求高、数据量大的场景如实时特征、流量类型实时分析等场景。
实时架构
在某些场景中数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上逐渐对数据的实时性提出了更高的要求。
于是随之诞生了大数据实时数仓并且衍生出了两种技术架构Lambda和Kappa。
1. Lambda架构
先来看下Lambda架构图 数据从底层的数据源开始经过Kafka、Flume等数据组件进行收集然后分成两条线进行计算
一条线是进入流式计算平台例如 Storm、Flink或者SparkStreaming去计算实时的一些指标 另一条线进入批量数据处理离线计算平台例如Mapreduce、HiveSpark SQL去计算T1的相关业务指标这些指标需要隔日才能看见。
为什么Lambda架构要分成两条线计算
假如整个系统只有一个批处理层会导致用户必须等待很久才能获取计算结果一般有几个小时的延迟。电商数据分析部门只能查看前一天的统计分析结果无法获取当前的结果这对于实时决策来说有一个巨大的时间鸿沟很可能导致管理者错过最佳决策时机。
Lambda架构属于较早的一种架构方式早期的流处理不如现在这样成熟在准确性、扩展性和容错性上流处理层无法直接取代批处理层只能给用户提供一个近似结果还不能为用户提供一个一致准确的结果。因此Lambda架构中出现了批处理和流处理并存的现象。
在 Lambda 架构中每层都有自己所肩负的任务。
1. 批处理层存储管理主数据集不可变的数据集和预先批处理计算好的视图
批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的能够修复任何错误然后更新现有的数据视图。输出通常存储在只读数据库中更新则完全取代现有的预先计算好的视图。
2. 流处理层会实时处理新来的大数据
流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后在速度层的数据就可以被替代掉了。
那Lambda架构有没有缺点呢
Lambda架构经历多年的发展其优点是稳定对于实时计算部分的计算成本可控批量处理可以用晚上的时间来整体批量计算这样把实时计算和离线计算高峰分开这种架构支撑了数据行业的早期发展但是它也有一些致命缺点并在大数据3.0时代越来越不适应数据分析业务的需求。缺点如下
使用两套大数据处理引擎维护两个复杂的分布式系统成本非常高。
批量计算在计算窗口内无法完成在IOT时代数据量级越来越大经常发现夜间只有4、5个小时的时间窗口已经无法完成白天20多个小时累计的数据保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
数据源变化都要重新开发开发周期长每次数据源的格式变化业务的逻辑变化都需要针对ETL和Streaming做开发修改整体开发周期很长业务反应不够迅速。
导致 Lambda 架构的缺点根本原因是要同时维护两套系统架构批处理层和速度层。我们已经知道在架构中加入批处理层是因为从批处理层得到的结果具有高准确性而加入速度层是因为它在处理大规模数据时具有低延时性。
那我们能不能改进其中某一层的架构让它具有另外一层架构的特性呢
例如改进批处理层的系统让它具有更低的延时性又或者是改进速度层的系统让它产生的数据视图更具准确性和更加接近历史数据呢
另外一种在大规模数据处理中常用的架构——Kappa 架构便是在这样的思考下诞生的。
2. Kappa架构
Kafka的创始人Jay Kreps认为在很多场景下维护一套Lambda架构的大数据处理平台耗时耗力于是提出在某些场景下没有必要维护一个批处理层直接使用一个流处理层即可满足需求即下图所示的Kappa架构 这种架构只关注流式计算数据以流的方式被采集过来实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本只是去除掉了Lambda架构中的离线批处理部分
Kappa架构的兴起主要有两个原因
Kafka不仅起到消息队列的作用也可以保存更长时间的历史数据以替代Lambda架构中批处理层数据仓库部分。流处理引擎以一个更早的时间作为起点开始消费起到了批处理的作用。 Flink流处理引擎解决了事件乱序下计算结果的准确性问题。
Kappa架构相对更简单实时性更好所需的计算资源远小于Lambda架构随着实时处理的需求在不断增长更多的企业开始使用Kappa架构。但这不意味着kappa架构能够取代Lambda架构。
Lambda和kappa架构都有各自的适用领域例如流处理与批处理分析流程比较统一且允许一定的容错用Kappa比较合适少量关键指标例如交易金额、业绩统计等使用Lambda架构进行批量计算增加一次校对过程。
还有一些比较复杂的场景批处理与流处理产生不同的结果使用不同的机器学习模型专家系统或者实时计算难以处理的复杂计算可能更适合Lambda架构。
四、实时数仓解决方案
实时数仓分层架构为了避免面向需求响应的烟囱式构建实时数仓也引入了类似于离线数仓的分层理念主要是为了提高模型的复用率同时也要考虑易用性、一致性以及计算成本。
当然实时数仓的分层架构在设计上并不会像离线数仓那么复杂避免数据在流转过程中造成的不必要的延时响应
实时数仓分层架构图 ODS层以Kafka为支撑将所有需要实时处理的相关数据放到Kafka队列中来实现贴源数据层
DWD层实时计算订阅业务数据消息队列然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合将一些相同粒度的业务系统、维表中的维度属性全部关联到一起增加数据易用性和复用性得到最终的实时明细数据
DIM层存放用于关联查询的维度信息可以根据数据现状来选择存储介质例如使用HBase或者Mysql
DWS层轻度汇总层是为了便于面向AdHoc查询或者Olap分析构建的轻度汇总结果集合适合数据维度、指标信息比较多的情况为了方便根据自定义条件的快速筛选和指标聚合推荐使用MPP类型数据库进行存储此层可视场景情况决定是否构建
APP层面向实时数据场景需求构建的高度汇总层可以根据不同的数据应用场景决定使用存储介质或者引擎例如面向业务历史明细、BI支持等Olap分析场景可以使用Druid、Greenplum面向实时监控大屏、高并发汇总指标等需求可以使用KV模式的HBase数据量较小的时候也可以使用Mysql来进行存储。
这里要注意下其实APP层已经脱离了数仓这里虽然作为了数仓的独立分层但是实际APP层的数据已经分布存储在各种介质中用于使用。
基于Flink 构建的实时数仓
随着业务场景的丰富更多的实时需求不断涌现在追求实时任务高吞吐低延迟的同时对计算过程中间状态管理灵活时间窗口支持以及 exactly once 语义保障的诉求也越来越多。
为什么选择Flink实时计算平台之所以选择用Flink替代原有Storm、SparkStreaming是基于以下原因考虑的这也是实时数仓关注的核心问题
1、高吞吐、低延时 2、端到端的 Exactly-once保证了数据的准确性 3、可容错的状态管理实时数仓里面会进行很多的聚合计算这些都需要对于状态进行访问和管理 4、丰富的API对Streaming/Table/SQL支持良好支持UDF、流式join、时间窗口等高级用法 5、完善的生态体系实时数仓的构建会涉及多种存储Flink在这方面的支持也比较完善。
基于Flink的实时数仓数据流转过程: 数据在实时数仓中的流转过程实际和离线数仓非常相似只是由Flink替代Hive作为了计算引擎把存储由HDFS更换成了Kafka但是模型的构建思路与流转过程并没有发生变化。
