文章实时采集(数据技术篇——实时技术5.1简介流计算(下))

优采云 发布时间: 2021-11-21 07:08

  文章实时采集(数据技术篇——实时技术5.1简介流计算(下))

  五、数据技术篇-实时技术

  5.1 简介

  流计算,业务希望第一时间拿到处理后的数据,实时监控状态,做出运营决策,引导业务往好的方向发展。

  特征:

  效率高,延迟可达到毫秒级常驻任务。流式任务数据属于常驻进程任务,启动后会一直运行(数据源无界)。高性能要求,高吞吐低时延,性能有待优化 应用限制,无法替代离线处理(计算成本高),数据是流式处理,在context上下文中,到达时间的不确定性导致一定的实时和离线处理结果的区别

  根据数据的时延,有3种时效

  5.2 流技术架构@

  

  5.2.1 个数据采集

  数据从日志服务器采集到数据中间件供下游实时订阅使用

  及时性和吞吐量是数据处理的矛盾

  数据类型采集:

  如何对数据执行采集(按批次):

  消息系统是数据库变更节点的上游,特点是:低延迟和有限的吞吐量。有些业务不通过消息系统更新数据库,所以从消息系统获取的数据是不完整的,但是从数据库变更日志中获取的数据必须是完整的。

  5.2.2 数据处理

  提供流计算引擎,将其拉入流计算系统的任务中进行处理。实时应用的拓扑结构是一个有向无环图

  任务计算往往是多线程的,会根据业务主键分桶处理,数据在内存中(需要定时处理,可以根据LRU清理)。封装了一层SQL语义,降低了门槛。以下是一些经典问题:

  1. 去重指标:

  在计算重复数据删除时,必须保存重复数据删除的详细数据,这会导致内存消耗过多。这里有两种情况:

  精确去重,明细数据必须保存,可以通过数据倾斜来处理,一个节点的压力分到多个节点上。

模糊去重,精度要求不高的情况,相关算法去重。

  去重算法:

  布隆过滤器。位数组算法的应用不保存实际的明细数据,只保存明细数据对应的哈希表的标记位。适用于:统计维度值较多的情况,如全网各种业务的UV数据统计。可以在各个维度之间共享。基础估计。Hash 还用于根据数据分散程度估计现有数据集的边界,从而获得近似的总去重值。适用于:统计维度值很厚的情况,比如整个市场的UV数据。它不能在各个维度之间共享。

  2. 数据倾斜:

  当单个节点的数据量比较大时,就会遇到性能瓶颈。数据需要分桶。

  重复数据删除指标分为桶。通过对bucket中的去重值进行hash,将相同的值放到同一个bucket中进行去重,然后将每个bucket中的值相加。利用 CPU 和内存资源按非重复数据删除指标划分桶。随机分配到每个bucket,每个bucket汇总,使用每个bucket的CPU容量

  3. 交易处理:

  实时计算中的分布式处理,系统不稳定,如何实现精确的数据处理

  5.2.3 数据存储

  数据实时处理(聚合、清洗)并写入在线存储系统。写操作为增量操作,源源不断

  存储的三种类型的数据:

  实时任务使用的数据库特点:

  表名设计:汇总层标识+数据字段+主维度+时间维度(主维度相同的所有数据在一张物理表中)

  rowkey设计:MD5+主维度+维度标识+子维度1+时间维度+子维度2(MD5对数据进行hash,平衡服务器负载)

  5.2.4 数据服务

  设置统一的数据服务层获取结果

  优势:

  5.3 流式数据模型5.3.1 数据分层

  ODS层

  属于运营数据层,业务系统直接返回的最原创数据采集,粒度最细。实时和离线在源头统一(好处:同一条数据处理的指标口径基本一致,便于比较)。如:原创订单变更记录数据,订单强度变化过程,一个订单有多条记录。

  DWD层

  根据业务流程中建模的实时事实细节,将没有上下文的记录返回离线系统,最大程度保证ODS和DWD层实时离线的一致性。如:订单的付款时间表,用户访问日志时间表。订单强度支付记录,一个订单只有一条记录。

  DWS层

  计算各个维度的汇总指标。如果维度对所有垂直业务线通用,则将其放置在实时通用汇总层中。比如一个电商数据(卖家实力)几个维度的汇总表。卖家的实时交易金额,每个卖家一个记录。

  ADS层

  对于不同的统计维度值数据,我们的销售人员会关注它。外卖区实时交易金额

  DIM层

  基本来源于离线维度表层(ODS离线处理),提取到实时应用。如产品维度表、卖家维度表等。 订单项目类别与行业对应表。

  5.3.2 多码流关联

  在流计算中,需要将两个实时流与主键关联起来,才能得到对应的表。

  关键点:需要互相等待,双方到达后才能成功关联。

  难点:数据到达是一个增量过程,数据到达时间不确定、无序,需要涉及中间状态的保存和恢复。

  当A表和B表实时关联ID时,无法知道表的到达顺序。因此,当两个数据流中的每个新数据到达时,都必须在另一个表中进行搜索。如果匹配,则拼接成一条记录输出到下游;如果无法匹配,则需要将其存储在内存或外部存储器中,直到表 B 中的记录也到达。每次都在对方表的当前全量数据中查找。可以根据关联的主键在bucket中进行处理

  5.3.3维表使用@

  实时计算时,相关维表会使用当前实时数据(T)关联T-2的维表数据

  你为什么这样做?

  数据无法及时准备。在零点,实时数据必须与维表相关联,T-1的维表数据不能在零点立即准备好,无法准确获取最新的全量数据。所有最新数据=T-1数据+当天变化。当天实时数据无序,时间不确定。数据的混乱。比如10点的业务数据与维表关联成功,获取维表的字段信息(只能说是获取到10点的最新状态数据,而不知道会不会变)

  有两种类型的维度表

  满载。数据量小,每天上万条记录,分类维表增量加载。无法全部加载,增量搜索和LRU过期形式,热点数据存储在内存中5.4大推广挑战5.4.1大推广特性毫秒延迟峰值明显(高吞吐量)保证(需要多链路冗余、快速切换、对业务方透明)公关特性(主键过滤、精确去重、统一口径一) 5.4.2大促保证@

  实时任务优化

  独占资源和共享资源的策略(一台机器长时间需要从共享资源池中抓取资源,考虑分配更多的独占资源)合理选择缓存机制,减少库的读写次数,合并计算单元,并降级拓扑级别。(每个节点的数据传输都必须进行序列化和反序列化,在级别深度上性能较差) 内存对象共享,避免字符串复制 高吞吐量和低延迟平均

  数据链路保证

  多链路建设、多机房容灾、异地容灾、链路切换推送

  压力测试

  数据压力测量:将实时操作的订阅数据点调整到几小时或几天前,以模拟蓄洪压力测量。

  产品压测:自压测试优化服务器性能(所有手机读取操作的URL,QPS:500次/秒压测);前端页面稳定性测试(8-24小时,提高前端页面稳定性)

0 个评论

要回复文章请先登录注册


官方客服QQ群

微信人工客服

QQ人工客服


线