云原生HSAP系统Hologres产品价值剖析

　　云原生HSAP系统Hologres产品价值剖析

　　一、主流实时数仓构架：Lambda

　　二、阿里Lambda实践

　　三、云原生HSAP系统Hologres产品

　　一、主流实时数仓构架：Lambda1.时效性是数据价值的倍增器

　　企业拥抱数字化变革已成为行业共识。众所周知，数据价值会随着时间的推移而快速增加，因此，时效性是数据价值的倍增器。

　　此处所言的时效性是广泛概念，首先收录端到端的数据，实时数据的采集、加工以及剖析。其次时效性收录怎么样让实时剖析的疗效快速转化为实时服务，为线上生产系统提供数据服务。同时还收录让现有数据构架的数据能为业务方进行快速自助式的剖析，快速响应业务变化。只有将以上三方面都做好，才能充分彰显数据价值，使数据中台、数据构架可以更好地为业务服务。

　　

　　1.png

　　2.主流实时数仓构架——Lambda构架

　　在企业数字化变革的过程中，许多企业都是摸着石头过河，为了解决业务的问题，不断升级数据构架。目前主流的实时数仓构架是Lambda构架。

　　美团、知乎、菜鸟等企业都成功进行了Lambda构架的实践。如下图所示，Lambda实时数仓在数据采集之后依照业务需求分为实时层与离线层，分别进行实时处理和离线处理。处理结果在数据服务层对接数据应用之前会进行数据的合并，从而实现实时数据与离线数据同时服务于在线数据应用和数据产品。

　　离线层处理：采集数据归并到离线数仓以后，首先会统一到ODS层。对ODS层的数据进行简单数据清洗，构建DWD层（明细层）。在企业数据建模的过程中，为了增强数据剖析效率以及进行业务分层，会对DWD层的数据进行进一步的加工和处理，相当于预计算。预估算结果在对接数据服务之前都会轮询到一些离线储存系统中。

　　实时层处理：逻辑与离线层类似，但是愈发讲求时效性。实时层同样是对上游数据库或则系统的数据进行实时数据的订阅和消费。消费数据然后会将其讲到实时的DWD层或DWS层。实时估算引擎提供的是估算能力，最终处理结果须要讲到一些实时储存中，例如KV Store等。

　　基于成本和开发效率的考虑，实时层和离线层通常并不完全同步。实时层通常保留两到三天的数据，或者出于极至的要求通常会储存三天的数据。而月、年的数据等更长的数据储存在离线数仓中。

　　以上是数仓的分层，而实际在业务的剖析应用时，业务方可能并不关心数据处理形式，而须要数据剖析的疗效，因此须要处理实时和离线的全量数据。实时层和离线层处理的数据分别写在两个不同的储存中，在对接数据服务之前须要进行数据合并操作，合并流处理与批处理的结果以后再提供在线服务。

　　

　　2.png

　　这个构架看似挺好地解决了离线数仓、数据剖析、数据大屏等众多业务问题。但是这个Lambda构架并不完美，仍存在一些难点。

　　3. Lambda构架疼点

　　1）一致性困局：主要彰显在2套语义、2套逻辑、2份数据。

　　Lambda构架一份数据分为离线层和实时层两条链路分别进行处理，而离线层和实时层引入的估算引擎、存储引擎都不同，也就是说流和批的语义不同，并且须要两套代码，也就是两套逻辑，那么势必数据处理的逻辑不同，导致同一份源数据处理结果不一致。

　　离线层和实时层的处理结果分别写在两个不同的储存中，一份数据经过批处理和流处理后形成起码两份数据，因此对接数据服务之前须要对多份数据进行合并。在此过程中须要不断地进行数据结构的重新定义，数据的轮询、变化、合并，都会带来数据一致性的问题。

　　数据一致性问题是构架设计的复杂性造成的，基本无解。目前业界都是从业务层面着手解决，即从业务上进行协商。例如当业务方可接受实时和离线数据的一致性差别率高于3%，就可以运行该构架。

　　

　　3.png

　　2）多套系统组合搭建、环环相扣、架构复杂、运维成本高：批处理一般会引入MaxCompute或自建的Hadoop引擎等离线估算引擎。流处理部份可能会引入Flink、Spark等多个新产品。数据处理后会写入到储存，数据服务层引入的产品可能会愈加复杂。例如为了提供高效的点查询引入HBase；为了对离线数仓中的数据进行交互式剖析，会引入Presto，Impala等；也有可能会将数据导出到Mysql中；为了在实时数仓中实现端到端的实时，多会采用Druid、ClickHouse等开源产品。以上系统首先引起系统构架复杂、运维成本高。数据开发朋友须要把握多套系统，系统引入的学习成本很高。同时，一份数据经过层层处理、层层清洗以后，整个链路的数据将发生特别多冗余。实时层、离线层各有一套数据，数据合并之前还有一套数据。数据不断膨胀导致储存资源的巨大消耗。

　　

　　4.png

　　3）开发周期长、业务不敏捷：任何一套数据或业务方案上线之前都须要进行数据校对、数据验证。数据校对过程中一旦出现问题，其定位和确诊将非常复杂。因为数据问题可能发生在任何环节，也可能在数据应用层才发觉问题。发现问题后须要排查数据合并、实时估算、离线层、甚至数据采集等环节是否出现问题，过程复杂，导致数据修订和补数周期长。同时，一份数据须要在离线层和实时层分别进行处理，并且处理链路较长。如果须要在链路尤其是偏上游环节新增数组，整条链路都须要一起订正，过程漫长，并且对历史数据进行补数，消耗巨大资源与时间。

　　4）数据开发完成、业务得到认可，上线驱动业务得到非常好的疗效以后，更多业务方会认识到数据构架的价值，并提出需求。产品营运或则决策层可能觉得该数据非常有价值，会要求开放新的数据剖析报表以进行剖析，或者能够自助式进行实时剖析。而在Lambda构架中，所有估算、分析都是在估算层完成的。例如在离线层加一层业务数据，需要重新开发一个DWS层的作业，将数据讲到DWS层数据储存中，再将其同步到数据服务系统，然后再提供线上报表服务。该过程须要数据开发朋友介入，需要进行数据需求评审与评估，并且开发周期起码将离线处理时间T+1。很多场景时间较紧急时，无法等待T+1的时间，也许就错过了商业机会。另外，新的业务需求要做实时链路的开发也是同样，需要进行实时作业的开发、校对、上线，开发周期长。因此Lambda构架灵活性未能满足线上业务诉求。

　　

　　5.png

　　二、阿里Lambda实践1.搜索推荐精细化营运老构架

　　实际构架比上述Lambda理想构架愈加复杂。阿里巴巴最大的数据场景是搜索推荐场景。下图所示为搜索推荐精细化营运的旧构架在Lambda构架上的实践，与上述Lambda构架非常相像。

　　下图最右侧为阿里的数据，包括交易数据、用户行为数据、商品属性数据、搜索推荐数据等。将数据统一通过数据集成批量导出到MaxCompute，或者通过实时消息队列DataHub采集数据后通过Flink清洗。

　　线上构架演变：Fink发展迅猛，阿里的典型业务——双11大屏，是中单上数据通过Flink清洗后写入HBase系统。HBase对接实时大屏提供高效的点查询。

　　MaxCompute是阿里巴巴发展十年以上的离线数仓产品，承载了阿里特别大的离线数据剖析的场景。实时数据处理完成后就会产生一套离线数据，绝大部分离线数据都储存在MaxCompute。线上营销、对抗竞争等数据都来自MaxCompute。

　　随着Flink实时估算能力的提高，以及Flink实时数仓、实时报表上的应用的发展，所有的产品营运以及决策层都听到了实时对于业务的价值。因此在MaxCompute提供了多年离线剖析能力、发现Flink强悍估算的实时能力的基础之上，业务方提出同样一份数据能够通过实时形式提供实时的在线剖析服务能力。因此引入了Druid等开源产品，通过Flink将线上日志实时讲到Druid，提供Druid提供实时剖析能力。例如对接实时报表、实时决策、实时库存系统。

　　综上所示产生了两条链路，实时数据在Druid中做剖析，离线数据在MaxCompute做剖析。但因为Druid的存储容量等各方面性能的要求，在Druid中仅储存两天或两三天内的数据。进行大促等营销活动常常须要对比历史环比或同比数据。比如须要和今年或则是前年的双十一做对比剖析，在营销策略的剖析上须要对上周或则上上周的数据进行剖析，双11正式期须要与预热期数据进行同比剖析等。此时运用的是离线数据和实时数据的结合场景。方式是引入了更多产品。将MaxCompute离线数仓的数据与Druid中的实时数据在Mysql中进行合并，合并完成后再提供线上服务。

　　

　　6.png

　　2.多套系统、多种场景、分析服务一体化能力

　　可见业务上游的数据、数据清洗的链路均未发生变化，而是业务应用层、业务剖析层场景发生了更多变化，出现了更多诉求，因此引入了更多产品进行业务支撑。但是该旧构架依然属于典型Lambda构架，因此在阿里巴巴高速的业务下降和膨胀之下，其一致性、运维复杂、成本高、业务敏捷性等问题逐步显现。

　　简单剖析在业务场景日渐复杂的情况下为什么引入多种系统，各系统分别提供如何的能力。

　　KV Store：Redis/Mysql/HBase/Cassandra，应对数据产品高QPS查询场景，提供高效点查询能力。

　　交互式估算能力：Presto/Drill。

　　实时数仓：ClickHouse/Druid，实时储存+在线估算能力。

　　

　　7.png

　　3..搜索推荐精细化营运新构架

　　引入多种产品是为了支撑以上三种能力，那么能够在多种业务场景下同时解决相同业务问题并且将多种大数据产品的能力有机统一于一个引擎。使数据才能进行统一储存，然后对下层提供统一服务。因此产生右图所示构架。

　　上游数据处理和清洗不发生变化，而在对接下层业务应用时提供愈发丰富的能力。例如系统才能同时提供点查询、结果缓存、离线加速、联邦剖析、交互式剖析等能力。将该系统定义为HSAP（Hybrid Serving Analytical Processing）系统，分析服务一体化，能够实现一份数据同时用于实时剖析与在线服务。

　　Hologres产品是在该背景下推出的云原生HSAP数据库系统。Hologres产品实现实时离线数据统一储存，支持Flink数据或实时估算的实时数据实时写入，支持离线数据批量导出。第二，对接数据服务层面以实时剖析为中心而设计，可同时满足业务实时剖析与在线服务需求。第三，不改变原有实时数仓构架，通过MaxCompute直接加速，利用Hologres估算能力直接对接线上服务。

　　

　　8.png

　　三、云原生HSAP系统Hologres产品1. Hologres产品核心优势

　　云原生HSAP数据库，一份数据同时用于实时剖析与在线服务。

　　极速响应：实现毫秒级响应，从而轻松满足顾客海量数据复杂多维剖析需求。千万QPS点查询，实时剖析上千QPS简单查询。

　　实时储存：支持亿级写入TPS，时效性强，写入即可查询。

　　MaxCompute加速：MaxCompute直接剖析，无数据搬迁，无冗余储存。

　　PG生态：PG开发者生态，开发人员友好，PG工具（pslq、Navicat、DataGrip）兼容。BI工具无缝对接。

　　

　　9.png

　　2019年双十一 Hologres线上服务数据：在双十二当日超大数据量场景下，Hologres支持了高峰1.3亿实时写入TPS，并且数据写入即可查，提供了1.45亿高并发在线查询QPS。

　　

　　10.png

　　2.Hologres交互式剖析产品-典型应用场景

　　离线数据加速查询：目前支持MaxCompute离线数据秒级交互式查询。无需额外ETL工作，便捷地把冷数据转换为便于理解的剖析结果，提升企业决策效率，降低时间成本。

　　实时数仓：Flink+Hologres，旨在通过搭建用户洞察体系，实时检测平台用户情况，并从不同视角对用户进行实时确诊，进而采取针对性的用户营运策略，从而达到精细化用户营运目的。助力实时精细化营运。

　　实时离线联合估算：基于离线数仓MaxCompute和实时数仓交互式剖析的联合估算，从商业逻辑出发，实现离线数据剖析实时化，实时离线联邦查询，构筑实时全链路精细化营运。

　　接下来具体介绍以上三种场景的具体构架以及应用。

　　

　　11.png

　　3.MaxCompute加速剖析

　　传统方案——数据冗余、成本高、开发周期长：如下图所示，左侧数据通过数据集成同步到离线数仓后进行DWD层、DWS层等的加工，加工过后的数据对接线上服务。

　　一种方案是直接使用MaxCompute的MapReduce估算能力提供线上营销策略、线上实时报表。该方案似乎可以挺好地完成业务需求，但是在MapReduce任务递交后须要一定的等待排队、等待资源分配的时间。很多时侯等待时间小于数据剖析时间，并且剖析时效性所为几十分钟甚至小时级别。效率较低。

　　因此将数据从MaxCompute离线数仓中转移到线上Redis、Mysql等产品中，利用其交互式剖析或点查询能力提供服务。但是从MaxCompute离线数仓中集成数据到线上Redis、Mysql等产品中存在困难。首先是数据容量方面，例如当离线数仓ADS层数据量十分大，Mysql难以承载时，需要在离线数仓中添加一层ADS作业，再次进行数据加工和预估算，缩小数据量后将数据集成到Mysql中。也就是为了进行数据剖析，需要进行进一步的数据预处理，维护一个数据同步的作业，数据同步后还须要储存到Mysql中。以上流程将会造成数据冗余、并且成本高，开发周期长。

　　

　　12.png

　　Hologres——无数据搬迁、数据剖析效率高：Hologres是储存估算分离的构架，与MaxCompute进行了无缝打通。Hologres在该场景下提供估算能力，而MaxCompute相当于Hologres的储存集群。可以直接对MaxCompute储存的数据进行读取与加速。只要数据在MaxCompute中加工完、可查询，通过Hologres可以直接进行数据剖析。在MaxCompute加速剖析场景下，Hologres是围绕交互式剖析场景设计的，发下作业后可立即得到结果，从而满足高效、自助式剖析，并且成本较低。

　　

　　13.png

　　Demo演示：可参考文档》实时剖析海量MaxCompute数据进行demo演示，多种功能均可实现微秒级查询，实时返回。

　　

　　14.png

　　DataWorks深度集成：Hologres与DataWorks进行了深度集成。MaxCompute数据直接进行加速剖析时须要构建一个Web表，在此支持了一键MaxCompute表结构同步、一键MaxCompute数据同步，以及一键本地上传文件，详情可以参考文档》》HoloStudio。

　　

　　15.png

　　4.实时数仓——实时成本高、开发周期长、业务支持不灵活

　　实时数仓构架是数据采集之后，在ODS层Kafka中通过Flink进行清洗，产生DWD层数据。如果有更进一步的加工需求，再次对DWD层数据进行订阅，写入DWS层。根据不同业务场景引入HBase、MySQL、OLAP等不同产品。

　　该构架早已挺好地解决了现有问题。但是该构架中所有估算逻辑是在Flink中处理完成后写入DWS层。一旦须要加入新的业务场景或则对现有业务场景进行调整，需要新增数组或估算逻辑时，就须要重新评估链路、重新进行Flink作业的开发，修改或降低一个Flink作业后再讲到DWS层。

　　因此在该场景中，大部分估算都在Flink层，其业务灵活性不够高。也就是说该构架估算都是预先做好的，无法满足自助式剖析或则剖析之前DWD层数据。

　　

　　16.png

　　5.实时、离线、分析、服务一体化方案

　　为解决上述问题，Hologres与飞天大数据平台（如Flink、MaxCompute）联合推出了新一代实时、离线、分析、服务一体化方案。数据依然在MaxCompute中进行离线数仓清洗，在Flink中进行实时清洗。但是Flink层数据清洗完成后可以将明细层数据直接写入Hologres，由Hologres对接线上大屏。Hologres提供了强悍的实时储存和实时估算能力，意味着明细层数据也可以直接对接线上报表。

　　实时数据和离线数据的联合剖析，从前存在MaxCompute中的数据可以直接与Hologres进行关联分析，实现联邦查询。

　　实际Flink估算的业务场景中，如果希望将数据沉淀出来提供线上服务，可以再度订阅Hologres，将Hologres DWD层数据加工为DWS层数据，写回Hologres。同时，Hologres在Flink作业中支持超大维表能力，其他Flink作业可以对Hologres中的数据进行关联剖析。

　　

　　17.png

　　上述为实时、离线、分析、服务一体化方案的阐述，实际业务场景中的方案远比以上陈述复杂。

　　实际业务场景：下图所示为飞天大数据平台产品家族推出的方案构架。数据链愈加复杂，但是本质与上述构架相同，上游数据源通过数据采集到实时数仓，进行关联剖析后最终对下层数据应用提供实时离线联邦查询能力或剖析能力。

　　

　　18.png

　　6.互联网-内容资讯顾客案例

　　Hologres不仅在阿里巴巴集团内部广泛应用外，在云上，互联网行业、传统企业等也早已得到了大量应用。

　　下图所示为典型的互联网顾客案例。小影是一款在泰国受欢迎的短视频APP。互联网行业不仅实时大屏、实时报表之外都会进行用户剖析、用户画像、用户标签、实时视频推荐等。该场景与阿里巴巴搜索推荐精细化场景相像，因此其构架引用是基于阿里云飞天大数据产品家族的离线数据MaxCompute、实时估算Flink、交互式剖析Hologres搭建上去的。

　　

　　19.png

　　7.围绕数据建设、打通全链路

　　Hologres围绕着大数据生态、PG生态、阿里云生态，围绕着数据建设的全链路建立了数据生态。从数据源对接，导数据同步，到数据加工，到数据运维，到数据剖析和应用都进行了全链路打通。

　　

　　20.png

　　Hologres在云上早已即将商业化，提供了包月包年、按量付费等不同计费尺寸，支持估算、存储资源不同配比订购，用户可以按照自身业务需求进行商品采购。同时数据产品、数据加工、数据同步、数据开发工具等支持引用自建、开源等产品。

　　指定尺寸首月3折，新一代HSAP系统Hologres重磅发布！点击》》立即订购

　　如果你们对Hologres产品有兴趣，关心产品动态，欢迎访问下方链接进行学习与交流。

　　

　　21.png