开发者学堂课程【大数据知识图谱系列—如何选择合适的OLAP引擎进行数据湖分析：开源大数据 OLAP 引擎最佳实践】学习笔记（二），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1064/detail/15370
开源大数据 OLAP 引擎的最佳实践
内容介绍：
一、开源产品—百花齐放
二、技术分类
三、开源大数据/数仓解决方案
四、 ClickHouse 介绍
五、 StarRocks 介绍
六、 Trino/PrestoDB 介绍
七、客户案例
主要是介绍几种引擎， StarRocks 、 ClockHouse 、 Presto。主要是一些最佳实践，还有一些偏技术的东西。
五、 StarRocks 介绍
现在重点介绍一下 StarRocks ，因为 StarRocks 的熟悉程度可能不及 CK 或者是远不及 CK 。但是可能听说过 Doris ，而 StarRocks 实际上原名叫做 Doris DB ，他相当于是一个加强版的也就是一个 Doris+ ,也就是说 Doris 所有的功能 StarRocks 都是有的，但是 StarRocks 有的这种加速的功能 Doris 目前是没有的。
1. StarRocks 价值
这个也是一个开源项目，就是在 get help 里直接搜 StarRocks 就可以看到。这里主要强调几个点。第一点就是说他这个速度，这里面速度大多数可以认为是单表速度，这个单表速度实际上是可以媲美 CK 的，然后他这个多表 Join 就非常的强了，因为这个多表 Join 对于 CK 来说，他不是一个性能问题而是一个能力问题，也就是说 CK 很有可能是查不出来，而不是说查得慢。然后 StarRocks 在这里边是一个比较重点的，这个跟他的 FE 和 BE 的这种架构是有很大的关系的，还有他这种分布式的执行引擎是有很大关系的。
第二个就是他的实时性，正常写这个速度能够达到100兆每秒，因为他这个是个事务写入，如果对比 CK 的话实际上是比 CK 慢的，就是说 CK 是一个非事务写入，也就是说这个 StarRocks 可以天生的支持这种 exactly once 的这种特性，因为只有全部写成功了才算写成功，就不会有这种部分可见的方式，所以他整个的100兆每秒的速度在同样的机器性能下，其实 CK 最多可以达到200兆每秒，实际上他这个写入速度还是跟 CK 有一定差距的，但是100兆每秒在大多数的这种实时数仓的业务是足够用了。
第三个就是能赋能更多的人员，这个是什么意思呢？就是说 CK 是很吃资源的也就是说很有可能一个 C 口能够用到机器的一半的资源，然后他对资源隔离做的也不是那么的好，而 StarRocks 会在重点的方向去做资源隔离，这个资源隔离也就是说在一些小的 batch 的这种 C 的查询或者小的这种C口或者说是 MV 的查询上，实际上 QPS 是非常高的可以高到几千甚至上万对，在这种高 QPS 的方式下，这个 TP 99也是能做到一秒之内的。
最后一个就是灵活的构建，但是强调一点就是这个 QPS 高的话，是达不到 serving 那种能力的稳定性，这个可能会介绍一下 hollow 的 sreving 方式，也就是说实际上他跟 HPS 或者说跟 hollow 的这种纯的 serving ，纯的用这种行存的方式，因为 StarRocks 里面是没有行存的，他还是个列存，接下来会细节讲一下，就是他还是一个列存的方式，所以说他没有这种稳定的 serving 的能力，如果是对接在线系统的话，如果要是不稳定的话，实际上肯定是不可接受的，因为可能一个查询不稳定了线上业务就出问题了。所以说 StarRocks 可以比较慎重的去用到那种场景下，但是他是更多的人员或者说是对这种广告主，广告主因为他人员虽然说很多，但是他能忍耐的时间比这个在线系统肯定还长些。然后这个灵活的构建，实际上 StarRocks 主要是强调了一个统和一个急速，对灵活的构建实际上就是一个统一的这种想法。
2.重构企业数据基础设施
这个就是一个 StarRocks 连接的几个源和几个 think 。第一个就是通过这个 CDC 或者说通过这个 ETL 的方式去灌到这个 StarRocks 里面；然后还可以去直接的和这些老的 kafka 或者是这种 TP 的数据库或者这种 log 的话，直接可以进行灌入；然后 External table 目前支持这种 hive 、es、 MySQL ，当然这里边还支持 hudi 和 Iceberg ，这个没有在PPT上是因为他在2.2的时候才会推出，这个部分是阿里云跟社区一起合作的比较重点去做的一个方向，会在 StarRocks 的2.1版本去做一个 experimental 的特性，2.2版本会做一个生产性的特性。
3.架构—新一代弹性 MPP 架构
这个是 StarRocks 的一个架构，这个架构就是有一个 FE 和 BE ，而这个 FE 有几个模块。第一个模块就是 catter log 的一个模块，就是他会存这个原数据，然后他还有一个 planner ,相当于所有的 MySQL 的第一站全部打到 FE 里，然后 FE 进行 SQL 的整个的解析，到最后的这个分布式的物理的 plan 的生成，然后都搞完之后真正的做整个的这个计算，是要在 BE 里去做计算的。
他整个的这个架构是非常简单的，就是说在 FE 目前是一个稍微老一些的，因为这个其实是从 Doris 演化过来的,所以这是一个当时 Doris 有的时候还没有这个 raft 的这种玩法,但是现在社区 StarRocks 要慢慢的把 FE 改成这种基于 raft 的这种结构，它是目前现在是基于 Borken DB的，但是可以认为跟 raft 也差不太多，他是几台高可用的 FE 再加上这种 BE 。 BE 实际上做的就是这种 Execution Engine 还有这种存储引擎 storage engine 基本他就是这两个大的模块。实际上整个链路就是 MySQL 第一条打到查询的时候打到 FE ，FE 再把这个 SQL 文本翻译成这个分布式的执行计划，分布式的执行计划的数据都是按这种 buget 的方式去存到 BE 里。这一个这张表或者说查的这些 SQL 都命中了哪些 tablet ，会把这个相应的 SQL 的执行引擎给他搞到这个 BE 上，然后 BE 算完之后再回给 FE ，大概整个就是这么一个数据流。
4.极速引擎—全面向量化
这里就是 StarRocks 最强的就是两个，第一个就是这个向量化，第二个就是这个 CBO 。实际上向量化也不需要过多的解释了，其实这个图就已经解释比较清楚了。一个指令就可以把整个的这一列这几行全部都做完，然后这样的话实际上他会有更好的这种 cpu cache ，然后会有更少的这种虚函数的调用，实际上这几个是向量化的一个比较基础的一些东西都用上了。他整个的效果是显而易见的，因为只要是搞起来这个向量化和这个非向量化去比较，实际上这就属于快的能快到一个数量级，慢的也应该有五六倍的这种提升。所以说这块是一个 StarRocks 区别于 Doris 的一个比较重要或者说是非常重要的一个特点，就是他是全面的向量化，他把所有的算子全部的向量化掉了。
5.极速引擎—全新 CBO
然后这个 CBO 实际上也是一个比较重要的， CBO 有两个比较。第一个是和 CK 去比，而第二是和 Doris 去比。如果跟 CK 去比，其实是比不到一个层面上，因为 CK 目前一是没有 CBO ，二是他连一个比较通用的一个planner 目前也是没有的；相当于就是说从这个 SQL 一步步最后走到分布式的物理计划然后在 BE 里面执行，实际上经过这几步，第一步就是相当于是这个词法和语法的分析，分析之后去做 SQL 的 rewriter 也就是常常说的 RBO 也就是基于规则的这种优化实际上是在 rewriter 那一步的，然后 logical 这个plan 实际上去看一下已经统计的一些信息，这些信息就是比较常见的一些信息包括一些直方图这种这些不同的列，或者说是跟不同的这个 scheme 相关的一些 static ，然后基于这些 statics 去做整个的这个plan，然后这个plan比如说在这做 Join的时候会做的非常的好。就比如说 ABC 这三个做 Join ，究竟是 A join B 还是 B Join C ，到底哪个 Join 最好。实际上整个奥卡论文都已经说的是比较明确了，然后整个的这个也是经典的数据库里边的一些理论，这些都已经做进去了。
6.极速引擎—多分布式 Join
然后这个就是分布式的 Join ，这个分布式的 Join 目前就是 CK 比较缺乏的一个功能。这个左边的图和右边的图，如果了解 spark 或者了解 presto 的话，其实都应该知道这都是有的，就是说这个其实就是做 Shuffle ，就是把不同的 Key 给 Shuffle 到同一个 bucket 里边，然后再去做 Join ，然后右边实际上是一个更加高效的一种 Join 方式也就是提前的去做好了这个 bucket 的分类，也就是说同一个 Key，两张表相同的 Key ，全部落到同一个 bucket 的范围，然后这个 bucket 的之间肯定是没有 over lap ，所以可以放心的做这个Colocate joy ，在这个 spark 里面也叫 bucket join 。
7.全场景—丰富的数据模型
然后这个全场景实际上他提供了四种模型，第三种模型是 StarRocks 2.0新出的 primary key 的模型。他首先支持第一个明细模型，明器模型实际上是区别于刚才说的那种聚合模型，就比如说纸质聚合模型的，包括 dryed ，包括 Kevin 就是包括这些模型实际上有一点不好的，就是没有明细模型就没有原始数据，并不知道这个原始数据怎么去搞的这个聚合模型，万一要去查这个明细模型如果没有，实际上整个数据是一个丢掉的状态，只有去从这个 Hadoop 里，如果有的话可以去 Hadoop 里面去捞，那整个数据看起来就比较碎了，就不太容易去挖掘出来了。
然后聚合模型就是相当于是有两种，一种就是直接导成聚合模型，比如说刚才直接用 spark 或者 flink 直接导成聚合模型，还有一种是基于明细模型来出了这个聚合模型，比如说用这种 materialized view 的这种方式，通过只灌这个明细模型，然后去提前写一些聚合的这种方式，做一些 MV ，这样实际上在这种查询毫秒级别的，就比如说几十毫秒或者是200毫秒以内可能用聚合模型用的比较多，这种适用的就是完全的知道每天需要的这个汇总和分类，是完完全全的都知道的，而且也不会有什么太多的改动的，会用这种聚合模型。
然后这个主建模型实际上就刚才说的，这个主键模型和更新模型，可以认为主见模型是更新模型的增强，如果主键模型比较稳定的话，其实更新模型就没有什么太多的用处。主键模型实际上针对的就是 CDC 的这种场景，或者说是这种订单变化的这种场景，会以非常快速，因为刚才说就是 CK 的方式，CK做这种变化，做这种 Upsert 的这种场景实际上是有缺陷的，因为 Upsert 场景，他是通过后台的这个 conpation 之后，才会把整个 delete ，还有 Upsert 给他更新掉。但是这个主建模型实际上就是有这个唯一的主键，那么这个主键一旦要是发生，比如说订单的 ID 号其实是在内存里边的，然后内存里边有一个 road path 相当于有一个指向每一行的一个 position ，然后这个时候一旦发生了变化就会 delete 掉原来的这条记录，然后会 Insert 一条新的这个记录，所以这个感官上体感上来看就是非常快的可以做变更，基本上做完之后直接就能实时的看到了。
8.全场景—高并发查询
这个是高并发查询也就是刚才说的，可以看一下最后的一点，就是说这个高并发查询，实际上是针对其他的这种 OLAP 引擎，如果要是和这种行存的 OLTP 或者和这个 hollow 来比高并发的查询，实际上是没有那个稳定的，因为 TP 这种行存的话，肯定是最稳定的一个 serving 的这种状态。那这个相当于可以认为是逐渐的缩小范围，做一个 table ，然后再做一个 partition ，而 partition 里又分成不同的这种 bucket ，不同的 bucket 中每个 bucket 都有这些 bloom filter 还有一些 blocked index 类似于这些可以做一些 data skipping 。所以说这个 data skipping 做的一旦非常快或者这个主键的索引叫 short key 做得非常的快的话，实际上是能够很快的去做这种高并发的这种查询。
9.全场景— LakeHouse
全场景还有一个就是 LakeHouse ,也就是刚才说的会在 StarRocks 的2.1和2.2的版本会把 Hudi 和 Iceberg 全部都支持了，因为 hive 目前已经是支持了。可以看一下这个测试的结果，实际上可以和大多的跟这个 presto 去相比，因为他对这个外表查询实际上跟这个 presto 的这个结构上是没有什么太大区别的，但是他对向量化引擎的这个优势是体现的比较明显的，也就是说在这个 presto 和 StarRocks 来比的话，实际上可以认为完全的就是计算层的这些优化进行了一些加速，毕竟这个 presto 还是由 Java 来写的。当然这个 presto 目前就是 Facebook 也在推这个 presto 的 C++ 的这个方案。可能后续也要开源，听说可能是也要开源，这个可以到时候再对比一下。
10.易运维—弹性伸缩，在线扩容
然后这个运维就是比较简单的，实际上他相当于可以跟几个维度比。第一个就是跟这个 Hadoop 整个的一个生态来比，如果这个业务非常适合用这个 StarRocks 来替代的话，实际上他这个运维比 Hadoop 要简单的多。然后再一个就是跟 CK 来比，这个在运维上实际上也是有很大的提升的，因为 CK 毕竟没有一个类似于 FE server 的这种方式,然后这个相当于就是每添加一个节点就会自动的做这种 balance 。就比如说添加一个四节点，然后原来的比较满的这个节点也就是那三个小的虚线框就已经过来了，对这个不需要改，只需要在 MySQL 里去增加一台 backend 就可以了，他会自己做这个平衡。
六、 Trino/PrestoDB 介绍
1. EMR 数据湖架构
最后再介绍一下 Trino 和 PrestoDB ，而 Trino/PrestoDB就是说这是最经典的一个数据湖的架构，数据湖架构就是说最底层是 OSS ；然后其上就是这个 Hadoop 的这种 API ，相当于这边是 Jingdo FS 来去做这个 Hadoop 的 API ，然后还有包括这种 cash ；然后再上面一层就是这个数据湖的几种格式；然后再上一层就是这个引擎还包括他的调度，而这边 channel 的这个引擎其实跟就是刚才介绍的 Prseto SQL ，可以认为跟 PrestoDB 差不多。然后这个 Presto 直接去通过数据湖的引擎去查询这个数据湖，这个应该是一个比较经典的，比较老生常谈的一个方案。
2. EMR Trino
然后在这个 EMR Trino 实际上主要关注两点。第一点就是说提供了K8S 的形态，这个在不同的客户里边也已经逐渐的用起来了，然后整个 EMR 产品里也有这个 K8S 的形态，目前提供的是 spark on K8S 还有 Trino on k8S 。然后第二个强调的一点就是整体对这个数据湖的这个加速是非常的好的；因为这个数据湖，比如说 delta ，比如说 Hudi 和 Iceberg ，很多的这个 PMC 都在阿里团队下边，然后实际上有一些非常好的一些特性，然后这边 Trino 都是配了在这个开源的 Trino 上实际上是没适配的或者说优化的不是那么好。所以说这是比较重要强的调两点，一个就是从成本上看，就是可以做在这个 K8S 里边，然后还有从这个数据湖上可以看到做的优化比较多。
七、客户案例
然后最后讲几个客户案例，就是这几个客户案例其实都是最开始在抽象那几个里从实际的客户案例里面去获得的，然后这个看起来也就不陌生了。
1.某在线教育客户
这是一个在线教育的客户可以关注一下他这个业务背景，就是这个业务背景最开始就是几十一条的这个数据，其实这个业务量在这之前应该算是不大不小，他现在面临的就是这个订单变更，订单变更就是比如说上课什么的这些确实是变更，还是说有一些预售或者有一些补售，或者说这个订单状态会时刻的改变，然后他们还有这种特征人群的这种圈选，就是说做一些应该是每一家数据公司应该都有的这个痛点，然后还有一些机器学习的这种训练。然后最开始的方案实际上是处理的不及时是一方面，还有就是说这 hive 架构有的时候他就是没法做，就是这个小时级的这个任务他做不了，就是小时级的任务，实际上整个看起来这个样就非常的繁忙了，因为每一次都要做一个上一个小时的所有数据的一个 in search of right 实际上整个集群看起来比较繁忙；然后还有一个痛点就是刚才搞不定这个 Upsert 的这种场景，他只能用这个 in search of right 相当于比如说第二天变更了第一天的数据，那只能说是把这个链重新再做一遍，当然也有一些拉链表什么的这些方式，但是这个资源耗费还是比较大的，就是典型的不是这种 Upsert 的场景，所以做完这种 Upsert 的场景有几个收益。第一个收益，就是说这个 Upsert 的场景就支持了；第二个就是说 presto 去查这个明细数据，而这个直接用 Hudi 就可以搞定了。然后他是用的 CK ，他主要是做两个。第一个就是 Hadoop 查询，所有的运营人员都能通过 CK 去做这个 OLAP 的 Hadoop ；然后第二个就是说他会支持一些 bi 报表，而报表有的是通过 CK 来的。
2.某社交领域客户
这个是一个社交领域的客户，社交领域的客户是用了两个数据仓库也就是利用两个两款产品。第一款产品实际上他做的是一个宽表，他认为或者说当时在他选型的时候， StarRocks 这个宽表做的速度可能跟 CK 比还是稍微差一点，所以他现在用的就是 CK 也就是做的是纯的宽表。然后这个 flink 已经事先的去聚合好数据和加工好这个宽表，然后直接 load 到这个宽表里，他给出反馈就是说最差也就五秒，就是PPT 上的一到五秒，实际上是一个比较保守的，他有很快的时候可能就是几百毫秒，然后比较快的基本就是五秒，很难说是有五秒之上的这种查询，因为他这个 OLAP 实际上是事先这个 adhoc 是没有定义的是随想随查。然后第二部分，就是做的这个 StarRocks ，这块就是他基本上来说做的都是聚合表，然后这个聚合表实际上是用的 StarRocks ，然后他主要是两方面的一个需求，一个是业务的检查，这个业务检查基本上他搞的就是那个广告主，就是给的广告主那个检查，并不是像刚才说的在线系统的这种查询，因为在线系统查询的话，目前来看还是 hollow 或者说 hbase 类似于这种的 service 系统才能够做的非常稳定。还有一个就是关联的 Hadoop 查询，然后 Hadoop 查询他给的实际数据不超于十秒，当然他这个不超于十秒，实际上是有 Join 在里边的，因为有了 Join 的话，对这个 Join 没有做特别多的优化，实际上有的时候就是比较慢，这是他们给出来一个数字。
3.某电商领域客户
然后还有一个就是电商领域，这个就是一个非常简单的一个玩法，相当于就是手里边有一个 MySQL ，当然这个可以看一下这个数据量其实不是非常大，就是所有的 MySQL 直接连 kafka 都不要了，所有的 MySQL 直接通过 flink CDC 直接给他搞到 StarRocks 里，然后 StarRocks 相当于跟 TP 的完全镜像的一个数据库，可以这么认为。相当于所有的表都是同步的，最开始用的 migration 的 tool 直接把所有 MySQL 的也就是想要的这些表，全部都导在这个 StarRocks 里，然后直接用这个 flink CDC 直接搞，因为这种搞法实际上是一种返璞归真的一个搞法，所以说这个就相当于这里边该有的表都有了，然后该怎么查就怎么查，所以他用的基本上都是这种 OLAP 的这种查询，然后对接这个业务系统的 serving 用的也是这个广告主的这种 serving 实际上他也不是用的这种在线系统 serving 。这个优点就非常清晰了，就是说他这个链路就非常简化了，他需要运维的操作不多，基本上就是增加一些节点，就是如果要是节点少了就增加一些节点，然后看看监控或者报警什么的，其实他就比较轻松，就是面对比如如果是用 MySQL 来去做一套整个 Hadoop 体系，实际上他需要操心的事儿还是挺多的。
