华为云用户手册

设置集群默认调度器 默认调度器 (default-scheduler) Kubernetes调度器可以发现集群中新创建且尚未被调度到节点上的Pod，并负责将未调度的Pod指派到一个合适的节点上运行。在同一个集群中可以使用多个不同的调度器，kube-scheduler调度器是Kubernetes社区提供的集群默认调度器，CCE同时还支持增强的Volcano调度器，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。 您可以选择将kube-scheduler调度器和Volcano调度器配合使用，也可以单独使用kube-scheduler调度器或Volcano调度器。 表1 集群默认调度器 调度器名称 说明 调度器配置 kube-scheduler调度器 提供社区原生调度器标准调度能力。 设置kube-scheduler调度器为默认调度器时，如果集群中同时安装Volcano调度器，将默认启用Volcano增强能力，为您提供资源利用率优化、AI任务性能增强、异构资源管理等高级调度能力，提升集群资源利用率，节约使用成本。此时，集群中的普通工作负载调度任务任由kube-scheduler调度器执行，仅部分指定的工作负载由Volcano调度器执行，详情请参见使用Volcano调度工作负载。 kube-scheduler调度器配置： 调度器性能配置 业务优先级保障调度 安装Volcano调度器后的增强配置： 资源利用率优化调度（Volcano调度器支持） AI任务性能增强调度（Volcano调度器支持） 异构资源调度（Volcano调度器支持） Volcano调度器 设置Volcano调度器为默认调度器后，Volcano调度器将替换kube-scheduler调度器，集群中的工作负载任务调度均由Volcano调度器执行。 Volcano兼容kube-scheduler调度能力，并提供增量调度能力。使用该调度器时，请先安装Volcano调度器插件，详情请参见Volcano调度器。 Volcano调度器增强配置： 业务优先级保障调度 资源利用率优化调度（Volcano调度器支持） AI任务性能增强调度（Volcano调度器支持） 异构资源调度（Volcano调度器支持）

版本记录 表4 Kubernetes Metrics Server插件版本记录 插件版本 支持的集群版本 更新特性 社区版本 1.3.60 v1.21 v1.23 v1.25 v1.27 v1.28 v1.29 适配CCE v1.29集群 0.6.2 1.3.39 v1.21 v1.23 v1.25 v1.27 v1.28 修复部分问题 0.6.2 1.3.37 v1.21 v1.23 v1.25 v1.27 v1.28 适配CCE v1.28集群 0.6.2 1.3.12 v1.19 v1.21 v1.23 v1.25 v1.27 - 0.6.2 1.3.10 v1.19 v1.21 v1.23 v1.25 v1.27 适配CCE v1.27集群 0.6.2 1.3.8 v1.19 v1.21 v1.23 v1.25 插件挂载节点时区 0.6.2 1.3.6 v1.19 v1.21 v1.23 v1.25 支持插件实例AZ反亲和配置 默认污点容忍时长修改为60s 0.6.2 1.3.3 v1.19 v1.21 v1.23 v1.25 适配CCE v1.25集群 CronHPA调整Deployment实例数，新增skip场景 0.6.2 1.3.2 v1.19 v1.21 v1.23 v1.25 适配CCE v1.25集群 0.6.2 1.2.1 v1.19 v1.21 v1.23 适配CCE v1.23集群 0.4.4 1.1.10 v1.15 v1.17 v1.19 v1.21 适配CCE v1.21集群 0.4.4 1.1.4 v1.15 v1.17 v1.19 资源规格配置单位统一化 0.4.4 1.1.2 v1.15 v1.17 v1.19 同步至社区v0.4.4版本 0.4.4 1.1.1 v1.13 v1.15 v1.17 v1.19 支持自定义资源规格配置，最大无效实例数改为1 0.3.7 1.1.0 v1.13 v1.15 v1.17 v1.19 适配CCE v1.19集群 0.3.7 1.0.5 v1.13 v1.15 v1.17 更新至社区v0.3.7版本 0.3.7

安装插件 登录CCE控制台，单击集群名称进入集群，单击左侧导航栏的“插件中心”，在右侧找到Kubernetes Metrics Server插件，单击“安装”。 在安装插件页面，设置“规格配置”。 表1 metrics-server插件规格配置 参数 参数说明 插件规格 该插件可配置“单实例”、“高可用”或“自定义”规格。 实例数 选择上方插件规格后，显示插件中的实例数。 选择“自定义”规格时，您可根据需求调整插件实例数。 实例数为1时插件不具备高可用能力，当插件实例所在节点异常时可能导致插件功能无法正常使用，请谨慎选择。 容器 选择插件规格后，显示插件容器的CPU和内存配额。 选择“自定义”规格时，您可根据需求调整插件实例的容器规格。 设置插件实例的“调度策略”。 调度策略对于DaemonSet类型的插件实例不会生效。 设置多可用区部署或节点亲和策略时，需保证集群中存在满足调度策略的节点且拥有足够的资源，否则插件实例将无法运行。 表2 插件调度配置 参数 参数说明 多可用区部署 优先模式：优先将插件的Deployment实例调度到不同可用区的节点上，如集群下节点不满足多可用区，插件实例将调度到单可用区。 均分模式：插件Deployment实例均匀调度到当前集群下各可用区，增加新的可用区后建议扩容插件实例以实现跨可用区高可用部署；均分模式限制不同可用区间插件实例数相差不超过1，单个可用区资源不足会导致后续其他实例无法调度。 强制模式：插件Deployment实例强制调度到不同可用区的节点上，如集群下节点不满足多可用区，插件实例将无法全部运行。 节点亲和 不配置：插件实例不指定节点亲和调度。 指定节点调度：指定插件实例部署的节点。若不指定，将根据集群默认调度策略进行随机调度。 指定节点池调度：指定插件实例部署的节点池。若不指定，将根据集群默认调度策略进行随机调度。 自定义亲和策略：填写期望插件部署的节点标签实现更灵活的调度策略，若不填写将根据集群默认调度策略进行随机调度。 同时设置多条自定义亲和策略时，需要保证集群中存在同时满足所有亲和策略的节点，否则插件实例将无法运行。 容忍策略 容忍策略与节点的污点能力配合使用，允许（不强制）插件的 Deployment 实例调度到带有与之匹配的污点的节点上，也可用于控制插件的 Deployment 实例所在的节点被标记污点后插件的 Deployment 实例的驱逐策略。 插件会对实例添加针对node.kubernetes.io/not-ready和node.kubernetes.io/unreachable污点的默认容忍策略，容忍时间窗为60s。 详情请参见容忍策略。 单击“安装”。

创建subpath类型SFS Turbo存储卷 subpath模式的卷请勿通过前端进行“扩容”、“解关联”、“删除”等操作。 创建SFS Turbo资源，选择网络时，请选择与集群相同的VPC与子网。 新建一个StorageClass的YAML文件，例如sfsturbo-subpath-sc.yaml。 配置示例： apiVersion: storage.k8s.io/v1 allowVolumeExpansion: true kind: StorageClass metadata: name: sfsturbo-subpath-sc mountOptions: - lock parameters: csi.storage.k8s.io/csi-driver-name: sfsturbo.csi.everest.io csi.storage.k8s.io/fstype: nfs everest.io/share-access-to: 7ca2dba2-1234-1234-1234-626371a8fb3a everest.io/share-expand-type: bandwidth everest.io/share-export-location: 192.168.1.1:/sfsturbo/ everest.io/share-source: sfs-turbo everest.io/share-volume-type: STANDARD everest.io/volume-as: subpath everest.io/volume-id: 0d773f2e-1234-1234-1234-de6a35074696 provisioner: everest-csi-provisioner reclaimPolicy: Delete volumeBindingMode: Immediate 其中： name：storageclass的名称。 mountOptions：选填字段；mount挂载参数。 默认使用如下所示配置，具体请参见设置挂载参数。此处不能配置为nolock=true，会导致挂载失败。 mountOptions: - vers=3 - timeo=600 - nolock - hard everest.io/volume-as：该参数需设置为“subpath”来使用subpath模式。 everest.io/share-access-to：选填字段。subpath模式下，填写SFS Turbo资源的所在VPC的ID。 everest.io/share-expand-type：选填字段。若SFS Turbo资源存储类型为增强版（标准型增强版、性能型增强版），设置为bandwidth。 everest.io/share-export-location：挂载目录配置。由SFS Turbo共享路径和子目录组成，共享路径可至SFS Turbo服务页面查询，子路径由用户自定义，后续指定该StorageClass创建的PVC均位于该子目录下。 everest.io/share-volume-type：选填字段。填写SFS Turbo的类型。标准型为STANDARD，性能型为PERFORMANCE。对于增强型需配合“everest.io/share-expand-type”字段使用，everest.io/share-expand-type设置为“bandwidth”。 everest.io/zone：选填字段。指定SFS Turbo资源所在的可用区。 everest.io/volume-id：SFS Turbo资源的卷ID，可至SFS Turbo界面查询。 执行kubectl create -f sfsturbo-subpath-sc.yaml。 新建一个PVC的YAML文件，sfs-turbo-test.yaml。 配置示例： apiVersion: v1 kind: PersistentVolumeClaim metadata: name: sfs-turbo-test namespace: default spec: accessModes: - ReadWriteMany resources: requests: storage: 50Gi storageClassName: sfsturbo-subpath-sc volumeMode: Filesystem 其中： name: PVC的名称。 storageClassName：SC的名称。 storage：subpath模式下，该参数无实际意义，容量受限于SFS Turbo资源的总容量，若SFS Turbo资源总容量不足，请及时到SFS Turbo界面扩容。 执行kubectl create -f sfs-turbo-test.yaml。 对subpath类型的SFS Turbo扩容时，没有实际的扩容意义。该操作不会对SFS Turbo资源进行实际的扩容，需要用户自行保证SFS Turbo的总容量不被耗尽。

创建Deployment挂载已有数据卷 新建一个Deployment的YAML文件，例如deployment-test.yaml。 配置示例： apiVersion: apps/v1 kind: Deployment metadata: name: test-turbo-subpath-example namespace: default generation: 1 labels: appgroup: '' spec: replicas: 1 selector: matchLabels: app: test-turbo-subpath-example template: metadata: labels: app: test-turbo-subpath-example spec: containers: - image: nginx:latest name: container-0 volumeMounts: - mountPath: /tmp name: pvc-sfs-turbo-example restartPolicy: Always imagePullSecrets: - name: default-secret volumes: - name: pvc-sfs-turbo-example persistentVolumeClaim: claimName: sfs-turbo-test 其中： name：创建的工作负载名称。 image：工作负载的镜像。 mountPath：容器内挂载路径，示例中挂载到“/tmp”路径。 claimName：已有的PVC名称。 创建Deployment负载。 kubectl create -f deployment-test.yaml

StatefulSet动态创建subpath模式的数据卷 新建一个StatefulSet的YAML文件，例如statefulset-test.yaml。 配置示例： apiVersion: apps/v1 kind: StatefulSet metadata: name: test-turbo-subpath namespace: default generation: 1 labels: appgroup: '' spec: replicas: 2 selector: matchLabels: app: test-turbo-subpath template: metadata: labels: app: test-turbo-subpath annotations: metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"","path":"","port":"","names":""}]' pod.alpha.kubernetes.io/initialized: 'true' spec: containers: - name: container-0 image: 'nginx:latest' resources: {} volumeMounts: - name: sfs-turbo-160024548582479676 mountPath: /tmp terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent restartPolicy: Always terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst securityContext: {} imagePullSecrets: - name: default-secret affinity: {} schedulerName: default-scheduler volumeClaimTemplates: - metadata: name: sfs-turbo-160024548582479676 namespace: default annotations: {} spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: sfsturbo-subpath-sc serviceName: wwww podManagementPolicy: OrderedReady updateStrategy: type: RollingUpdate revisionHistoryLimit: 10 其中： name：创建的工作负载名称。 image：工作负载的镜像。 mountPath：容器内挂载路径，示例中挂载到“/tmp”路径。 “spec.template.spec.containers.volumeMounts.name ”和 “spec.volumeClaimTemplates.metadata.name”有映射关系，必须保持一致。 storageClassName: 填写自建的SC名称。 创建StatefulSet负载。 kubectl create -f statefulset-test.yaml

指标清单 Kubelet视图使用的指标清单如下： 表2 Kubelet指标说明 指标 类型 说明 storage_operation_errors_total Counter 存储操作期间发生的错误次数 storage_operation_duration_seconds_count Counter 存储操作的操作次数 storage_operation_duration_seconds_bucket Histogram 存储操作的持续时间 kubelet_pod_start_duration_seconds_count Counter 进行过pod start的数量 kubelet_pod_start_duration_seconds_bucket Histogram pod start的耗时分布情况 kubelet_runtime_operations_duration_seconds_bucket Histogram 不同操作的累计操作耗时分布情况 kubelet_runtime_operations_errors_total Counter 不同操作的累计操作失败的数量 kubelet_node_config_error Gauge 如果节点遇到与配置相关的错误，则此指标为true（1），否则为false（0） volume_manager_total_volumes Gauge Volume Manager中的卷数 kubelet_running_containers Gauge 当前运行的Containers数 kubelet_running_pods Gauge 当前运行的pod数 kubelet_node_name Gauge 节点名称，值始终为1 kubelet_runtime_operations_total Counter 运行过程中不同的操作类型的累计操作次数 kubelet_cgroup_manager_duration_seconds_count Counter 销毁和更新的数量 kubelet_cgroup_manager_duration_seconds_bucket Histogram 销毁和更新操作的耗时分布情况 kubelet_pleg_relist_duration_seconds_count Counter PLEG relist pod不同耗时的数量 kubelet_pleg_relist_interval_seconds_bucket Histogram PLEG relist 间隔的分布情况 kubelet_pleg_relist_duration_seconds_bucket Histogram PLEG relist pod耗时的分布情况 rest_client_requests_total Counter 请求apiserver的总次数（按照返回码code和请求类型method统计） rest_client_request_duration_seconds_bucket Histogram 请求apiserver的总次数（按照返回码code和请求类型method统计）的分布情况 process_resident_memory_bytes Gauge 进程驻留内存大小（以字节为单位） process_cpu_seconds_total Counter 进程用户和系统 CPU 总时间（以秒为单位） go_goroutines Gauge 协程数量

文件存储挂载参数 CCE在挂载文件存储时默认设置了如表1所示的参数。 表1 文件存储挂载参数 参数 参数值 描述 keep-original-ownership 无需填写 表示是否保留文件挂载点的ownership。 默认为不添加该参数，此时挂载文件存储时将会默认把挂载点的ownership修改为root:root。 如添加该参数，挂载文件存储时将保持文件系统原有的ownership。 vers 3 文件系统版本，目前只支持NFSv3。取值：3 nolock 无需填写 选择是否使用NLM协议在服务器上锁文件。当选择nolock选项时，锁对于同一主机的应用有效，对不同主机不受锁的影响。 timeo 600 NFS客户端重传请求前的等待时间(单位为0.1秒)。建议值：600。 hard/soft 无需填写 挂载方式类型。 取值为hard，即使用硬连接方式，若NFS请求超时，则客户端一直重新请求直至成功。 取值为soft，即软挂载方式挂载系统，若NFS请求超时，则客户端向调用程序返回错误。 默认为hard。 sharecache/nosharecache 无需填写 设置客户端并发挂载同一文件系统时数据缓存和属性缓存的共享方式。设置为sharecache时，多个挂载共享共享同一缓存。设为nosharecache时，每个挂载各有一个缓存。默认为sharecache。 说明： 设置nosharecache禁用共享缓存会对性能产生一定影响。每次挂载都会重新获取挂载信息，会增加与NFS服务器的通信开销和NFS客户端的内存消耗，同时同客户端设置nosharecache存在cache不一致的风险。因此，应该根据具体情况进行权衡，以确定是否需要使用nosharecache选项。 除了以上参数外，您还可以设置其他的文件存储挂载参数，具体请参见挂载NFS文件系统到云服务器（Linux）。

按需计费区域单价 表2 按需计费区域单价 区域 集群管理费用 Pod 华南-广州友好 公测期间免收集群管理费用 CPU：0.000049元/秒/Core 内存：0.00000613元/秒/GiB 西南-贵阳一 公测期间免收集群管理费用 CPU：0.000044元/秒/Core 内存：0.00000552元/秒/GiB 华南-广州 公测期间免收集群管理费用 CPU：0.000049元/秒/Core 内存：0.00000613元/秒/GiB 华东-上海一 公测期间免收集群管理费用 CPU：0.000049元/秒/Core 内存：0.00000613元/秒/GiB

规格说明 Autopilot会自动规整不支持的规格，向上规整为最接近的vCPU与内存配置，以确保Pod始终拥有运行所需的资源。 表3 Autopilot支持的vCPU与内存组合 vCPU 内存（GiB） 0.25 vCPU 0.5GiB、1GiB、2GiB 0.5 vCPU 1GiB、2GiB、3GiB、4GiB 1 vCPU 2GiB、3GiB、4GiB、5GiB、6GiB、7GiB、8GiB 2 vCPU 4GiB、5GiB、... 、15GiB、16GiB（以 1GiB 为增量） 4 vCPU 8GiB、9GiB、... 、31GiB、32GiB（以 1GiB 为增量） 8 vCPU 8GiB、12GiB、... 、60GiB、64GiB（以 4GiB 为增量） 16 vCPU 16GiB、24GiB、... 、120GiB、128GiB（以 8GiB 为增量） 32 vCPU 32GiB、64GiB、128GiB、256GiB 48 vCPU 96GiB、192GiB、384GiB 64 vCPU 128GiB、256GiB、512GiB

指标说明 Prometheus Agent视图暴露的指标如下： 表1 Prometheus Agent视图说明 视图指标 单位 描述 CPU使用率 百分比 Prometheus Agent Pod CPU平均使用率 内存使用率 百分比 Prometheus Agent Pod 内存平均使用率 远程写Bps 字节/秒 每秒远程写入的字节数 远程写平均耗时 秒 远程写入平均耗时 远程写Pending字节数 字节 远程写入挂起的数据字节数 远程写Packet每秒丢弃次数 次 远程写入每秒丢弃的数据包数 远程写每秒错误请求次数 次 远程写每秒错误请求次数 远程写错误请求百分比 百分比 远程写错误请求百分比 远程写每秒重试次数 次 远程写每秒重试次数 采集Scrapers数量 个 采集Scrapers数量 每秒采集次数 次 每秒采集次数 采集平均耗时 秒 采集平均耗时 每秒采集读取错误次数 次 每秒采集读取错误次数 每秒采集写入错误次数 次 每秒采集写入错误次数 每秒采集大小超限次数 次 每秒采集大小超限次数 发送队列读取Bps 字节/秒 发送队列每秒读的字节数 发送队列写Bps 字节/秒 发送队列每秒写的字节数 发送队列Pending大小 字节 发送队列挂起的数据字节数 每秒Block读取次数 次 发送队列每秒读block的次数 每秒Block写入次数 次 发送队列每秒写block的次数 每秒Block丢弃次数 次 发送队列每秒block丢弃的次数

指标清单 Prometheus Agent视图使用的指标清单如下： 表2 Prometheus Agent指标说明 指标名称 类型 说明 container_cpu_usage_seconds_total Gauge 容器CPU使用量 container_memory_working_set_bytes Gauge 容器工作内存使用量 vmagent_remotewrite_bytes_sent_total Counter Prometheus Agent远程写入字节数发送总计 vmagent_remotewrite_duration_seconds_sum Summary Prometheus Agent远程写入耗时 vmagent_remotewrite_pending_data_bytes Gauge Prometheus Agent远程写入挂起数据字节数 vmagent_remotewrite_packets_dropped_total Counter Prometheus Agent远程写入数据包丢弃总数 vmagent_remotewrite_requests_total Counter Prometheus Agent远程写入请求总数 vmagent_remotewrite_retries_count_total Counter Prometheus Agent远程写入重试次数总数 vm_promscrape_active_scrapers Gauge 采集的分片数量 vm_promscrape_scrapes_total Counter 采集次数 vm_promscrape_scrape_duration_seconds_sum Summary vmagent采集指标的耗时 vm_promscrape_conn_read_errors_total Counter 采集读取错误次数 vm_promscrape_conn_write_errors_total Counter 采集写入错误次数 vm_promscrape_max_scrape_size_exceeded_errors_total Counter 采集大小超过限制的次数 vm_persistentqueue_bytes_read_total Counter 发送队列读取的总字节数 vm_persistentqueue_bytes_written_total Counter 发送队列写入的总字节数 vm_persistentqueue_bytes_pending Gauge 发送队列Pending的字节数 vm_persistentqueue_blocks_read_total Counter 发送队列读block的次数 vm_persistentqueue_blocks_written_total Counter 发送队列写block的次数 vm_persistentqueue_blocks_dropped_total Counter 发送队列block丢弃的次数

高级Rewrite配置 对于一些复杂高级的Rewrite需求，可以通过如下注解来实现，其本质也是修改Nginx的配置文件（nginx.conf），可以实现上面提到的“nginx.ingress.kubernetes.io/rewrite-target”注解的功能，但是自定义程度更高，适合更加复杂的Rewrite需求。 nginx.ingress.kubernetes.io/server-snippet：在nginx.conf的“server”字段中添加自定义配置。 nginx.ingress.kubernetes.io/configuration-snippet：在nginx.conf的“location”字段中添加自定义配置。 snippet配置在NGINX Ingress控制器版本为2.4.6版本及以上时（对应社区版本为v1.9.3）不再默认启用，详情请参见Changelog。如果您仍需要使用snippet配置，可以通过allow-snippet-annotations启用。 通过以上两个注解可以在nginx.conf中的“server”或“location”字段中插入Rewrite指令，完成URL的重写，示例如下： annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/configuration-snippet: | rewrite ^/stylesheets/(.*)$ /something/stylesheets/$1 redirect; # 添加 /something 前缀 rewrite ^/images/(.*)$ /something/images/$1 redirect; # 添加 /something 前缀 如上两条规则在访问URL中添加了“/something”路径，即： 当用户访问rewrite.bar.com/stylesheets/new.css时，重写为rewrite.bar.com/something/stylesheets/new.css 当用户访问rewrite.bar.com/images/new.jpg时，重写为rewrite.bar.com/something/images/new.jpg

极速文件存储介绍 CCE支持将极速文件存储（SFS Turbo）创建的存储卷挂载到容器的某一路径下，以满足数据持久化的需求。极速文件存储具有按需申请，快速供给，弹性扩展，方便灵活等特点，适用于海量小文件业务，例如DevOps、容器微服务、企业办公等应用场景。 SFS Turbo为用户提供一个完全托管的共享文件存储，能够弹性伸缩至320TB规模，具备高可用性和持久性，为海量的小文件、低延迟高IOPS型应用提供有力支持。 符合标准文件协议：用户可以将文件系统挂载给服务器，像使用本地文件目录一样。 数据共享：多台服务器可挂载相同的文件系统，数据可以共享操作和访问。 私有网络：数据访问必须在数据中心内部网络中。 安全隔离：直接使用云上现有IaaS服务构建独享的云文件存储，为租户提供数据隔离保护和IOPS性能保障。 应用场景：适用于多读多写（ReadWriteMany）场景下的各种工作负载（Deployment/StatefulSet）和普通任务（Job）使用，主要面向高性能网站、日志存储、DevOps、企业办公等场景。

集群服务器配置（kube-apiserver） 容器故障迁移默认容忍周期 容器故障迁移默认容忍周期配置默认对集群中所有的容器生效，您也可以为指定Pod进行差异化容忍配置，此时将以Pod配置的容忍时长为准，详情请参见默认容忍策略说明。 请合理设置容忍时间配置，否则可能出现以下问题： 配置过小：在网络抖动等短时故障场景下，容器可能会频繁迁移而影响业务。 配置过大：在节点故障时，容器可能长时间无法迁移，导致业务受损。 表1 容器故障迁移默认容忍周期配置参数说明 名称 参数 说明 取值 容器迁移对节点不可用状态的容忍时间 default-not-ready-toleration-seconds 表示节点处于NotReady状态下的容忍时间。当节点出现异常，变为不可用状态时，容器将在该容忍时间后自动驱逐，默认为300s。 默认：300s 容器迁移对节点无法访问状态的容忍时间 default-unreachable-toleration-seconds 表示节点处于unreachable状态下的容忍时间。当环境出现异常，例如节点无法访问（如节点网络异常）时，容器将在该容忍时间后自动驱逐，默认为300s。 默认：300s 准入控制器插件配置 Kubernetes支持开启一些准入控制插件，可以在集群对Kubernetes API对象（如Pods、Services、Deployments等）进行修改操作前，进行相应的约束与控制。 v1.23.14-r0、v1.25.9-r0、v1.27.6-r0、v1.28.4-r0及以上版本的集群支持该参数。 表2 准入控制器插件配置参数说明 名称 参数 说明 取值 节点限制插件 enable-admission-plugin-node-restriction 节点限制插件限制了节点的 kubelet 只能操作当前节点的对象，增强了在高安全要求或多租户场景下的隔离性。详细信息请参考官方文档。 开启/关闭 Pod节点选择器插件 enable-admission-plugin-pod-node-selector Pod节点选择器插件允许集群管理员通过命名空间注释设置默认节点选择器，帮助约束 Pod 可以运行的节点，并简化配置。 开启/关闭 Pod容忍度限制插件 enable-admission-plugin-pod-toleration-restriction Pod容忍度限制插件允许通过命名空间设置 Pod 的容忍度的默认值和限制，为集群管理者提供了对 Pod 调度的精细控制，以保护关键资源。 开启/关闭

集群控制器配置（kube-controller-manager） 控制器公共配置 控制器性能配置：用于设置控制器访问kube-api-server的性能参数配置。 请合理设置控制器性能配置，否则可能出现以下问题： 配置过小：可能会触发客户端限流，对控制器性能产生影响。 配置过大：可能会导致kube-apiserver过载。 表3 控制器性能配置参数说明 名称 参数 说明 取值 控制器访问kube-apiserver的QPS kube-api-qps 与kube-apiserver通信的QPS，即每秒查询率。 集群规格为1000节点以下时，默认值为100 集群规格为1000节点及以上时，默认值为200 控制器访问kube-apiserver的突发流量上限 kube-api-burst 与kube-apiserver通信的突发流量上限。 集群规格为1000节点以下时，默认值为100 集群规格为1000节点及以上时，默认值为200 资源对象处理并发配置：允许同时同步的资源对象的数量。配置数量越大，管理响应越快，但 CPU（和网络）负载也越高。 请合理设置资源对象处理并发配置，否则可能出现以下问题： 配置过小：可能导致管理器处理响应慢。 配置过大：会对集群管控面造成压力，产生过载风险。 表4 资源对象处理并发配置参数说明 名称 参数 说明 取值 Deployment concurrent-deployment-syncs 可以并发同步的Deployment对象个数。数值越大意味着对Deployment的响应越及时，同时也意味着更大的CPU（和网络带宽）压力。 默认：5 Endpoint concurrent-endpoint-syncs 可以并发同步的Endpoints对象个数。数值越大意味着更新Endpoints越快，同时也意味着更大的CPU（和网络）压力。 默认：5 GC回收 concurrent-gc-syncs 可以并发同步的垃圾收集（Garbage Collector）工作线程个数。 默认：20 Job concurrent-job-syncs 可以并发同步的Job对象个数。较大的数值意味着对Job的响应越及时，不过也意味着更多的CPU（和网络）占用。 默认：5 CronJob concurrent-cron-job-syncs 可以并发同步的CronJob对象个数。较大的数值意味着对CronJob的响应越及时，不过也意味着更多的CPU（和网络）占用。 默认：5 Namespace concurrent-namespace-syncs 可以并发同步的Namespace对象个数。较大的数值意味着对Namespace的响应越及时，不过也意味着更多的CPU（和网络）占用。 默认：10 Replicaset concurrent-replicaset-syncs 可以并发同步的ReplicaSet个数。数值越大，副本管理的响应速度越快，同时也意味着更多的CPU（和网络）占用。 默认：5 ResourceQuota concurrent-resource-quota-syncs 可以并发同步的ResourceQuota对象个数。数值越大，配额管理的响应速度越快，不过对CPU（和网络）的占用也越高。 默认：5 Service concurrent-service-syncs 可以并发同步的Service对象个数。数值越大，服务管理的响应速度越快，不过对CPU（和网络）的占用也越高。 默认：10 ServiceAccountToken concurrent-serviceaccount-token-syncs 可以并发同步的服务账号令牌对象个数。数值越大，令牌生成的速度越快，不过对CPU（和网络）的占用也越高。 默认：5 TTLAfterFinished concurrent-ttl-after-finished-syncs 可以并发同步的ttl-after-finished-controller线程个数。 默认：5 RC concurrent_rc_syncs 可以并发同步的副本控制器对象个数。数值越大，副本管理操作越快，不过对CPU（和网络）的占用也越高。 说明： 该参数仅在v1.19及以下版本集群中使用。 默认：5 RC concurrent-rc-syncs 可以并发同步的副本控制器对象个数。数值越大，副本管理操作越快，不过对CPU（和网络）的占用也越高。 说明： 该参数仅在v1.21至v1.23版本集群中使用。v1.25版本后，该参数弃用（正式弃用版本为v1.25.3-r0）。 默认：5 HPA并发处理数 concurrent-horizontal-pod-autoscaler-syncs 允许并发执行的HPA弹性伸缩数量。 数值越大，HPA弹性伸缩响应越快，不过对CPU（和网络）的占用也越高。 该参数仅v1.27及以上版本集群支持。 默认：5 取值范围为1-50 节点生命周期控制器（node-lifecycle-controller）配置 v1.23.14-r0、v1.25.9-r0、v1.27.6-r0、v1.28.4-r0及以上版本的集群支持该参数。 表5 负载弹性伸缩控制器配置参数说明 名称 参数 说明 取值 可用区亚健康阈值 unhealthy-zone-threshold 当可用区故障节点规模达到指定比例时被认定为不健康，针对不健康的区域，故障节点业务的迁移频率会降级，避免规模故障场景下大规模迁移操作产生更坏的影响。 说明： 比例配置过大可能导致区域在规模故障场景下仍尝试执行大规模迁移动作，导致集群过载等风险。 默认：0.55 节点迁移速率 node-eviction-rate 当某区域健康时，在节点故障的情况下每秒删除Pod的节点数。该值默认设置为0.1，代表每10秒钟内至多从一个节点驱逐Pod。 说明： 结合集群规模合理设置，建议按比例折算后每批迁移Pod数量不超过300。 迁移速率设置过大可能引入集群过载风险，同时每批迁移重调度的Pod过多，大量Pod无法及时调度，影响整体故障恢复时间。 默认：0.1 次级节点迁移速率 secondary-node-eviction-rate 当某区域不健康时，在节点故障的情况下每秒删除Pod的节点数。该值默认设置为0.01，代表每100秒钟内至多从一个节点驱逐Pod。 说明： 配合node-eviction-rate设置，一般建议设置为node-eviction-rate的十分之一。 区域亚健康场景迁移速率设置过大无实际意义，且可能引入集群过载风险。 默认：0.01 大规模集群大小阈值 large-cluster-size-threshold 集群内节点数量大于此参数时，集群被判断为大规模集群。 说明： 在拥有大量节点的集群中，适当增加此阈值可以帮助提高控制器的性能和响应速度。对于规模较小的集群，保持默认值即可。在调整此参数时，建议先在测试环境中验证其对性能的影响，然后再在生产环境中应用。 被视为大型集群时，kube-controller-manager 会进行特定配置调整。这些配置用来优化大规模集群性能。因此阈值如果过低，规模小的集群用上的大集群的配置，反而降低性能。 默认：50 负载弹性伸缩控制器（horizontal-pod-autoscaler-controller）配置 请合理设置负载弹性伸缩控制器配置，否则可能出现以下问题： 配置过小：可能导致控制器处理响应慢。 配置过大：会对集群管控面造成压力，产生过载风险。 表6 负载弹性伸缩控制器配置参数说明 名称 参数 说明 取值 Pod水平伸缩同步的周期 horizontal-pod-autoscaler-sync-period 水平Pod扩缩器对Pod进行弹性伸缩的周期。配置越小弹性伸缩器反应越及时，同时CPU负载也越高。 默认：15s Pod回收控制器（pod-garbage-collector-controller）配置 表7 Pod回收控制器配置参数说明 名称 参数 说明 取值 终止状态Pod触发回收的数量阈值 terminated-pod-gc-threshold 在Pod GC开始删除终止状态（terminated）的Pod之前，系统允许存在终止状态的Pod数量。 说明： 请合理设置该参数，配置过大时，集群中可能存在大量终止状态的Pod，影响相关List查询请求性能，产生集群过载风险。 默认：1000 取值范围为10-12500 资源配额控制器（resource-quota-controller）配置 在高并发场景下（如批量创建Pod），配额管理机制可能导致部分请求因冲突而失败，除非必要不建议启用该功能。如启用，请确保请求客户端具备重试机制。 表8 资源配额控制器配置参数说明 名称 参数 说明 取值 启用资源配额管理 enable-resource-quota 通过配额管理功能，用户可以对命名空间或相关维度下的各类负载（Deployment、Pod等）数量以及资源（CPU、Memory）上限进行控制。命名空间通过ResourceQuota对象进行配额限制。 关闭（false）：不自动创建ResourceQuota对象。 开启（true）：自动创建ResourceQuota对象。ResourceQuota的默认取值请参见设置资源配额及限制。 默认：关闭（false）

通过逆向数据库导入物理表 通过逆向数据库，您可以从其他数据源中将一个或多个已创建的数据库表导入到物理表目录中，使其变成物理表。 在数据架构控制台，单击左侧导航树中的“关系建模”，进入关系建模页面，选择一个物理表进入。 在物理表的列表上方，单击“逆向数据库”。 在“逆向数据库”对话框中，配置如下参数，然后单击“确定”。 表7 逆向数据库配置 参数名称 说明 *所属主题 在下拉列表中选择所属主题。 *数据连接类型 在下拉列表中将显示逆向数据库支持的数据连接类型，请选择所需要的数据连接类型。 *数据连接 选择数据连接。 如需从其他数据源逆向数据库到物理表目录中，需要先在 DataArts Studio 管理中心创建一个数据连接，以便连接数据源。创建数据连接的操作，请参见管理数据连接。 *数据库 选择数据库。 *Schema 下拉选择Schema。该参数仅DWS和POSTGRESQL模型的表有效。 *队列 DLI 队列。仅当“数据连接类型”选择“DLI”时，该参数有效。 更新已有表 如果从其他数据源逆向过来的表，在物理表中已存在同名的表，选择是否更新已有的物理表。 名称来源 逆向后表名称/字段名称的来源，可以是描述或者是相应英文名，如表/字段未指定描述则固定使用英文名。 来自描述 来自英文名称 *数据表 选择全部或部分需导入的数据表。 图13 逆向配置 逆向数据库的结果会在“上次逆向”页面中显示。如果逆向成功，单击“关闭”。如果逆向失败，您可以查看失败原因，问题解决后，选中失败的表，然后单击“重新逆向”进行重试。 图14 逆向结果

函数说明 新建原子指标时，需要按照函数设定表达式。以聚合函数的部分函数为例，函数说明如表3所示： 表3 聚合函数说明 函数名 表达式 函数说明 avg(col) avg() 求平均值。 corr(col1, col2) corr() 返回两列数值的相关系数。 count(*) count() 返回记录条数。 covar_pop(col1, col2) covar_pop() 返回两列数值协方差。 covar_samp(col1, col2) covar_samp() 返回两列数值样本协方差。 max(col) max() 返回最大值。 min(col) min() 返回最小值。 stddev_pop(col) stddev_pop() 返回指定列的偏差。 stddev_samp(col) stddev_samp() 返回指定列的样本偏差。 sum(col) sum() 求和。 var_samp(col) var_samp() 返回指定列的样本方差。 如果想要查询更多函数的功能及说明，可以在新建原子指标页面的基本信息中的设定表达式项，单击对应函数，在页面右侧的函数说明框中会显示对应的函数说明。 图5 函数说明

新建时间限定并发布 在DataArts Studio控制台首页，选择实例，单击“进入控制台”，选择对应工作空间的“数据架构”模块，进入数据架构页面。 图1 选择数据架构 （可选）在数据架构控制台，单击左侧导航树中的“配置中心”，在功能配置下选择是否开启“时间限定生成使用动态表达式”功能，默认关闭。 图2 功能配置 在数据架构控制台，单击左侧导航树中的“技术指标”，选择“时间限定”页签。 进入时间限定页面后，单击“新建”按钮。 在新建时间限定页面，参考表1配置参数，然后单击“发布”。 图3 时间限定 表1 新建时间限定参数说明 参数名称 说明 *限定名称 只能包含中文、英文字母、数字和下划线，且必须以中文或英文字母开头。 *限定英文名称 只能包含英文字母、数字和下划线。 *时间配置 可选择“按年”、“按月”、“按日”、“按小时”或“按分钟”，然后根据需要选择“快速选择”或“自定义”进行时间条件的设置。 自定义时，“-”表示从当前时间向前的时间段，“+”表示从当前时间向后的时间段。例如，过去一年到未来三年，可以按年自定义为“-1到+3”或“+3到-1”。 描述 描述信息。支持的长度0~490字符。 在弹出框中，选择审核人，单击“确认提交”，提交发布审核。 如果当前用户已被添加为审核人，则可以勾选“自助审批”，单击“确认提交”后，状态显示为“已发布”。 选择审核人时，系统支持选择多个审核人，全部审批通过后，状态才会显示为已发布。如果有任意一个人驳回，则状态为已驳回。 等待审核人员审核。 审核通过后，时间限定创建完成。

删除业务指标 如果您已不再需要某个业务指标，可以删除该业务指标。如果待删除的业务指标已发布，则无法执行删除操作，您必须先将该业务指标下线后，才能执行删除操作。 在数据架构控制台，单击左侧导航树中的“业务指标”，进入业务指标页面。 在维度列表中找到需要删除的业务指标度，勾选该业务指标，然后单击业务指标列表上方“更多”中的“删除”。 图8 删除业务指标 在系统弹出的“删除”对话框中，确认无误后，单击“是”将业务指标删除。

Apache server日志 日志样例： [Mon Jan 08 20:43:51.854334 2018] [mpm_event:notice] [pid 36465:tid 140557517657856] AH00489: Apache/2.4.12 (Unix) OpenSSL/1.0.1t configured -- resuming normal operations 正则表达式为： ^\[(.*)\] \[(.*)\] \[(.*)\] (.*).* 解析结果如下： 表5 Apache server日志解析结果 列号 样值 1 Mon Jan 08 20:43:51.854334 2018 2 mpm_event:notice 3 pid 36465:tid 140557517657856 4 AH00489: Apache/2.4.12 (Unix) OpenSSL/1.0.1t configured -- resuming normal operations

Django日志 日志样例： [08/Jan/2018 20:59:07 ] settings INFO Welcome to Hue 3.9.0 正则表达式为： ^\[(.*)\] (\w*) (\w*) (.*).* 解析结果如下： 表4 Django日志解析结果 列号 样值 1 08/Jan/2018 20:59:07 2 settings 3 INFO 4 Welcome to Hue 3.9.0

Tomcat日志 日志样例： 11-Jan-2018 09:00:06.907 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux 正则表达式为： ^(\d.*\d) (\w*) \[(.*)\] ([\w\.]*) (\w.*).* 解析结果如下： 表3 Tomcat日志解析结果 列号 样值 1 11-Jan-2018 09:00:06.907 2 INFO 3 main 4 org.apache.catalina.startup.VersionLoggerListener.log 5 OS Name:Linux

Log4J审计日志 日志样例： 2018-01-11 08:51:06,156 INFO [org.apache.sqoop.audit.FileAuditLogger.logAuditEvent(FileAuditLogger.java:61)] user=sqoop.anonymous.user ip=189.xxx.xxx.75 op=show obj=version objId=x 正则表达式为： ^(\d.*\d) (\w*) \[(.*)\] user=(\w.*) ip=(\w.*) op=(\w.*) obj=(\w.*) objId=(.*).* 解析结果如下： 表2 Log4J审计日志解析结果 列号 样值 1 2018-01-11 08:51:06,156 2 INFO 3 org.apache.sqoop.audit.FileAuditLogger.logAuditEvent(FileAuditLogger.java:61) 4 sqoop.anonymous.user 5 189.xxx.xxx.75 6 show 7 version 8 x

Log4J日志 日志样例： 2018-01-11 08:50:59,001 INFO [org.apache.sqoop.core.SqoopConfiguration.configureClassLoader(SqoopConfiguration.java:251)] Adding jars to current classloader from property: org.apache.sqoop.classpath.extra 正则表达式为： ^(\d.*\d) (\w*) \[(.*)\] (\w.*).* 解析出的结果如下： 表1 Log4J日志解析结果 列号 样值 1 2018-01-11 08:50:59,001 2 INFO 3 org.apache.sqoop.core.SqoopConfiguration.configureClassLoader(SqoopConfiguration.java:251) 4 Adding jars to current classloader from property: org.apache.sqoop.classpath.extra

数据治理 组织职责 在战略层面，由数据治理Sponsor和各部门负责人组成的数据治理领导组制定数据治理的战略方向，以构建数据文化和氛围为纲，整体负责数据治理工作的开展、政策的推广和执行，并作为数据治理问题的最终决策组织解决争议，监控和监督数据治理工作的绩效，并确保数据治理工作预算支持。 数据治理委员会和各领域数据治理工作组是数据治理战略在运作层面具体的实施团队。其中： 数据治理委员会：由数据治理负责人、数据治理专家和数据架构专家团组成，面向企业进行数据治理工作的统筹并提供工作指导，在整个企业范围定期沟通数据治理工作，形成数据质量精细化管控文化。根据数据治理领导组的愿景和长期目标，建立和管理数据治理流程、阶段目标和计划，设计和维护数据治理方法、总则、工具和平台，协助各数据领域工作组实施数据治理工作，对整体数据治理工作进行度量和汇报，并对跨领域的数据治理问题和争议进行解决和决策。 各领域数据治理工作组：在各领域数据范围内进行数据治理的工作，依据数据治理委员会制定的数据治理方法和总则，制定本领域数据治理目标和工作计划，负责领域数据资产的看护，维护更新相应数据标准和及相关元数据，设计本领域数据度量和规则，监控收集数据质量问题并持续改进提升，主动升级数据相关问题。最终完成领域内数据资产的看护，并支撑数据治理目标的达成。 领域数据治理工作组由数据Owner、数据代表、数据管家、数据专员和数据架构师组成。其中： 数据Owner（Data Owners）：数据Owner是领域数据治理工作的责任人。 制定本领域数据治理的目标，工作计划和执行优先级。 建立数据治理责任机制，将本领域的数据治理工作分解到工作组成员，并跟进及管理工作组工作。 设计数据质量规格，承接数据需求，对数据问题及争议进行裁决。 建设和维护本领域信息架构。 建立和推动领域数据文化和氛围。 数据代表（Data Representatives）：数据代表是领域数据治理工作的专家带头人。 深刻理解数据工作的目标、方法、规则、工具，并通过识别关键业务流程和IT系统，对本领域数据治理的路标和工作计划进行细化并排序，最终管理执行。 作为本领域数据治理专家，管理并解决问题和争议，必要时提交数据Owner进行裁决。 对业务环节数据的完整性、及时性、准确性、一致性、唯一性、有效性负责，确保行为即记录，记录即数据，并依据数据质量规格对本领域数据进行度量和报告。 落实本领域信息架构的建设和遵从，负责本领域数据资产的看护，维护相应数据标准和数据目录并更新发布。 承接上下游数据需求，并主动根据领域内应用场景和业务需求识别数据需求，对需求的实现进行推动和管理。 依据相关规定定义本领域数据安全等级，并进行数据授权管理。 数据管家（Data Stewards）：数据管家是领域数据治理工作的协助者。 确保领域治理工作的流程和内容规范，符合数据治理要求。 协助数据代表进行问题跟踪和解决。 梳理、维护并更新领域数据元数据（业务对象、数据标准、数据模型）。 推广和维护数据治理工具和平台在本领域的应用。 数据专员（Data Specialists）：数据专员是领域数据治理工作的专家团队。 基于本领域数据治理的工作计划，利用数据专项技能，支撑数据代表完成数据Owner分配的各类数据治理工作。 数据架构师（Data Architects）：数据架构师是领域数据治理工作在IT层面的代表。 开发和维护本领域的数据系统或子系统，确保数据在系统中得以记录，数据标准、数据质量规则、数据安全、主/参考数据管理、数据服务在系统中得以实施。 提供数据系统的数据相关信息（元数据、数据字典、数据血缘）。 协助执行IT相关的数据治理工作。 确保数据系统的技术方案符合本领域的信息架构，技术选择能够满足数据发展中长期的需求。 父主题： 数据治理组织架构

华为数据治理实践 华为数据治理的规范流程建设，完成了从数据产生、数据整合、数据分析与数据消费全价值流的规则制定。华为数据治理组织实践，建立实体化的数据管理组织，向公司数据管理部汇报，同时组建了跨领域数据联合作战团队。华为已建立统一的数据分类管理框架，指导各领域进行分类管理。华为信息架构框架，通过政策发文明确信息架构的定义和构成要素，在公司层面建立统一的架构方法。基于ISO8000标准，华为建立了数据质量管理框架和运作机制，每年例行开展两次公司级数据质量度量，从“设计“与”执行”两个方面度量数据质量，由公司数据Owner定期发布公司数据质量报告，牵引各业务领域持续改进数据质量。 图1 华为数据治理愿景与目标 图2 华为数据治理能力 父主题： 华为数据治理案例

数据治理模块域 数据治理主要专注于如下模块域： 数据集成 数据集成用来完成数据入湖动作，不是简单的数据搬家，而是按照一定的方法论进行数据备份。数据入湖的前提条件是满足6项数据标准，包括：明确数据Owner、发布数据标准、定义数据密级、明确数据源、数据质量评估、元数据注册。此标准由数据代表在入湖前完成梳理并在数据治理平台上进行资产注册。 数据标准 数据标准管理着重建立统一的数据语言，各级数据层级业务对象的定义是数据标准的载体，并对应发布各数据层级的数据标准。各业务对象对应物理实现的IT系统需发布相应的数据字典并进行数据源认证。而对于梳理出来，但没有落IT系统的业务对象，需在后继的开发中进行数字化落地。 数据开发 数据开发是编排、调度和运维的中心，数据开发是一个提供分析、设计、实施、部署及维护一站式数据解决方案，完成数据加工、转换和质量提升等。数据开发屏蔽了各种数据存储的差异，一站式满足从数据集成、数据清洗/转换、数据质量监控等全流程的数据处理，是数据治理实施的主战场。 数据质量 数据质量管理的目标在于保证数据满足使用的要求。数据标准是衡量数据质量最基本的基准。数据质量要求各业务部门对相应数据领域的数据质量全权负责，按业务需求设计数据质量标准，制定数据质量管控目标，并遵循企业数据治理要求进行数据质量度量，制定符合各自业务情况的数据质量政策及数据质量相关的改进计划，持续进行数据质量管控。 数据资产 数据资产包括业务资产、技术资产、指标资产等。数据资产管理是数据治理的重要支撑手段，核心是构建企业级的元数据管理中心、建立数据资产目录、建立数据搜索引擎、实现数据血缘和数据全景可视。其中元数据包括业务元数据、技术元数据和操作元数据，要求将企业所有概念数据模型、逻辑数据模型以及物理数据模型系统化地管理起来，同时建设企业数据地图及数据血缘关系，为数据调用、数据服务、数据运营及运维提供强有力的信息支撑。 数据服务 数据服务通过在整个企业范围统一数据服务设计和实现的规范并进行数据服务生命周期管理，集约管理数据服务并减少数据调用和集成的开发成本。 数据安全 由于企业使用的数据资源，既有来自于内部业务系统，所有权属于企业的数据，同时也有来自外部的数据，必须将数据安全纳入数据治理的范畴，对所有企业数据要求依据数据安全等级定义进行数据安全定级，在数据产生、传输、存储和使用的过程中进行必要的数据安全访问控制，同时对数据相应的CRUD活动均需产生日志以完成安全审计。 主数据 主数据管理是数据标准落地和提升数据质量的重要手段，是企业级数据治理的重要范畴，其目标在于保证在企业范围内重要业务实体数据的一致（定义和实际物理数据的一致）。主数据管理首先进行企业主数据的识别，然后对已识别主数据按照主数据规范要求进行数据治理和IT改造，以支撑企业业务流和工具链的打通和串联。 管理中心 数据治理的开展离不开组织、流程和政策的建设，管理中心也管理着数据治理过程中公共核心的统一数据源、数据驾驶舱等，满足不同角色的用户拥有个性化的工作台。 父主题： 数据治理框架

新冠疫情数据治理思考 中共中央政治局常务委员会2020年2月3日召开会议强调：这次疫情是对我国治理体系和能力的一次大考。全民抗疫的过程中，缺乏有效数据支持就是缺乏对于疫情的快速响应机制、缺乏对于医疗资源合理调配的能力。 通过数据治理，我们可以构建开放通用的数据采集接口，提高数据采集效率；统一数据标准，轻松融合数据；建立跨平台的数据提取和数据追溯，实现开放共享，打通信息孤岛；保护隐私数据，构建可信数据。 以“健康码”为依托的各类政务小程序，正在加速提升市民信息化应用能力，基于数据治理、数据共享，很可能在不久以后，我们就可以实现“一码走天下”。将线上疫情应急治理体系转变为常态化管理体系，降低日常行政成本，发挥更大的数据流动与服务价值。通过自主申报健康信息，民众可获取反映健康状况的健康码，并凭码通行社区、办公楼、交通口等核验场景。在防疫初期，健康码有助于防止线下扎堆填报信息带来的病毒传染风险，一改政府人海战术排查病患的做法；随着疫情得到初步控制，健康码实现的人员行程追踪、同行密切接触人员自查等功能亦助力企业复工复产。随着各地复工复产加速，跨区域人口流动为疫情防控带来新的挑战，统一各层级政府和不同部门的数据标准，共享确诊、疑似病例、密切接触者、县域风险等级数据库是当下数据治理的关键。

高质量数据是业务创新的基础 企业在市场中的竞争领域已经从同一领域市场份额争夺，发展到开发新竞争领域的创新性竞争阶段，这从客观上对企业的创新能力提出了更高的要求，现在企业的创新在很大程度上要借助科技的手段，在业务数据的开发和利用基础上进行创新，数据为企业实施有效的创新提供了丰富强大的动力。 企业数据繁杂，无标准，质量低。 企业的IT系统经历了数据量高速膨胀的时期，这些海量的、分散在不同角落的数据导致了数据资源利用的复杂性和管理的高难度。企业无法从统一的业务视角去概览整个企业内部的数据信息。暴露出来的只是一个个独立的系统，系统与系统之间的关系、标准数据从哪里获取都无从知晓。