建设实时数仓的目的和意义
实时数仓目的
数仓概念：数据尽可能多，保存时间尽可能久
实时概念：数据流式，处理及时、瞬时、短时、事件或者微批响应
数仓跟实时从概念上就有冲突，所以本质上不太适合处理广泛的问题，比如，对一个月，甚至是一年的数据进行统计计算。
所以，实时数仓应该目前作为离线数仓的一种补充，解决因离线数仓实时性低而无法解决的问题，具体点说就是处理离线两个周期间隔的数据问题，不适合解决大批量数据聚合问题、业务性太强的以及对实时性要求很高问题。
实时数仓的意义
实时数仓从概念上讲还是要靠近数仓的概念，数据分层，面向主题，数据尽可能集成，结构相对稳定，不易发生变化。
对于实时数仓来讲，数据量不需要保存像离线那么久，上一节我们提到，实时数仓处理两个离线周期间隔的数据即可，如上图，以时报为例，实时数仓补充中间数据即可，以天为例，实时数仓最多只需要保留3~5天数据即可，能够支持一段时间的数据追溯和重导就可以了。
实时数仓可以解决哪类问题
利用EMR建设实时数仓
实时数仓对比离线数仓
实时数仓架构
从图中可以看到，
1、ODS并不是实时数仓的一部分，是依赖外部数据源，比如binlog,流量日志，系统日志，或者是其他消息队列
2、应用层也不是实时数仓的一部分，对于数据的使用，通过实时数仓暴露Topic来使用
3、实时数仓要求层次要少，因为需要尽可能降低延迟
用EMR搭建实时数仓
1、底层数据源可以接企业内部binlog、日志或者消息队列
2、从ODS层经过与维表轻度扩展，形成明细层明细表，明细表用一个Ckafka topic表示，计算采用Oceanus或者EMR FlinkSql 关联查询，维表采用EMR Hbase存储
3、从明细层经过进一步汇总计算，形成汇总层，此时数据已经是面向主题的汇总数据，就是传统意义上的大宽表，一个主题是一系列Ckafka topic，计算采用Oceanus或者EMR FlinkSql 关联查询以及汇总计算
实时数仓各层搭建
ODS层搭建
1、 之所以没有把ODS层放在实时数仓的一部分，是因为实时数仓的ODS并不像离线数仓ODS是采集过来的原始数据，现在一般企业都已经具备了如上图的底层数据源
2、 Binlog，是数据库日志，通过Binlog可以自数据库主从间同步，可以同步关系型数据库数据，目前企业线上数据库都采用Mysql这样的数据库，可以通过抓取Mysql binlog 获取数据库变更信息，数仓中重要的业务数据，支付相关，用户相关，管理相关数据一般都从这种数据源获得
3、 Log日志，服务器日志，像服务器系统日志采集，都是通过这种形式进行采集
Ckafka，企业通过消息队列提供数据源服务，比如，点击流服务，会把用户点击事件通过上报服务器上报到Ckafka，为后续分析提供原始数据
该层搭建的注意点：
1、 业务选择数据源，尽量跟离线保持一致，比如某个业务，数据源即可以通过Binlog，也可以通过Log日志采集，如果离线数仓业务是通过Binlog，那么实时数仓也取Binlog，否则后续产生数据不一致，非常难以定位
2、数据源要求一致性，对于Ckafka和Binlog 需要进行分区一致性保证，解决数据乱序问题
明细层搭建
建设标准与离线数仓目标一致，解决原始数据存在噪音，不完整，形式不统一等问题
数据解析，业务整合，数据清洗，解决噪音，不完整，数据不一致问题;模型规范化（提前指定号规则，尽量跟离线保持一致），形成数据规范，规范尽可能跟离线保持一致，命名，比如，指标命名等;
与离线数仓不同之处在于，离线调度是有周期的，时报一小时，天报周期为一天，如果修改数据表字段，只要任务没开始，就可以修改，而实时是流式，7X24小时不间断运行的，想要修改流中的字段或者格式，对下游影响是不可预估的
实时数仓如果修改字段不像离线，在间隔期间通知下游把作业都改了就没事了，但是实时不一样，实时你改掉了字段，下游作业必须可以认识你修改的内容才行，kafka不是结构化存储，没有元数据的概念，不像Hive，如果表名不规范，找一个统一时间，把catolog改规范，然后把脚本一改就就解决了。
明细建设关键，我们会在每一条数据上增加一些额外字段到数仓里
举例说明这些额外字段的意义
事件主键：对于上游数据重复问题，我们会根据一些数据内的字段来判断上有数据的唯一性，比如binlog，<集群id_><库id_><表id_>数据id_数据生成时间。
数据主键：唯一标识数据表的一行记录，可以使用数据库主键，主要用来解决分区一致性及分区有序。
数据元数据版本：上面介绍了，流式计算是7X24小时不间断的运算，当修改了数据结构，增加，删除了字段，对下游的影响是不可预估的，因此元数据变更需修改该字段，保持数据流中新老版本数据双跑，下游选择合适的时机进行数据切换。
数据批次：跟元数据用途相似，当明细层逻辑发现问题，需要重跑数据，为了对下游任务不产生影响，调整了明细层逻辑后，需要回倒位点重跑数据，同时需要跟老逻辑任务双跑，待下游业务都切换到新的逻辑后，老逻辑任务才可以停止。
还有一个思路，可以直接把明细层数据，也可以直接写到druid 直接用于分析。
维度层搭建
维度数据处理：
如上图，对于变化频率低，地理，节假日，代码转换，直接同步加载到缓存里，或者是新增数据，但是增加进来就不变了，通过数据接口，访问最新数据，然后通过本公司数据服务对外提供数据
如上图，对于变化频率高，比如商品价格，也是需要监听变化消息，然后实时更新维度拉链表。对于比如像最近一个月没有消费用户这样的衍生维度，是需要根据变化消息，通过计算得到的衍生维度拉链。
因为维度数据也在发生变化，为了能够让源表数据匹配到维表，我们会给维表增加多版本minversion，然后通过TIMERANGE => [1303668804,
1303668904]筛选出源数据指定的维表版本数据。
这里有些同学可能觉得如果版本一致保存下去，会不会非常大，是的，我们响应的需要配置TTL保证维表数据量可控，上文我们介绍过，实时数仓解决是离线数仓两个间隔的问题，那么像这种变化频繁的数据我们TTL设置一周足够了。
关于源表与维表如果进行join，Flink原生sql以及Oceanus都是采用UDTF函数以及Lateral
Table 进行联合使用，其中UDTF我们可以实现查询数据服务获取维表数据的能力，Oceanus请参考相关材料。
汇总层搭建
汇总层加工其实跟离线数仓是一致的，对共性指标进行加工，比如，pv，uv，订单优惠金额，交易额等，会在汇总层进行统一计算。
Flink提供了丰富的窗口计算，这使得我们可以做更细力度的聚合运算，例如，我们可以算最近5分钟，10分钟的数据聚合，根据时间窗口的间隔，也需要调整相应的TTL，保障内存高效实用。
Flink提供了丰富的聚合计算，数据都是要存在内存中的，因此需要注意设置state的TTL，例如，做Count（Distinct
x）。或者在进行PV，UV计算时候，都会使用大量的内存，这一块，当处理的基数比较大的时候，推荐使用一些非高精度去重算法，Bloom过滤器，Hyper LogLog等。
汇总层也需要在每一条数据上增加一些额外字段到数仓里，这块与明细层一致，就不在单独讲解了。
数据质量保证
对于实时数仓数据质量的管理，我们通常由三步操作组成
第一步，数据与离线数据进行对比
首先，将汇总层数据Topic通过平台接入任务接入到离线仓库，然后通过数据质量任务，定时对实时数仓和离线数仓数据进行对比，并配置报警，数据差异，数据波动等。
第二步，配置报警，我们会在明细层以及汇总层，Topic配置生产监控，与以往数据波动，上游数据延迟或者积压，都需要进行报警。
第三部，构建实时血缘， Flink 在读取数据时候，会把信息读到flink catalog 这样就知道这个任务读取了哪个表，在解析客户DDL代码时，可以获得目标表信息，同步到我们的元数据服务。
参考文献：
美团实时数仓搭建：https://tech.meituan.com/2018/10/18/meishi-data-flink.html