数据仓库、数据湖、流批一体，终于有专家讲清楚了！

做者：

蒋晓伟（量仔） 阿里云研究员

金晓军(仙隐) 阿里云高级技术专家

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

1、业务背景

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架构

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

其实这套大数据方案本质上就是一个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既能作流计算又能作批计算，再深挖其底层原理，还解决了存储问题，流数据和批数据都统一存储在同一个产品。

2、看起来很完美的Data Lakes

针对以上简化的架构，咱们能够看看开源社区为了解决这些问题所推出的一些产品，例如Data Lakes。
首先采集的数据有统一的存储，无论是HDFS、OSS仍是AWS，数据以增量的形式存储在数据湖里，再经过查询层无论是Hive、Spark仍是Flink，根据业务需求选择一个产品来作查询，这样实时数据以及离线数据都能直接查询。整个架构看起来很美好，可是实际问题在于：

1）数据增量写入不知足实时性

开源的实时写入并非实时写入，而是增量写入。实时和增量的区别在于，实时写一条数据就能立马查询可见，可是增量为了提升吞吐会将数据一批一批的写入。那么这套方案就不能彻底知足数据实时性的要求。

2）查询的QPS

咱们但愿这个架构既能作实时分析，又能作流计算的维表查询，存储里面的数据可否经过Flink作一个高并发的查询，例如每秒钟支持上千万上亿QPS的查询？

3）查询的并发度

整个方案本质都是离线计算引擎，只能支持较低的并发，若是要支持每秒钟上千的并发，须要耗费大量的资源，增长成本。

综上所述，这个方案目前还不能彻底解决问题，只能做为一个初期的解决方案。

3、HSAP之我见

3.1 什么是HSAP

针对以上问题咱们作了一个细致的分析，大体根据查询并发度要求或者查询Latency要求，将Patterns分为四类：

• Batch：离线计算
• Analytical：交互式分析
• Servering：高QPS的在线服务
• Transaction：与钱相关的传统数据库（绝大多数业务并不须要）

目前市面上都在说HTAP，通过咱们调研HTAP是个伪命题，由于A和T的优化方向不同。为了作T，写入链路将很是复杂，QPS没法知足需求。如果对T的要求下降一点，就会发现Analytical和Severing的联系很是紧密，这两块的技术是能够共用的，因此咱们放弃了T就至关于放弃了Transaction，因而咱们提出新的一个架构叫作HSAP，那咱们须要作的就是把提供服务和分析的数据存储在一个系统里，经过一套分析引擎来作处理。

3.2 基于HSAP的大数据架构

HASP系统接入到咱们刚刚简化的架构中就成为很是的完美的大数据架构。HSAP系统与Flink作维表关联，对离线数据作批处理，而后对接在线应用提供在线服务，例如报表、大盘等。

3.3 PostgreSQL生态

那么接入HSAP系统以后，在线应用和系统怎么样来用呢？为了减小使用难度，就要引须要一个生态系统来作支撑，通过咱们反复调研，咱们认为是PostgreSQL，主要有如下几点：

1）丰富的工具对接

PostgreSQL具备很是完备的工具对接，无论是开发工具仍是BI分析工具，都有着丰富的支撑能力。

2）详尽的文档支撑

一般来说写文档须要耗费大量的时间，PostgreSQL有着很是详尽的文档，若是可以直接复用PostgreSQL的文档，将会减小工做量。同时开发者们只须要根据postgreSQL文档来开发，减小学习成本。

3）多元化的扩展

PostgreSQL有着很是多元化的扩展，例如地理信息的PostGis，Matlab等，开发者们能够根据业务需求选择对应的扩展。

4、新一代的实时交互式引擎--Hologres

基于以上全部内容，进入到咱们今天的重点主题，也就是咱们在阿里云重磅发布的新一代实时交互式引擎，中文名叫交互式分析，英文名叫Hologres。Hologres这个名字怎么来的呢？Hologres由Holographic（全息宇宙）和Postgres组成。

4.1 Hologres的架构

Hologres的架构比较简单，从下往上看，最底层是统一的存储系统，能够是阿里云统一的Pangu、业务的HDFS或者OSS、S3等，存储上面是计算层，提供相似的MMP架构计算服务，再往上是FE层，根据查询信息将Plan分发到各个计算节点，再往上就是PostgreSQL生态的对接，只要有JDBC/ODBC Driver就能对Hologres作查询。

4.2 Hologres：云原生

1）存储计算分离

Hologres的架构是彻底是存储计算分离，计算彻底部署在K8s上，存储可使用共享存储，能够根据业务需求选择HDFS或者云上的OSS，这样用户就能根据业务需求对资源作弹性扩缩容，完美解决资源不够带来的并发问题。

2）存储优点

• 全异步：支持高并发写入，可以将CPU最大化利用；
• 无锁：写入能力随资源线性扩展，直到将CPU所有写满；
• 内存管理：提供数据cache，支持高并发查询。

3）计算优点

• 高性能混合负载：慢查询和快查询混合一块儿跑，经过内部的调度系统，避免慢查询影响快查询；
• 向量化计算：列式数据经过向量化计算达到查询加速的能力；
• 存储优化：可以定制查询引擎，可是对存储在Hologres数据查询性能会更优。

4.3 基于Hologres的典型应用

下面给你们介绍一下，Hologres在阿里巴巴内部的一个典型应用。数据实时写入至Flink，经由Flink作实时预处理，好比实时ETL或者实时训练，把处理的结果直接写入Hologres，Hologres提供维表关联点查、结果缓存、复杂实时交互、离线查询和联邦查询等，这样整个业务系统只须要经过Hologres来作惟一的数据入口，在线系统能够经过PostgreSQL生态在Hologres中访问数据，无需对接其余系统，这样也能解决以前架构的各类查询、存储问题。

4.4 真正的实时数仓：Flink+Hologres

综上所述，咱们认为，真正的实时数仓只须要Flink+Hologres便可，Flink作流、批数据的ETL处理，将处理的数据写入Hologres作统一的存储和查询，这样业务端直接对接Hologres提供在线服务。

联系咱们

欢迎你们扫码加入Hologres钉钉交流群，咱们将会在群里分享有关Hologres的最新产品咨询、解读产品技术以及为开发者们答疑解惑！

附件：演讲材料

1）演讲PDF：📎08-仙隐-Data WareHouse, Data Lakes, What's Next的副本.pdf

2）视频回看地址：https://www.bilibili.com/video/BV1Uf4y1m7Hx?p=15