大数据实时学习笔记
1、应用场景
分为4类场景，包括核心数据大屏、活动实时指标、运营体系看板、搜索广告实时；
1）核心数据大屏：包括公司经营情况的一些大盘数据，移动版数据，最重要的是实时的核心日报。所谓核心即真正能体现价值的数据，也可以说与战略、生死无关的指标，都不能叫做核心指标。在日报中体现最重要的核心指标，并实时出来，才是有价值。
2）活动实时：提供常规的移动端活动核心数据和活动模板的看板。但最有价值的应该是活动大屏，比如大型活动，比如春晚、双十一等特别日期的一些活动，需要关注整体的指标，也有分板块的一些实时统计，能从不同角度展示数据，并通过数据呈现内在价值。
3）运营数据：主要还是C端面的数据展示，有直播的实时看板，也可以基于实时的数据预测运营策略并为最终的运营策略提供强有力的支撑。
4）实时特征：搜索和广告的实时效是非常重要的，为客户提供最快捷最及时的讯息，为客户的转化助力，为搜索和广告提供实时的特征信息，促进转化，发挥数据价值。
2、目标及难点
目标：不管是离线数仓还是实时数仓，基本都会落到准确性、延迟性（性能）、稳定性3个方面。
1）数据准确性，离线差异1%以内；
2）数据延迟，活动核心报表<5min；
3）数据稳定性，数据不出现尖刺掉坑；
难点：
1）数据量大，数据量万亿级别，QPS峰值亿/秒；
2）组件依赖复杂，链路涉及5~6个组件(kafka,kv,rpc接口,olap引擎)；
3）链路复杂，200+核心业务实时作业，50+核心数据源，整体作业量级超过1000+；
3、技术架构
分为4层，包括接入数据层、公共基础层、应用层、场景，整个过程是业务数据化->数据资产化->数据业务化的一个模型。
1）接入数据层：包括常规的DB、以及Binlog监控的数据日志信息、客户端的日志、服务器端的日志4种类型。这个是业务数据化的一个过程，将分散在各地、各业务场景中的数据进行整合，进行统一的管理或入库入湖，为数仓建模提供必要的条件。
2）公共基础层：包括常规的DWD明细层（基础的数据整合清洗）、DWS汇总层（按照一定的粒度规范）、DIM维度层外，还有按照流量、用户设备、直播生产、直播消费、社交、视频生产、视频消费、风控等主题构建的数据主题层。进行进一步的数据归类，更好的为应用层服务。这个是数据资产化生产过程，合理的规划、有效的执行、良好的规范是强有力的保障。
3）应用层：包括大盘数据、多维分析模型、业务专师数据等，这个是数据业务化的过程，是数据产生价值的地方，是数据为业务赋能的真正载体。
4）场景：即第一部分介绍的4类场景，是应用层最终的呈现形式，按场景提供，更有针对性、场景感、更有价值。
4、预警监控机制
预警监控从实时的生产过程来看，主要包括数据接入层的保障、计算过程中的保障、数据应用层的保障。从保障的维度来看，主要是质量、时效、可用性3个方面。下面分别从3个过程和3个维度来分析下：
1）数据接入层：从质量来看，包括乱序监控、数据源探查。乱序就是数据源的顺序是否有保障，数据源探查即定时巡检数据源是否正常；从时效保障来看，主要是流量/延迟监控，一般情况通过原始数据生成时间和采集时间比对进行延迟的监控，可以结合队列积压数据，监控延迟情况。同时通过压测判断数据处理性能也是一个必要的措施。
2）数据计算层：不管是DWD数据清洗层、还是DWS数据聚合层，还是ADS的数据主题业务化层，都需要进行相应的保障机制。在这里分为了3个阶段来处理，包括研发阶段、上线阶段、服务阶段的相应机制。
研发阶段：包括6个机制，质量方面包括标准化计算方案、离线对比验证、资源的预估3个机制；时效方面主要是单作业压测；稳定方面包括切换演练和分级保障2个机制。
上线阶段：包括4个机制，质量方面包括服务监控、指标监控；时效方面主要是任务监控；稳定方面主要是数据源限流，也可理解为灰度；
服务阶段：包括质量方面的实时计算启用及状态，离线初始化及修复逻辑；在时效方面主要是重启恢复的性能指标，是否影响了业务应用。
5、场景应用实践
1）PV/UV场景
最初的方案采取自然时间的滚动窗口机制，但这样会产生比较多的问题，比如：
乱序的问题、重启后曲线不平滑的问题（回溯问题）、语义的问题。
基于以上问题，最终采取了WaterMark&EventTime的方案给予解决。
对于乱序的问题：做到数据不丢弃，并可以随时按最新的记录进行统计；
对于回溯的问题：基于真实的EventTime时间戳，并以WaterMark进行延迟处理，达到窗口后再进行计算，以确保回溯数据的准确；
对于语义的问题：同样基于真实的EventTime事件时间，同时可以通过离线进行修复，保证结果的平滑。
2）DAU场景
DAU，即日活、增量、留存（次日、7日）的用户使用情况指标
DAU的计算，也采集延迟方案，通过WaterMark&EventTime，进行去重和乱序处理。
为了节省状态存储空间和提升查询性能，采取了位运算的模式。具体为按照常规进行计算，状态的存储会占用比较大的存储空间，采取BIT位运算的方式后，存储空间降低到原来的1/10，空间的节省及查询性能得到了大大提升。
3）运营看板：
a）具体包括数据大屏支持，支持直播间分析数据、支持大盘数据分析，可以做到分钟级延迟，更新要求高；
b）直播看板支持，支持特定维度、支持特定人群，对于维度的丰富性要求高，可以做到分钟级延迟；
c）数据策略榜单支持，支持预测热门作品、预测爆款，可以做到小时级数据，更新要求低；
d）C端实时指标展示，支持创作者中心、主播中心，可以支持15分钟级延迟；
采取的是基础明细层的计算、基础汇总层（Kafka数据直接计算）、应用汇总层（基础汇总层做为输入，并进行维度关联，应用汇总层的数据通过kafka再推送给APP应用进行信息展示），基础汇总层和应用汇总层的数据会落盘，包括Redis、druid、clickhouse，提供给C端应用（创作者中心、主播中心）、C端策略（爆款策略、榜单策略）、实时大屏（实时大屏、核心看板）、实时业务看板（大盘看板、多维分析）使用。
通过对KS方案的学习总结，整体来看，KS的Flink实践还是非常不错，有很多值得学习的地方。基于Flink的实时链路，解决了4大类实时场景的问题，在乱序方面，也做了相应的处理，在维度建模上也做了很多的实践，同时落盘存储也采用了多种形态，针对高并发、性能采取不同的引擎，支撑不同的应用场景。有几个疑问，包括非固定维度的建模、实时清洗关联大量历史数据的计算场景、复杂关联查询的存储查询引擎支持如何，目前也是遇到的比较大的问题，期望不断探索，得到最优解。