一. 背景说明
一方面互联网行业对实时化服务的要求日益增多，尤其在信息流，短视频应用最为显著，同时随着实时技术引擎的发展能够提供高效，稳定的实时数据服务能力。另一方面初期实时计算都是以需求为导向，采用"一路到底"的开发模式，没有形成完整的，统一的，规范化的实时数据体系。
为了避免我们同事踩坑，总结自己的过往实时开发经验，梳理对应实时数据体系。
二. 实时数仓技术架构和应用
根据离线数据的开发，过往实时开发经验，对应实时计算架构和分层如下图所示：
通常离线数仓，采用空间换取时间的方式，所以层级划分比较多从而提高数据计算效率；而对于实时数仓考虑时效，分层越少越好，减少分层也是为了减少中间流程出错的可能，主流的是数据接入 → 数据汇总 → 结果输出 这三层。
① ODS层：主要是埋点，流量等消息数据的接入，这一层是数据输入层。
② DIM层：主要是一些维表，如用户维表，产品维表等信息数据，在实时ETL，实时统计，或者特征加工时需要进行流数据和静态维表数据关联处理，这一层非必须的。
③ DWD层：一般是数据关联后的多维数据，比如双流join, 消息聚合，多维明细数据，特征加工数据输出，提供在线消息系统(如规则告警)，实时olap，特征工程使用，这一层因为直接对接是业务层，也可以叫DWS层。
④ DWS层：主要分为两部分，一部分是统计计算，指标汇总输出，提供给实时大屏显示，实时报表等，或者实时标签输出到redis, 被push推荐系统调用等；另一部分就是DWD层，能够进行实时olap处理的数据输出。
还有一种情况，是一个实时流任务中，既要先进行多维明细数据的关联，这种数据没有进行持久化存储，然后进行汇总计算，也是考虑数据和外部多一次交互，出错的可能性就会增加，缺点是增加了对应的计算资源要求。
附： 实时计算引擎选型对比 https://tech.meituan.com/2017/11/17/flink-benchmark.html
三. 实时规范
① 数据接入规范
kafka基于group id区分对应消费topic数据内容，group ip 命名规范 计算引擎_业务方_数据输出类型，汇总还是明细数据_存储db类型__存储表名， 例如flink_push_sum/detail/feature_mysql/es_tab_demo
②. 实时任务规范
实时任务名和kafka的group id的命名保持一致，因为是7*24小时服务，所以不涉及调度，只涉及任务监控；
实时数据的一致性和准确性，从两方面处理，一是进行在线测试，通过测试数据进行计算结果或者数据输出测试，是否符合业务需求，符合才正式上线；另一种是实时输出数据，通过hive等离线进行对比，如果一致则任务实时任务没有异常,需要对应离线的数据处理脚本。
③. 实时存储规范
实时数据输出是在线系统侧遵从业务方命名规范，如果是数据中心自己的存储，使用实时任务一致的命名规范。
四. 实时监控
分为两部分监控，一个是计算集群层面的，一个是计算任务层面，简单说明如下：
①实时计算集群：现有服务器，hadoop集群或者k8s监控，实时计算资源和状态监控；
②实时计算任务：根据job id进行kafka lag消息延迟，任务内存消耗，任务状态异常，任务自动重启等监控告警。
