关键词：大数据；数据孤岛；数据管理；数据仓库；数据湖；云原生；HSAP；PostgreSQL
作者：蒋晓伟；金晓军
编辑：侯天舒
本文从实时业务场景出发，抛出如何在日益庞大的数据中完成实时的数据分析、查询等任务的难题。阿里云研究员从技术维度道出数据仓库、数据湖、HSAP 架构、 Flink 社区提出的流批一体等技术的核心问题与难点，以及如何依托数据湖或者数据仓库解决上述难题。最后本文推出了新一代实时交互式引擎Hologres，并介绍其在阿里巴巴的内部典型应用，提出了实时数据仓库的构想。
业务背景
典型实时业务场景
首先我们来看一个典型的实时业务场景，这个场景也是绝大部分实时计算用户的业务场景，整个链路也是一个典型的流计算架构：把用户的行为数据或者数据库同步的 Binlog，写入至 Kafka，再通过 Flink 做同步任务，订阅 Kafka 消费的实时数据。这个过程中需要做几件事情，比如 Preprocessing（预处理），在处理的过程中做 Online Training（在线训练），在线训练过程中需要关联一些维表或者特征，这些特征可能可以全量加载到计算节点里面去，也有可能非常大，就需要用 HBase 做一个高并发的点查，比如我们做一些样本也会写入到 HBase 中去，形成一个交互过程，最后实时产生的采样数据或者训练模型推到搜索引擎或者算法模块中。以上就是一个很典型的 Machine Learning 的完整链路。注：
binlog,即二进制日志,它记录了数据库上的所有改变；
Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），多用于日志收集系统和消息系统；
Flink是分布式、高性能、随时可以用以及准确的流处理应用程序打造的开源流处理框架；
HBase是一个分布式的、面向列的开源数据库，适合于非结构化数据存储。
越来越复杂的架构
以上场景展示的链路与离线链路是相辅相成的，也有一些公司实时的链路还没有建立起来，用的是离线链路，不过这套链路已经是一个非常成熟的方案了。如果我们把这个链路变得更加复杂一些，看看会带来什么样的问题。首先我们把刚刚的链路做一个变化，实时数据写入 Kafka，再经过 Flink 做实时的机器学习或者指标计算，把结果写入到在线服务，例如 HBase 或者 Cassandra 用来做点查，再接入在线大盘，做指标的可视化展现。
这里面产生的一个问题就是：在线产生的数据和样本，如果想对它们做一个分析，基于 HBase 或者 Cassandra 的分析能力是非常弱的且性能是非常差的。
那么怎么办呢？
有聪明的开发者们可能就有一些实现方式如下：
HBase 或者 Cassandra 不满足分析需求，就把实时数据写入至适合数据分析的系统中，比如 ClickHouse 或者 Druid，这些都是典型的列存架构，能构建 index、或者通过向量化计算加速列式计算的分析，再对接分析软件，对数据做实时报表、实时分析展现等，以此链路来解决实时高效分析的问题。
但上面的架构中，还有一些额外的需求，就是要将实时产生的数据数据归档至离线系统，对离线数据做一个基于历史的全量分析，基于此开发者们最常用的链路就是把实时数据离线的归档至 Hive 中，在 Hive 中做 T+1 天或者其他的离线算法。通过 Hive 对离线数据的处理来满足离线场景的需求。
但是业务既有实时写入的数据又有离线的数据，有时我们需要对实时数据和离线数据做一个联邦查询，那应该怎么办呢？
基于现市面上的开源体系，开发者们最常用的架构就是基于 Drill 或者 Presto，通过类似 MPP 的架构层做多数据的联邦查询，若是速度不够快，还能通过 Druid、ClickHouse 等做查询加速。
注：MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。
以上联邦查询的链路有个问题就是，QPS 很难上去，比如前端调用需要每秒钟几百上千的 QPS，如果几百上千的 QPS 全部通过加速层来做，那性能肯定是有所下降的，这时应该怎么办呢？最常见的解决方案就是在常见的加速层再加一个 cache，用来抵挡高并发的请求，一般是加 Redis 或者 MySQL 用来 cache 数据，这样就能提供 server 以及在线服务的能力。
注： QPS每秒查询率(Query Per Second) ：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）
典型的大数据Lambda架构
以上就是绝大部分公司所使用的大数据架构，也有很多公司是根据业务场景选择了其中一部分架构，这样既有实时又有离线的大数据完整架构就搭建出来，看起来很完美，能实际解决问题，但是仔细想想，里面藏了很多坑，越往后做越举步维艰，那么问题在哪呢？现在我们来仔细看一下。其实这套大数据方案本质上就是一个 Lambda 架构，原始数据都是一个源头，例如用户行为日志、Binlog 等，分别走了两条链路：一条是实时链路，也就是加速层（Speed Layer），通过流计算处理，把数据写入实时的存储系统；另一条链路就是离线链路，也就是批计算，最典型的就是将数据归档至 Hive，再通过查询层如 Spark 对数据做加速查询，最后再对接在线应用、大盘或者第三方 BI 工具。
典型大数据架构的痛点
针对市面上这些开源产品，就存储而言，我们来逐一分析，这些产品是否都能具备满足业务需求的能力。
首先是基于离线存储的 Hive，其次是提供点查询能力的 HBase、Cassandra、然后是 MPP 架构号称能面向 HTAP 的 Greenplum、以及最新兴起的用于做快速分析的 Clickhouse 等等都是基于解决方案而面世的存储产品。
但以上的每个存储产品都是一个数据的孤岛，比如为了解决点查询的问题，数据需要在 HBase 里面存储一份；为了解决列存的快速分析，数据需要在 Druid 或者 Clickhouse 里面存一份；为了解决离线计算又需要在 Hive 里面存储一份，这样带来的问题就是：
1）冗余存储
数据将会存储在多个系统中，增加冗余存粗。
2）高维护成本
每个系统的数据格式不一致，数据需要做转换，增加维护成本，尤其是当业务到达一定量级时，维护成本剧增。
3）高学习成本
多个系统之前需要完全打通，不同的产品有不同的开发方式，尤其是针对新人来说，需要投入更多的精力去学习多种系统，增加学习成本。
简化的大数据架构
面对这样一个无比冗余无比复杂的系统，我们应该怎么去解决这些问题呢？我们可以对 Lambda 架构做一个简化。其实业务的本质就是将数据源做一个实时处理或者离线处理（批处理），从业务场景出发，我们希望不管是实时数据还是离线数据，都能统一存储在一个存储系统里面，而且这个存储还必须要满足各种各样的业务需求。这样听起来很玄乎，感觉这个产品需要支持各种各种的场景，非常复杂。但是如果我们能把架构做成这样，将会非常完美，这样就从本质上解决了流批统一的计算问题，一套 SQL 既能做流计算又能做批计算，再深挖其底层原理，还解决了存储问题，流数据和批数据都统一存储在同一个产品。
编者注：
这一部分作者从实时业务场景推演到典型的大数据架构，提出了实时数据的分析、存储、查询等需求，同时总结现有框架的痛点：冗余存储、高维护成本、高学习成本。最后作者描述了可以满足种种需求的理想大数据框架。
看起来很完美的Data Lakes
针对以上简化的架构，我们可以看看开源社区为了解决这些问题所推出的一些产品，例如 Data Lakes。首先采集的数据有统一的存储，不管是 HDFS、OSS 还是 AWS，数据以增量的形式存储在数据湖里，再通过查询层不管是 Hive、Spark 还是 Flink，根据业务需求选择一个产品来做查询，这样实时数据以及离线数据都能直接查询。整个架构看起来很美好，但是实际问题在于：
1）数据增量写入不满足实时性
开源的实时写入并不是实时写入，而是增量写入。实时和增量的区别在于，实时写一条数据就能立马查询可见，但是增量为了提高吞吐会将数据一批一批的写入。那么这套方案就不能完全满足数据实时性的要求。
2）查询的 QPS
我们希望这个架构既能做实时分析，又能做流计算的维表查询，存储里面的数据能否通过 Flink 做一个高并发的查询，例如每秒钟支持上千万上亿 QPS 的查询？
3）查询的并发度
整个方案本质都是离线计算引擎，只能支持较低的并发，如果要支持每秒钟上千的并发，需要耗费大量的资源，增加成本。
综上所述，这个方案目前还不能完全解决问题，只能作为一个初期的解决方案。
编者注：
数据湖是针对以上痛点和需求提出的新的解决方法，相较于典型的大数据架构，虽然实现了对实时数据和离线数据的直接查询，但是数据湖框架依旧存在一些问题：不满足实时性；QPS瓶颈；查询的并发度不高。
HSAP之我见
什么是HSAP
针对以上问题我们做了一个细致的分析，大致根据查询并发度要求或者查询 Latency 要求，将 Patterns 分为四类：
- Batch：离线计算
- Analytical：交互式分析
- Servering：高 QPS 的在线服务
- Transaction：与钱相关的传统数据库（绝大多数业务并不需要）
目前市面上都在说 HTAP，经过我们调研 HTAP 是个伪命题，因为 A 和 T 的优化方向不一样。为了做 T，写入链路将非常复杂，QPS 无法满足需求。若是对 T 的要求降低一点，就会发现 Analytical 和 Severing 的联系非常紧密，这两块的技术是可以共用的，所以我们放弃了 T 就相当于放弃了 Transaction，于是我们提出新的一个架构叫做 HSAP，那我们需要做的就是把提供服务和分析的数据存储在一个系统里，通过一套分析引擎来做处理。
基于HSAP的大数据架构
HASP 系统接入到我们刚刚简化的架构中就成为非常的完美的大数据架构。HSAP 系统与 Flink 做维表关联，对离线数据做批处理，然后对接在线应用提供在线服务，例如报表、大盘等。
PostgreSQL生态
那么接入 HSAP 系统之后，在线应用和系统怎么样来用呢？为了减少使用难度，就要引需要一个生态系统来做支撑，经过我们反复调研，我们认为是 PostgreSQL，主要有以下几点：注： PostgreSQL是一种特性非常齐全的自由软件的对象-关系型数据库管理系统（ORDBMS）。POSTGRES的许多领先概念只是在比较迟的时候才出现在商业网站数据库中。
1）丰富的工具对接
PostgreSQL 具有非常完备的工具对接，不管是开发工具还是 BI 分析工具，都有着丰富的支撑能力。
2）详尽的文档支撑
通常来讲写文档需要耗费大量的时间，PostgreSQL 有着非常详尽的文档，如果能够直接复用 PostgreSQL 的文档，将会减少工作量。同时开发者们只需要根据 postgreSQL 文档来开发，减少学习成本。
3）多元化的扩展
PostgreSQL 有着非常多元化的扩展，例如地理信息的 PostGis，Matlab 等，开发者们可以根据业务需求选择对应的扩展。
编者注：
大数据架构中从transaction到analytical的转换导致了HTAP到HSAP的演化。作者提出HSAP架构，把提供服务和分析的数据存储在一个系统里，通过一套分析引擎来做处理。同时介绍了PostgresSQL作为生态系统支撑。
新一代的实时交互式引擎—Hologres
基于以上所有内容，进入到我们今天的重点，也就是我们在阿里云重磅发布的新一代实时交互式引擎，中文名叫交互式分析，英文名叫 Hologres。Hologres 这个名字怎么来的呢？Hologres 由 Holographic（全息宇宙）和 Postgres 组成。
Hologres的架构
Hologres 的架构比较简单，从下往上看，最底层是统一的存储系统，可以是阿里云统一的 Pangu、业务的 HDFS 或者 OSS、S3 等，存储上面是计算层，提供类似的 MPP 架构计算服务，再往上是 FE 层，根据查询信息将 Plan 分发到各个计算节点，再往上就是 PostgreSQL 生态的对接，只要有 JDBC/ODBC Driver 就能对 Hologres 做查询。注： JDBC（Java Data Base Connectivity,java数据库连接）是一种用于执行SQL语句的Java API；
开放数据库互连（Open Database Connectivity，ODBC）是微软公司开放服务结构（WOSA，Windows Open Services Architecture）中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API。
Hologres：云原生
注：云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
1）存储计算分离
Hologres 的架构是完全是存储计算分离，计算完全部署在 K8s 上，存储可以使用共享存储，可以根据业务需求选择 HDFS 或者云上的 OSS，这样用户就能根据业务需求对资源做弹性扩缩容，完美解决资源不够带来的并发问题。
注：
k8s：Kubernetes 是用于自动部署，扩展和管理容器化应用程序的开源系统。
2）存储优势
- 全异步：支持高并发写入，能够将 CPU 最大化利用；
- 无锁：写入能力随资源线性扩展，直到将 CPU 全部写满；
- 内存管理：提供数据 cache，支持高并发查询。
3）计算优势
- 高性能混合负载：慢查询和快查询混合一起跑，通过内部的调度系统，避免慢查询影响快查询；
- 向量化计算：列式数据通过向量化计算达到查询加速的能力；
- 存储优化：能够定制查询引擎，但是对存储在 Hologres 数据查询性能会更优。
基于Hologres的典型应用
下面给大家介绍一下，Hologres 在阿里巴巴内部的一个典型应用。数据实时写入至 Flink，经由 Flink 做实时预处理，比如实时 ETL 或者实时训练，把处理的结果直接写入 Hologres，Hologres 提供维表关联点查、结果缓存、复杂实时交互、离线查询和联邦查询等，这样整个业务系统只需要通过 Hologres 来做唯一的数据入口，在线系统可以通过 PostgreSQL 生态在 Hologres 中访问数据，无需对接其他系统，这样也能解决之前架构的各种查询、存储问题。
注： ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。
真正的实时数仓：Flink+Hologres
综上所述，我们认为，真正的实时数仓只需要 Flink+Hologres 即可，Flink 做流、批数据的 ETL 处理，将处理的数据写入 Hologres 做统一的存储和查询，这样业务端直接对接 Hologres 提供在线服务。
编者注：
作者介绍了Hologres架构及其优点，最后提出了实时数字仓库的构想。
总结
目前的实施业务已经不满足于典型框架存储和一般维表特征关联，需要指标可视化、**维表关联点查、结果缓存、复杂实时交互、离线查询和联邦查询**等功能完成数据流分析。传统的大数据架构已经不能满足日益复杂的需求和日渐膨胀的数据量，工业界希望提出新的大数据架构解决以上的难题。
如今，数据湖、数据仓库等概念被提出用来构建新的大数据框架，这些框架虽然对上述难题进行了一定程度的缓解，但是仍然存在一些问题，如实时性、QPS值不高等。在此基础上，作者介绍了阿里云新发布的实时交互式引擎（Hologres）,该引擎由存储系统、计算层、FE层和PostgreSQL层，实现了存储计算分离并使用户能根据业务需求对资源做弹性扩缩容，完美解决资源不够带来的并发问题。本文最后介绍了Hologres的存储、计算优势，并举例其在阿里巴巴的典型应用，提出了使用Flink+Hologres构建实时数据仓库更高性能实现在线服务的构想。
若有收获，就点个赞吧
0 人点赞
