实时数仓的概念及实现方式

目前企业数据架构基本也就包含3种模式，离线数仓，实时数仓，实时流。 离线数仓没有任何歧义，实时数仓和实时流之前有什么区别呢？从技术实现上，实时数仓肯定可以通过实时流来实现的，那么为什么会把这2种东西做一个区分. 在概念上，数据主题和指标会有很多，通常离线做一套，实时也会做一套，保证有些指标能实时的出数据，这部分实际上是更多的倾向报表类型，比如公司的大屏展示，而很多业务系统也需要实时的计算数据，不仅仅是报表，这部分的计算相比实时流会更复杂，会涉及到比较复杂的多表关联的问题。

比如计算每种产品销售量或者销售额，通过实时流实时获取订单库的信息，然后根据维度直接做销售量的累加即可 ，这种实时流实际上比较容易，因为简单来说就是根据维度的区分，对每个产品的销售量 做累加即可。技术上比较容易，这种一般给前端实时报表来使用。

那么上面表述的业务系统也需要实时数据和实时流到底有啥区别，表面看其实是没什么区别，因为对于业务系统来说，不会简单的只返回1-2个字段，那么关联的时候会更复杂。 对于这种关联更复杂的，就好比离线数仓使用HIVE或者SPARK批处理的处理方式转换为通过流来处理，这种会定义会实时数仓。

实时数仓有几种处理模式，目前大部分人借助Flink/kafka来实现，通过窗口+流进行JOIN，就好比表的JOIN的一样来实现数据的实时化。我们更深入的 理解这问题，实际上就是实时跨库查询. 但是因为业务系统的数据库都是分离的，并且分布在不同机器，做不了跨库查询，因此需要Flink/kafka的窗口方式来处理. 

以下就我 个人对实时数仓技术实现上的理解:

1. 云服务

如果服务器是采用云服务的,可以花钱购买,阿里云提供的DTS+ADB实际就是这种跨库查询业务，DTS通过 实时同步业务数据表到ADB，业务系统直接通过JDBC进行跨库跨表JOIN，实时获取数据，连数据分层都不需要 ，一条SQL就搞定。

2. 通过分布式数据库解决

如果企业数据库全部是MySQL可以通过这种方式解决，通过类似于TIDB这种分布式数据库，直接多源复制即可，是否需要分层，我个人局的可以分也可以不分，一条SQL搞定。

这种方案不好的地方是，DTS+ADB是根据表来同步，但是TIDB一般是根据库来同步，因为设置表同步实在是比较麻烦，如果增加表还需要重启。

3. 实时流+窗口+join

这种方式是使用Flink根据相同窗口的流进行JOIN来实现 ，同一个窗口的定义在FLINK里面是一样的，比如Time.wdinow(5)，在窗口的定义实际就是0-5，6-10，11-15， 同窗口的数据直接进行JOIN得到实时的结果。

一般的处理方式分为实时日志的解析，把binlog解析为一个完整的数据行，把此数据再推送到下一层的KAFKA，下一层再通过FLINK进行JOIN，因为KAFKA的数据和表的的数据已经一致了，就好比一张表存储在KAFKA而已 ，再根据窗口直接JOIN，如果 需要使用维度表 ，这些表本身可能就在主数据里，直接通过JDBC取出来即可。

对于大公司来说 ，数据库太多，有些可能也很大，使用全量同步DB，也就是类似TIDB这种方式可能不太可行，更多会采用FLINK的方式 ，而对于中小公司，我其实更愿意使用多源复制，因为最简单，直接数据库层面解决跨库 查询的问题。

接下来我会做几个 CASE来 通过FLINK实现实时业务主题的指标计算，这种东西更多的是一种模式，打通了一种，其他的也就类似。

但是难点是，多流进行JOIN的时候，发生数据延迟，该如何处理？ 如果 仅仅是单流，很容易实现