cover_image

探索 StarRocks on Kubernetes

Yun 信也科技拍黑米
2024年07月15日 05:51

一、技术介绍

1. StarRocks简介

     StarRocks是一个高性能的分析型数据库，专为大规模数据分析而设计。它采用了MPP(Massively Parallel Processing)架构，能够在多个节点上并行处理查询，从而实现快速响应。

StarRocks的特点包括：

  • 实时分析：StarRocks能够对实时写入的数据进行即时查询分析，无需等待数据加载完成。

  • SQL兼容：StarRocks支持标准SQL语法，使得数据分析师和开发者能够无缝使用他们熟悉的工具和语言。

  • 自动分区和分布式查询：StarRocks自动将数据分区并分布到不同的节点，实现负载均衡和查询优化。

  • 存算分离：动态增删计算节点，实现秒级的扩缩容。存算分离大大降低了数据存储成本和扩容成本，有助于实现资源隔离和计算资源的弹性伸缩。

  • 多Catalog：通过Hive Catalog，不需要执行数据导入就可以直接查询 Apache Hive里的数据。 

  • 异步物化视图：支持多表关联以及更加丰富的聚合算子。

2. Kubernetes简介

    Kubernetes是一个强大的开源平台，用于管理容器化应用的生命周期。它最初由Google设计并捐赠给Cloud Native Computing Foundation (CNCF) 管理。

Kubernetes核心特性：

  • 服务发现和负载均衡：Kubernetes为应用提供内置的服务发现机制，并支持负载均衡，确保应用的高可用性。

  • 存储和网络抽象：Kubernetes提供了持久化存储解决方案和网络策略，使得容器可以安全、可靠地访问存储资源和网络。

  • 自动部署和回滚：Kubernetes支持声明式部署，可以自动应用配置更改，并在出现问题时回滚到先前的状态。

  • 自动扩展：Kubernetes可以根据实时负载自动扩展应用副本，以满足服务需求。

3. StarRocks 与 Kubernetes 的结合优势

StarRocks在Kubernetes上的部署，充分利用了云原生技术的优势。带来了以下好处：

优势类别

StarRocks 特点

Kubernetes 支持

自动化部署

简化集群部署和管理

提供自动化工具

弹性伸缩

动态调整资源

支持自动扩展应用副本

高可用性

保持服务不中断

自我修复能力

资源优化

有效管理资源使用

资源配额和限制功能

二、K8S部署Starrocks集群

图片（图1 StarRocks存算分离架构）

1. 创建Kubernetes集群

以使用云托管的Kubernetes服务，例如Amazon Elastic Kubernetes Service(EKS)或者Google Kubernetes Engine(GKE)集群，或者私有Kubernetes集群。本次使用私有K8S集群，搭建步骤忽略。

2. 部署 StarRocks Operator

    Kubernetes集群上通过StarRocks Operator自动化部署和管理 StarRocks 集群。

# 您可以选择使用默认配置文件或者自定义配置文件部署 StarRocks Operator。# 1.使用默认配置文件部署kubectl apply -f https://raw.githubusercontent.com/StarRocks/StarRocks-kubernetes-operator/main/deploy/StarRocks.com_StarRocksclusters.yaml
# 2.使用自定义配置文件部署 StarRocks Operator# a.下载用于部署 StarRocks Operator 的配置文件curl -O https://raw.githubusercontent.com/StarRocks/StarRocks-kubernetes-operator/main/deploy/operator.yaml# b.根据您的实际需要，修改配置文件 operator.yaml# c.部署 StarRocks Operatorkubectl apply -f operator.yaml
# 3.检测StarRocks Operator 的运行状态。如果 Pod 处于 Running 状态且 Pod 内所有容器都 READY，则表示 StarRocks Operator 成功运行。$ kubectl -n starrocks get podsNAME                                  READY   STATUS    RESTARTS   AGEStarRocks-controller-65bb8679-jkbtg   1/1     Running   0          5m6s

3. 部署 StarRocks 集群

# 1.可以直接使用 StarRocks 提供的配置文件范例，部署 StarRocks 集群,包含三个 FE 和三个 BE 节点。kubectl apply -f https://raw.githubusercontent.com/StarRocks/StarRocks-kubernetes-operator/main/examples/StarRocks/StarRocks-fe-and-be.yaml
# 2.可以根据需要修改配置文件，支持的字段和详细说明，请参见 https://github.com/StarRocks/StarRocks-kubernetes-operator/blob/main/doc/api.md
# 3.部署 StarRocks 集群需要一定时间，期间，您可以执行 kubectl -n StarRocks get pods 查看 StarRocks 集群启动状态。#   如果 Pod 处于 Running 状态且 Pod 内所有容器都 READY，则表示 StarRocks 集群已经成功运行。
$ kubectl -n starrocks get podsNAME                                  READY   STATUS    RESTARTS   AGEStarRocks-controller-65bb8679-jkbtg   1/1     Running   0          22hStarRockscluster-sample-be-0          1/1     Running   0          23hStarRockscluster-sample-be-1          1/1     Running   0          23hStarRockscluster-sample-be-2          1/1     Running   0          22hStarRockscluster-sample-fe-0          1/1     Running   0          21hStarRockscluster-sample-fe-1          1/1     Running   0          21hStarRockscluster-sample-fe-2          1/1     Running   0          22h
# 4.说明# 如果部分 Pod 长时间仍无法启动，您可以通过 kubectl logs -n StarRocks <pod_name> # 查看日志信息或者通过 kubectl -n StarRocks describe pod <pod_name> 查看 Event 信息，# 以定位问题。

三、使用探索

1. 存算分离，加速查询

1.1 背景

目前公司在使用报表类查询时会需要依赖于离线集群进行大数据量的加工处理，然后再将Hive数据进行导出到如MySQL、MongoDB、Clickhouse等存储查询一体引擎中做再次聚合分析查询。

在当前的数据处理流程中，我们面临两个主要挑战：首先，使用Impala处理大数据量后，数据导出过程存在瓶颈，导致计算速度快但导出速度慢的问题。其次，虽然将数据导出到MySQL、MongoDB或ClickHouse后可以进行进一步的聚合分析查询，但查询性能受限，且多套组件的维护存在难度。

基于上面存在的问题，希望有一个统一的查询加速方案，可以解决导数，查询以及运维组件的问题。

1.2 新方案

    StarRocks作为一款高性能的分析型数据库，通过其Hive Catalog和异步物化视图功能，提供了一种创新的解决方案来加速Hive表的查询。

Hive Catalog功能允许StarRocks直接连接到Hive集群，无需数据迁移或复制。这样，StarRocks可以无缝地访问Hive表，并将它们作为外部表进行管理。Hive Catalog的优势在于它能够提供对Hive元数据的透明访问，同时利用StarRocks的查询引擎优化查询性能。 

异步物化视图是StarRocks的一项关键技术，它通过预计算和存储查询结果来提高查询性能。与传统的物化视图相比，异步物化视图支持更复杂的查询场景，包括多表关联和多样化的聚合操作。更重要的是，它们可以基于Hive创建，从而将Hive的数据转换为StarRocks可以快速查询的形式。 

通过这种方式，StarRocks不仅能够提供对Hive数据的快速访问，还能够显著减少查询延迟，提高数据处理效率。这对于需要处理大规模数据并发查询的业务场景尤为重要，如数据仓库、实时数据分析和商业智能应用等。

1.3 加速Hive查询的步骤

  1. 连接Hive Catalog：在StarRocks中配置Hive Catalog，与Hive集群建立连接。

  2. 创建外部表：映射Hive表为StarRocks的外部表，实现元数据的透明访问。

  3. 定义异步物化视图：根据需求创建预计算查询结果的视图，优化查询性能。

  4. 查询改写：StarRocks自动改写查询，利用物化视图加速过程。

  5. 刷新策略：手动或定时刷新物化视图，确保数据时效性。

  6. 性能监控：使用StarRocks监控工具，持续优化视图性能。

图片

（图2 加速Hive查询的步骤）

1.4 加速测试

Impala和StarRocks查询速度比较

组件

Impala

StarRocks

资源类型

物理机

Docker容器

节点数量

5ImpalaDaemon节点

3 CN 节点

CPU 核数

64 核

8 核

内存容量

40 GB

32 GB

1. 全表物化视图

-- ods.tr_term表36字段，约450w条数据。-- 只对比第一次查询，避免缓存问题。SELECT COUNT(1) FROM ODS.TR_TREM

Impala查询：0.84S

图片

（图3 Impala执行SQL1）

StarRocks做物化视图后，0.11S

CREATE MATERIALIZED VIEW test.tr_termrefresh MANUAL AS SELECT    *FROM hive_catalog_cdp.ods.tr_term;

图片

（图4 StarRocks执行SQL1）

2. 聚合SQL物化视图

-- ods.cpu表10个字段，约186亿条数据。select  count(1)from  (    select      par_dt,host,sum(`value`)    from      ods.cpu    where      metrics = 'idle'    group by      par_dt,      host  ) t;

Impala查询：240.57S

图片

（图5 Impala执行SQL2）

StarRocks做物化视图后，第一刷新大约需要12min，增量数据刷新物化视图在秒级别。

CREATE MATERIALIZED VIEW test.sum_cpu_idleDISTRIBUTED BY HASH(`par_dt`)refresh IMMEDIATE async START('2024-07-11 10:00:00') EVERY (interval 1 day)PARTITION  by str2date(par_dt, "%Y-%m-%d")PROPERTIES ("force_external_table_query_rewrite" = "true") AS SELECT    par_dt ,host,sum(`value`) FROM hive_catalog_cdp.ods.cpu where metrics = 'idle' group by  par_dt,host;
图片
（图5 聚合物化视图刷新情况）
查询聚合SQL物化视图毫秒级
图片
（图7 StarRocks执行SQL2）

3.结论

  • StarRocks 通过创建物化视图显著提高了查询性能，尤其是在处理大规模数据集时。物化视图允许 StarRocks 预先计算和存储查询结果，从而加快后续查询速度。

  • 尽管 Impala 节点的 CPU 核数和内存容量更高，但 StarRocks 通过优化查询和物化视图的使用，实现了高效的资源利用和快速查询响应。

4.使用场景

  • 加速重复集合查询：如果数仓存在大量包含相同聚合函数子查询的查询，占用了大量计算资源，可以基于该子查询来建立异步物化视图，计算并保存该子查询的所有结果。建立成功后，系统将自动改写查询语句，直接查询异步物化视图中的中间结果，从而降低负载，加速查询。

  • 周期性多表关联查询：如果需要定期将数据仓库中多张表关联，生成一张新的宽表，可以为这些表建立异步物化视图，并设定定期刷新规则，从而避免手动调度关联任务。异步物化视图建立成功后，查询将直接基于异步物化视图返回结果，从而避免关联操作带来的延迟。

1.5 总结

StarRocks，作为一款高性能的分析型数据库，通过其 Hive Catalog 和异步物化视图功能，提供了一种创新的解决方案来加速 Hive 表的查询。

Hive Catalog功能允许StarRocks直接连接到 Hive 集群，无需数据迁移或复制。这样，StarRocks 可以无缝地访问 Hive 表，并将它们作为外部表进行管理。Hive Catalog 的优势在于它能够提供对 Hive 元数据的透明访问，同时利用 StarRocks 的查询引擎优化查询性能。 

异步物化视图是 StarRocks 中的一项关键技术，它通过预计算和存储查询结果来提高查询性能。与传统的物化视图相比，异步物化视图支持更复杂的查询场景，包括多表关联和多样化的聚合操作。更重要的是，它们可以基于 Hive 表创建，从而将 Hive 中的数据转换为 StarRocks 可以快速查询的形式。 利用基于 Hive catalog 的物化视图，直接将大宽表提供给用户，性能不佳时再进一步优化。

通过这种方式，StarRocks 不仅能够提供对 Hive 数据的快速访问，还能够显著减少查询延迟，提高数据处理效率。这对于需要处理大规模数据并发查询的业务场景尤为重要，如数据仓库、实时数据分析和商业智能应用等。

图片

（图8 StarRocks数仓加速）

四、验证过程中的遇到的问题

1. Kerberos认证

背景：需要使用存算分离，StarRocks远端数据存放于开启Kerberos认证的HDFS集群。

操作：对官网提供的基础镜像，构建一个新镜像，安装Kerberos客户端和Crontab定时器，定时刷新Kerberos令牌，将hdfs-site.xml和core-site.xml放入StarRocks的conf目录下，krb5.conf和keytabs文件放入etc目录下。

问题：Kerberos访问失败

图片

（图9 Kerberos认证报错）

解决：StarRocks镜像中安装的JDK版本为11，搭建Kerberos服务端的集群为JDK8使用rc4.hmac加密类型，JDK11已经弃用。krb5.conf需要添加allow_weak_crypto=true允许弱加密算法。

图片

（图10 Kerberos加密类型）

2. 对外访问

2.1 NodePort方式

背景：在Kubernetes集群外，支持通过FE Service的LoadBalancer和 NodePort访问StarRocks集群。

问题：使用NodePort的方式暴露Web和Jdbc连接，使用简单，但占用端口较多，需要管理和确定暴露的端口。

解决：使用Ingress的方式暴露。

2.2 Ingress方式

背景：FE的Web界面，避免一套StarRocks集群，运维一个域名的问题，希望同一个域名跟不同路径标识，可以访问不同的StarRocks集群Web界面。

问题：StarRocks前端请求的CSS，JS等静态文件并不会携带自定义的后缀，无法正确访问到Web界面


图片

（图11 StarRocks无法正确解析后缀）

解决：

1.使用域名区分的方式，一套StarRocks集群一个域名。

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: starrocks-cluster-ingress-8030  namespace: starrocksspec:  rules:  - host: starrocks-cluster-1.ui.com    http:      paths:      - backend:          service:            name: starrockscluster-1-fe-service            port:              number: 8030        path: /        pathType: Prefix  - host: starrocks-cluster-2.ui.com    http:      paths:      - backend:          service:            name: starrocks-cluster-2-service            port:              number: 8030        path: /        pathType: Prefix

（多域名Ingress资源文件）

2.修改StarRocks的JS文件，添加方法，转发后缀。

function getPathTwoLevels(pathname) {    var parts = pathname.split('/');    var filteredParts = parts.filter(function (part) {        return part !== '';    });    var result = filteredParts.slice(0, 2).join('/');    console.log(result)    if (result) {        result = '/' + result + '/';    } else {        result = '/';    }    return result;}
document.addEventListener('DOMContentLoaded', function modifyFePrefix() {    var prefix = getPathTwoLevels(window.location.pathname)    var aList = document.getElementsByTagName("a")    for (var i = 0; i < aList.length; i++) {        var a = aList[i]        if (a.href.includes("?")) {
        } else {            var oldHref = a.href.replace(window.location.host, "").replace(window.location.protocol, "").replace(/\//g, "")            a.href = prefix + oldHref        }    }});

（JS新增方法）

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  annotations:    kubernetes.io/ingress.class: nginx    nginx.ingress.kubernetes.io/rewrite-target: /$1  name: starrocks-fe-webserver  namespace: starrocksspec:  rules:  - host: fat-k8s.starrocks.fe.ppdai.com    http:      paths:      - backend:          service:            name: starrockscluster-1-fe-service            port:              number: 8030        path: /(.*static)        pathType: Prefix      - backend:          service:            name: starrockscluster-1-fe-service            port:              number: 8030        path: /starrocks/starrockscluster-1-fe/(.*)        pathType: ImplementationSpecific      - backend:          service:            name: starrocks-cluster-2-service            port:              number: 8030        path: /starrocks/starrockscluster-2-fe/(.*)        pathType: ImplementationSpecific

（多后缀Ingress资源文件）

图片

（图12 StarRocks正确解析后缀）

3.编写TCP/UDP端口转发规则实现L4层服务暴露,对外暴露JDBC服务。

apiVersion: v1data:  "8030": starrocks/sr-3-1-mv-fe-proxy-service:8080  "9030": starrocks/sr-3-1-mv-fe-service:9030kind: ConfigMapmetadata:  name: tcpproxy-nginx-ingress-tcp  namespace: ingress-nginx

（TCP/UDP端口转发资源文件）

3. Flink读写

3.1 写入数据

    以Flink读取写入StarRocks为例，Starrocks提供FeProxy组件，用来写入数据。

3.2 读取数据

问题：读取数据时，提示无法解析Pod的全限定名字，因为是K8S内部的域名，外部无法解析。

图片

（图13 K8S外部Flink任务无法正确解析FQDN）

原因：StarRocks自研的Flink Connector具备从StarRocks集群中各BE节点并行读取数据的能力，大大提高了数据读取效率。Flink先从FE节点获取查询计划 (Query Plan)，然后将获取到的查询计划作为参数，下发至BE节点，最后获取 BE 节点返回的数据。Flink程序无法解析FQDN，导致无法连接BE节点，无法正确读取数据。

图片

（图14 Flink Connector读取流程）

解决

1.Flink读取的程序也跑在同一套K8S集群中。

2.对每一个CN节点创建一个Service服务，通过NodePort方式暴露。通过这个参数[scan.be-host-mapping-list]将新的映射关系传递到StarRcoks配置中。

public class TestReadAndSinkSrOnK8S {    public static void main(String[] args) throws Exception {        StreamExecutionEnvironment env = FlinkEnvUtils.getFlinkEnvLocal();        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
        tableEnv.executeSql("CREATE TABLE `table1` (\n" +                "    `id` INT,\n" +                "    `name` STRING,\n" +                "    `score` INT,\n" +                "    PRIMARY KEY (id) NOT ENFORCED\n" +                ") WITH (\n" +                "    'connector' = 'StarRocks',\n" +                "    'jdbc-url' = 'jdbc:mysql://x.x.x.x:9030',\n" +                "    'scan-url' = 'x.x.x.x:30180',\n" +                "    'database-name' = 'test',\n" +                "    'table-name' = 'table1',\n" +                "    'username' = 'xxxx',\n" +                "    'password' = 'xxxx',\n" +                "    'scan.be-host-mapping-list' = 'x.x.x.x:29060,StarRocks-cluster-fe-cn-3-1-11-cn-0.StarRocks-cluster-fe-cn-3-1-11-cn-search.StarRocks.svc.cluster.local:9060;x.x.x.x:29061,StarRocks-cluster-fe-cn-3-1-11-cn-1.StarRocks-cluster-fe-cn-3-1-11-cn-search.StarRocks.svc.cluster.local:9060;x.x.x.x:29062,StarRocks-cluster-fe-cn-3-1-11-cn-2.StarRocks-cluster-fe-cn-3-1-11-cn-search.StarRocks.svc.cluster.local:9060;'\n" +                ")");
        tableEnv.executeSql("CREATE TABLE `table2` (\n" +                "    `id` INT,\n" +                "    `name` STRING,\n" +                "    `score` INT,\n" +                "    PRIMARY KEY (id) NOT ENFORCED\n" +                ") WITH (\n" +                "    'connector' = 'StarRocks',\n" +                "    'jdbc-url' = 'jdbc:mysql://x.x.x.x:9030',\n" +                "    'load-url' = 'x.x.x.x:30180',\n" +                "    'database-name' = 'test',\n" +                "    'table-name' = 'table2',\n" +                "    'username' = 'xxxx',\n" +                "    'password' = 'xxxx'\n" +                ")");
        tableEnv.executeSql("insert into table2 select id,name,score from table1");
        env.execute();    }}

（Flink读写StarRocks程序Demo）

五、总结

1.优势

  1. 计算加速：StarRocks的Hive Catalog功能具备显著优势，它支持 StarRocks直接与Hive集群建立连接，无需进行繁琐的数据迁移或复制操作。此功能的突出之处在于能够提供对Hive元数据的无障碍透明访问，并且能够充分借助StarRocks强大的查询引擎来优化查询性能，从而实现对Hive表查询的显著加速。例如，在处理大规模数据的复杂查询时，原本耗时数分钟的操作可能在引入Hive Catalog后仅需数秒即可完成，极大地提升了查询效率。

  2. 存储优化：采用存放分离的架构，相较于传统的存算一体架构，能够显著减少冗余的存储空间，有效降低硬盘的使用量。存算分离架构能够节省大量的存储空间，降低硬件成本投入。

  3. 查询优化：Kubernetes的弹性伸缩特性为StarRocks集群带来了极大的便利。它允许StarRocks集群依据负载情况，实现自动或手动的资源分配调整。在高峰查询阶段，能够自动增加计算资源，满足业务需求；在低谷时期，则能够及时释放资源，达到节省成本的目的。特别是CN计算节点的自动扩缩容功能，能够有效减轻大查询对效率的不良影响。

  4. 高可用：Kubernetes具备支持多个副本和自我修复的强大功能，这为 StarRocks服务的稳定运行提供了坚实后盾，能够显著降低单点故障的风险。即使某个节点出现故障，Kubernetes能够迅速启动副本或进行自我修复，确保服务不中断。

  5. 迁移与部署：K8S集群能够实现StarRocks服务的快速迁移与部署，极大地提高了系统的灵活性和可扩展性。当需要进行系统升级或环境迁移时，K8S能够迅速将StarRocks服务迁移到新的环境中，确保业务不受影响。

2.挑战

  1. 运维复杂度增加：运维人员不仅要熟悉Kubernetes的运维知识，还要精通StarRocks和Hive的运维要点。例如，在处理故障时，运维人员需要迅速判断是K8S资源调度问题、StarRocks计算节点故障还是Hive元数据异常，这需要对各个组件有深入的理解和丰富的实践经验。

  2. 更完善的配套功能：对于KS8集群，需要进一步完善与之相关的一系列功能，包括但不限于监控体系的优化、日志采集的规范化、访问记录的详细化以及权限安全的强化等。例如，当前错误日志通过K8S内部域名返回的方式，给日志的查看以及问题的排查带来了诸多不便。因此，有必要将所有类型的日志统一输出到一个易于访问和操作的平台。

作者简介

图片

招聘信息

Java、大数据、前端、测试等各种技术岗位热招中，欢迎了解~

更多福利请关注官方订阅号信也科技拍黑米、拍码场

喜欢请点击↓↓↓

继续滑动看下一个
信也科技拍黑米
向上滑动看下一个