| 编辑推荐: |
本文主要介绍了传统数仓痛点、HSAP：服务分析一体化、Hologres及数仓架构升级内容。
本文来自于segmentfault，由Linda编辑、推荐。 |
|
一、传统数仓痛点
1）传统数据仓库痛点
目前来说，大数据相关的业务场景一般有实时大屏、实时BI报表、用户画像和监控预警等，如下图所示。
实时大屏业务，一般是公司领导层做决策的辅助工具，以及对外成果展示，比如双十一实时成交额大屏等场景。
实时BI报表，是运营和产品经理最常用到的业务场景，适用于大部分的报表分析场景。
用户画像，常用在广告推荐场景中，通过更详细的算法给用户贴上标签，使得营销活动更加有针对性，更加有效的投放给目标人群。
预警监控大屏，比如对网站、APP进行流量监控，在达到一定阈值的时候可以进行报警。
对于上面这些大数据业务场景，业界在很早之前就开始通过数据仓库的建设来满足这些场景的需求，比较传统的做法是如下图所示的离线数据仓库，其大致流程就是：首先将各类数据收集起来，然后经过ETL处理，再通过层层建模对数据进行聚合、筛选等处理，最后在需要的时候基于应用层的工具对数据进行展现，或者生成报表。
上面这种方式虽然可以对接多种数据源，但是存在一些很明显的痛点：
ETL逻辑复杂，存储、时间成本过高；
数据处理链路非常长；
无法支持实时/近实时的数据，只能处理T+1的数据。
2）Lambda架构痛点
随着实时计算技术的兴起，出现了Lambda架构。Lambda架构的原理如下图所示，其思路其实是相当于在传统离线数仓的基础上再加上一个处理实时数据的层，然后将离线数仓和实时链路产生的数据在Serving层进行Merge，以此来对离线产生的数据和实时产生的数据进行查询。从2011年至今，Lambda架构被多数互联网公司所采纳，也确实解决了一些问题，但是随着数据量的增大、应用复杂度的提升，其问题也逐渐凸显，主要有：
由多种引擎和系统组合而成，开发和维护成本高，学习成本高；
数据在不同的View中存储多份，空间浪费，数据一致性的问题难以解决；
从使用上来说，Batch，Streaming以及Merge Query等处理过程中均使用不同的language，使用起来并不容易；
学习成本非常高，增大了应用成本。
上面讲到的问题，在阿里内部其实也都遇到过。如下图所示是阿里巴巴在2011-2016年沉淀下来的一套实时数仓架构，其本质上也是Lambda架构，然而随着业务量及数据的增长，关系复杂度越来越大，成本急剧增加，因此，我们迫切的需要一种更优雅的方案去解决类似的问题。
二、HSAP：服务分析一体化
基于上述背景，我们提出了HSAP（Hybrid Serving and AnalyticalProcessing）理念，它既能支持很高QPS场景的查询写入，又能将复杂的分析场景在一套体系里面完成。那么，HSAP理念落地的核心是什么？
首先，要有一套非常强大的存储，能够同时存储实时数据和离线数据，统一数据存储；
同时还要有一种高效的查询服务，在同一个接口下（比如SQL），能够支持高QPS的查询，支持复杂的分析以及联邦查询和分析；
系统能够直接对接前端应用，例如报表和在线服务等，不需要再额外的导入导出就能即席分析，统一数据服务，减少数据移动。
三、关于Hologres
基于HSAP的设计理念，我们要开发并落地出相应的产品，于是便诞生了Hologres。Hologres是基于HSAP服务分析一体化理念的最佳落地实践，兼容PostgreSQL生态、支持MaxCompute数据直接查询，支持实时写入实时查询，实时离线联邦分析，低成本、高时效帮助企业快速构筑流批一体的实时数仓。Hologres这个词是Holographic和Postgres的组合，Postgres比较好理解，代表着Hologres兼容PostgreSQL生态。而Holographic需要展开分享，先看下图：
Holographic中文翻译是"全息"，就是大家经常听到的3D全息投影技术的"全息"。而Holographic
Principle（全息原理）在物理学中是用来描述一个空间的性质可编码在其边界上。上图是一副假想中黑洞的图片，距离黑洞一定距离处于可以逃逸出黑洞引力的临界点构成了Event
Horizon，就是图中发亮光的那一圈。全息原理认为所有落入黑洞的物体信息内容可能会被完全包含在Event
Horizon的表面。Hologres要做的事情就是对数据黑洞中的全部信息做存储和各种类型的计算。
四、Hologres核心技术揭秘
Hologres架构非常简单，是存储计算分离的架构，数据全部存在一个分布式文件系统中，系统架构图如下图所示：
服务节点Backend真正去接收数据、存储和查询，并且能够支持数据的计算；
执行引擎Frontend接收路由分发的SQL，然后生成逻辑执行计划，再通过优化器生成分布式的物理执行计划，发布到Backend做分布式的执行；
接入端由LBS做相应的负载均衡任务。
下图中黄色部分均部署在容器中，整个分布式系统可以做到高度容错。
兼容PostgreSQL生态，在上层可以直接对接开源或者商业化的开发/BI工具，开箱即可用。
存储计算分离
Hologres采用存储计算分离架构，用户可以根据业务需求进行弹性扩缩容。分布式存储中，常用的架构有如下三种：
Shared Disk/Storage：就是在存储集群上挂载了很多磁盘，每个计算节点都可以直接访问这些共享盘；
Shared Nothing：架构就是每个计算节点自己挂载存储，节点之间可以通信，但是各个节点之间的盘不共享，存在资源浪费的情况；
Storage Disaggregation：就是相当于把存储集群看做一个大的磁盘，每个计算节点都可以访问，且每个计算节点都有一定的缓存空间，可以对缓存数据进行访问，也无需关心存储集群的管理，这种存储计算分离的架构便于灵活扩容，能够有效节省资源。
流批一体的存储
Hologres定位是流批一体统一存储。对于典型的Lambda架构，是将实时数据通过实时数据的链路写入到实时数据存储中，离线数据通过离线数据的链路写入到离线存储中，然后将不同的Query放入不同的存储中，再做Merge，由此带来多份存储开销和应用层复杂的Merge操作。而通过Hologres，数据收集之后可以走不同的处理链路，但是处理完成之后的结果都可以直接写入Hologres，这样就解决了数据的一致性问题，也不需要去区分离线表和实时表，降低了复杂度，也大大降低了使用者的学习成本。
存储引擎
Hologres底层支持行存储和列存储两种文件格式，行存适用于基于PK的点查场景，列存适用于OLAP复杂查询场景。对于两种存储格式Hologres在底层处理也有略微不同，如图所示。数据写入的时候先写log，log存储在分布式文件系统，保证整个服务的数据不会丢失，因为即便服务器挂掉也可以从分布式系统中恢复。Log写完之后再写MemTable，就是内存表，这样系统才认为是数据写入成功。MemTable有一定的大小，写满了之后会将其中的数据逐渐Flush到文件中，文件是存储在分布式系统中的。而对于行存储和列存储的区别就在Flush到文件的这个过程中，这个过程会将行存表Flush成行存储的文件，列存表会Flush成列存文件。在Flush的过程中会产生很多小文件，后台会将这些小文件合并成一个大文件。
执行引擎
Hologres执行引擎是通用的分布式查询引擎，侧重于优化高并发低延迟的实时查询。通用是指可以表达和高效地执行所有类SQL查询。其它的分布式查询引擎，有的专注优化实时表的常用单表查询，但是对复杂查询表现不佳；有的支持复杂查询，但是实时场景性能要差一截。Hologres的理念是不做妥协，对这些场景都要瞄准极致性能。Hologres执行引擎能够做到对各种查询类型的高性能处理，主要是基于以下特点：
端到端的全异步处理框架，可以避免高并发系统的瓶颈，充分利用资源，并且最大可能地避免存储计算分离系统带来的读数据延迟的影响。
查询用异步算子组成的执行图DAG表示，可以方便对接查询优化器，利用业界各种查询优化技术。
算子内部处理数据时最大可能地使用向量化执行。
和存储引擎的深度集成，灵活的执行模型，能够充分利用各种索引，并且最大化地延迟向量物化和延迟计算，避免不必要的读数据和计算。
对常见实时数据应用查询模式的自适应增量处理。
对一些查询模式的独特优化。
优化器
Hologres的目标就是用户开箱即可用，即通过SQL就能完成日常所有的业务分析需求，无需再做额外的建模处理等操作。基于新的硬件技术，Hologres设计并实现了自己独特的计算和存储引擎，而优化器扮演的角色就是将用户执行的SQL高效的运行在计算引擎上。Hologres优化器采用基于代价的优化器，能够生成复杂的联邦查询执行计划，尽可能发挥多套计算引擎的能力。同时，在长期与业务打磨的过程当中，也积累沉淀了大量的业务优化手段，让Hologres的计算引擎在不同的业务场景下都能够发挥极致的性能。
HOS&HoloFlow
Hologres最核心的组件名叫blackhole，是一款完全自研的存储计算引擎，采用异步编程方式开发。blackhole的底层提炼出了灵活高效的异步框架：holo-os（简称HOS）。在实现高性能的同时，还实现了load
balance，解决了query长尾问题；实现了资源的高利用率、以及多种共享与隔离的机制。于此同时，holo-os还推广到了分布式环境，发展出了holo-flow分布式任务调度框架，这样就能保证在分布式环境下也能享受到单机调度的灵活性。
Frontend
Frontend是Hologres的接入层，兼容PostgreSQL协议，负责用户请求的接入、处理以及元数据的管理。但由于PostgreSQL是单机系统，处理高并发的用户请求能力有限。而Hologres面对的是复杂的业务场景以及需要支持万甚至亿级别的用户请求，所以在实现上Frontend采用分布式，通过多版本控制+元数据同步等方式实现了多Frontend之间信息实时同步，再配合LBS层的负载均衡实现了完全线性扩展和超高QPS的能力。
扩展执行引擎
在Frontend的基础上，Hologres也提供多扩展执行引擎。
PQE（P Query Engine)：运行SQL以及各种Function的执行器，Hologres兼容Postgres提供扩展能力，支持PG生态的各种扩展组件，如Postgis，UDF（pl/java，pl/sql,pl/python）等，完美满足不同场景不同用户的需求，从而提供更多的计算能力。
SQE（S Query Engine）：无缝对接MaxCompute(ODPS)的执行器，实现对MaxCompute的native访问，无需迁移和导入数据，就可以高性能和全兼容的访问各种MaxCompute文件格式，以及Hash/Range
clustered table等复杂表，实现对PB级离线数据的交互式分析。
生态与数据集成
Hologres作为流批一体的实时数仓，支持多种异构数据源的实时、离线写入，包括MySQL、Datahub等，能够达到每秒千万条的实时写入能力，写入即可查和每秒千万次的点查能力。而这些强大的能力都是基于Hologres的JDBC接口。Hologres在接口上完全兼容PostgreSQL（包括语法、语义、协议等），可以直接使用PostgreSQL的JDBC
Driver去连接Hologres，并进行数据的读写。目前市面上的数据工具，例如BI工具、ETL工具等等，都支持PostgreSQL
JDBC Driver，所以这意味着Hologres天生就有了广泛的工具兼容性和强大的生态，实现从数据处理到数据的可视化分析完整大数据生态闭环。
在线服务优化
Hologres作为HSAP服务与分析一体化的最佳落地实践，除了具备处理分析型query的能力外，还具备十分强大的在线服务能力，例如，KV点查与向量检索。在KV点查场景中，Holgres通过SQL接口可以轻松稳定地支持百万级的QPS吞吐与极低的延时。在向量检索场景，用户同样可以通过SQL的方式来实现向量数据的导入、向量索引的构建、查询等操作，无需额外转换就能查询，性能经过实际业务的测试也相比其他产品更优。此外，一些非分析型的query通过合理的建表、配合上Hologres强大的索引能力，也同样可以完美适用serving场景。
五、数仓架构升级
基于Hologres，多个业务场景也完成了架构升级，极大的简化了业务架构的复杂度，如下图所示：
总结
Hologres作为新一代云原生实时数仓，在今年阿里巴巴双11最核心的数据业务场景，连同实时计算Flink首次落地流批一体，并在稳定性、性能等方面经受住考验，实现商业全链路实时化，毫秒级的海量数据处理能力，2020双十一，Hologres顶住了5.96亿每秒的实时数据洪峰，单表存储高达2.5PB。基于万亿级数据对外提供多维分析和服务，99.99%的查询可以在80ms以内返回结果，真正做到数据的实时及离线一体化，支持在线应用服务，为商家和消费者带来了更加智能的消费体验。随着业务的发展和技术的演进，Hologres也将持续优化核心技术竞争力，真正实现服务和分析一体化的美好愿望，为更多用户持续赋能。
Hologres诞生到参与2020年史上最强双十一的三年多时间里，完成不少从0到1的突破：
从一个业务到数百业务实例，覆盖了阿里巴巴集团内90%以上业务场景，包括双十一实时直播间、智能推荐、阿里妈妈数据平台、国际站数据平台、菜鸟数据平台、友盟+全域数据分析、CCO智能客服、新零售数据平台、考拉、饿了么等业务。
集群规模从0到近万台，且存储集群和计算集群使用率都比较高，并完成了系统产品化-上云-商业化的三级跳，完美赋能阿里云公共云+专有云+金融云业务。
提出HSAP（HybridServing & Analytics Processing）服务分析一体化的系统设计理念，同一份数据同时满足实时离线在线场景的计算需求，极大的简化了数仓架构的复杂度，降低了成本，重新定义数仓趋势。
同时，有关Hologres的技术解读Paper入选数据库顶会VLDB《Alibaba Hologres:
ACloud-Native Service for Hybrid Serving/Analytical
Processing》（http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf）
值此之际，我们也将首次对外公开Hologres的核心底层技术，揭秘Hologres为何能支撑阿里巴巴核心场景的落地。 |
