演讲嘉宾简介：阿里云计算平台-交互式分析团队产品经理——李姗姗（花名：柔惠）
以下内容根据演讲视频以及PPT整理而成。点击查看》》视频回放
本次分享主要围绕以下三个方面：
一、主流实时数仓架构：Lambda
二、阿里Lambda架构实践
三、云原生HSAP系统Hologres
一、主流实时数仓架构：Lambda
1.时效性是数据价值的倍增器
企业拥抱数字化转型已成为行业共识。众所周知，数据价值会随着时间的推移而快速降低，因此，时效性是数据价值的倍增器。
此处所言的时效性是广泛概念，首先包含端到端的数据，实时数据的采集、加工以及分析。其次时效性包含怎么样使实时分析的效果快速转化为实时服务，为线上生产系统提供数据服务。同时还包含使现有数据架构的数据能为业务方进行快速自助式的分析，快速响应业务变化。只有将以上三方面都做好，才能充分体现数据价值，使数据中台、数据架构可以更好地为业务服务。
2.主流实时数仓架构——Lambda架构
在企业数字化转型的过程中，许多企业都是摸着石头过河，为了解决业务的问题，不断升级数据架构。目前主流的实时数仓架构是Lambda架构。
美团、知乎、菜鸟等企业都成功进行了Lambda架构的实践。如下图所示，Lambda实时数仓在数据采集之后根据业务需求分为实时层与离线层，分别进行实时处理和离线处理。处理结果在数据服务层对接数据应用之前会进行数据的合并，从而实现实时数据与离线数据同时服务于在线数据应用和数据产品。
离线层处理：采集数据归并到离线数仓之后，首先会统一到ODS层。对ODS层的数据进行简单数据清洗，构建DWD层（明细层）。在企业数据建模的过程中，为了提高数据分析效率以及进行业务分层，会对DWD层的数据进行进一步的加工和处理，相当于预计算。预计算结果在对接数据服务之前还会转储到一些离线存储系统中。
实时层处理：逻辑与离线层类似，但是更加讲究时效性。实时层同样是对上游数据库或者系统的数据进行实时数据的订阅和消费。消费数据之后会将其写到实时的DWD层或DWS层。实时计算引擎提供的是计算能力，最终处理结果需要写到一些实时存储中，例如KV Store等。
基于成本和开发效率的考虑，实时层和离线层一般并不完全同步。实时层一般保留两到三天的数据，或者出于极致的要求一般会存储七天的数据。而月、年的数据等更长的数据存储在离线数仓中。
以上是数仓的分层，而实际在业务的分析应用时，业务方可能并不关心数据处理方式，而需要数据分析的效果，因此需要处理实时和离线的全量数据。实时层和离线层处理的数据分别写在两个不同的存储中，在对接数据服务之前需要进行数据合并操作，合并流处理与批处理的结果之后再提供在线服务。
这个架构看似很好地解决了离线数仓、数据分析、数据大屏等诸多业务问题。但是这个Lambda架构并不完美，仍存在一些难点。
3. Lambda架构痛点
1）一致性难题：主要体现在2套语义、2套逻辑、2份数据。
Lambda架构一份数据分为离线层和实时层两条链路分别进行处理，而离线层和实时层引入的计算引擎、存储引擎都不同，也就是说流和批的语义不同，并且需要两套代码，也就是两套逻辑，那么势必数据处理的逻辑不同，导致同一份源数据处理结果不一致。
离线层和实时层的处理结果分别写在两个不同的存储中，一份数据经过批处理和流处理后产生至少两份数据，因此对接数据服务之前需要对多份数据进行合并。在此过程中需要不断地进行数据结构的重新定义，数据的转储、变化、合并，都会带来数据一致性的问题。
数据一致性问题是架构设计的复杂性导致的，基本无解。目前业界都是从业务层面着手解决，即从业务上进行协商。例如当业务方可接受实时和离线数据的一致性差异率低于3%，就可以运行该架构。
2）多套系统组合搭建、环环相扣、架构复杂、运维成本高：批处理通常会引入MaxCompute或自建的Hadoop引擎等离线计算引擎。流处理部分可能会引入Flink、Spark等多个新产品。数据处理后会写入到存储，数据服务层引入的产品可能会更加复杂。例如为了提供高效的点查询引入HBase；为了对离线数仓中的数据进行交互式分析，会引入Presto，Impala等；也有可能会将数据导入到Mysql中；为了在实时数仓中实现端到端的实时，多会采用Druid、ClickHouse等开源产品。以上系统首先导致系统架构复杂、运维成本高。数据开发同学需要掌握多套系统，系统引入的学习成本很高。同时，一份数据经过层层处理、层层清洗之后，整个链路的数据将发生非常多冗余。实时层、离线层各有一套数据，数据合并之前还有一套数据。数据不断膨胀造成存储资源的巨大消耗。
3）开发周期长、业务不敏捷：任何一套数据或业务方案上线之前都需要进行数据校对、数据验证。数据校对过程中一旦出现问题，其定位和诊断将十分复杂。因为数据问题可能发生在任何环节，也可能在数据应用层才发现问题。发现问题后需要排查数据合并、实时计算、离线层、甚至数据采集等环节是否出现问题，过程复杂，导致数据修订和补数周期长。同时，一份数据需要在离线层和实时层分别进行处理，并且处理链路较长。如果需要在链路尤其是偏上游环节新增字段，整条链路都需要一起订正，过程漫长，并且对历史数据进行补数，消耗巨大资源与时间。
4）数据开发完成、业务得到认可，上线驱动业务得到非常好的效果之后，更多业务方会认识到数据架构的价值，并提出需求。产品运营或者决策层可能认为该数据十分有价值，会要求开放新的数据分析报表以进行分析，或者能否自助式进行实时分析。而在Lambda架构中，所有计算、分析都是在计算层完成的。例如在离线层加一层业务数据，需要重新开发一个DWS层的作业，将数据写到DWS层数据存储中，再将其同步到数据服务系统，然后再提供线上报表服务。该过程需要数据开发同学介入，需要进行数据需求评审与评估，并且开发周期至少将离线处理时间T+1。很多场景时间较紧急时，无法等待T+1的时间，也许就错过了商业机会。另外，新的业务需求要做实时链路的开发也是同样，需要进行实时作业的开发、校对、上线，开发周期长。因此Lambda架构灵活性无法满足线上业务诉求。
二、阿里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做对比分析，在营销策略的分析上需要对上周或者上上周的数据进行分析，双11正式期需要与预热期数据进行环比分析等。此时运用的是离线数据和实时数据的结合场景。方式是引入了更多产品。将MaxCompute离线数仓的数据与Druid中的实时数据在Mysql中进行合并，合并完成后再提供线上服务。
2.多套系统、多种场景、分析服务一体化能力
可见业务上游的数据、数据清洗的链路均未发生变化，而是业务应用层、业务分析层场景发生了更多变化，出现了更多诉求，因此引入了更多产品进行业务支撑。但是该旧架构仍然属于典型Lambda架构，因此在阿里巴巴高速的业务增长和膨胀之下，其一致性、运维复杂、成本高、业务敏捷性等问题逐渐突显。
简单分析在业务场景逐渐复杂的情况下为何引入多种系统，各系统分别提供怎样的能力。
KV Store：Redis/Mysql/HBase/Cassandra，应对数据产品高QPS查询场景，提供高效点查询能力。
交互式计算能力：Presto/Drill。
实时数仓：ClickHouse/Druid，实时存储+在线计算能力。
3..搜索推荐精细化运营新架构
引入多种产品是为了支撑以上三种能力，那么能否在多种业务场景下同时解决相同业务问题但是将多种大数据产品的能力有机统一于一个引擎。使数据能够进行统一存储，然后对上层提供统一服务。因此形成下图所示架构。
上游数据处理和清洗不发生变化，而在对接上层业务应用时提供更加丰富的能力。例如系统能够同时提供点查询、结果缓存、离线加速、联邦分析、交互式分析等能力。将该系统定义为HSAP（Hybrid Serving Analytical Processing）系统，分析服务一体化，能够实现一份数据同时用于实时分析与在线服务。
Hologres产品是在该背景下推出的云原生HSAP数据库系统。Hologres产品实现实时离线数据统一存储，支持Flink数据或实时计算的实时数据实时写入，支持离线数据批量导入。第二，对接数据服务层面以实时分析为中心而设计，可同时满足业务实时分析与在线服务需求。第三，不改变原有实时数仓架构，通过MaxCompute直接加速，利用Hologres计算能力直接对接线上服务。
三、云原生HSAP系统Hologres产品
1. Hologres产品核心优势
云原生HSAP数据库，一份数据同时用于实时分析与在线服务。
极速响应：实现毫秒级响应，从而轻松满足客户海量数据复杂多维分析需求。千万QPS点查询，实时分析上千QPS简单查询。
实时存储：支持亿级写入TPS，时效性强，写入即可查询。
MaxCompute加速：MaxCompute直接分析，无数据搬迁，无冗余存储。
PG生态：PG开发者生态，开发人员友好，PG工具（pslq、Navicat、DataGrip）兼容。BI工具无缝对接。
2019年双11 Hologres线上服务数据：在双11当天超大数据量场景下，Hologres支持了高峰1.3亿实时写入TPS，并且数据写入即可查，提供了1.45亿高并发在线查询QPS。
2.Hologres交互式分析产品-典型应用场景
离线数据加速查询：目前支持MaxCompute离线数据秒级交互式查询。无需额外ETL工作，便捷地把冷数据转换为易于理解的分析结果，提升企业决策效率，降低时间成本。
实时数仓：Flink+Hologres，旨在通过搭建用户洞察体系，实时监测平台用户情况，并从不同视角对用户进行实时诊断，进而采取针对性的用户运营策略，从而达到精细化用户运营目的。助力实时精细化运营。
实时离线联合计算：基于离线数仓MaxCompute和实时数仓交互式分析的联合计算，从商业逻辑出发，实现离线数据分析实时化，实时离线联邦查询，构筑实时全链路精细化运营。
接下来具体介绍以上三种场景的具体架构以及应用。
3.MaxCompute加速分析
传统方案——数据冗余、成本高、开发周期长：如下图所示，左侧数据通过数据集成同步到离线数仓后进行DWD层、DWS层等的加工，加工之后的数据对接线上服务。
一种方案是直接使用MaxCompute的MapReduce计算能力提供线上营销策略、线上实时报表。该方案虽然可以很好地完成业务需求，但是在MapReduce任务提交后需要一定的等待排队、等待资源分配的时间。很多时候等待时间大于数据分析时间，并且分析时效性所为几十分钟甚至小时级别。效率较低。
因此将数据从MaxCompute离线数仓中转移到线上Redis、Mysql等产品中，利用其交互式分析或点查询能力提供服务。但是从MaxCompute离线数仓中集成数据到线上Redis、Mysql等产品中存在困难。首先是数据容量方面，例如当离线数仓ADS层数据量非常大，Mysql无法承载时，需要在离线数仓中添加一层ADS作业，再次进行数据加工和预计算，缩小数据量后将数据集成到Mysql中。也就是为了进行数据分析，需要进行进一步的数据预处理，维护一个数据同步的作业，数据同步后还需要存储到Mysql中。以上流程将会导致数据冗余、并且成本高，开发周期长。
Hologres——无数据搬迁、数据分析效率高：Hologres是存储计算分离的架构，与MaxCompute进行了无缝打通。Hologres在该场景下提供计算能力，而MaxCompute相当于Hologres的存储集群。可以直接对MaxCompute存储的数据进行读取与加速。只要数据在MaxCompute中加工完、可查询，通过Hologres可以直接进行数据分析。在MaxCompute加速分析场景下，Hologres是围绕交互式分析场景设计的，发下作业后可立刻得到结果，从而满足高效、自助式分析，并且成本较低。
Demo演示：可参考文档》实时分析海量MaxCompute数据进行demo演示，多种功能均可实现毫秒级查询，实时返回。
DataWorks深度集成：Hologres与DataWorks进行了深度集成。MaxCompute数据直接进行加速分析时需要建立一个Web表，在此支持了一键MaxCompute表结构同步、一键MaxCompute数据同步，以及一键本地上传文件，详情可以参考文档》》HoloStudio。
4.实时数仓——实时成本高、开发周期长、业务支持不灵活
实时数仓架构是数据采集之后，在ODS层Kafka中通过Flink进行清洗，产生DWD层数据。如果有更进一步的加工需求，再次对DWD层数据进行订阅，写入DWS层。根据不同业务场景引入HBase、MySQL、OLAP等不同产品。
该架构已经很好地解决了现有问题。但是该架构中所有计算逻辑是在Flink中处理完成后写入DWS层。一旦需要加入新的业务场景或者对现有业务场景进行调整，需要新增字段或计算逻辑时，就需要重新评估链路、重新进行Flink作业的开发，修改或增加一个Flink作业后再写到DWS层。
因此在该场景中，大部分计算都在Flink层，其业务灵活性不够高。也就是说该架构计算都是预先做好的，无法满足自助式分析或者分析之前DWD层数据。
5.实时、离线、分析、服务一体化方案
为解决上述问题，Hologres与飞天大数据平台（如Flink、MaxCompute）联合推出了新一代实时、离线、分析、服务一体化方案。数据依然在MaxCompute中进行离线数仓清洗，在Flink中进行实时清洗。但是Flink层数据清洗完成后可以将明细层数据直接写入Hologres，由Hologres对接线上大屏。Hologres提供了强大的实时存储和实时计算能力，意味着明细层数据也可以直接对接线上报表。
实时数据和离线数据的联合分析，从前存在MaxCompute中的数据可以直接与Hologres进行关联分析，实现联邦查询。
实际Flink计算的业务场景中，如果希望将数据沉淀下来提供线上服务，可以再次订阅Hologres，将Hologres DWD层数据加工为DWS层数据，写回Hologres。同时，Hologres在Flink作业中支持超大维表能力，其他Flink作业可以对Hologres中的数据进行关联分析。
上述为实时、离线、分析、服务一体化方案的简述，实际业务场景中的方案远比以上陈述复杂。
实际业务场景：下图所示为飞天大数据平台产品家族推出的方案架构。数据链更加复杂，但是本质与上述架构相同，上游数据源通过数据采集到实时数仓，进行关联分析后最终对上层数据应用提供实时离线联邦查询能力或分析能力。
6.互联网-内容资讯客户案例
Hologres除了在阿里巴巴集团内部广泛应用外，在云上，互联网行业、传统企业等也已经得到了大量应用。
下图所示为典型的互联网客户案例。小影是一款在东南亚受欢迎的短视频APP。互联网行业除了实时大屏、实时报表之外还会进行用户分析、用户画像、用户标签、实时视频推荐等。该场景与阿里巴巴搜索推荐精细化场景相似，因此其架构引用是基于阿里云飞天大数据产品家族的离线数据MaxCompute、实时计算Flink、交互式分析Hologres搭建起来的。
7.围绕数据建设、打通全链路
Hologres围绕着大数据生态、PG生态、阿里云生态，围绕着数据建设的全链路构建了数据生态。从数据源对接，导数据同步，到数据加工，到数据运维，到数据分析和应用都进行了全链路打通。
Hologres在云上已经正式商业化，提供了包年包月、按量付费等不同计费规格，支持计算、存储资源不同配比购买，用户可以根据自身业务需求进行商品采购。同时数据产品、数据加工、数据同步、数据开发工具等支持引用自建、开源等产品。
指定规格首月3折，新一代HSAP系统Hologres重磅发布！点击》》立即购买
如果大家对Hologres产品有兴趣，关心产品动态，欢迎访问下方链接进行学习与交流。
