5.2流式技术架构
数据采集
流式计算处理的数据可大致分为2种：
1.业务数据库产生的变更日志，如果mysql的bin-log日志、hbase的h-log日志、oracle的变更日志等
2.用户访问网站的埋点日志。
一般采集都不是来一条日志采集一条，而是基于时间和大小阀值或者条数来触发采集。
采集到的日志数据需要存储到一个消息队列里以供削峰填谷，比如kafka，下游的流式计算框架再通过主动或被动的方式来获取数据。
数据处理
出于性能考虑，一般都是采用多线程处理，可根据业务主键hash 取模进行分桶处理，每一个线程处理一个桶内的数据。为了避免内存溢出，可以用LRU（最近最少使用）策略淘汰最近较少使用的数据。
实时处理一般容易遇到的问题
去重指标
当一个节点上的数据过多时，单节点无法承受。可以用分桶原理将数据分发到不同的节点上处理。采用分治法来处理。
如果遇到模糊去重，可以采用如下方式减少内存使用量：
布隆过滤器：布隆过滤器采用了位数组，不存储真实值，只存储值对应的hash标记位，hash标记位的占用空间比真实值小很多，1亿条数据大概只占用100M的内存。但是会发生hash碰撞的场景，适用于精度要求不高的场景。
基数估计：也是利用hash原理，按照数据的分散程度来来大致估算边界，非常粗粒度的计算，不精确。
数据倾斜：
在分布式计算中经常会遇到数据倾斜，如计算一天中全网的成交额。该成交额结果只有一个值，通常在一个节点上计算。单节点的处理能力是有限的。可以把数据分桶分发到不同节点分别汇总再总体汇总。
如果需要指标先去重再汇总，则需要先对业务直接做hash再根据hash值将该条数据分桶，这样相同的数据一定会分发到相同的节点上。相同节点去重后再汇总
如果指标不需要去重，则可以随机分发，单节点局部汇总再全部节点总体汇总。
事务处理
由于分布式场景下必然会出现网络通信问题，如网络抖动导致数据发送不成功，
超时时间：当由于数据处理都是按照批次来的，当一批数据处理超时上游数据会重发数据。所以批处理量不应该过大，过大则导致数据超时重新计算
事务id，每批数据都会自带一个事务id，在重发的情况下让开发者自行决定数据第一次到达和重发时不同的处理逻辑。
备份机制：开发人员需要保障内存数据可以通过外部存储恢复。
数据存储
实时数仓分层和离线数仓也是差不多的，只是每一层没有像离线做得那么宽，维度和指标也没有离线那么多。涉及到回溯状态的数据在实时计算中几乎没有。
数据服务
5.3流式数据模型
数据分层
分为ods、dwd、dws、ads、dim，
ods的数据存在于kakfa中，类似于业务库的变更数据，网站浏览日志。flink等实时计算框架实时消费kafka里的数据，读取出来。这一层实时和离线基本保持一致，该层的数据一般保存7天到1个月，根据业务需求而定。
dwd层是一定程度拓宽的基础明细表。基础明细ods和dim层关联得到多维的事实明细。计算完存回hbase
dws，用于计算通用维度的汇总，下游经常会用到的。合同维度的应收，商家维度的销售。计算完存回hbase
Ads，个性化维度汇总层，对于个性化的统计维度放在这一层，如各个垂直业务线的计算指标。计算完直接落到mysql，供下游读取
dim层，由离线任务定时将维度数据从业务库同步到hbase中。
各层于hbase中的表名及rowkey涉及：
表：汇总层标识 + 数据域 + 主维度 + 时间维度
如dws_trd_slr_dtr,dws层 交易数据域 卖家维度 + 0点截止当前时间
rowkey：md5（ID）前4位 + 主维度 + 维度标识 + 子维度1 + 时间维度 + 子维度2
多流关联
流式处理需要保证中间状态数据的保存和恢复机制。flink对于中间状态数据天然有保存机制，宕机恢复可以靠barrier。
当涉及到去重时，由于计算节点是分布式的，要实现分布式去重可以靠外部中间件如hbase、redis。也可以将数据按照业务主键分桶处理，相同的业务主键必然被分到一个桶里，这样就不存分布式去重的问题了。
维表使用
这里的维表使用的是T - 2的数据，在T的凌晨0点就要开始关联维度数据，也就是在0点要准备好维度数据，如果不能及时关联上就失去了实时数据的时效性。而T - 1的数据一般不能在T的凌晨准备好，在0点凌晨之前只能准备好T - 2的数据，也就是在T - 1的时候准备T - 2的数据。在凌晨用的就是T - 2的数据。由于是维度数据，变更频次没有像实时数据那么高，实时数据的精准度要求也不是100%的，使用使用T - 2的数据已经满足了。
1.全量加载到内存，当维度数据较少时可以全量加载，查询效率高，但是缺点是一直占用着内存，并需要定时更新，如商铺表，每天只有几万条，每天0点全量加载到内存。
2.增量加载。在内存中只保存热数据，根据增量查找和LRU策略保留常用的数据，定期清理较少使用的数据。优点是可以控制内存使用量，缺点是会降低效率，当关联不到数据时需要到外部存储系统如hbase查找数据。
如会员维度表，可能有上千万的数据量，全部加载到内存可能会吃不消。可以实时到hbase中查找关联，关联后常驻内存。启动定时任务去清理数据。
5.4大促挑战&保障
大促特征
不能因为泄洪而导致程序崩溃
毫秒级延迟，洪峰明细，高保障性。对于强保障性的场景一般会采用多链路冗余的方式进行保障。
大促保障
在大促前需要对链路进行压测，压测主要是采用泄洪压测，采用线上真实数据，累计几天的数据量在一个时间点全部泻出。或者将偏移量调至前几天消费前几天到当前的数据量。
