1、StarRocks 3.0 Overview
StarRock3.0之前定位于实时数仓，重要有以下几方面的才干：
StarRocks3.0推出了新的数据湖剖析配置，支持Hive、Iceberg、Hudi，和MySQL等传统DB外表，加上StarRocks自身的外表，使得StarRocks 能够作为一个一致的查问引擎，去查问各种数据源。基于这些才干，咱们宿愿把 StarRocks 打形成一个实时的Lakehouse产品，更好地整合数据湖和数据仓库这两种产品概念。
LakeHouse可以分为传统数仓和数据湖两大块：
湖仓目前看来还是有较大gap的、割裂的两个场景，StarRocks做了很多技术和Feature，去整合这两种场景，从早期的Warehouse，到3.0做了较大的架构更新，具有了很好的弹性才干。支持存算分别，可以由原生活储变成S3。支持多种部署模式，可以选用线下部署，也可以选用K8s等部署模式。支持数据库查问才干，可以作为一个查问引擎去查问数据湖。最终宿愿打造云原生弹性扩展才干，更好地整分解LakeHouse的产品外形。
StarRocks3.0之前须要手动创立外表DDR来查问外部数据源，在表很多的时刻操作十分繁琐。3.0的Catalog配置可以间接查问Hive、Iceberg、Hudi、Deltalake、ES、Mysql、Oracle、Postgres和文件等各种数据源，笼罩了大局部的数据经常使用场景。
只要要口头create external Catalog命令，就可以连到Hive Metastore智能失掉元数据，而后就可以间接查问其中的数据。除此之外另一种场景是在S3上放了一堆文件，但没有将其组织成Iceberg的format，也可以创立Catalog间接去查问。
在 External Catalog 的基础上，结合 StarRocks 的内表存储，两种数据源可以 Join 起来同时查问。由于内表有自己的存储引擎，具有较好的实时性，可以服务虚时workload；同时External Table可以用于存储历史数据，这样就可以联结经常使用多种不同的存储引擎，来笼罩更多的经常使用场景。
Trino、Presto有自己的SQL方言和许多自定义函数，而StarRocks目前重要兼容的是MySQL语法和协定。假设用户曾经过了POC阶段，正在消费系统经常使用Trino、Presto等查问引擎，想要迁徙到StarRocks就会有很多的上班，只管不用迁徙数据，然而须要变革很多业务SQL。
为此StarRocks做了兼容Trino的feature，在SQL parser中支持MySQL和Trino 两种方言，经常使用一致的口头方案，目前曾经笼罩了99%的语法。用户只要要将方言切换为StarRocks，就可以成功无缝迁徙，取得数倍的性能优化。
数据湖由File format和Table format两局部组成，File format通常会用比拟高效的ORC、parquet，Table format通常会用Iceberg、Hudi。
数据湖跟内表存储引擎理念比拟凑近，没有太多实质差异，然而在详细的细节上还是有些差异的，比如说文件格局、文件紧缩成果、IO成果以及全体性能等。HDFS和S3等不同的存储系统只管可以提供一致的接口，但它们是有性能差异的，HDFS通常在Latency上会比S3的性能稍微好一些，有些场景下S3会有更好一些。ORC的IO counter或许比parquet要多十分多，也就是parquet可以IO size更大一些。
思考到这些状况，StarRocks外部做了十分多的IO优化，去克制不同系统之间的性能差异。
上图是用eBPF之类的工具观察到的结果，可以看出在数据湖场景下愈加IO密集，传统数仓场景下往往是计算密集。有些用户的写数系统比拟复杂多样，数据格局品质不那么好，发生了很多parquet小文件。有些用户ORC的stripe size设置得十分小，假设按传统战略每个row group外面读每个column，它的IO会十分小或许就几KB，效率十分低，咱们也不能把IO粒度扩展到文件级别，由于或许某一个文件十分大。
StarRocks针对不同IO密集场景做了优化。
假设column size十分小就兼并IO，一次性读取多个column。
假设文件十分小，就一次性读取整个文件，即使文件中有一些数据或许并不须要，但在做了这样一个兼并之后，总IO次数会少十分多。
假设经常使用了S3存储，不论你怎样优化，当访问它的冷数据的时刻，它的IO消耗必定会十分高，最好的优化模式是把数据cache在本地。相较于Presto、Trino会用一些三方组件去做数据cache， StarRocks 宿愿把系统架构做得更繁难一些，所以自己成功了一套协同memory和disk的cache系统，数据会先cache在memory中，当memory 不够时数据会溢出到disk上。通常来说大局部workload都会有一个相对比拟小的working set，比如有几百GB的数据要剖析，当屡次查问后，大局部数据都能够命中cache，从而失掉比拟好的查问性能。
除此之外 StarRocks 也做过一些算法层面的IO优化，比如提前物化技术，会依据查问条件中的where条件先把某一列查进去，再造一个过滤去读其它列。还有Top N算子，也可以做提前物化，前面咱们或许也会在join也支持提前物化技术。
综合经常使用各种IO优化技术，可以很大水平上缩小文件IO。在雷同的数据集、雷同的资源规模下，StarRocks查问Iceberg比Trino快3-5倍。在大局部用户案例中，从Trino切换到StarRocks都会有一个十分清楚的性能优化，像TPC-H其实是一个相对没有那么复杂的数据集，假设用户的实践业务中有一些特意复杂的SQL，它会有愈加清楚的性能优化。
6、StarRocks LakeHouse - 一致放开
StarRocks在架构层面和配置技术层面做了很多整合，比如物化视图、Catalog、IO优化以及Trino兼容等，宿愿这些技术能够整合起来，打形成一致放开的Lakehouse架构。
StarRocks可以作为查问引擎去查问数据湖中的数据，交流Spark、Flink等相对比拟老的组件。StarRocks 也有自己的存储引擎，它可以提供 Colocate才干，以及用户指定的分区、排序、分桶才干，和实时场景下须要的实时更新以及索引的才干。
综合经常使用这些技术，使得用户可以让一局部workload放在数据湖里，继续经常使用Spark、Flink做加工处置，另一局部更偏实时的workload放在内表里，而后用 StarRocks 作为一致的查问入口，也可以让实时workload经过StarRocks写入。结合起来，比拟好地成功了实时 LakeHouse这样的架构。
1、StarRocks Materialized View
物化视图的语法有几个局部：
partition by： 对物化视图分区，和StarRocks内表一样，可以依照期间等维度启动分区。分区后可以对查问裁剪，防止访问不须要的数据，比如按蠢才区后就只要要刷今日的数据，历史数据不须要去touch。还可以启动分区级的数据智能刷新、数据变卦的智能订阅，成功比拟好实时性。
支持全量刷新、增量刷新、定时刷新、手动刷新等多种模式。满足不同业务场景的需求。
resource group： 把物化视图跟其它workload更好地整合在同一个系统、同一个集群里。由于用户的查问是一种偏前端的workload，而物化视图的保养是偏后端、资源十分密集的workload，所以如何把这两种整合到一同，稳固地跑到同一个集群外面，是一个很大的技术难点。所以咱们这里选用用 resource group 技术来成功资源隔离。
查问语句： 支持aggregation、join等查问语句。
对不同的查问语句类型可以经常使用不同的刷新模式，假设是繁难的聚合查问可以增量刷新，假设有join或许更复杂的语句就要全量刷新。未来StarRocks会逐渐扩展物化视图的增量刷新才干，支持更多的复杂经常使用场景，比如增量的 join 窗口，相似Flink 的增量计算等等。
消费环境中有很多适宜用物化视图的场景，例如：
增量聚合： 很多业务报表会对immutable的event、log数据做sum、distinct、bitmap、Hyperlog等聚合，这类数据普通数据量十分大、写入TPS高，所以不适宜全量刷新。之前罕用Flink来做增量计算，像sum、bitmap去重以及Hyperlog等，如今也可以用StarRocks的增量物化视图来支持。
数仓建模： 物化视图的语法十分适宜代替传统ETL用来建模。业务有时或许不太关心增量刷新还是全量刷新，也不太关心数据之间的依赖相关如何表白、如何调度，就可以经常使用DBT这种工具间接用物化视图去建模，它还可以屏蔽底层的刷新模式。
透明减速： 用户可以透明地创立出一个物化视图，而后应用优化器的查问改写才干，改为查问物化视图来成功很好的减速成果。
数据湖减速： 数据湖查问往往是IO密集型的，普通可以经常使用cache来优化，但假设数据量十分大就无法cache在本地。这时可以借助物化视图来估量算，计算结果的数据量通常会小几个数量级，再把计算结果cache到本地，就可以很好地减速数据湖的查问。
传统数仓建模可以分ODS、DWD、DWS、ADS几层，每层或许都会用到Hive、Sqoop以及Flink等ETL工具，如今也可以用StarRocks物化视图技术来构建。从ODS到DWD往往是聚合和荡涤，这一层可以用物化视图的SQL谓词和增量聚合技术来构建。再往上或许会做宽表join以及面向详细业务的报表，往往须要比拟复杂的join，或许窗口函数的计算，也可以用物化视图来表白。
它带来价值是能够简化架构的复杂度，不须要在外部保养很多的数据组件去做加工，假设保养了这些数据组件，不只要经常使用物理资源去部署运转，还须要部署一些调度、监控的组件去支持，这样的架构是比拟复杂的。假设迁徙到物化视图上方来，就只要口头几条SQL，不须要额外保养组件，物化视图还保养了调度相关。
另外还能充沛应用StarRocks口头引擎的性能长处，假设经常使用Hive等内部系统，数据或许先要过一遍Hive，两边的计算开支以及IO开支就会十分的消耗资源，而后再往下游系统写数据，它的IO又会多了几倍，一旦有很多的IO开支以及组件，全体性能就很难优化，十分消耗资源，ETL义务的实时性也很难保证。
迁徙到StarRocks就可以很好地处置这些疑问，重要用到上方几个关键技术：
上图中T1是理想表，T2是维度表，罗列了一些分区刷新的经典场景：
理想表细粒度刷新： 维度表的变化频率是相对比拟低的，假设理想表做了比拟细粒度的分区，比如天级、小时级或分钟级的分区，无理想表刷新之后，基于分区就可以发现物化视图对应的某一个分区也须要更新，那就只要要刷新一个分区，代价是相对比拟低的。
维度表精准刷新： 最经典的场景是刷新整个物化视图，代价相对较大。有些业务像酒店餐饮是可以不回刷数据的，那么可以精细化的扫除某些维度，不触发回刷。也有一些业务，宿愿回刷比如一个月的数据，那么可以精准的控制回刷几个分区。
智能刷新： StarRocks支持订阅外表分区的数据变卦，当发现Hive等外表分区变卦后，可以智能刷新物化视图对应的分区。
StarRocks成功了一致的架构，能够同时运转Ad-hoc query、Dashboard、Realtime、Batch等多个workload。Realtime物化视图时效性要求通常比拟高，对比实时看板普通是分钟级，所以资源消耗比拟大。Batch物化视图准许慢一点普通是天级，通常是在中午定时去跑，所以不须要占用十分多的资源。那么如何资源隔离，使不同的workload不会相互影响，就成为了一个难题。目前StarRocks用了资源组软性隔离和Warehouse硬性隔离两个技术来成功资源隔离。
资源组软性隔离： 用户可以经常使用自动资源组，或许依据业务须要创立资源组，十分细腻的控制每个视图的CPU、Memory、Disk等资源的最大配额占比。当只要1个workload 时准许跑到100%，当有多个workload时，就依据配额的比例调配资源，由于是软性，所以加起来可以超越100%。
Warehouse硬性隔离： 在云原生架构成功了有形态计算节点的架构。物化视图可以放在独立的节点运转，将资源彻底隔分开来。Warehouse 自身是弹性的，可以随时创立、监禁。
在BI 报表场景的SQL很多是系统智能生成的，而且通常很复杂，用户很难经过修正SQL的模式来启动调优，所以须要一种相似于传统数据库索引的透明减速才干。
物化视图针对SPJG（select、project、join、group by）场景，支持查问改写减速。比如有两表的join再聚合的query，咱们可以创立一个逻辑一样的物化视图，在query时间接scan这个物化视图，这是exactly match的。假设还有聚算计算，或许聚合key、表白式有区别，那么可以在这个物化视图的基础上做二次的聚合、join计算。
上图左边是物化视图，有期间和city两个维度。可以驳回相似某些系统的Cube来减速查问，在创立Cube的时刻就把一切维度都估量算进去，前面的查问简直不须要做任何计算。然而假设维度很多，会造成维度组合数量爆炸。物化视图可以把经常出现的维度预聚合，比如把期间和市区预聚合，比如一天有几亿数据，按天聚合后数据量会少几个量级，带来的成果十分清楚。
上图左边是三个实践的查问，查问语句不须要跟物化视图一样，否则就比拟鸡肋了。大局部查问的维度组合是比拟灵敏的，维度也不必定和物化视图分歧，所以须要上卷以及更多的探求。示例1的查问依照期间维度聚合count，count是可以上卷的，只要要把物化视图依照city聚合count一次性，所以优化器会智能改写为基于物化视图的上卷。示例2依照city聚合也是一样可以上卷。上卷之后可以取得更多的维度组合，有比拟好查问减速成果，同时也会统筹灵敏性，还有一些不凡的case是做count distinct，须要结合Bitmap技术，在底层创立物化视图的时刻同时创立bitmap，而后在上方就可以做更多的维度的组合了。
join是十分经常出现的数据加工模式，宽表join的物化视图或许把理想表和多个维度表join起来。查问的时刻比拟灵敏，或许join结果并不须要一切维度，只要要join其中一局部。由于join类型有很多，inner join跟outer join不一样，一对一join跟一对n join也不一样，会有一些参数和其余的语法去适配不同的场景，或许把inner join改成其余join模式，也或许齐全改写到物化视图上去，剔除掉其中不须要访问的那些数据。
国际某共享出行公司有几十个实时看板，须要做准确的count distinct，运营人员要求数据新颖度到达分钟级、并兴旺到100。之前保养了很多Flink job做增量计算，结果发现间接去现算简直是无法能的，每次计算或许须要几秒钟，由于它的distinct有千万级。之前的系统经常使用了HypoLogLog技术含糊去重后再count distinct，数据新颖度比拟好，但结果是不准确的。
经常使用StarRocks交流Flink系统后，资源老本和保养老本都缩小了很多。优化方案是经常使用StarRocks做两层物化视图：
第一层在明细数据上依照市区、期间做增量聚合，可以用bitmap技术和物化视图增量更新技术，先聚分解市区粒度、分钟级的数据。
第二层用物化视图做面向ODS的分钟级刷新视图，由于有几十个看板，所以视图十分多，分钟级刷新是能够比拟好地掂量数据新颖度和资源经常使用。
这些看板的SQL不繁难修正，所以还用了物化视图的透明减速才干，智能改写交流掉它这个报表中的一些SQL。由于第一层曾经做了增量聚合，所以第二层计算量比拟小，不须要做十分重的聚算计算，只要要把物化视图的结果做一些繁难的过滤就可以前往了。
StarRocks掂量了数据新颖度和性能，如今100并发时latency 大略由3秒缩减到了30毫秒，并且成功了准确的1分钟新颖度的count distinct。
物化视图相关的技术，包括构建外表物化视图、分区相关保养、智能刷新、改写SQL等等，都可以和数据湖整合起来，使得在外表的场景能够用物化视图减速。其中外表的查问改写和内表还是有一些差异的，比如Hive或许申明一些外键解放、惟一键解放，在查问改写环节中是须要这些消息的，咱们可以用其它一些模式把这些消息透传上来，而后就能在优化期器中用于查问改写。这几个技术结合起来成功了比拟好的查问减速成果。
数据湖的架构往往是比拟复杂的，接上去看几个案例。
分层建模分为以下四层：
ODS层可以是数据湖外表，存储历史数据。
DWD层经常使用外表物化视图把数据荡涤后放到StarRocks外部存储，以及用PK表可以实时地把TP等数据同步出去，可以用来存储实时数据。
DWS层用了物化视图和逻辑视图两种技术，物化视图把结果给物化上去用于减速查问，逻辑视图依然可以访问实时数据用于简化业务逻辑，把这两种技术结合起来就可以面向不同的业务场景、成功不同的成果。
ADS层用逻辑视图把很多的业务数据给union起来，以及做一些更面向业务的表白。
这样分层后相对愈加灵敏，成功了近实时的实时性。存储也比拟放开，历史数据依然可以存在数据湖中。两边的数据刷新局部也不用保养，而且依然可以用其余的查问引擎。
严厉来说，实时数据湖并不是一个产品或许一个Feature，而是一种处置方案。目前 StarRocks 会结合 Iceberg 以及一些其余Feature，去成功LakeHouse 场景的实时聚合、实时更新，成功全体的处置方案。
实时聚合： 重要面向immutable的数据，这类数据可以间接去写Lake，经常使用Iceberg这种数据湖的写入吞吐量会比拟高。
实时更新： 重要面向mutable的数据，数据湖目前还没有较好的实时更新才干，StarRocks primary key则可以很好的支持，所以首先会把数据写到pk表，定时下沉到Lake中，同时在此之上，可以用物化视图做实时的增量聚合。
结合实时聚合和实时更新两种场景，把全量数据存在Iceberg中，把聚合、更新数据放在StarRocks中，而后在下层构建物化视图去做面向业务的加工宽表、聚合结果，可以带来以下几方面的业务价值：
第一个是应用云原生架构更好地治理资源，在接入数据湖并构建很多ETL workload之后，如何把各种资源一致管控起来，将会是一个很大的应战。
第二个是支持更多的ETL的场景，物化视图目前还不能处置所有ETL场景，无法彻底交流Flink，所以未来会开发更多的ETL的feature，更好地把ETL场景一致同来。
第三个是进一步增强实时链路，会针对数据摄取和数据实时计算等场景开发更多的feature，让导入各种实时系统的数据变得愈加容易，会支持更多的增量计算场景，而不只仅是实时聚合。
问：物化视图底层存储也是用三正本吗？
答：对。物化视图也是依照表来存储的，不同于普通表的是会智能保养。Base表跟物化视图表的存储都取决存储引擎，可以设置3正本，可以设置2正本，也可设置1正本，也可以用云原生架构做存算分别，是十分灵敏的，关键在于如何保养这个base表跟计算结果的映射相关。