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

其实这套大数据方案本质上就是一个Lambda架构，原始数据都是一个源头，例如用户行为日志、Binlog等，分别走了两条链路：一条是实时链路，也就是加速层（Speed Layer），通过流计算处理，把数据写入实时的存储系统；另一条链路就是离线链路，也就是批计算，最典型的就是将数据归档至Hive，再通过查询层如Spark对数据做加速查询，最后再对接在线应用、大盘或者第三方BI工具。

文章插图

1.4 典型大数据架构的痛点针对市面上这些开源产品，就存储而言，我们来逐一分析，这些产品是否都能具备满足业务需求的能力。
首先是基于离线存储的Hive，其次是提供点查询能力的HBase、Cassandra、然后是MPP架构号称能面向HTAP的Greenplum、以及最新兴起的用于做快速分析的Clickhouse等等都是基于解决方案而面世的存储产品。
但以上的每个存储产品都是一个数据的孤岛，比如为了解决点查询的问题，数据需要在HBase里面存储一份；为了解决列存的快速分析，数据需要在Druid或者Clickhouse里面存一份；为了解决离线计算又需要在Hive里面存储一份，这样带来的问题就是：

1）冗余存储数据将会存储在多个系统中，增加冗余存粗。
2）高维护成本
每个系统的数据格式不一致，数据需要做转换，增加维护成本，尤其是当业务到达一定量级时，维护成本剧增。
3）高学习成本
多个系统之前需要完全打通，不同的产品有不同的开发方式，尤其是针对新人来说，需要投入更多的精力去学习多种系统，增加学习成本。

文章插图

1.5 简化的大数据架构面对这样一个无比冗余无比复杂的系统，我们应该怎么去解决这些问题呢？我们可以对Lambda架构做一个简化。其实业务的本质就是将数据源做一个实时处理或者离线处理（批处理），从业务场景出发，我们希望不管是实时数据还是离线数据，都能统一存储在一个存储系统里面，而且这个存储还必须要满足各种各样的业务需求。这样听起来很玄乎，感觉这个产品需要支持各种各种的场景，非常复杂。但是如果我们能把架构做成这样，将会非常完美，这样就从本质上解决了流批统一的计算问题，一套SQL既能做流计算又能做批计算，再深挖其底层原理，还解决了存储问题，流数据和批数据都统一存储在同一个产品。

文章插图

看起来很完美的Data Lakes针对以上简化的架构，我们可以看看开源社区为了解决这些问题所推出的一些产品，例如Data Lakes 。
首先采集的数据有统一的存储，不管是HDFS、OSS还是AWS，数据以增量的形式存储在数据湖里，再通过查询层不管是Hive、Spark还是Flink，根据业务需求选择一个产品来做查询，这样实时数据以及离线数据都能直接查询。整个架构看起来很美好，但是实际问题在于：
1）数据增量写入不满足实时性
开源的实时写入并不是实时写入，而是增量写入。实时和增量的区别在于，实时写一条数据就能立马查询可见，但是增量为了提高吞吐会将数据一批一批的写入。那么这套方案就不能完全满足数据实时性的要求。
2）查询的QPS
我们希望这个架构既能做实时分析，又能做流计算的维表查询，存储里面的数据能否通过Flink做一个高并发的查询，例如每秒钟支持上千万上亿QPS的查询？
3）查询的并发度
整个方案本质都是离线计算引擎，只能支持较低的并发，如果要支持每秒钟上千的并发，需要耗费大量的资源，增加成本。
综上所述，这个方案目前还不能完全解决问题，只能作为一个初期的解决方案。

文章插图

HSAP之我见3.1 什么是HSAP
针对以上问题我们做了一个细致的分析，大致根据查询并发度要求或者查询Latency要求，将Patterns分为四类：
·Batch：离线计算
·Analytical：交互式分析
·Servering：高QPS的在线服务
·Transaction：与钱相关的传统数据库（绝大多数业务并不需要）
目前市面上都在说HTAP，经过我们调研HTAP是个伪命题，因为A和T的优化方向不一样。为了做T，写入链路将非常复杂，QPS无法满足需求。若是对T的要求降低一点，就会发现Analytical和Severing的联系非常紧密，这两块的技术是可以共用的，所以我们放弃了T就相当于放弃了Transaction，于是我们提出新的一个架构叫做HSAP，那我们需要做的就是把提供服务和分析的数据存储在一个系统里，通过一套分析引擎来做处理。