数据仓库、数据湖、流批一体，终于有大神讲清楚了 _数据仓库

文章插图
作者：
蒋晓伟（量仔）阿里云研究员
金晓军(仙隐) 阿里云高级技术专家

摘要数据仓库，数据湖，包括Flink社区提的流批一体，它们到底能解决什么问题？今天将由阿里云研究员从解决业务问题出发，将问题抽丝剥茧，从技术维度娓娓道来：为什么你需要数据湖或者数据仓库解决方案？它的核心难点与核心问题在哪？如果想稳定落地，系统设计该怎么做？

业务背景
1.1 典型实时业务场景首先我们来看一个典型的实时业务场景，这个场景也是绝大部分实时计算用户的业务场景，整个链路也是一个典型的流计算架构：把用户的行为数据或者数据库同步的Binlog，写入至kafka，再通过Flink做同步任务，订阅kafka消费的实时数据，这个过程中需要做几件事情，比如Preprocessing（预处理），在处理的过程中做Online Training（在线训练），在线训练过程中需要关联一些维表或者特征，这些特征可能可以全量加载到计算节点里面去，也有可能非常大，就需要用HBase做一个高并发的点查，比如我们做一些样本也会写入到HBase中去，形成一个交互过程，最后实时产生的采样数据或者训练模型推到搜索引擎或者算法模块中。以上就是一个很典型的machine Learning的完整链路。

文章插图

1.2 越来越复杂的架构以上场景展示的链路与离线链路是相辅相成的，也有一些公司实时的链路还没有建立起来，用的是离线链路，不过这套链路已经是一个非常成熟的方案了。如果我们把这个链路变得更加复杂一些，看看会带来什么样的问题。首先我们把刚刚的链路做一个变化，实时数据写入kafka，再经过Flink做实时的机器学习或者指标计算，把结果写入到在线服务，例如HBase或者Cassandra用来做点查，再接入在线大盘，做指标的可视化展现。

文章插图
这里面产生的一个问题就是：在线产生的数据和样本，如果想对它们做一个分析，基于HBase或者Cassandra的分析能力是非常弱的且性能是非常差的。
那么怎么办呢？
有聪明的开发者们可能就有一些实现方式如下：
HBase或者Cassandra不满足分析需求，就把实时数据写入至适合数据分析的系统中，比如ClickHouse或者Druid，这些都是典型的列存架构，能构建index、或者通过向量化计算加速列式计算的分析，再对接分析软件，对数据做实时报表、实时分析展现等，以此链路来解决实时高效分析的问题。

文章插图
但上面的架构中，还有一些额外的需求，就是要将实时产生的数据数据归档至离线系统，对离线数据做一个基于历史的全量分析，基于此开发者们最常用的链路就是把实时数据离线的归档至Hive中，在Hive中做T+1天或者其他的离线算法。通过Hive对离线数据的处理来满足离线场景的需求。

文章插图
但是业务既有实时写入的数据又有离线的数据，有时我们需要对实时数据和离线数据做一个联邦查询，那应该怎么办呢？
基于现市面上的开源体系，开发者们最常用的架构就是基于Drill或者Presto，通过类似MPP的架构层做多数据的联邦查询，若是速度不够快，还能通过Druid、ClickHouse等做查询加速。

文章插图
以上联邦查询的链路有个问题就是，QPS很难上去，比如前端调用需要每秒钟几百上千的QPS，如果几百上千的QPS全部通过加速层来做，那性能肯定是有所下降的，这时应该怎么办呢？最常见的解决方案就是在常见的加速层再加一个cache，用来抵挡高并发的请求，一般是加redis或者MySQL用来cache数据，这样就能提供server以及在线服务的能力。

文章插图

1.3 典型的大数据Lambda架构以上就是绝大部分公司所使用的大数据架构，也有很多公司是根据业务场景选择了其中一部分架构，这样既有实时又有离线的大数据完整架构就搭建出来，看起来很完美，能实际解决问题，但是仔细想想，里面藏了很多坑，越往后做越举步维艰，那么问题在哪呢？现在我们来仔细看一下。