开发者学堂课程【大数据知识图谱系列—如何选择合适的OLAP引擎进行数据湖分析：开源大数据 OLAP 引擎最佳实践】学习笔记（一），与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1064/detail/15370
开源大数据 OLAP 引擎的最佳实践
内容介绍：
一、开源产品—百花齐放
二、技术分类
三、开源大数据/数仓解决方案
四、 ClickHouse 介绍
五、 StarRocks 介绍
六、 Trino/PrestoDB 介绍
七、客户案例
主要是介绍几种引擎， StarRocks 、 ClockHouse 、 Presto。主要是一些最佳实践，还有一些偏技术的东西。
一、开源产品—百花齐放
现在先说一下 OLAP 的中束，这个中束可以看一下这个表格；和一些客户做交流的时候总是问起来这些问题，就是说现在这个花花绿绿的这些所有的这个 OLAP 的引擎，有的是 OLAP 相关的，还有一些是类似于原来的这种批处理相关的这些引擎；然后他们到底怎么选、怎么组合，这其实是一个比较好的问题。这个问题实际上对这个数据处理来说，因为数据处理有很多种路径可以达到同一种目的；每一种这个路径，比如说从最开始的 OLTP 数据库到这种大数据的发展，最后到这种 OLAP 的发展，还有中间夹杂着各种并行的，然后这里边还有很多 trade off ，还有解决不同问题的这种痛点，所以说今天主要是来梳理一下。这些都是什么样的这种含义，怎么样的去组合这些才能发挥出这种业务价值
二、技术分类
然后在这里面做了归类的一个总结，主要第一种也就是 ROLAP ，这种 ROLAP 可以认为是那种相对来说存储一体的，是一种类似于数据仓库，比如 snowflake 或者说是闭园的 snowflake ，然后有这种hollow，还可能的是这种比如说 max compute，也可以归结到这里边，就是存算一体的数据仓库。在开源领域比较重要的就提炼出来三个，其实还有包括这种green plum什么的都没往上写，现在用的比较多的，脱颖而出的基本就是 StarRocks (DorisDB) 、 ClickHouse 、 Apache Doris 。然后这里边可以说一下 StarRocks 的一个进展相当于是原来这个 DorisDB 出来的，然后他现在目前的这个发展的这个趋势在 gethap 上的这种 trend 实际上是一个非常好的一个趋势，他目前应该是完全替代了这个 Apache Doris 这个项目，相当于他可以被认为这个 StarRocks 是一个 Doris+ 或者是 Doris plus 这种感觉，他覆盖了 Doris 的功能，然后在这种单表、这种向量化、在这种 CBO 什么的做的是更加优秀，然后也用了很多最前沿的一些技术。
第二种就归为一类了，比如说这种预处理的、类似于预处理，类似于这种线上能够提供这种 certain 的这种服务，比如说这种 Druid、 Kylin 或者是 HBase ，当然这三个的技术实现是很不一样的，但是归到一类相当于在业务里边可以认为他们有一部分是重叠的。比如说 Druid ，做的都是非明细表，然后都是一些聚合表类的查询，比如说像 ansbook ,主要是解决这种不同的数据源，比如说 CSV 格式、包括这种 part 格式，把他们统一成同一个这种 table format 模式，这个就是一个大体的分类。
三、开源大数据/数仓解决方案
然后下面会介绍一下开源大数据的一些数仓方案，这个数仓方案主要就相当于是一种组合的方案，就是知道了这些技术，然后这些技术怎么组成一种比较合理的带有业务价值的这种玩法。主要是分为几个部分，第一个部分就是看一下 EMR 的整体架构；然后从 Lambada 的架构开始讲，讲到最后比如说一些推出的这种实时数仓方案，大概从开源的领域到底应该怎么去建设。
1. EMR 整体架构
这个就是 EMR 的一个整体的架构，这个整体的架构和今天 OLAP 关系不是非常的大。构建一个大数据平台，其实无非就是以下这几种。第一个就是 ECS 层，然后 pass层基本就是业界比较通用的这种样儿；目前这个 K8S 也逐渐的走进了大数据的这个领域，包括这种 flink on k8s 、 spark on k8S 还有 press on k8S 。越来越多的这种引擎都已经在 K8S 上跑了，也有一些在生产实践中用的比较好的，包括近期阿里云 EMR 开源的这个remote shuffle service 实际上也是在支持这种 K8S 形态的方式的一个必须的一个组件，在 Spark on K8S 的一个必须的组件，还包括 flink 也开源了 remote shuffle service，他是支持这个 flink 批处理的，是在 K8S 上的一个增强的软件。
然后下一层就是存储层，存储层的话， EMR 比较明星的一个产品就是 jingdoFS 提供了一种 Hadoop 接口的,以 OSS为基底的这种方式，也就是说在计算引擎，包括 spark 、 flink 、 presto等，他们完全可以不感知后边是 OSS ，直接还是用 Hadoop 的这种接口去直接使用这个 OSS ，这个在成本上和扩展性上，实际上是有一个比较大的提升的。然后下一层就是数据库格式，数据库格式主要是解决了几种痛点，比如说 absurd ，比如说这种统一的元数据管理。
然后上一层中的绿色部分是今天比较重点的部分。然后其他，就是包括 spark ，包括最老的这种 map reduce ，还有一些机器学习相关的东西。然后再上一层就是阿里的一个产品，这个产品相当于就是 bi 的产品，包括一些 datawords 的产品，还包括一些 EMR 提供的 tools 。最右边的就是一些权限管理的一些监控，包括一些资源的打标、日志等一些服务。这个就是整体 EMR 的构成，后续会主要讲绿色这些部分。
2.离线数仓体系— Lambada 架构
现在来看一下目前状态用的最多的一个离线数仓体系，就是这个 Lambada 架构。 Lambada 架构其实就是分两条链，第一个就是实时这条链，他实际上从数据源开始，数据源就是有这种 CDC 的数据源也就是 LTP 的这种数据源，还有就是类似于这种流量的数据源，一般都是 log 或者是包括一些行为的数据分析，然后他们都到这种圆的 kafka ，然后通过上边的一条就是 flink 去做一次加工或者说做几次加工；最后给他灌到几种形态里边，有的时候直接灌是这种 redis ，还有 kafka 结构的这种 Hbase ，然后包括还要给他灌到这种 sik 里面，灌到这种 StarRocks 里边。
主要提供的是几种服务；第一个就是，如果这个 redis 或者是 Hbase 希望的是业务在线系统能够直接的对他们提供这种 service 的能力，也就是说在线系统可以直接调用这种 API 了，因为他检查的这种效率是相当高的；第二个，就是说要给他导到这种 OLAP 系统里边，把这些所有聚合的数据或者说是这种半聚合的数据都导在这种 OLAP 的系统里面，然后运营人员可以快速的去用他自己的思维即事先没有定义好的，可以去 adhoc 一些想要了解的运营数据，因为每天这种数据科学家也好，还有就是运营人员也好，他每天的想法可能是不一样的，他突然发现有一些新的这种数据的这种感知，可以通过灵活的这种 OLAP 不间断式的去完成思路。
第二条链就是离线链，离线这条链实际上他有几个想法。第一个想法就叫做 log retention ，这个就相当于 kafka ，认为他不是一个最终的日志保留的一个介质，怎么看他都是一个临时的介质，比如说会配这个 log retention 可能是七天或者说是三天，但是都不认为 kafka 是一个长久保存数据的，所以一定要有一个这种长久保存数据的这个口，所以一般用的都是这种 hive ，然后把所有的这个 kafka 全部都 load 到这个hive里边，然后在这个 hive 里边去做这种 insert all right ，其实提到hive，如果没有增量数据库格式，都是用 insert all right ，就是把 ODS 所有这个表都 load 完了，然后用这种 packet 的方式去做上一层的表，包括这种 DWD 的detail 的表，然后在这种 detail 的表上面再去做一些数据集市或者说数据产品的一些表。
这些表其实有两个出处，一个出处就是事先定义好的这种 bi 接口，直接 T+1 直接就跑到最右边的这种报表的形式;还有一种是把他里边的比较热的数据给他 load 到一些 OLAP 的这个产品里边，包括 StarRocks 、 ClockHouse ，主要这个也是提供给这个运维人员的一些输入；第二个想法，这个底线收藏比较重要的一点就是实时，很有可能实时做这个数据订正实际上是不理想的，通过这种 T+1 的数据，比如说同一个数据的口径不是特别的一致，然后通过离线的这个 T+1 的这个口径来去订正这个实时的这个口径，这是比较重要的即 hive 比较重要的两点。当然这个就面临着一些问题，这个问题可能最重要的问题，第一个就是数据里面像 one single truth 就是相当于他的数据来源是同一个或者数据口径是同一个。如果这个数仓做的比较久，应该知道离线的和实时的这个口径实际上很多的时候是无差的，一般来说在七加一的时候都会去更正一下，也就是说可以认为是实时一般得出的是一个近似的值而离线得到的是一个准确的值。
3.实时数据湖解决方案
然后基于上面的一些痛点也就是业界发展出来这种数据湖的一些方案。数据湖的方案一般来说，都选这个 ICEBERG 、 hudi 还有 delta lake 。 Delta lake 一般就是 spark 战也就是说如果所有的数据引擎全给予 spark 来说，这样的话直接基本就是搞 delta lake ，因为delta lake 毕竟是 data bricks 开源的，所以说他对 spark 支持是最好的。然后比较通用的就是这种 hudi、 ICEBEGE 这种链路是什么？就是说解决了上一个链路的一个离线这条链路的问题，那直接就是全部都通过 flink 去走这条路径。这条路径实际上解决了两个大问题。第一个大问题还是说这个数据，因为这种的数据 ICEBEGE 或者 hudi 基本都是保存在这种对象存储上即 OSS 上或者 HDFS 上；解决了第一个问题就是 log 不会丢，最后肯定都是在这种永久的存储上。
第二个解决的是他的一个时间级别的一个问题，这个比如说 hive的话，应该都用的是 insert all right ,做一次这个 hive 的表的话，实际上要求的资源是一个全量的数据;但是做这个 hudi 或者 ICEBEGE 的话，要的是一个增量的数据，增量的数据肯定是要比全量的数据要小的，所以说在做这种更小级别更细力度的这种数仓的话，实际上是有这种方式的，因为 hive 的话一般来说做的都是天级别的，还有的在实践中有这种做半天级的、有这种做小时级的或者几小时级别的，但是再做细粒度的实际上就已经搞不定了，因为每个都要调度实际上整个会特别的繁重，整个这个集群跑起来，如果要做这种分钟级别的或者半小时级别的这种数仓，如果用 hive 来做，实际上集群会非常的繁忙，但如果要是用这种增量的方式去做整体上整个数据链路可以做到分钟级别的，其实再小的级别可能也用的不好了。一般来说，做小时级别或者分钟级别，可以尝试用 ICEBERG 或 hudi 去做。
下面画一个presto，就是说 presto 是可以连接整个 ICEBERG 或 hudi ，只要落到这里的增量仓里就可以直接用这种presto去做这种查询。然后最终的归宿也就是所有这个数据，要么就是直接躺在这种 ICEBERG 和 hudi 里；然后还有一部分比较热的数据即非常关心的数据，要么就是给他放到这种 hbase 的 service的系统，要么就给他放到这种 OLAP 系统，然后能更加速度。后续会有一个时间范围，比如这个 presto 去查这种 ICEBERG 、hudi 的这种表的话，经过一些优化和比较多的原数据的元数据的提取，还有这种 data skipping 的这种操作，实际上能够查到几十秒，就是十秒至几十秒或者更快的可能四五秒；但是在 OLAP 里边实际上如果数据 load 到这里边，由于他是存算一体的，还有 SSD 这种加速，所以说大概就是毫秒级的也就是几百毫秒。
4.实时数仓解决方案
（1）方案一
再往下演进就是这个实数仓的解决方案。这几种方案并不是互相的替代的关系，而是说这些方案更适合某些的场景，然后这种场景实际上其实是一个比较传统的或者说比较流行的一个实时数仓方案，就是实时数仓的每一层都是用这种 kafka 去做也就是用 flink 加 kafka 去做每一层的实时数仓，但是每一层的实时数仓刚才还是要解决一个问题即 log retention 的问题，怎么保留住这些 log 。那这些 log 可以给他加载到这种 StarRocks 里，也就是说 ODS 层做完之后，这个 kafka 实际上可以连一条链也就是 kafka 直接用 flink 或者 StarRocks 直接消费 kafka 就把 ODS 层都 load 到这个 StarRocks 里了。同时这个 DWD 层、 DWS 层，每层处理完之后全部都是增量的落到这种 StarRocks 里也就是说这个 StarRocks 可以完全的去把整个的各种层全部的给搞到一起，那这样实际上所有的层都在 StarRocks 里了。刚才说的这种无论是 bi ，还有这种 adhoc ，还有这种 API 的 serving ，还有最后的 OSS ，实际上就是 StarRocks 可以有两种方式。一种方式就是冷热的方式即 StarRocks 里面存的数据比较冷的或者比如说认为可能七天或者说一个月的数据给他导到冷备里边，导到 OSS 里边；还有一种就是如果 StarRocks 可以做这个外表的关联，能够直接读这个 OSS 里面的数据。
这下面画了四个小框，而这四个框是怎么保证是没有问题的呢？第一个方框就是说速度快，也就是做了销量化做了这个新的这种 pipeline 这种执行引擎，做了这种全新的 CBO ；第二个方框的 Materialized View ，一般来说就是预处理也就是说订一些预处理好的这种C 口去实时的更新这个 Materialized View ；第三个方框的Resource Group ，实际上就是一种资源的管理，就相当于是资源之间互相不打架，各种租户之间互相不打架；第四个方框的 External Table ，就是刚才针对OSS 这部分说的。
（2）方案二
下一个解决方案实际上是一个可以想到的一个未来的一个解决方案，目前 StarRocks 正在往这个方向去做也就是 kafka 的数据直接给他灌到 ODS 里边，然后整个这个 StarRocks 自己去做一些 trigger，做一些 micro-batch 的这种任务调度器直接可以用 ODS 到这个 DW 和 DWS ，这几层全部都是用这个 StarRocks 来完成的。如果已经落入在这个数据仓库里边，实际上有的时候这个建模也未必是完完全全的按照这种 ODS 、 DW 、 DWS 类似于这些比较传统的方式去做，可以经过一些更多的简化也就是相当于用同一套数据仓库的这种引擎去做整个的这种数仓的这种方式。
5.使用场景小结
然后这里是做的一个小节，这个小节实际上整个趋势性也就是看到一些趋势性的东西。
（1） Lambda 架构
Lambda 架构一般来说是所有的大厂里边目前都没有去掉 Lambda 架构也就是虽然说 Lambda 架构痛点也都很清楚，但是在大厂里边只能说是越来越多的这个业务去往实时的方案去转化，实际上这个 Lambda 架构是从来没有被去掉过的。这个比如说有一个厂已经是10PB 级别的，希望以离线的这个底座去做这个数据中台，然后所有的数据全都给他存储到 OSS 和 HDFS 里边，有了这个基座之后会进行一些数据的加工，会把这个离线数据给他加工到这种 StarRocks 或者 CK 等类似于这种 OLAP 引擎里边。在这里边其实如果要做到 CK 里边，是需要做这个大宽表的，因为 CK 不适合这种 Join的级别的东西所以必须要做大宽表，做完大宽表。这个 StarRocks 和 CK 理论上来说，他在这个做 OLAP 查询里边，90%或者99%的这种命中率，基本上都是在500毫秒至两秒的，大概就是这么一个范围，可以灵活地去做这种 OLAP 。然后实时链路就是刚才说那种，实时链路如果是到这个 OLAP 引擎里边，大概查询起来也是500毫秒到两秒。这里面重点强调一下，就是如果 Join 做的比较多也就是说这个宽表做起来不及时，或者说这个宽表做起来有难度，或者说没想的那么明白、没想的那么清楚，肯定这个 C 口里面会有很多 Join ，那么这个Join 用的比较多的情况下 StarRocks 是一个很好的选择。同时 StarRocks 目前在这个单表的能力实际上现在应该是可以比拟 CK 。在某些场景下，比如说在 TPCH 这种标准的测试下边，实际上相差的已经很接近了。
（2）实时数据湖方案
然后实时数据湖的解决方案，就是刚才强调的，还是希望这个数据存到 OSS 或者 HDFS 里边。然后也希望统一这套代码，比如说这条代码全部用 flink 来做或者完全用 structured streaming 来做，希望完全的统一整个的代码。然后这个数据量，在经手过的业务，基本来说是10PB 以下的，但是他的扩展性不见得是10PB 以下，所以保守的写就是 PB 级别的，用这种方式实际上是没有太大问题的。然后业务有几个需求，比如说有 Upsert 需求，而 UPS的需求理论来说应该是非常多的，比如说这个订单需要随时改他的状态，最开始这个订单是一个未付款的状态，而这个付款有的时候类似于网约车什么的有很大的付款延迟性，可能一天之后才付款，然后一天之后要把整个这个订单重刷一遍，哪些订单是延迟付款的；还有第二种就是希望做这种分钟级或者小时级的数仓，这个刚才强调了，他会比较大量的节省这种调度的资源，节省计算的资源。其实要是直接从水位线上看，就是这个样就不是那么繁忙了可以这么认为，或者说整个物理资源用的 load 也不是那么高了。然后在这里边也是有，就是要把这个最热的数据给他导到这个 StarRocks ，然后大概来说是一个一秒两秒的这种试验。如果要是直接去用 Presto 去查这个 Hudi/Iceberg/Delta ，可能试验大概是一个五秒至30秒，这些结论实际上都是一个采样的数据，可以认为这是一个 range 。
（3）实时数仓方案
最后这个实时数仓方案这个方案实际上就是他已经突破了原来说的这套 hadoop 系统了，他跟前两套就已经是完全不相关了，他其实就是突破了 Hadoop 系统。他这个每天增量数据是10TB+ 这都是真实客户案例，希望以单软件或者单组件的方式去做这个底座，因为一套 Hadoop 系统，实际上需要装的组件是很多的。比如说相当于在数仓方案的，就是以这个 ClickHouse 或 StarRocks 去做这个基座，然后把冷的数据也就是第一站直接给打到这个 CK 和 StarRocks 里，如果要是有这种冷的数据才去给他做到 OSS 里边做一些冷背或者说做一些资源的一个成本的一个优化，这个特点就是运维很少，不会去做这个运维体系，比如说一个 MYSQL 客户端，或者因为 StarRocks 是完全兼容 MYSQL 的这个客户端，一个 MYSQL 的客户端，或者说一个 CK 的一个客户端直接就做了，这个运维起来比较简化的话，那么相当于就媲美全托管了，但是整个在 EMR 上的成本还是比全托管要便宜的。然后实时性也非常的强，因为相当于现在就是比如说 CK 的话，直接做的就是大宽表； StarRocks 也是做这个用 flink 做一些数据加工，只要导入之后，那么大概的查询基本上都是在秒级别或者是百毫秒级别，不会有特别大的这种偏差。还有就是后续要推存算分离的这种方案，这种存算分离的方案相当于会以这种 OSS 为底座，然后以 Cache 加速，这种 Cache 会用这种 JingdoFS 这种明星产品去做 Cache 加速，所以这样一旦推起来实际上认为就比如说一个合理的建议，十台 Hadoop 或者是20台 Hadoop 类似于这种的量，实际上可以尝试一下直接用这种第三套方案就可以一站式的做这件事而不是说在学校去维护一套十台或者是几台 Hadoop ，去做一个小的那种 Hadoop 集群的那种方式。
四、 ClickHouse 介绍
讲了这些之后，会简单的或者说大概的介绍一下这几个内核。
1. ClickHouse 是什么
那第一个就是 CK ，实际上做数据的大体上都听过也就是大体上都知道，在这里就再去复述一下。第一个他是一个列存的数据库；然后他是一个 MPP 的架构，其实这里边说的 MPP 实际上是一个广义的 MPP ，如果是带 shaforing 的这种 MPP 实际上 CK 是不具备的，他其实更可以看成就是最老的那种分级，叫 scatter gather 的架构，相当于他会把整个的 C口 分布到多台的 CK 上，然后多台的 CK 算完结果之后，最后再聚合到某一个节点，然后再 to 给这个用户，实际上他是这种 scatter gather了而不是那种大规模的 MPP 带 shaforing 的那种方式;然后他最大的特点就是快，实际上就是这个向量化的支持做的特别好，而且他对细节的把握比如说他做这个 aggregate 的时候，正常做 aggregate 可能想就搞一个 hash map 就可以了，但是他这个 hash map 可能有十种以上也就是说他会对不同的方式用不同的 hash map ，所以说整体上看就是一个细节优化的特别棒的一款引擎；然后他对 SQL 的支持也基本上是完善的，虽然说没有 StarRocks 这种 MSQL 的方式，ICSQL 支持的好，但是基本上来说也是一个完善的；但是他可能对这个实时更新做的或者说实时删除做的不是那么好，因为他毕竟还是类 LSM 这种 tree 的方式，他还是用合并的方式去做删除和更新，所以这块做的不是那么实时；然后现在这个社区也是在逐渐的开始意识到这一块，因为 Upsert 的这种功能，还是 OLAP 的一个必要的环节，所以社区也在往这边做对。如果使用过 CK 的话，可能会认为他的数据量是一个中等的数据量，比如说是百 GB 类似于这种级别的，基本上都是秒出。
2. ClickHouse 为什么这么快
主要他就是类似于 LSM Tree ，然后他整个的这个数据文件实际上就是把 table 每一个，因为写 CK 的话就不会去一条一条的写，一般都是攒一个 VP ，比如说攒一个十兆的或者说攒一个20万条的，比如说在 flink 或者在 spark 里边攒完，攒完之后一次性的打到 CK 里边， CK 就先把整个的这一个 block 也就是这一个 ablock ，相当于把各种的这个列给他拆开，然后把每一列都进行排序，排序完之后，每一个列形成一个并文件，可以看到一个 part 会形成一个文件夹，然后这个文件夹会有 .bin ,“.bin 就是有几个 column 就是有几个 .bin ”这里的细节就不展开了，因为还有一种不是几个 column 等于几个 .bin 的那种就是 compact 的方式，这个就不展开了。
就比如有五个列，那就是五个 .bin ，然后还有相对应的 mark ，还有相对应的 PK 的 index ，而 pk index 和 other index 其实和 tree 里边的或者跟 bplus tree 里边的 index 实际上不是一个东西，那个 index 实际上是行存的一个索引直接能通过某个 key 就能找到对应的 roll ；但是这里边这个 index 实际上就是一个 data skipping 的一个方式，比如说他这个 other index 里面可以有这个 bloom filter 还有一些其他的这种 Data skipping 的 index 。也就是一个稀疏索引，而这个稀疏索引大概是去查整个范围或者说查某一个等号这种方式，就直接在这个 PK 里边先过滤掉这个数据，直接就知道去查某一个 block 下边的某一个颗粒，这个 granularity 就是一个颗粒，是一个颗粒为一个力度.然后整体的所有他的优化，就刚才讲的，他这个细节做的特别好，就是他有很多都是对这个关键数据结构都是量身定做的，然后他整体用的是这种向量化，全面向量化的这种引擎。然后 Pipeline 的并行化，实际上做的也是相当好的，也是基于几篇论文去一起做的。
3. ClickHouse 应用场景
对于场景来说，大概来就是这几种还有一些比如说包括时序数据库的这种方式也有很多是用在 LT 里但是这里展开，其实这个里可做的方式非常多，比如说有这种 lodo 分析，然后有这种 abtest ，然后包括这个广告里面用的最多的就这种圈人，就相当于各种 tag 去这种整体做圈人的操作，实际上 CK 用的是相当多的。目前来说，这个 CK 的接受度应该也都接受起来了，用的也比较广泛了，大多都是跟 flink 连着用，然后有的时候还用 spark 去做数据清洗之后，然后 spark 的离线数据导入这两个方式，就刚才讲的那些场景其实都有提及。
4. EMR ClickHouse 架构
这里面是 EMR 做的一些 CK也就是跟一些社区不同的。与社区不同的第一个就是有 In Memory Part 就是刚才讲的很多的 flink 或者是 spark 需要攒批去写入的，但是想打破这个瓶颈也就是相当于按几条或者几十条，就不用让这个客户非常的繁琐，因为客户要是想配十兆或者说20万条还是几十万条，实际上有的时候客户配不清楚，他不知道1万条是多大数据，也不知道每条数据是一个 K 还是几十个 B ，不清楚有多大数据就可以直接用这种 In Memory Part ，在 In Memory Part 里会为你来攒批，攒完批之后会落入。然后这里边有一篇文章，主要是写了做的这个 Flink Exactly Once 事务写入，这个是支持端到端用 flink 做实时数仓的一个写入的。
然后这个 Sharding Key 是，正常来说如果有线上运维 ClickHouse 这种经验的话，就知道 ClickHouse 实际上是不能够写分布式表的，如果写分布式表，比如说写到这个 Shard 1里边，那么这个 Shard 1会先落盘，然后这个 Shard 2才会从这个 Shard 1里去 fatch 这个数据，所以说整个会对 Shard 1的磁盘的这种 io load ，实际上是非常高的，所以在前端也就是在 ClickHouse Jdbc 的这一层去做了这个 Sharding Key 也就是对应的 Sharding Key 可以写到对应的 Shard 里边。比如说这里面的 Shard 1，可能“1”这个数字永远就落到这个 Shard 1里了，这个“1”数字不会再随机地落到 Shard 2里。因为有了 Sharding Key 的聚促，相当于他有本地性，那么直接做这个 Join 的时候可以做一些 Join 上的优化，然后再做一些其他的算子上的优化。然后这里支持冷热存储，这个冷热存储就是 CK 可以直接把这些冷的数据给他直接放到这个 OSS 里。还有就是 EMR 的一些通用特性像报警、监控，还有一些扩容的方式。后续会在 CK 里去推几个事。
第一个就是 HouseKeeper 去替代Zookeeper，这个是社区2022年的一个重点的方向相当于在 in production 的环境。因为现在已经发布了21.8的版本，实际上就已经有实验性质就是去替代这个 Zookeeper ，但是在生产级别是2022年上半年需要追求的，也会把整个的 Zookeeper 给去掉，因为在 Zookeep里边去做复制的分布式表，实际上是有一些不好的地方，所以要剃掉他。
第二个就是做存算分离，就是刚才想讲的这种用这个 OSS 为底座，然后用 cash 去做整个的数据加速层，然后能够得到的是成本的降低，但是在热表上或者说在一些非常想要的这个表上这个性能还不会比原来差多少。第三个就是构建 Front End Server ，因为构建 Front End Server 在社区里没有提到，但是这个做起来是非常好的。一会讲到 StarRocks 架构的时候，可以看到 Front End Server 实际上对整个的架构有一个比较大的帮助的。
