开发者学堂课程【云原生一体化数仓新能力解读课程：分析服务一体化新能理解读】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1193/detail/18110
分析服务一体化新能理解读
内容介绍：
一、分析服务一体化需求分析
二、分析服务一体产品新能力解读
三、典型案例
一、分析分析服务一体化需求分析
首先会聊一下分析服务一体化产品需求，接着会聊一些分析服务产品一体化新能力的解读，最后会通过一个典型的案例来解读这些能力到底是怎么样来服务于我们的业务场景。
可以先看一下这张图，其实随着互联网业务的兴起，信息、业务对于在线化精细化需求日益强烈。过去的领导驾驶舱、实时大屏。起到了越来越多的作用。对于ToB来说我们需要实施数据的决策，将数据分析的能力赋予业务。同时对于ToC的业务，核心是要提高在线的转化率，那么就产生了实时数据的数据中台、用户画像、个性化推荐以及实时风控的需求。
这个图是一个典型的面对这种实时场景的技术架构，发现像这个数据会从这种日志系统、在线的交易系统去写入的实时数仓，对于这种写入数据可能会经过两条链路。一方面它会实时的写入数仓，形成这样的明细数据，这些明细数据经过持续的聚合，持续的被前端的BI系统进行消费，同时也会持续的北区前端的Dashboad等等进行交互式的、探索式的分析，这些明细数据会有时候实施聚合，对于明细数据也会定期的做批量的聚合，形成定期的聚合数据。
比如日常的明细的这种页面的流量的明细、用户点击的明细、交易的明细，会被聚合成比如说五分钟的物料的点击。七天的这种页面的浏览数据或者三十天的周转数据，那么这些剧组数据也会汇总之后对线上这种推荐服务提供在线查询。同时在线服务提供查询的时候，往往需要根据一些业务维度去把这些数据打宽，那么这个时候我们需要在线的去跟这些维表做 Lookup 的这种聚合、关联，然后在向外界推荐这种聚合服务。
由此引申变成这样的一个系统架构，来满足前面讲到的整个业务和数据流向的需求。上面可以看到这是一条实时链路，日志通常会写入比如 Kfaka 或者阿里自研的datahum 里面，这些实时的数据写入这些系统。比如 ClickHouse 那么对在线的Reports 或者 Dashboards 进行一些提供交互式的探索式的分析，同时离线式数据会归档到离线式仓，比如 Hive、MaxCompute 这些技术里。那么这些数据有时候业务需要这种离在线的业务分析，它会同时加速这些离线的数据和在线数据，作为同一类出口再提供给 Reports 或者 Dsshboards 去使用。
同时之前的链路还会讲到有一些实时聚合的需求，以及维表 Lookup 的需求，这些维表往往会存在 ittres 里边，然后和这些交易的数据同时实时聚合之后，变成比如刚刚提到的五天的 SKU 的浏览量或者七天的页面的浏览、七日留存、十五日留存等等这些数据再写回到 HBase 或者 Redis 里面，在实时的面对比如 API 的服务，或者手机上的 plications 去提供服务。那么自然而然会发现在整条链路里边有很多线，自然就形成很多问题，比如说架构复杂、数据同步难、资源消耗大、数据孤岛、人才培养难、开发成本高、不敏捷，随着数据湖的兴起架构变的更加复杂。
在这个架构下一起看每种技术分别解决了什么问题。大概可以将这些技术分为三大类，可以想象一下整个场景业务的需求。比如说要适应这种实时的聚算以及高吞吐能力、高可用能力。
首先对于第一类是事务型的数据库，这里面的数据其实是按行存储的，对于交易型的数据有很好的更新能力，但是对于千万级别以上的统计型查询或者交互式查询，其实消耗是非常大的，所以一般也不会用事务型的数据库去做分析。
第二类其实是 Analytics 分析型的技术，它典型的技术会使用比如说列存、分布式技术所有的技术，这类技术查询都很快，但往往在数据更新上略显不足。
第三种定义为 Serving 的系统，它主要是需要提供这些在线的服务，需要有高吞吐和超快的查询的响应，但是牺牲了一定的灵活性。比如说文档数据库或者典型的像ittres、keyvalue 这种数据库，对于它的整个查询和更新的效率都非常高。现有的架构也是要根据需要服务的业务特征，将不同的业务拆分到不同的系统存储，数据就在这些各个系统里面进行交换。每一次数据交换就带来一次这种数据的迁移成本，数据不一致的可能性以及数据开发的复杂性，所以大家自然而然的想找一些领域做一些创新，其实第一类就是在 TP 和 AP 的领域去做一些创新，在混合负载的场景下使用一种技术去解决 TP 和 AP 的负载，一个系统既能支持事务又能支持分析。
这个状态其实非常理想，我们也希望真正有系统可以落地这个状态，但是在我们看来，这个系统还有些过于理想。因为支持事务势必会带来更多的开销，那么在整个并发查询和更新上就会有更高的代价。所以更多在左侧去思考业务的创新，那么发现左侧和右侧的区别主要是来运用于事务的，我们没有那么多的锁，但是牺牲了一定的锁会带来更高的查询性能以及更强的读写和更新的能力，可能左侧的技术更加能够覆盖到以上说的分析和服务一体化的这种场景。
Hologres 其实就是符合刚才说的左侧的这种分析和服务一体化的产品，一套系统去支撑多个场景，包括分析场景、点查场景、包括在线服务的场景，同时不仅支持离线的数据导入实时的数据更新，真正意义上做到分析服务一体化。
二、分析服务一体产品新能力解读
说明了分析服务一体化对于产品的需求，那么基于这些需求再来聊一聊产品的解读。
其实产品的能力和需求是息息相关的，它是一一对应的。在 OLAP 的分析场景里面提供了高性能的实时写入与更新的能力。在写入即可查上做了一定的优化。同时使用了列存、压缩、索引等等技术，以支持高性能的查询分析的能力，同时还支持了基于主键场景能量更新和局部更新，其实这种能力在实时场景下尤为的重要，会发现很多数据一部分是来源于日志的，同时另一部分是来自于 OLTP 这种交易型的数据。
事务型的数据库中数据通常都是有主见的，同时在实时的场景里面会用Flink去消费这些数据，或者等等的一些场景。那么主键的设置也可以有效的避免脏数据的重复写入，所以现在越来越多的系统在强调主键更新的能力以及主键更新在场景下的重要性，同时在线上服务这种场景下支持行存能够提供上万支以及千万QPS等查询能力，对于行存的数据能够支持多副本的高可用能力，如果一个副本挂了这时候可以打到另外一个副本上，保证业务的连续性和高可用能力。
由于整个服务的场景是非常敏感，需要更强的资源隔离，保证服务的稳定性。所以现在提供了这种读写分离的架构，避免了高吞吐的写入对于读的影响。
最后，之前提到了对于离线的场景也要有兼顾，那么在这种离线的数据湖的场景的交互式分析，对于MaxCompute中的数据可以进行离线加速，无需任何的数据搬迁即可分析MaxCompute中的数据，并且支持百万行每秒的极速数据同步，以及元数据的发现，依次来减少数据研发等等带来的数据延迟。
为什么做到这些，其实并没有那么多神秘的地方，这个还得得益于IT剧组发展，现在网络带宽越来越大。我们在使用了存储计算分离的架构，对于存储使用了阿里自研的分布式文件系统盘古，这样就可以更加便捷的将整个系统做到更轻，制造高副本和高可用。在发现意外的时候可以快速的从盘古上将数据加载回来，快速的去恢复服务，更容易做到高可用。
对于数据更新的场景其实过去更多受限于磁盘的性能，所以很多的系统设计都是针对这种扫描的场景，它需要更多去运用这种数据读写能力提高整个扫描能力。那么底层其实是使用了 SSD 这种存储介质，这样的存储介质其实对于读写的能力更强，这样就使得我们整个架构设计的时候，可以抛开过去传统的对于扫描场景的设计，有行存和列存来应对不同的场景。
第三个其实是随着CPU的多核话，现在其实 CPU 的核心也越来越多，那么如何提升 CPU 的利用率，发挥并行计算能力其实就可以有效的提升性能，它其实是用 C++ 开发的，这样更有利于我们使用这种权益执行和调度的框架来提升整个多核的利用率，以最大程度提升整个系统的性能。
前面提到此前版本已经支持了行存，数据按照行的方式来存储，行存其实更加适合这种 Keyvalue 的点查，用于支撑高 QPS 的场景。同时也支持列存，其实更多是将数据按列存储，更加适合 OLAP 的场景，但是其实现实场景会更加复杂。一张表生成之后很难绝对的说只使用行存或者列存或者点查或者 OLAP 分析的证明一种场景。
因此又作了一种行列共存的存储方式，一张表在在写入之后在后端会同时存储一张库存的表，同时也会存储一张列存的表。那么 Hologres 内部会去保证读写的一致性，当一条 C 打过来的时候优化器会根据实际的查询特征，去选择到底是使用行存还是列存回答。这样其实这样就同时兼顾了行存和列存的优势场景。
同时为了提高可用性提供更强的资源隔离能力，现在不仅支持同一个资源内部现存级别的资源组隔离，同时还支持多个实例共享一份存储这种实例级别的隔离。对于读写这种请求，可以把它的整个负载、工作流，比如说写入的负载、ETL 数据加工的负载都放在读写的主实例上。同时对于 OLAP 的查询一些在线的 dashboad ，把它的负载放在另外一个读实例上，去做报表的灵活的分析。同时可能会有在线点查的场景，它是极度的敏感，那么对于这种场景我们可以再写一个然后用它来提供在线的服务。多个实例之间是共享一份盘古存储的，他们的数据是行秒级别同步的。用的时候其实更加简单且互相之间互不影响实现了高可用的资源隔离。
除此之外这里算是一个预告，因为这张片子说的是在1.3版本中将进一步提供的更多能力，在数据湖的整个离线加速场景会支持直接读取 OS 上的数据，更好的利用数据湖的新的格式。同时也支持 MaxCo
Mpute Transcational Table 这些外表，对于这种表我们也可以支持离线加速。之前提到的写入也是非常重要的一个场景，在写入上独特的优化、Flixed Plan 的整个场景会更多去扩展，从只支持整行更新变成整个部分列的更新，然后以及可以直接写入分区附表，同时支持 where 的条件子句过滤等等一些场景。
在于查询上面支持的是实时物化视图，支持加速实时聚合的场景。以及支持的这种JSONB 存储优化，通过采用列式存储的方式，不仅提高了它的存储效率同时也提高了整个查询效率。为了提高用户管理分区表效率也提供了自动分区子表和删除分区子表这些能力等。同时在生态兼容性上支持 Oracle 扩展包，多支持数百个兼容性的函数，以及函数支持原生引擎查询、显著提高查询效率等。
这里要单独介绍，针对几个比较重要的内容在此做一些展开。在新版本中为了进一步帮助客户去优化成本提供了冷热分层的能力，在实际业务中对于这种分区表的数据，通常事务会进入冷静期特别是这种新鲜的数据，这样的数据需要存储在SSD的存储介质中。因为满足这种需要高性质性能的需求，随着整个时间的推移热数据会主键变为访问频次低的冷数据。
此时可以在系统里设置一些策略让它能够归档到 HDD 这种存储介质里面，以便用户可以去优化这些存储的成本。
第二个其实是我们之前提到的整个 Fixed Plan 能力，Fixed Plan 是 Hologres 独有的执行引擎的优化方式，传统的一条特别是写入，会经过优化器、协调器、查询引擎、存储引擎等等多个组件。比如现在展示的如果不用 Fixed Plan，它整个经过多个组件最后才写入数据。如果使用 Fixed Plan 它会去选择更短的一个路径，绕过前面提到的优化器、协调器、查询引擎、存储引擎等等多个组件。直接通过 Fixed 去访问，实现了效率的成倍提升。用来支撑高吞吐的实时写入以及高并发的查询。如果使用 Fixed Plan 其实就像刚才展示它的执行计划就是右边的这种，直接在 Road 里面写以提高整个的写入吞吐量。
这个是简单拿官云上64 CU 的一个实例简单的一个测试场景，会用行存、列存以及行列共存做这种更新。会发现使用了 Fixed Plan 之后整个会有一个明显的提升这个橙色是使用 Fixed Plan 之后的一个 RPS 黄色是不使用的，会发现这里将近有20倍的一个提升。
接着看一下新版本支持实时物化系统能力，其实物化视图是一个数据库通的概念，但是一般的数据库需要定期刷新物化视图，存在一定的数据滞后性，那么在的物化系统其实是不用用户手动刷新，数据在写入的时候进行计算然后进入物化视图。例如这里有一个非常简单的业务场景，比如某客户有100多家门店，他想实时查看各个门店的营收情况去调整业务策略，在这里其实就是一个业务名称表，我们会发现这个表里有订单编号、客户号、门店 ID、订单的日期金额这些列，，当创建实时雾化视图以后数据写入明细表的时候我们就实时雾化，让他聚合。当一条c视察每个问店里面，在一定的订单日期里到底有多少交易金额，这个时候会发现整个雾化视图会把他改写成雾化视图，直接从雾化视图里面查询数据，从而极大提升它。
最后一个大功能其实是 JSON 的列式存储存储方式，由于整个压缩效率非常高，其实可以更有效的提升数据存储效率，同时对于不需要访问的数据可以不需要查它，那么一方面减少扫描数据量的同时也可以更快的访问查询的数据，比如有一个常见场景，对于某个视频网站场景来说希望查询男性用户的用户数和平均年龄，会有一个多层嵌套等等的一些。其实是查询它的平均年龄，如果不依赖列式存储就需要把所有的 JSON 数据把男性过滤出来，然后算一下评论年龄，如果使用列式存储，实际存储方式就如图，按列进行存储。实际查询只需要读取两列就可以，大大降低了整个需要扫描的数据量，从而极大程度提升了查询效率。
三、典型案例
最后分析典型案例，看怎样帮客户优化整个分析服务一体化的场景。如图是一家头部物流公司的仓的物流历程，整个物流公司对于实时决策和实时分析有很强的诉求，原有的架构也非常复杂，会定期的对于营销的大促的流量高峰、系统的负载比较大，同时还需要直接支持很多Toc的场景对服务的要求很高，在架构升级之前该企业多采用传统的数据库的架构来实时查询监控包括刷新每个包裹物流状态的场景，但是这样的其实存在很多实时性不足的问题，比如说订单的数据更新效率低、链路长，无法满足实时链路的需求。同时也会降低物流的整个配送效率，同时多个指标之间往往需要很复杂的关联计算，查询效率比较慢，无法满足实时业务决策需求。
架构的另一个就是稳定性不足，因为多个业务高并发查询的时候整体的延迟会明显增加，会影响业务稳定性。双11期间又会遇到一个流量的暴涨，需要承担的流量会是平时数倍，原有的语法承受突然增长流量，从而导致更多的额外人工，因此为用户做了一种分析服务一体化实时数据仓升级和改造。代替原有的，对于高频的数据把计算结果直接存在 Hologres 之中，对于一些终将汇总的数据，上流应用实现了高并发的快速查询，该方案采用了服务分析一体化的混合架构，充分发挥了流计算的能力，以及业务加工能力也充分利用了 Hologres 强大的复杂的分析能力。成功替代了传统系统等等数据库软件。更好的适应了这个场景，简化了数据。升级之后系统得到了极大的改善，无论是实时数据写入，还是数据读取都体现极强的稳定性，整个双11做到零故障，满足实时业务需求，支撑了实时的揽件、库内操作、中转调拨等场景，为运营提供了强有力的实时数据支撑，整体的实效性也得到了显著的改善和提升，提升了整个公司的服务水平。此外，双11的流量高峰比通常高出上千倍，通过 Hologres 延伸的弹性能力实现了资源的动态扩缩容，满足了对资源不同的需求，降低了整个运维成本。
