微服务盛行下，数据库表拆分的越来越细。很多查询都会涉及多张表关联之后才能满足对应业务查询诉求。在海量数据基础之上，直接关联查询，响应时间超出用户忍耐时间。因此构建宽表，对针对宽表直接查询得到结果是个通用的方案。但构建宽表涉及的相应表常常会更新，就使宽表构建变的复杂了。
我们常常看到的各支持的订单/交易查询，在应对海量数据的时候，只支持近期很短时间的查询。如招商银行提供近8个月的交易查询，稍微还好一点。
微信支付宝做得很好，都支持历史数据全部能查。
那么技术上如何实现呢？
常常大家采用分布式数据库来存储海量数据，Hbase是个常用的存储组件。
在构建解决关联查询延时，构建宽表方面，下面给出三种方案，一探究竟。
1、在源数据库直接SQL查询join后结果，落存宽表库Hbase等。要注意的说是，轮动拉取的时间，要有所有可变表的时间。缺点：依赖源数据库计算能力，会延时非实时。SQL操作直接得到结果，不用建立中间模型，简单快捷。能针对oracle数据日志不能解析的情况下做数据宽表。SQL任务可在streamingSets调度平台配置定时任务。
2、单表获取解析源数据库表binlog日志，在Hbase处设计业务表模型做插入更新维护该模型，业务上设计每张表与宽表关系，以便FLink接收到每张表的更新时，能找到对应宽表记录，做宽表相应更新处理。优点：准实时，模型构建可重复利用，减少混乱庞杂数据。缺点，Flink处理有开发任务，开发周期较长。这是目前当前流行FLink的流行做法。
3、单表获取解析源数据库表binlog日志，使用Spark 流处理，对小段RDD通过Spark sql做join关联，落存Hbase。这种方式，是将关联计算从数据源处计算移到spark计算层。可以通过抽象存储与执行计算，通过配置SQL的方式完成宽表构建，减少编码。 缺点：根据业务间隔设置微批时间段。少数实在超过时间范围外的（更新）数据会丢失。 对在每个时间段内，没有关联上的数据，需要有补偿机制。
因为我们公司构建了基于impala+kudu的实时数仓，宽表构建，在方案一中，依赖数据源的关联计算能力，可能会使数据库负重，从而影响数据库性能。在此方案上，一种优化是，升级数据源，把数据源升级成TIDB，增强数据源的计算能力，使其不受影响。另一种方式是， 将关联计算从数据源处执行移到终端数仓阶段做关联计算得到宽表数据。 同样，该方案根据定时任务也有相应延时，但不会丢失数据。
