关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 #436

Handikang · 2025-01-10T03:31:14Z

Issue Type

Others

Have you searched for existing issues?

Yes

Link to Relevant Documentation

No response

Question Details

kuscua版本：0.8.0b0
scql版本：0.9.2b1

按照官方提供的https://www.secretflow.org.cn/zh-CN/docs/kuscia/v0.9.0b0/tutorial/run_scql_on_kuscia_cn
和https://www.secretflow.org.cn/zh-CN/docs/scql/0.9.2b1/topics/deployment/run-scql-on-kuscia
两个连接我将scql部署在了kuscia中，目前仅是单节点自查单表的sql
下面是对应的操作以及结果：
# 在容器内执行示例
export CTR_CERTS_ROOT=/home/kuscia/var/certs
curl -k -X POST 'https://localhost:8082/api/v1/domaindatasource/create' \
 --header "Token: $(cat ${CTR_CERTS_ROOT}/token)" \
 --header 'Content-Type: application/json' \
 --cert ${CTR_CERTS_ROOT}/kusciaapi-server.crt \
 --key ${CTR_CERTS_ROOT}/kusciaapi-server.key \
 --cacert ${CTR_CERTS_ROOT}/ca.crt \
 -d '{
  "domain_id": "com2023011620072311738",
  "datasource_id":"scql-demo-local-datasource",
  "type":"mysql",
  "name": "DemoDataSource",
  "info": {
      "database": {
          "endpoint": "10x.28.5.09:3306",
          "user": "root",
          "password": "123456",
          "database":"alice"
      }
  },
  "access_directly": true
}'


export CTR_CERTS_ROOT=/home/kuscia/var/certs
curl -k -X POST 'https://localhost:8082/api/v1/domaindata/create' \
 --header "Token: $(cat ${CTR_CERTS_ROOT}/token)" \
 --header 'Content-Type: application/json' \
 --cert ${CTR_CERTS_ROOT}/kusciaapi-server.crt \
 --key ${CTR_CERTS_ROOT}/kusciaapi-server.key \
 --cacert ${CTR_CERTS_ROOT}/ca.crt \
 -d '{
  "domain_id": "com2023011620072311738",
  "domaindata_id": "scqltable2",
  "datasource_id": "scql-demo-local-datasource",
  "name": "alice001",
  "type": "table",
  "relative_uri": "alice.user_credit",
  "columns": [
    {
      "name": "ID",
      "type": "str"
    },
    {
      "name": "credit_rank",
      "type": "int"
    },
    {
      "name": "income",
      "type": "int"
    },
    {
      "name": "age",
      "type": "int"
    }
  ]
}'


curl -X POST http://127.0.0.1:80/intra/project/create \
--header "host: scql-broker-intra.com2023011620072311738.svc" \
--header "kuscia-source: com2023011620072311738" \
-d '{
    "project_id":"demo2",
    "name":"demo2",
    "conf":{
        "spu_runtime_cfg":{
        "protocol":"SEMI2K",
        "field":"FM64"
        }
    },
   "description":"this is a project"
}'


curl -X POST http://127.0.0.1:80/intra/table/create \
--header "host: scql-broker-intra.com2023011620072311738.svc" \
--header "kuscia-source: com2023011620072311738" \
-H "Content-Type: application/json" \
-d '{
    "project_id": "demo2",
    "table_name": "ta",
    "ref_table": "scqltable2",
    "db_type": "mysql",
    "columns": [
        {"name":"ID","dtype":"string"},
        {"name":"credit_rank","dtype":"int"},
        {"name":"income","dtype":"int"},
        {"name":"age","dtype":"int"}
    ]
}'


curl -X POST http://127.0.0.1:80/intra/ccl/grant \
--header "host: scql-broker-intra.com2023011620072311738.svc" \
--header "kuscia-source: com2023011620072311738" \
-H "Content-Type: application/json" \
-d '{
    "project_id": "demo2",
    "column_control_list":[
    {"col":{"column_name":"ID","table_name":"ta"},"party_code":"com2023011620072311738","constraint":1},
    {"col":{"column_name":"age","table_name":"ta"},"party_code":"com2023011620072311738","constraint":1},
    {"col":{"column_name":"income","table_name":"ta"},"party_code":"com2023011620072311738","constraint":1},
    {"col":{"column_name":"credit_rank","table_name":"ta"},"party_code":"com2023011620072311738","constraint":1}
    ]
}'


curl -X POST http://127.0.0.1:80/intra/query \
--header "host: scql-broker-intra.com2023011620072311738.svc" \
--header "kuscia-source: com2023011620072311738" \
-H "Content-Type: application/json" \
-d '{
    "project_id": "demo2",
    "query":"SELECT * from ta;"
}'


下面是对应结果
curl -X POST http://127.0.0.1:80/intra/query \
--header "host: scql-broker-intra.com2023011620072311738.svc" \
--header "kuscia-source: com2023011620072311738" \
-H "Content-Type: application/json" \
-d '{
    "project_id": "demo2",
    "query":"SELECT * from ta;"
}'
{"status":{"code":320, "message":"RunExecutionPlan run jobs(fb626e58-cf02-11ef-a085-d2a244c564e6) failed, catch std::exception=[engine/datasource/odbc_adaptor.cc:44] catch unexpected Poco::Data::DataException: MySQL: [MySQL]: [Comment]: mysql_stmt_prepare error\t[mysql_stmt_error]: Table 'alice.scqltable2' doesn't exist\t[mysql_stmt_errno]: 1146\t[mysql_stmt_sqlstate]: 42S02\t[statemnt]: select scqltable2.ID,scqltable2.age,scqltable2.credit_rank,scqltable2.income from scqltable2;", "details":[]}, "result":null}



我的疑问是，通过kusciadatamesh路由到的数据源为什么没能找到ta对应的表alice.user_credit，而是通过kuscia中的domaindata去查

zimu-yuxi · 2025-01-10T06:18:30Z

mysql数据源ref_table使用alice.user_credit尝试下

tyrone-yu · 2025-01-10T06:34:31Z

curl -X POST http://127.0.0.1:80/intra/table/create \
--header "host: scql-broker-intra.com2023011620072311738.svc" \
--header "kuscia-source: com2023011620072311738" \
-H "Content-Type: application/json" \
-d '{
    "project_id": "demo2",
    "table_name": "ta",
    "ref_table": "scqltable2",
    "db_type": "mysql",
    "columns": [
        {"name":"ID","dtype":"string"},
        {"name":"credit_rank","dtype":"int"},
        {"name":"income","dtype":"int"},
        {"name":"age","dtype":"int"}
    ]
}'

这里 ref_table 必须是物理表名，所以用 kuscia 的时候，kuscia 里面注册的表名要和原始的表名一致。目前只能这么使用，可能文档说明不是很清楚。

Handikang · 2025-01-10T06:46:14Z

感谢回复，我这边重试一下

Handikang · 2025-01-10T07:09:46Z

我这边再创建表阶段ref_table引用的是alice.user_credit就报kuscia那边没有这个domaindata了，所以这边就很奇怪

tyrone-yu · 2025-01-10T08:11:44Z

我这边再创建表阶段ref_table引用的是alice.user_credit就报kuscia那边没有这个domaindata了，所以这边就很奇怪

注册 domaindata 的时候的 domaindata_id 也要改下，改成 alice.user_credit
SCQL 的逻辑是根据你提供的 query 找到对应 create table 的时候的 ref table，如果你用的是 kuscia 则用这个 ref table 去查询对应的 domaindata，所以 domaindata 要和 ref table 一致，也要和实际数据库里的表名一致

Handikang · 2025-01-10T08:19:41Z

这个我也试过了，由于创建domaindata这种命名方式（alice.usercredit）不被允许，所以这种我也没跑通。

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2025年1月10日(周五) 下午4:12 收件人: ***@***.***>; 抄送: "Han ***@***.******@***.***>; 主题: Re: [secretflow/scql] 关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 (Issue #436) 我这边再创建表阶段ref_table引用的是alice.user_credit就报kuscia那边没有这个domaindata了，所以这边就很奇怪注册 domaindata 的时候的 domaindata_id 也要改下，改成 alice.user_credit SCQL 的逻辑是根据你提供的 query 找到对应 create table 的时候的 ref table，如果你用的是 kuscia 则用这个 ref table 去查询对应的 domaindata，所以 domaindata 要和 ref table 一致，也要和实际数据库里的表名一致 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

tyrone-yu · 2025-01-10T08:21:37Z

这个我也试过了，由于创建domaindata这种命名方式（alice.usercredit）不被允许，所以这种我也没跑通。
…
---原始邮件--- 发件人: @.> 发送时间: 2025年1月10日(周五) 下午4:12 收件人: @.>; 抄送: "Han @.@.>; 主题: Re: [secretflow/scql] 关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 (Issue #436) 我这边再创建表阶段ref_table引用的是alice.user_credit就报kuscia那边没有这个domaindata了，所以这边就很奇怪注册 domaindata 的时候的 domaindata_id 也要改下，改成 alice.user_credit SCQL 的逻辑是根据你提供的 query 找到对应 create table 的时候的 ref table，如果你用的是 kuscia 则用这个 ref table 去查询对应的 domaindata，所以 domaindata 要和 ref table 一致，也要和实际数据库里的表名一致 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

发一下你创建的时候 curl 命令，理论上不应该出现这种情况

Handikang · 2025-01-10T08:22:22Z

好的，这边是对应的结果，您看下

tyrone-yu · 2025-01-10T08:38:37Z

好的，这边是对应的结果，您看下

记错了 domaindata_id 要从 alice.usercredit 改成 usercredit

Handikang · 2025-01-10T08:43:50Z

好的，这边我之后再试下，辛苦😁，这下应该没问题了

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2025年1月10日(周五) 下午4:39 收件人: ***@***.***>; 抄送: "Han ***@***.******@***.***>; 主题: Re: [secretflow/scql] 关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 (Issue #436) 好的，这边是对应的结果，您看下记错了 domaindata_id 要从 alice.usercredit 改成 usercredit — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

Handikang · 2025-01-21T13:43:42Z

您好，我这边还是像请教下SCQL run in kuscia中出现的问题：在邀请的时候报的错，但是其实两方通信是没问题的

kuscia版本是最新的，SCQL版本是0.7.0b1 @tyrone-yu

zimu-yuxi · 2025-01-23T07:12:09Z

参考这里，提供下相关日志

Handikang · 2025-01-23T07:21:16Z

下面是engine的日志

这里面只有broker有报错，莫名其妙的错误 @zimu-yuxi

jingshi-ant · 2025-01-23T07:47:34Z

check下受邀请方的broker是否有报错，之前邀请有成功过吗？
测试broker之间网络是否可达，可以curl http://scql-broker-inter.{节点id}.svc

Handikang · 2025-01-23T08:15:36Z

我在kuscia中没有邀请成功过
下面是对应broker之间通信curl的结果

但是两边路由其实是没问题的 @jingshi-ant

jingshi-ant · 2025-01-23T08:27:06Z

用最新版的kuscia、scql镜像试试看？文档里的配置和实际镜像版本不match也可能导致异常。
另外：如果broker服务拉起来了之后，http://scql-broker-inter.{节点id}.svc 一定是可访问的，http://scql-broker-intra.{节点id}.svc 类似

jingshi-ant · 2025-01-23T08:56:12Z

update：我在测试环境里验证了下curl远端参与方broker服务的指令以及输出，供参考：
curl scql-broker-inter.bob.svc/inter/project/invite -d '{}'
会有如下的输出：{"status":{"code":101, "message":"failed to query kuscia domain xxx

Handikang · 2025-01-23T09:19:20Z

为啥我没有任何反应用相同的操作

但是可以ping同这个svc

有没有可能和这个端口没有放开到宿主机有关

jingshi-ant · 2025-01-23T09:25:34Z

确认两边的broker都是正常拉起的吗？在两边都看下服务状态（curl后会有日志），以及check下服务是否可达。
如果没有其它线索的话，建议更新下镜像版本。

Handikang · 2025-01-23T09:42:24Z

两边都是正常拉起的，而且SCQL和kuscia都是最新的版本

我以为是domianroute的问题，我删掉了之前的route,重新创建后状态如下，是进行创建host的时候要写对端ip还是要写对端kuscia容器的名字,我看好像cdr状态是false

我按照最新版本创建route的接口进行创建的

jingshi-ant · 2025-01-23T09:47:39Z

cdr的创建问题建议在kuscia repo里咨询。现在看起来是kuscia节点的router问题？

Handikang · 2025-01-23T10:09:51Z

不是router的问题，我以为是router的问题，换了新版本也是报错，而且curl scql-broker-inter.bob.svc/inter/project/invite -d '{}'对端broker也是没有日志,而且我发现这个命令好像domainid不是对端的也一样的结果

jingshi-ant · 2025-01-23T11:03:51Z

broker没有日志，应该是没正常收到请求导致的。没太get到你为什么要curl bob/crd。你的两个kuscia节点应该是com开头的？你可以试试分别在两个kuscia节点里curl这两个svc：curl scql-broker-inter.com2023xxx.svc/inter/project/invite -d '{}'，预期应该都会有broker的日志。
不过你的环境可能curl对端有问题。（请求发不出去）

Handikang · 2025-01-23T11:15:19Z

broker对端确实是没有有关curl的日志，但是其他接口调用是没问题的（创建表，授权CCL等），只是邀请对端会有问题

yushiqie · 2025-01-24T02:40:07Z

broker对端确实是没有有关curl的日志，但是其他接口调用是没问题的（创建表，授权CCL等），只是邀请对端会有问题

创建表，授权CCL 不需要对端 broker 参与，可以先检查一下对端的 broker 应用服务状态是否是正常的

Handikang · 2025-01-24T03:20:43Z

对端服务状态是没问题的，但是感觉问题出在broker的inter服务没有成功拦截到对端发起的邀请请求，下面是broker在kuscia中的日志，调自己这边不涉及到对端的接口是会有响应日志的，但是调inter的接口一点反应也没有，但我看服务没啥问题，感觉可能是没有请求到的原因，我看对内（22485）和对外（22486）的端口都没问题，这边有其他测试inter服务状态的方法么

yushiqie · 2025-01-24T06:12:56Z

可以截图两边 broker pod 状态，以及 scql-broker-inter 详情

pod 状态：kubectl -n xxx get po [broker 名称]
service详情：kubectl -n xxx get svc scql-broker-inter -oyaml
endpoint 详情：kubectl -n xxx get ep scql-broker-inter -oyaml
查看对端 kuscia 的网关 external.log 日志，看是否接收到请求发起方的 invit 请求，日志查看具体请参照 https://www.secretflow.org.cn/zh-CN/docs/kuscia/v0.13.0b1/deployment/logdescription#id3

Handikang · 2025-02-10T02:25:46Z

主动方发起邀请的报错（comxxx7797是发起邀请的domainid,comxxx1738是被邀请方的domainid）

被邀请方网关 external.log如下

主动方的endpoint详情

被邀请方的endpoint详情

还请各位老师看下问题出在了哪里 @yushiqie

wangzul · 2025-02-11T02:35:53Z

方便提供一下

主动方发起邀请的报错（comxxx7797是发起邀请的domainid,comxxx1738是被邀请方的domainid）被邀请方网关 external.log如下主动方的endpoint详情被邀请方的endpoint详情

还请各位老师看下问题出在了哪里 @yushiqie

kubectl get svc -A |grep "scql" 看下Service配置。

Handikang · 2025-02-11T02:55:55Z

好的，这是我的一些截图，我初步猜测可能是dns解析scql-broker-inter.com2023011620072311738.svc的ip和实际inter服务的endpoint不一致导致的，您看下是这个原因吗，我想给inter service手动配置一个ip但是可能因为被deployment管理了，不太好修改 @wangzul

wangzul · 2025-02-11T06:53:17Z

comxxx7797这一侧能访问到吗？提示404是不是你的节点无法访问到这个地址。

Handikang · 2025-02-11T07:40:03Z

comxxx7797这一侧也是不行的，两边都是一样的反应，是的，按照教程上就是没能访问到对端的broker @wangzul

wangzul · 2025-02-11T09:16:02Z

执行kubectl get kd -A 看下双方的scql broker应该有一方没有启动起来。
你可以确定一下

补充后可正常执行

Handikang · 2025-02-11T09:32:34Z

comxxx7797对应的appimage配置

comxxx7797对应的kd配置

comxxx1738对应的appimage配置

comxxx1738对应的kd配置

两边appimage状态都是正常的，都是可用

Handikang · 2025-02-11T12:33:11Z

补充信息：

下面是触发404被邀请方k3s日志

下面是触发404被邀请方kuscia日志

下面是触发404发起邀请方k3s日志

下面是触发404发起邀请方kuscia日志

yushiqie · 2025-02-13T09:05:55Z

从被邀请方的网关external.log，说明被邀请方已经接收到了邀请方发来的请求。你直接在邀请方以及被邀请方 curl -kv http://sql-broker-inter. comxxx1738.svc/inter/project/invite，看看分别输出什么信息

Handikang · 2025-02-13T09:15:07Z

辛苦各位老师的回复和解答，我这边问题已经解决了，最终发现问题的根源是我通过kusciadeploymenet部署的时候同时部署了broker和engine导致这边邀请报404，详情如下图（我已经反复验证过原因就是这个）

我困惑的是，为什么broke和engine不能同时部署在一个kusciadeploymenet中

tongke6 assigned tyrone-yu Jan 10, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 #436

关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 #436

关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 #436

关于SCQL run in kuscia中使用kusciadatamesh的一些疑问 #436

Comments

Issue Type

Have you searched for existing issues?

Link to Relevant Documentation

Question Details