将模型转为NNIE框架支持的wk模型第一步:tensorflow->caffe

摘要:本系列文章旨在分享tensorflow->onnx->Caffe->wk模型转换流程,主要针对的是HI3516CV500, Hi3519AV100 支持NNIE推理框架的海思芯片的算法工程落地。

本文分享自华为云社区《将模型转为NNIE框架支持的wk模型——以tensorflow框架为例(一)》,原文作者:wwwyx_*^▽^*  。

使用过NNIE框架的同学都知道,NNIE框架只支持wk模型的推理。

实际使用过程中用海思提供的转换软件工具 RuyiStudio 将 caffe 1.0 模型转为wk。一般情况下如果购买了芯片,海思将会直接将相关的SDK包发送给客户,如果没有的话,大家可以从这个链接获取:RuyiStudio

从上面可知,最终需要将别的框架模型转为caffe才可以使用RuyiStudio,目前主流框架包含pytorch、tensorflow、mxnet等,关于pytorch转caffe之前已经有大佬写过了pytorch->caffe,有需要的同学可以去看下。本文主要讲述tensorflow框架转为caffe可能会遇到的问题以及解决方法。mxnet有直接的接口可以转onnx,也可以参考这篇文章做caffe转换。

下面进入正题。

tensorflow->caffe

这个真的是个大坑(哭泣),这里我使用了中间模型onnx,即最终成功转换的路径是 pb->onnx->caffe->wk,下面就说一下具体的操作吧~

第一步:tensorflow->onnx

这一步是最简单的一步= =,目前转了一些模型还没有在这里遇到坑。
使用github上的开源项目:tensorflow->onnx,直接使用pip install 安装后使用。

关注一下都有哪些参数,每个参数的作用,主要是输入、输出、推理使用nchw还是nhwc(caffe框架为nchw,所以这里都使用nchw)、opset(默认使用 9 ),很多的参数我没有使用到,大家有疑问可以直接去issues上面看下哈。

下面给出一个转换命令供大家参考下:

python -m tf2onnx.convert --input ./model.pb --inputs input_image:0[1,112,112,3] --inputs-as-nchw input_image:0 --outputs output_0:0,output_1:0,output_2:0,output_3:0,output_4:0 --output ./convert.onnx

得到onnx模型之后,可以使用onnx simplifer将一些零散算子合并,或者将一些冗余算子去除,这个工具视情况使用。

python -m onnxsim input_onnx_model output_onnx_model

转换为onnx之后,需要验证输出的结果是否与pb一致,一致后再走后面的流程!!

第二步:onnx->caffe

这里已经得到了onnx模型,但是距离成功还有99%的路要走!!

这一小节Baseline:onnx2caffe

环境: caffe 1.0 + onnx 1.8.0

主要功能代码:

onnx2caffe

+-- onnx2caffe

|   +-- _operators.py

|   +-- _weightloader.py

+-- convertCaffe.py

+-- MyCaffe.py

运行命令:

python convertCaffe.py ./model/MobileNetV2.onnx ./model/MobileNetV2.prototxt ./model/MobileNetV2.caffemodel

在转换过程中如果遇到了问题,可以从下面几个方面来适配,

(1)遇到caffe与NNIE不支持的算子,可以修改onnx模型中的node以适配caffe(这里要发动自己的小脑筋,一些算子替换可以参考一下pytorch->caffe这篇博客)。
(2)如果遇到了NNIE与onnx支持的算子,但是caffe 1.0 官方不支持的话,可以在caffe中添加新的层,重新编译之后,再做转换。caffe中添加新的层可以参考:caffe 添加新node

(3)caffe与NNIE都支持的算子,但是转换工具没有支持该算子的转换,在转换代码中添加相应的算子实现。
(4)转换过程中算子转换成功,但是出现了shape问题,手动添加一些不需要参数的操作在已经生成的prototxt中。

针对上面的每个方法给出对应的解决方式。

修改onnx模型中的node以适配caffe

改写onnx模型,首先需要了解一下onnx都支持哪些算子。

onnx支持的op:onnx op

更换模型中的操作时,查看该node的输入输出模式,按照格式对模型进行改写。onnx模型改写涉及多种情况,下面介绍几种常用的方法。

1.关于node的改写有时需要已知其输入输出size,故一开始先准备一个包含每个node输入输出的onnx模型。

import onnx.helper as helper
from onnx import shape_inference, TensorProto
import onnxruntime
import onnx

def add_input_output_from_onnx(onnx_path, save_path):
    ONNX_DTYPE = {
        0: TensorProto.FLOAT,
        1: TensorProto.FLOAT,
        2: TensorProto.UINT8,
        3: TensorProto.INT8,
        4: TensorProto.UINT16,
        5: TensorProto.INT16,
        6: TensorProto.INT32,
        7: TensorProto.INT64,
        8: TensorProto.STRING,
        9: TensorProto.BOOL
    }

    # load model
    onnx_model = onnx.load(onnx_path)
    graph = onnx_model.graph

    # rewrite the input tensor of graph
    input_tensor = graph.input[0]
    input_shape = input_tensor.type.tensor_type.shape.dim
    input_tensor_new = onnx.helper.make_tensor_value_info(name = input_tensor.name, elem_type = 1,
                                                          shape = [1, input_shape[1].dim_value, input_shape[2].dim_value, input_shape[3].dim_value])
    graph.input.remove(input_tensor)
    graph.input.insert(0, input_tensor_new)

    # append all tensor infos to graph input
    weight_infos = []
    tensors = graph.initializer
    for i, tensor in enumerate(tensors):
        value_info = helper.make_tensor_value_info(tensor.name, ONNX_DTYPE[tensor.data_type], tensor.dims)
        weight_infos.append(value_info)
        graph.input.insert(i+1, value_info) # because 0 is for placeholder, so start index is 1

    # run node shape inference
    node = graph.node
    value_info = graph.value_info
    inferred_onnx_model = shape_inference.infer_shapes(onnx_model)
    onnx.checker.check_model(onnx_model)
    inferred_graph = inferred_onnx_model.graph
    inferred_value_info = inferred_graph.value_info
    onnx.save(inferred_onnx_model,save_path)
    return

使用netron打开onnx模型,查看添加size之后的变化:

添加node的输入输出size

2.遇到caffe与NNIE不支持的算子,删除onnx模型中的node,将相关操作在外部的预处理阶段进行。这种情况只涉及onnx模型中已经存在的节点删除与改变已有边连接的关系,不涉及新的边关系的建立。

` 这里使用graph中node的index来访问node
  该代码删除graph node 0,1,2
  并且修改node 3的input边
  即   input_image --> mul_1 --> sub --> mul --> conv1
  变为 input_image --> conv1
`
def delete_node(onnx_path, save_path):
    onnx_model = onnx.load(onnx_path)
    graph = onnx_model.graph
    Mul_1 = graph.node[0]
    sub = graph.node[1]
    mul = graph.node[2]

    conv1 = graph.node[3]
    conv1.input[0] = Mul_1.input[0]

    graph.node.remove(Mul_1)
    graph.node.remove(sub)
    graph.node.remove(mul)

    onnx.checker.check_model(onnx_model)
    onnx.save(onnx_model, save_path)

3.更改caffe与NNIE不支持的算子,修改onnx模型中的node去适配。如 squeeze 算子,squeeze算子在onnx->caffe的时候会报错,这时可以将onnx模型中的squeeze替换为reshape算子。reshape需要两个输入,而squeeze只对应一个输入,这时需要在graph中创建一个新的常数tensor input。这种情况涉及更换已经存在的node,新的常数tensor的加入,但并不涉及新的边关系的建立。

`查看onnx op的操作,reshape需要两个输入
对于reshape需要将一个shape tensor加入到onnx graph中,
tensor size可以查看第一步生成的onnx model中该squeeze node对应的output size

即   input --> squeeze --> output
变为 input --> reshape(shape) --> output`
def remove_headpose_squeeze_node(onnx_path, save_path):
    onnx_model = onnx.load(onnx_path)
    graph = onnx_model.graph
    ## 添加常数 input
    shape = onnx.helper.make_tensor('shape', onnx.TensorProto.INT64, [2], [1,3])
    graph.initializer.append(shape)
    for i in range(len(graph.node)):
        if graph.node[i].op_type == "Squeeze":
            reshape_node_def = helper.make_node(
                        'Reshape', # node name
                        inputs=[graph.node[i].input[0], 'shape'], # inputs
                        outputs=[graph.node[i].output[0]], # outputs
                        name = graph.node[i].name
                    )
            graph.node.remove(graph.node[i])
            graph.node.insert(i, reshape_node_def)

    onnx.checker.check_model(onnx_model)
    onnx.save(onnx_model, save_path)

4.caffe不支持div算子,可以将div算子转为pow+mul。这种情况涉及将一个node更换为两个,新的常数tensor的加入,以及新的边连接关系。

div 操作: z = x / y

更换为 pow + mul, pow为幂操作,mul为乘法操作:

temp = pow(y, -1)
z = temp * x

`

即:

input_x    input_y

 \\   //

  \\ //

   div

更改为:

input_x         input_y

 \\         //

  \\       //

   \\      pow(常数tensor作为指数输入)

    \\    //

     \\  //  --> (新的边)

      mul

`

def change_headpose_div_node(onnx_path, save_path):

    onnx_model = onnx.load(onnx_path)

    graph = onnx_model.graph

    pow_scale = onnx.helper.make_tensor('pow_scale', onnx.TensorProto.FLOAT, [3], [-1.0, -1.0, -1.0])

    mul12_output = helper.make_tensor_value_info('pred_pose/mul_12_pow_output:0', onnx.TensorProto.FLOAT, [1, 3])

    graph.initializer.append(pow_scale)



   # 'pred_pose/mul_12:0' 类似于上图中的input_y

   #  pow_scale 为上面创建的相应的指数tensor

   # 'pred_pose/mul_12_pow_output:0' 为新建的output tensor

   #  pow name 给一个不与图中node重复的name

    mul12_pow_node_def = helper.make_node(

        'Pow', # node name

        inputs=['pred_pose/mul_12:0', 'pow_scale'], # inputs

        outputs=['pred_pose/mul_12_pow_output:0'], # outputs

        name = 'pred_pose/mul_12_pow'

    )

    graph.node.insert(len(graph.node), mul12_pow_node_def)



    for i in range(len(graph.node)):

        if graph.node[i].name == "pred_pose/truediv_3":

            input1 = graph.node[i].input[0]

            input2 = graph.node[i].input[1]

            output = graph.node[i].output[0]

            name = graph.node[i].name

            pow_node_def = helper.make_node(

                'Mul', # node name

                inputs=[input1, mul12_pow_node_def.output[0]], # inputs

                outputs=[output], # outputs

                name = name

            )

            print(graph.node[i].name, i)

            graph.node.remove(graph.node[i])

            graph.node.insert(i, pow_node_def)

            break



    graph = helper.make_graph(graph.node, graph.name, graph.input, graph.output, graph.initializer)

    info_model = helper.make_model(graph)

    model = onnx.shape_inference.infer_shapes(info_model)

    onnx.save(model, save_path)

经过这个修改之后,使用netron查看node边关系,看是否正确。

5.打印onnx中间某个节点的输出,需要在graph加一个output tensor。

def add_outputNode_info(onnx_path, add_name, output_size, save_path):
    onnx_model = onnx.load(onnx_path)
    graph = onnx_model.graph
    prob_info =  helper.make_tensor_value_info(add_name,onnx.TensorProto.FLOAT, output_size)
    graph.output.insert(0, prob_info)
    onnx.save(onnx_model, save_path)
    return

if __name__ == '__main__':
    onnx_model = './model.onnx'
    add_node_path = "./addPreprocessOutput.onnx"
    # "mul:0": 想要输出node的output name
    # [1,24,14,14]: 想要输出node的output size
    add_outputNode_info(onnx_model, "mul:0", [1,24,14,14], add_node_path)

上面的例子已经将大部分node修改的情况涵盖了,修改onnx模型可以参考上述代码。

小tips:Reshape大法好,各种跟维度有关系的都可以用reshape来代替,除此之外,transpose也是网红node,具体问题具体分析~

 

在转换代码中添加相应的算子实现

在caffe中添加新的层没什么好说的,按照上面给的链接来就可以,这里主要介绍下如何修改转换代码去适配某个模型转换。经过上面修改onnx模型这一步,我们已经将onnx模型中的node全部换为caffe与NNIE支持的算子了,但这时onnx2caffe可能还会出现问题,下面会从不同的情况做onnx2caffe代码适配来逐步完成模型转换。

1.caffe和NNIE都支持某个操作,但是onnx2caffe模型转换时报错。

如:TanH操作,从源码/caffe/src/caffe/layers/中看到有tanh层的实现,NNIE也支持该操作,但是转换报错。查看onnx2caffe源码发现没有TanH的转换实现,这时需要我们添加相应的转换代码,主要修改_operators.py、_weightloader.py两个文件,下面以TanH为例讲解一下怎么增加转换node。

_operators.py 文件用来实现onnx操作到Caffe操作的变换。对于TanH的适配,首先需要在文件的最后注册算子模块添加TanH,然后增加转换代码。

`转换代码:`

def _convert_tanH(node,graph,err):

    input_name = str(node.inputs[0])

    output_name = str(node.outputs[0])

    name = str(node.name)

    layer = myf("TanH",name,[input_name],[output_name])

    graph.channel_dims[output_name] = graph.channel_dims[input_name]

    return layer

   

`添加注册算子:`

_ONNX_NODE_REGISTRY = {

    ……

    "Tanh": _convert_tanH,

}

_weightloader.py 文件用来实现node参数从onnx到Caffe的传递。第一步也是在文件末尾添加注册算子,添加同_operators.py。第二步,从 caffe.proto 中查看tanh操作是否存在weight:

message TanHParameter {

  enum Engine {

    DEFAULT = 0;

    CAFFE = 1;

    CUDNN = 2;

  }

  optional Engine engine = 1 [default = DEFAULT];

}

由于tanh操作不存在weight,所以onnx到caffe的参数传递为空:

def _convert_tanH(net, node, graph, err):

    pass

至此,在onnx2caffe中添加tanh操作就完成了,具体工程就包含修改上面两个文件夹,主要是注册算子、操作转换的实现、weight值传递。

2.caffe和NNIE都支持某个操作,onnx2caffe也支持该操作,但是操作中有一个输入在模型中被写为weight,与原来的实现不一致。

如: mul算子,普通的mul算子一般都包含两个输入,模型中可能会存在mul算子只有一个输入,另一个输入作为weight参数,如下所示:

mul的两种输入形式

这种情况下,由于已经存在了mul的注册算子,我们只需要在mul算子转换的时候新加一个分支来实现就可以了,还是只涉及两个文件的改写。

_operators.py 添加分支代码

def _convert_input1_is_weight_mul(node,graph,max_dim, err):

    node_name = node.name

    `这里的input_name需要在netron视图中观察一下是哪一个input作为外部输入,这里不能写 weight 的输入名称!`

    input_name = str(node.inputs[0])

    output_name = str(node.outputs[0])

    scale_layer = myf("Scale", node_name, [input_name],[output_name],in_place=False,bias_term=False)

    graph.channel_dims[output_name] = max_dim

    return scale_layer

def _convert_Mul(node,graph,err):

    input_name_list = [str(i) for i in node.inputs]

    output_name = str(node.outputs[0])

    node_name = node.name



    `这里使用node_name 判断mul算子是否是一个input,新增只有一个input的分支`

    if node_name == "mul_1":

        max_dim = 16

        return _convert_input1_is_weight_mul(node,graph,max_dim, err)



    ···

    ···

_weightloader.py 也不需要重新注册,直接添加分支代码

def _convert_input1_is_weight_mul(net, node, graph, err):

    node_name = node.name



    ` 注意!!

      scale = np.ones(3) * 3.0

      对应的是 外部输入size =(1,3), weight size = (1),

      这种情况可以借助 numpy 实现weight与外部输入的channel对齐



      这里还有另外一种情况,例如 外部输入 size = (1,128,8,8), weight = (1,128,1,1)

      可以这样操作:scale = node.input_tensors[node.inputs[1]]

                   scale = np.reshape(scale, scale.shape[1])

     `



    scale = np.ones(3) * 3.0

    np.copyto(net.params[node_name][0].data, scale, casting='same_kind')



`mul本身是没有weight的,所以之前就是直接pass`

def _convert_Mul(net, node, graph, err):

    node_name = node.name

    if node_name == "mul_1":

        _convert_input1_is_weight_mul(net, node, graph, err)

    else:

       pass

实际转换过程中,add算子也会出现上面的情况,其中有一个输入作为算子参数,这时可以把其类比到 _convert_BatchNorm 中的scale操作,将scale的weight视为1,bias为add算子的内部输入参数,可以参照BatchNorm修改代码,这里就不详细写了。

 

转换过程中算子转换成功,但是出现了shape问题,手动修改prototxt

上面介绍的是算子的适配,但有时通过onnx2caffe转换代码之后,已经生成了prototxt文件,最终报错 feature map 的 shape 不匹配,由于onnx2caffe工具在转换的时候就打印出了每一层的output,通过与netron视图对比,定位第一个出现问题的node。

onnx2caffe转换输出log
知己知彼方能百战百胜,为了定位shape为什么不一致,我们先要了解一下不同框架的padding策略以及相应的output size的计算方法。

  • 查看caffe的output size计算方式,根据代码可得:
    output_size=floor((w+2*pad-(d(k-1)+1))/s)+1
template <typename Dtype>
void ConvolutionLayer<Dtype>::compute_output_shape() {
    const int* kernel_shape_data = this->kernel_shape_.cpu_data();
    const int* stride_data = this->stride_.cpu_data();
    const int* pad_data = this->pad_.cpu_data();
    const int* dilation_data = this->dilation_.cpu_data();
    this->output_shape_.clear();
    for (int i = 0; i < this->num_spatial_axes_; ++i) {
      // i + 1 to skip channel axis
      const int input_dim = this->input_shape(i + 1);
      const int kernel_extent = dilation_data[i] * (kernel_shape_data[i] - 1) + 1;
      const int output_dim = (input_dim + 2 * pad_data[i] - kernel_extent)/ stride_data[i] + 1;
      this->output_shape_.push_back(output_dim);
    }
}
  • tensorflow的padding策略可根据这篇博客,结合上面caffe的output size计算,感觉caffe的 conv padding 策略与tensorflow pad=VALID一致,会把不能参与的pixel自动去除不进行计算。

好了,了解了不同框架的padding策略以及output size的计算方式之后,我们来分析我们的模型,模型转换是这样的:

 

分析上面模型转换的表格参数:

  • tensorflow pad=SAME,为了使所有的input pixel都参与计算,tensorflow在推理时偷偷在input的右下补了一行0,这样最后的输出:
    output size = (112 - (1 * (3 - 1) + 1) + 1) / 2 + 1 = 56
    其中 (112 - (1 * (3 - 1) + 1) + 1) 斜体1表示偷偷补的0。
  • 对于onnx, 经过查询与实验,发现 pads 参数[0,0,1,1]表示 feature map 上面不补,左边不补,下面补一行 0,右边补一列,与tf一致,输出没有什么问题。
  • 转为caffe之后,caffe模型 conv pad 参数都为0,上下左右都不补,这时根据caffe的outputshape公式,最终计算结果为(1,3,55,55),直接去除input的最后一行和最后一列不参与计算。

为了使输出shape一致,并且计算结果相同,我采用了下面的解决方法。

caffe中设置 pad_h:2, pad_w:2。 由于caffe是设置pad参数之后是对称补0的,即input的上下左右都补了两行或者两列0,这时结合output_shape公式,最终输出的shape为:

output_shape = floor((112 + 2 * 2 - (1 * (3 - 1) + 1) + 1) / 2) + 1 = 57

思考一下conv原理,就知道此时caffe得到的feature map 只是比tf的多了最上面一行和最左边一列。稍微解释一下,虽然caffe设置pad=2,但是根据caffe的conv实现,会将右下比tf多补的那一行和那一列自动去除,不参与运算。这时feature map输出为(1,3,57,57), 为了得到正确结果,在prototxt文件的conv算子之后添加两个slice操作,去除最上面一行与最左边一列。

layer {

  name: "add_slice1"

  type: "Slice"

  bottom: "depthwise:0"

  top: "add_slice1/split:0"

  top: "add_slice1/split:1"

  slice_param {

    axis: 2

    slice_point: 1

  }

}



layer {

  name: "add_slice2"

  type: "Slice"

  bottom: "add_slice1/split:1"

  top: "add_slice2/split:0"

  top: "add_slice2/split:1"

  slice_param {

    axis: 3

    slice_point: 1

  }

}

上面就是针对caffe模型的适配,东西很多很杂,有时候需要一些新奇的思路才能解决问题,当然还涉及一些prototxt文件中算子param的修改,具体问题具体分析,这里就不展开讲了。

第三步:验证

将得到的caffe模型的输出结果与pb的输出结果进行对比,一般情况下应该是一模一样的,如果不一样主要关注一下 输入预处理,输出预处理,被修改的node之前的那个node的输出是不是OK(主要是定位是不是自己改的node的问题),切忌心浮气躁,掌握方法。每进行一次魔改都做一次推理,这样比较好定位。

 

总结

对于tf转caffe确实有一些麻烦,上面可能也只是列了万分之一的问题吧,不过希望可以帮助到大家。大家针对这方面什么好的想法希望可以多交流奥~

针对onnx模型的魔改可能是多余的,应该将相关的转换方式直接写进onnx2caffe的转换工具中会更加好,但是之前想着修改onnx会更简单些,之后希望可以有时间把转换工具修改的更通用一些

强烈要求算法同学训练模型之前先看下NNIE框架支持的算子类型!!具体参考《HiSVP 开发指南》5.3.2节支持的算子类型以及3.1.6.2每个算子支持的规格,避免模型转换不过去又要返工!!

 

点击关注,第一时间了解华为云新鲜技术~

相关推荐

鸿蒙案例上新啦 | 购物、听歌、健身:15个模板带你一键激活社交娱乐

页面层级如何组织、跨页共享状态如何同步、列表与详情及个人中心如何形成稳定闭环。鸿蒙开发实践中心将这些高频消费与互动场景沉淀为可参考的标准模板,提供从业务架构到界面实现的快捷实践入口。更多实战案例欢迎前往鸿蒙开发实践中心案例中心查看并开启云端体验。

华为云官方博客 338

鸿蒙案例上新啦 | 出门打车、到家上课:25个模板带你一屏打通日常生活

如何合理拆分页面组件、如何建立单一可信的状态源、如何让用户在每一步操作中都获得明确反馈。鸿蒙开发实践中心以标准化的应用与元服务模板为入口,将清晰的业务架构与可复用的代码结构直观呈现。不妨立即挑选一个感兴趣的方向进入云端环境,从页面布局、组件封装、状态管理到路由组织,亲手跑通你的鸿蒙实战项目。

华为云官方博客 324

LakeAgent:DWS数据仓库的第二大脑,告别 “翻译式运维”,迈入智能自治时代

和普通 SQL 改写工具不同,LakeAgent 自动做多方案代价对比,主动规避负优化陷阱:补充分区键过滤实现剪枝,扫描分区由 37 收敛至 1,执行代价从 758.28 降至 113.74;未来的数据仓库,将不止能算、能存,更能看懂自己、诊断自己、理解自己。长久以来,数仓的智能都依附于人:信号需要人解读,瓶颈需要人研判,经验困在个体里,无法随底座永续生长。CPU 高、CPU 告警、CPU 诊断、CPU 使用率过高、CPU 满。语法、错误码、计费、性能调优、最佳实践、故障处置等全场景内容。

华为云官方博客 555

如何使用RDS Supabase后端BaaS能力:文件存储(File Storage)

• product-images(公开桶,允许公共读取):策略名称"Public read for product-images",允许SELECT,目标角色anon,策略定义bucket_id = 'product-images'。上传/删除需另配INSERT/DELETE策略,详见SQL。• product-specs(私有桶,仅认证用户访问自己的文件夹):建议拆为上传、读取、删除三条策略,策略定义均为 bucket_id = 'product-specs' 且仅限本人文件夹(详见下文 SQL)。

华为云官方博客 476

如何使用RDS Supabase后端BaaS能力:实时订阅与推送(Realtime)

Realtime 把数据库的每次变更同步到客户端:表里增、删、改一行,订阅者无需刷新页面或主动请求即可秒级收到。三大能力各司其职:• Postgres Changes — 监听表的 INSERT/UPDATE/DELETE,变化即通知• Broadcast — 客户端之间直接互发,适合瞬时通知、协同编辑• Presence — 跟踪频道里“谁在线”典型场景有实时数据展示(订单、库存、监控指标即时刷新)、即时通讯(消息收发、在线名单、“对方正在输入”)、协同编辑与实时通知。

华为云官方博客 464

AI Agent如何通过MCP连接到华为云RDS Supabase应用平台

Schema元数据列出所有可访问的表(按schema分组)。Schema元数据列出表的列及元数据(类型/默认值/约束)。Schema元数据列出所有约束(PK/FK/UNIQUE/CHECK/EXCLUDE)。可按schema/表/类型过滤。Schema元数据列出所有外键关系。可按schema/表过滤。Schema元数据列出所有索引及定义和大小。可按schema/表过滤。Schema元数据列出已应用的数据库迁移记录。Schema元数据列出已安装的PostgreSQL扩展。

华为云官方博客 473

华为大数据Flink让每一 CU 算力,跑出开源 5.74 倍的性能

1. 开源Apache Flink 已成为业界流计算事实标准,但在极端重负载场景下存在性能瓶颈。2. 华为大数据Flink通过多项自研深度优化,在执行计划、算子执行、状态存储三个层面构建协同的优化体系。3. Nexmark Benchmark 测试结果:整体性能提升 5.74 倍,极端重负载场景性能领先最高 18.3 倍。4. 100% 兼容 Apache Flink 1.20,业务代码零改造,无缝迁移。

华为云官方博客 380

LakeAgent实战 | 业务分析篇从一句提问到业务分析

本文以“订单金额变化”分析为例,展示LakeAgent如何通过自然语言提问,结合DataArtsStudio的数据资产与专业技能,帮助业务人员快速定位数据、生成SQL、追踪血缘、生成报告。从问题出发,逐步实现数据发现、变化洞察、原因追溯与团队协作,最终形成可复用的分析流程与企业规则,显著提升数据分析效率与一致性。

华为云官方博客 389

华为云RDS Supabase AI应用已开放公测 :30分钟搭建AI应用后端

认证、存储、实时推送、数据库API——4个后端模块,传统开发需要数周。今天,你只需要30分钟。AI创业公司的全栈开发工程师。上周老板说"下周要上线的AI对话应用,后端你来搞"——认证鉴权、数据库接口、文件存储、实时推送,每一个模块都需要数周搭建,而市场不会等你。小张打开华为云RDS Supabase,30分钟搭好认证、数据库API、对象存储,剩下的时间全用来打磨AI交互体验。基于开源Supabase+华为云RDS PostgreSQL全托管能力,为开发者提供。

华为云官方博客 396

如何使用RDS Supabase后端BaaS能力:数据库函数(Database Function)

上一篇介绍了 Database Data API——建表即自动生成增删改查接口,解决单表读写,但聚合统计、跨表事务、字段自动维护等逻辑已超出其能力边界。本篇推进到数据库函数(Database Function):把业务逻辑封装进数据库,前端通过 .rpc() 调用,由触发器自动响应数据变更。上一篇中,小张基于 Data API 完成了产品目录的建表与基础读写。但新需求随之而来:按分类统计产品数与价格区间、上架新品同时写产品表与定价表、产品修改后自动刷新更新时间。

华为云官方博客 464

如何使用RDS Supabase后端BaaS能力:创表即生成API(Database Data API)

认证、存储、实时推送、数据库API——4个后端模块,传统开发要数周。本系列逐个拆解,首篇聚焦数据库API(Database Data API):建表即得 API,无需手写后端。小张,AI创业公司的全栈工程师。老板让他做个产品目录页,展示产品与价格、支持上下架。传统做法要搭后端、写接口、配权限,工期少说1-2周;而在华为云RDS Supabase,建两张表、应用 SDK 直连,几分钟增删改查全跑通。

华为云官方博客 478

从一句话到一个能出去的链接,AI开发者空间做了什么

自行搭建的 Agent、正在使用的开源项目、团队既有的工具,都可以接入,可以通过AI创建或者手动搭建环境;华为云 AI开发者空间——面向开发者的云端一站式开发平台,做的就是把这段路接上:环境免安装,浏览器打开即为完整的 Linux 运行环境,预置的 AI 智能体开箱即用。第一个任务建议选能出结果的:做一个游戏、生成一个页面、创建一台实例,从需求走到可访问的链接,一次就能看清这个环境在做什么。沙箱是一个完整的 Linux 环境,依赖、服务、端口都是真实的,不是模拟。环境释放后,权限随之失效。

华为云官方博客 425

华为云码道配置自定义大模型,四种方式完整实操

案例介绍。

华为云官方博客 624

图数据库:实现穿透式监管的数据基座

穿透式监管标志着国企监管从“管企业”向“管资本”转型过程中的关键一跃。而图数据库正是这一跃的技术支点。从股权穿透到资金链穿透,从供应链穿透到数据穿透,华为GES图数据库正在将“穿透式监管”从理念变为可落地、可操作的实践。无论是天眼查式的全量链路查询,还是某集团财经的税务规则判断,抑或是芯片供应链式的部件风险分析,乃至通过Palantir构建决策知识图谱,其底层逻辑都是一致的——用图的力量,穿透一切形式的“隔离层”,直抵风险本质与责任核心。

华为云官方博客 664

《公共云三十问》正式收官,奔赴企业AI百场景新征程

今年6月底,公共云产业联盟重点推出《公共云三十问》专栏,以每周三问的节奏,连载十周,解读《先进公共云》白皮书,分享国计民生系列案例,旨在凝聚共识、推动落地实践。同时,专栏分析公共云在产业升级、民生福祉、科技创新、全球发展等方面的作用,梳理中国特色公共云发展路径:以普惠云拓展用云广度,以智算云提升用云深度,以自主云夯实用云厚度,以全球云打开用云跨度。这十问从专属云、行业云切入,深入政务、金融、交通、电力、钢铁、化工、油气、制造等国计民生场景,回答公共云“怎么用”。

华为云官方博客 473

开发者小技巧|IAM配置,让码道代码智能体连续30天免登录

案例介绍。

华为云官方博客 645

码道深度对接CodeArts,让需求自动落地为代码

案例介绍。

华为云官方博客 719

【公共云三十问 之三十】拥抱AI,企业如何建设面向智能体的专属云?

企业可分阶段建设覆盖开发、运行、运营及安全的一体化智能体平台——从构建一站式、高低码协同的智能体开发平台,到打造高性能、极致弹性的运行时环境,再到搭建AgentOps驱动的持续运营与运维体系,同时构建端到端、多层次的全链路安全防护体系。在数据湖建设方面,遵循“存量复用、平滑演进、AI导向、分步迭代”原则,分三阶段推进——打造AI多模数据湖核心能力、完成存算分离与统一元数据管理、实现闭环赋能全面支撑智能体规模化落地,在保护既有投资的前提下将传统数据平台转型为AI数据专属供给平台。

华为云官方博客 823

【公共云三十问 之二十九】国计民生之制造:制造云如何重塑数智时代的新质生产力?

平台打通软件交付的完整路径,覆盖需求管理、代码托管、代码检查、编译构建、制品仓库、部署、测试等关键环节,支持大模型能力融入研发全流程,实现从需求到交付的端到端管理。通过构建“研发一朵云”,方案打破地域与组织壁垒,实现跨团队协同开发,有效缩短软件交付周期,助力工业制造企业从“传统研发”走向“敏捷研发”,加速数智化转型进程。当制造云真正成为数据流通的平台、AI创新的底座,公共云的社会价值将从基础设施层向生产场景层持续延伸,为新型工业化建设和制造强国战略注入源源不断的动力,重塑数智时代的中国制造新质生产力。

华为云官方博客 789

告别重复手工迁仓,码道MCP+Skill实现仓库批量迁移

案例介绍。

华为云官方博客 790

【公共云三十问 之二十八】国计民生之油气:智算云如何叩响数智时代的“地心蓝金”?

西南油气田以“向地球深部要资源”为战略方向,联合以华为云Stack为代表的公共云服务商共同打造统一算力底座,建设西南区域数据湖与通用技术平台,构建“勘探开发工程技术、天然气生产过程管控、天然气产运储销”等三个一体化协同应用场景,支撑油气勘探、开发生产、管输储运等全业务链的数智化转型。当智算云真正成为数据流通的平台、AI创新的底座,油气田得以将算力效能、数据价值与智能技术深度融入勘探开发全链条,将“看不见的算力”转化为“摸得着的储量”,以智能化手段持续降低勘探风险、缩短发现周期、提高采收效率,确保生产安全。

华为云官方博客 613

【公共云三十问 之二十七】国计民生之化工:数智云如何重塑传统化工新范式?

在架构方面,方案构建云边协同的统一体系,涵盖AI协同、数据协同与运营协同三大维度——总部集中训练大模型,边缘节点负责推理执行,云边持续迭代,实现“边用边学”的智能闭环,模型平均精度提升20%以上。此外,方案提供一站式企业级工业物联网平台、数据湖与数据治理平台,覆盖工业数据分析“采、存、算、管、用”全流程,打通生产现场与管理系统间的数据壁垒,有效消除数据孤岛。层面,方案充分发挥软硬协同优势,实现计算、存储、网络与云平台的深度协同,训练线性度超95%,为大模型训练推理提供强劲算力支撑。▲化工“数智”新模式。

华为云官方博客 663

【公共云三十问 之二十六】国计民生之钢铁:数智云如何淬炼中国钢铁新力量?

同时,构建云边端协同的统一架构,支撑集团总部与各生产基地两级协同发展——总部集中训练大模型,边缘节点负责推理执行,云边持续迭代,实现训推一体化的资源调度与高效协同,为钢铁行业的数智化转型构建了坚实的算力底座。层面,方案构建覆盖“工业数采→边缘IT/OT融合→统一数据湖→数据治理平台→数据应用”全链路的一站式数据治理与流通平台,打通生产现场与管理系统间的数据壁垒,让数据“采得到、流得动、用得好”,加速数据价值从生产现场向经营决策层流动释放。湘潭钢铁集团的钢铁数智云,是钢铁工业智能云建设的标杆案例。

华为云官方博客 526

LakeWatch——MRS 智能运维Agent

从资源池、队列、作业等多个维度,对集群CPU与内存资源进行精细化分析与对比,直观呈现不同时间段的空闲、满载等使用状态,识别资源浪费,指导治理优化,为扩缩容决策提供数据支撑。对HDFS存储进行多维度深度分析(目录、用户、用户组等),涵盖使用量、增量、文件大小分布及数据热度等指标,帮助快速识别增长较快的目录、长期未访问的文件,统计目录文件数量与小文件占比,评估HDFS总存储量与扩缩容需求,为存储治理与资源规划提供全面数据支撑。Agent主动巡检,识别异常趋势并提前预警,让运维从"事后处理"转向"事前预防"。

华为云官方博客 515

华为云专题文档发布:丰富的AI案例、选型指导和概念解读

发布 “云服务选型”、“云计算概念”专题,提供云服务选型指导,助您选择匹配业务的云服务,解读云计算相关概念,开启云上学习之路。开发者工具和文档专区上线,提供从学习、实践到反馈的全链路支持。帮助中心新增100余篇AI案例。

华为云官方博客 286

一个人,也能用AI做点“星东西”

华为云星耀创想者大赛-2026华为云OPC创意大赛等你来~

华为云官方博客 290

从需求到可执行工作项:MCP+Skill 让智能体规划真正落地

回顾整个体验,以前让智能体帮我拆需求,它是洋洋洒洒给我列了一大篇 Markdown,看着挺像那么回事,但最后还是得我一条条往 CodeArts Req 里搬,搬完再手动挂父子关系、排日期,拆需求五分钟,搬运两小时。现在好了,MCP 给智能体接上了"手",Skill 给它装上了"项目经理的脑子",一句话下去,34 个工作项连带排期、层级关系全给我建好了,甘特图一拉,齐刷刷都在两周内,节省了多少工作量啊,美滋滋。本次实操在码道代码智能体基础上,构建了一套"需求→可执行工作项"的自动化规划方案。

华为云官方博客 576

华为云码道「码力续航计划」更新!

✅上新GLM‑5.3‑Flash,高速响应,代码生成、工程解析、Agent调试高效输出。新增GLM‑5.3‑Flash福利模型,每日解锁1000万免费Tokens。● 本次活动共发放总量价值100万元Tokens,发完即止!把耗算力的编码重活,交给华为云码道代码智能体🚀🚀。● 每日额度准时刷新,当日清零、次日满血重置。✅复杂算法、大项目解析、批量代码生成随便跑。✅不用抠额度、不用算消耗,放开调试大胆迭代。✅无需额外操作,登录即送,直接切换模型使用。● 把算力交给码道,让撸码不再内耗👏🏻。

华为云官方博客 685

【公共云三十问 之二十四】国计民生之交通:交通云如何铺就数智通衢新坦途?

交通行业作为支撑实体经济的关键基础设施,涵盖公路、铁路、机场、港口、地铁等众多子领域,其中,公路网络作为综合交通运输体系的基础骨架,承担着全国超过70%的客货运量,其数字化、智能化转型的需求尤为迫切。方面,提供Agent开发框架、知识库管理、RAG工程、意图识别、静态应用编排及模型评测等能力,支持客户将行业知识、业务流程与AI能力深度融合,快速构建面向收费稽核、路网调度、应急处置等场景的智能应用。开发并实现落地应用,全面覆盖建设、管理、养护、运营、服务、安全、办公七大业务领域。

华为云官方博客 461

【公共云三十问 之二十五】国计民生之电力:电力云如何点亮数智电力新引擎?

方案构建了覆盖数据获取、质量评估到标准化处理的全链路能力。基于公共云服务商智算底座及气象大模型,通过时空图神经网络重新建模产流机制,中国华电建成超50TB多源融合数据集,突破时空建模与机理融合等五大关键技术,短期径流预测精度较传统机理模型提升5个百分点以上,实现15天中期径流预测精度超85%,推理效率达秒级。基于气象大模型的基础架构与预训练能力,客户可直接在大模型之上开展增量训练与微调,充分利用场站所在区域的高精度历史数据(如3公里、1公里分辨率),针对不同场站和区域的地形地貌与气候特征进行模型调优。

华为云官方博客 381
上一篇: 不同数据库模式下DATE类型的行为解析
下一篇: 谋而后动:解读数仓计划生成中行数估算和路径生成的奥秘
华为云开发者联盟
华为云开发者联盟 企业官方账号 企业官方账号
博客等级 码龄10年 72万+粉丝 5985原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值