• [技术干货] [技术干货] 大数据干货合集(2024年10月)
    大数据时代的到来,颠覆了传统业态的运作模式,激发出新的生产潜能。数据成为重要的生产要素,是信息的载体,数据间的流动也潜藏着更高阶维度的价值信息。对于数据控制者和数据处理者而言,如何最大化数据流动的价值,是数据挖掘的初衷和意义。然而,一系列信息泄露事件的曝光,使得数据安全越来越受到广泛的关注。各国各地区逐步建立健全和完善数据安全与隐私保护相关法律法规,提供用户隐私保护的法律保障。如何加强技术层面的数据安全和隐私保护,对数据仓库产品本身提出更多的功能要求,也是数据安全建设最行之有效的办法。数据脱敏https://bbs.huaweicloud.com/forum/thread-0220164693512617001-1-1.html如何实现动态数据脱敏https://bbs.huaweicloud.com/forum/thread-02127164695040498014-1-1.html数据脱敏执行过程https://bbs.huaweicloud.com/forum/thread-0216164695086814006-1-1.html实时数据分析技术https://bbs.huaweicloud.com/forum/thread-0221164695465811006-1-1.html数据仓库平台ETLhttps://bbs.huaweicloud.com/forum/thread-0223164695971148003-1-1.html数据抽取、转换、加载的过程https://bbs.huaweicloud.com/forum/thread-0216164696074366007-1-1.htmlETL系统实现要点https://bbs.huaweicloud.com/forum/thread-0244164696109213008-1-1.htmlGSQL封装https://bbs.huaweicloud.com/forum/thread-0221164696179004007-1-1.html数据库智能运维https://bbs.huaweicloud.com/forum/thread-0221164696659769008-1-1.html数据库监控https://bbs.huaweicloud.com/forum/thread-0220164696910816002-1-1.html数据库监控服务https://bbs.huaweicloud.com/forum/thread-0216164696967861008-1-1.html数据库智能运维体系https://bbs.huaweicloud.com/forum/thread-0234164697022767009-1-1.html数据库智能运维典型用户与需求https://bbs.huaweicloud.com/forum/thread-0216164697066974009-1-1.html数据库智能运维指标https://bbs.huaweicloud.com/forum/thread-0220164697123832003-1-1.htmlMPP数据库https://bbs.huaweicloud.com/forum/thread-02117164697511918007-1-1.html
  • [技术干货] MPP数据库
    MPP数据库的特殊构型,数据库实例是作为进程试运行在节点上的。因此,我们的指标设计其实本身会自带维度属性,比如磁盘使用率指标,最小的维度应该是某个DN实例,上一级是节点级,再上一级就是整个集群。所以,我们实际提供的监控指标应该是指标维度关系与集群指标地图的一个笛卡尔积。为了描述这种情形,我们引入原子指标,派生指标和组合指标的概念。以上面的磁盘使用率为例,我们将DN实例的磁盘使用率作为原子指标,而其他维度的磁盘使用率作为派生指标。原子指标:描述数据库某个特性的最小维度指标,比如节点的CPU使用率,DN实例的磁盘使用率,等等。派生指标:(1)原子指标在不同维度上的聚合结果,比如集群平均CPU使用率,集群磁盘使用率,等等;(2)对原子指标做统计运算得到的新指标,比如CPU倾斜率,等等。组合指标:将多个原子指标或者派生指标组合在一起,从而得到的更加便于理解的新指标。比如集群健康度,等等。目前DMS的指标建设更多停留在原子指标和派生指标阶段,因为我们认为应该首先补齐数据库的基础指标形成基本的监控运维能力之后,才能结合用户使用习惯,深度挖掘指标在各个维度下的运维含义以及多种指标组合后所代表的运维意义。
  • [技术干货] 数据库智能运维指标
    数据库监控指标数量多,形式和逻辑复杂,根据指标类型可以分为逻辑关系与物理关系两种。其中逻辑关系指数库内部逻辑关系,比如,最顶层是数据库,数据库中有多个schema,schema中有多个表,数据库中有多个用户,一个用户可以有多个schema和表。而物理关系是指,gaussDB(DWS)集群的拓扑关系,比如,一个数据库集群是由多个计算节点构成,每个计算节点上会部署多个计算实例。这两种指标关系都会影响到数据库指标的采集维度和聚合展示维度。数据库是一个软件服务,而它必须运行在一个宿主机和操作系统之上,因此监控指标大致可以分为两类:系统资源类指标:这一类指标主要描述系统上的各种资源消耗。数据库相关指标:这一类指标主要描述数据性能相关的业务负载水平。DMS采集的数据库主要指标,具体指标项按照指标大类,原子指标和派生指标三个层次排列。不过,目前该指标地图并不固定,未来随着GaussDB(DWS)智能运维系统的逐步成熟,该指标地图会逐步完善并固定下来。
  • [技术干货] 数据库智能运维典型用户与需求
    为了进一步理清数据库智能运维产品的设计思路,我们计划从用户的角度分析其需求,然后从需求导出功能(工具)页面设计,从功能(工具)页面总结出所需监控数据库指标。通过分析数据库监控系统的各种使用场景,我们对数据库监控系统的用户做了用户角色画像,定义了数据库运维过程中的三种角色,并认为不同角色仅仅关注数据库运维的一个侧面。在实际的数据库运维场景中,可能同一个用户会身兼多种角色,但是这里我们为了方便分析仅仅从逻辑上定义这三种角色。应用开发:主要指客户侧的应用开发角色,他们负责设计具体的业务SQL。他们关心业务SQL执行的正确性和执行效率。应用开发工程师需要用到web SQL来调试其SQL语句的查询效率;需要用到查询监控页面来查看业务SQL在实际执行场景中的表现和资源消耗;需要用到工作负载队列监控来确认新开发的业务SQL是否在合适的工作负载队列中,以及所配置的熔断规则是否合理,等等。SRE:指的是华为云侧的数据库运维角色,他们通常一个人需要负责成百上千个集群的稳定运行,他们需要能够迅速识别出集群运行状态的异常,集群资源瓶颈以及集群潜在的扩容需求,并且他们还需要积极响应客户的求助,帮助客户定位,确认和解决问题。SRE需要节点资源监控来识别集群中的资源倾斜;需要识别集群资源消耗基线变化趋势,从而识别到扩容需并提醒用户;需要关注存储变化以推算下一次常规保养的时间点并自动规划;同时还需要响应用户需求,使用DMS提供的问题定位工具,辅助用户定位现网问题。DBA:指的是GaussDB(DWS)数据库集群专家,他们熟悉数据库设计方法论,数据库的调优,数据库问题定位。他们需要分析定位数据库的故障,从资源和业务角度运用多种工具综合分析定位系统故障,系统稳定性和潜在瓶颈;也需要帮助用户从业务、数据库设计的角度去推荐数据库的索引,分布列配置,根据用户业务水平推荐用户购买合适的集群规模等等;同时还需要辅助应用开发工程师调优引起性能劣化的SQL语句;在找到确切的故障根因后,推荐合适的解决方案修复故障。在一般来说在公有云场景中,用户角色一般只有应用开发和SRE两种,公有云场景中的SRE角色往往涵盖了DBA的角色。我们在这里将运维角色细分的目的,其实是要展示一个完整的运维场景沙盘,将客户的运维诉求分门别类的罗列出来,为后续进一步的功能(工具)页面设计和运维场景设计提供基础。
  • [技术干货] 数据库智能运维体系
    GaussDB(DWS)使用DMS来承载数据库的智能运维体系。DMS将会串起数据库运维过程中的监控,分析,处理三个步骤,分别对应上文提到的数据库智能运维体系中的眼,脑,手三部分,从概念设计上形成运维体系的闭环。监控部分:主要负责数据库运行状态数据的采集、存储和可视化展示,这一部分基本等同于传统的数据库的监控业务。这一部分功能和指标的选取,我们参考了友商以及运维团队的建议,将监控指标分为底层IT系统运维指标和数据库系统运维指标两类,正在分别逐步补齐和完善中。监控模块是DMS数据库运智能监控运维体系首先发力,并要在短时间内形成竞争力的模块。分析部分:作为整个DMS数据库智能运维体系的大脑,该部分是承担运维数据分析与决策的关键模块。该部分因为其复杂性,目前还处于设计构想阶段。初步规划有三个子模块,时间序列的趋势分析子模块,该模块主要用来做趋势预测分析,用来预判潜在的问题;逻辑推断子模块,用户分析问题现象与实际根因之间的关系,可以实现从问题现象到触发原因的推断,初步考虑使用搜索引擎技术实现;知识图谱子模块,主要用于现象、根因与解决方案之间的映射关系表示,方便从定位的根因中找到最合适的解决方案。处理部分:主要由DWS提供的数据库管理功能承担,目前可以提供数据库参数配置(可配置参数少,需要进一步丰富),工作负载队列配置,集群安装/卸载,集群重启,集群扩容,集群数据重分布以及节点温备等运维能力。
  • [技术干货] 数据库监控服务
    传统意义上的数据库监控服务仅仅是指:(1)采集数据库运行状态;(2)上报/存储数据库运行数据;(3)图形化展示数据库运行状态数据。但是,这仅仅是数据库智能监控运维体系的一部分。如果把整个数据库智能监控运维体系比作一个人的话,传统意义上的数据库监控服务仅仅代表了,眼睛的角色。该服务只能做到发现问题,识别定位问题和解决问题都需要DBA的介入。因此DBA才是传统数据库监控运维体系中的核心要素,这也是DBA人才为何如此关键的原因之一。而云时代的到来和大数据分析、人工智能等技术的成熟,给了数据库监控运维更多的想象空间。我可以在传统数据库监控(眼睛)的基础上,增加预测分析和根因判断模块,建立现象-根因-解决方案的映射关系(大脑),最后通过数据库管理模块执行解决方案(双手),从而实现从发现问题,定位问题,到解决问题的运维闭环。并且机器不同于人类,只要算力允许,它可以做到眼观六路,耳听八方,不知疲倦,也不会觉得无聊,7x24的盯着成百上千数据库系统的各种运行数据,不会放过任何一个微小的潜在问题。因此,数据库运维工作的智能化中,使用规则或算法固化DBA判断和决策经验将是非常重要的一环。
  • [技术干货] 数据库监控
    早期,数据库系统仅仅提供SQL命令来查询其内部的运行状态,导致数据库运维操作门槛高,易用性差,DBA一度成为高度专业化的关键岗位,享受高薪和大家羡慕的目光的同时,也为企业的数据安全带来了不确定性风险。并且,命令行运维不直观,严重依赖运维人员经验,不能做到快速的发现、定位、解决问题,导致数据库运维问题,发现难,定位难,解决难。为了应对这个窘境,数据库运行状态可视化(数据库监控系统)应运而生,通过可视化的手段以人类便于理解的图表形式,将重点数据以图形化的手段展示给运维人员,从而显著的降低了数据库运维的门槛,提高了数据库运维的效率。这个阶段有一些代表性的产品比如:OEM(Oracle), ViewPoint(Teradata),等等。但是,这个时期用户的数据的规模不是很大,数据库也依然部署在用户自己的数据中心,依然是几个DBA运维几套数据库的阶段。随着云时代的到来,云数据库逐渐托管了客户的数据存储服务,云化将一切繁重的IT运维工作都集中在云后台管理了起来,从而把客户从专业,复杂,繁重的数据中心运维活动中解放了出来,使客户能够更加专注于其核心业务。同时,云服务提供商作为数据存储服务的提供者,则需要在IT运维与数据库运维上深耕细作,发挥其团队稳定,专业化程度高,掌握海量数据库运行数据的优势;充分利用目前机器学习、人工智能领域的科研成果,使用技术手段逐步提高每名运维人员所能管理的数据库数量,从而实现数据库运维工作的“减员增效”。另一方面,数据库服务上云后,云服务提供商所需要运维的数据库数量与之前相比天差地别,以前的工具可能已经不适应云时代的需求。
  • [技术干货] 数据库智能运维
    数据库智能运维:初识数据库智能运维数据库智能运维(DMS)是GaussDB(DWS)为客户数据库快速、稳定运行实现保驾护航的能力,对业务数据库所使用磁盘、网络、OS指标数据,集群运行关键性能指标进行收集、监控、分析。通过综合收集到的多种类型数据,对数据库主机、实例、业务SQL进行诊断,及时暴露数据库中关键故障及性能问题,指导客户进行优化解决。产品优势:可视化手段通过可视化的手段以人类便于理解的图表形式,将重点数据以图形化的手段展示,从而显著的降低了数据库运维的门槛,提高了数据库运维的效率。运维无忧。将一切繁重的IT运维工作都集中在云后台管理,从专业,复杂,繁重的数据中心运维活动中解放出来,使客户能够更加专注于其核心业务。海量数据运行在IT运维与数据库运维上深耕细作,发挥其团队稳定,专业化程度高,掌握海量数据库运行数据的优势。减员增效充分利用目前机器学习、人工智能领域的科研成果,使用技术手段逐步提高每名运维人员所能管理的数据库数量,优化云端运维体验,从而实现“减员增效”。数据库智能运维体系DMS定义了监控,分析,处理三个部分,分别对应数据库智能运维体系中的眼,脑,手三部分,从概念设计上形成运维体系的闭环。监控部分:主要负责数据库运行状态数据的采集、存储和可视化展示。底层IT系统运维指标数据库系统运维指标分析部分:作为整个DMS数据库智能运维体系的大脑,该部分是承担运维数据分析与决策的关键模块。时间序列的趋势分析-用做趋势维护预测;逻辑推断一根因分析;知识图谱-用于现象、根因与解决方案之间的映射关系处理部分:主要由GaussDB(DWS)提供的数据库管理功能承担。工作负载队列配置集群安装/卸载集群重启/扩容集群数据重分布节点温备等其他运维操作。
  • [技术干货] GSQL封装
    增加封装的必要性:GSQL和调度软件解耦:调度软件都具备调用Python/Perl/Shell脚本的能力,通过脚本封装,把GSQL和调度软件解耦,降低GSQL和调度软件的适配兼容性风险;封装模板需要考量的功能点:调度命令到GSQL运行命令的转换:调度命令相对简单,和业务逻辑相关:如业务子系统代码,算法模板代码,数据日期等;GSQL的运行参数不需要或不应当暴露在调度系统接口下:如登录密码,verbose参数等级等与业务无关的或者为了便于运维,性能跟踪的额外参数;登录密码加密解密:GSQL登录密码不允许明文存储,需要密文方式保存在ETL服务器上,执行时候也需要避免出现在后台命令行中被ps指令查看到;异常处理:GSQL脚本运行出错后的异常处理功能:如重跑,告警通知等;运行日志解析:GSQL的运行日志解析:针对GSQL脚本中不同语句,不同事务的执行时间解析跟踪,错误,告警代码的解析跟踪,为性能分析提供最详细的底层数据;
  • [技术干货] ETL系统实现要点
    对于GaussDB(DWS)而言,大多数场合下推荐采用MPPDB方案。实现这种方案实际上要实现ETL SQL模板的封装,把ETL开发过程与外部ETL调度系统的结合进行分层处理。通过模板方式实现与调度软件,和操作系统的接口封装,把SQL实现业务的模块封装在GSQL工具中,开放给业务人员和开发人员,令其聚焦在业务实现本身,而不用在意外部环境对于ETL过程操作的影响。ETL调度数据仓库平台的ETL作业系统是一种后台非交互方式运行的批量数据处理系统。ETL作业调度是将数据仓库系统中运行的各种后台作业自动化,并监视和控制作业的运行。使用调度软件实现作业调度。作业可以分布在多个服务器平台上,能够设定作业定义、依赖关系、顺序关系、工作组关系等,方便地对作业进行自动调度、运行和管理。调度监管平台可以图形方式动态监视和控制作业的运行,对作业执行中出现的错误/警告提供详细的信息。ETL脚本封装:GSQL是执行SQL的工具,但是与调度软件之间的结合还有一定的功能缺失,如参数解析,日志解析,异常处理等,所以需要对GSQL进行必要的封装,提高和调度软件之间的契合度。gsql模板:对加工处理的etl过程进行抽象,总结,形成算法模板。指定必要的输入参数,设定会话启动的公共参数,为后续的优化和跟踪埋点打桩。调用形式:调度工具->Python或其他脚本工具模板->GSQL->{.gsql}
  • [技术干货] 数据抽取、转换、加载的过程
    数据抽取:数据抽取是从数据仓库的上游系统(通常是核心系统,业务系统或外部系统)进行全量或增量数据抓取的过程。而随着企业内部信息底层架构的完善和数据平台功能的划分,不同平台通常采用松耦合的方式进行关联。传统中下游系统直接到上游系统进行数据抽取的这种方式并不符合当前技术的发展趋势。一方面,下游系统直接到上游系统进行数据抽取操作牵涉到权限的开放管理,增加了上游系统的数据安全风险。另一方面,本身数据抽取操作也应当在业务系统自身正常业务完成后的时间窗口进行,以避免数据抽取时对正常作业流程的资源竞争。因此数据抽取这个环节的操作,通常是上下游系统进行接口协商,由上游系统按照接口规范进行数据卸载操作。或者对于更成熟的企业,会构建统一的数据交换平台来完成企业内部统一的数据抽取/卸载工作。对于数据仓库平台来说,数据抽取的工作更多的是形成统一的接口规范。数据转换:广义上的数据转换包括数据清洗,数据关联加工,数据标准化处理,数据汇总聚合等操作。大部分基于业务规则和数据模型的数据转换操作在MPPDB数据库内实现比在数据库外的ETL服务器上进行实现效率更高。而这种转换操作在数据库内通过SQL实现T过程,也比通过ETL工具实现T过程更具有标准化和开放性,适合业务人员参与T过程的开发,校验。数据加载:对于数据仓库而言,不仅仅是数据加载,还包括数据卸载,也就是Loading和Unloading过程。典型的场景就是在数据到达的高峰期进行大量的文件加载入库的操作。而库内数据加工完成后,及时地进行数据卸载操作,形成接口文件推送给下游系统。所以高效地批量数据加载和卸载操作是数据仓库ETL系统要面对的主要挑战之一。而随着客户对实时数据仓库的需求越来越普遍,数据库和消息队列,数据流组件之间的实时数据加载和卸载的技术则是当前ETL系统构建时面临的又一个技术挑战。
  • [技术干货] 数据仓库平台ETL
    在数据仓库平台建设过程中,数据的加载、卸载,各层数据模型之间的数据流转,业务规则的实现等等数据加工过程都会以ETL任务的方式实现。 构建ETL子系统是数据仓库系统实施的一个非常重要的环节,在仓库平台建设过程中搭建一个完整、标准的ETL子系统是数据仓库平台建设的基础性目标之一。ETL是Extraction(数据抽取),Transform(数据转换)和Loading(数据加载)这三个数据处理动作的缩写,也是早期数据仓库建设的数据流转处理顺序,因此形成的专用术语沿用至今。但是随着作为数据仓库核心的数据库引擎技术的不断发展,ETL模式也在不断发展和改变,逐渐形成了E-L-T,E-T-L-T等不同形式。对于GaussDB(DWS)为代表的MPPDB数据仓库平台,则多以ELT或是ETLT模式为主来构建ETL子系统。ETL子系统的建设目的是将企业中的分散、零乱、标准不统一的异构数据源的业务数据整合到一起,进行必要的清洗和转换,形成高质量的统一的数据模型,或者是便于用户查询,分析和探索的维度模型。借助专业化的ETL软件:Informatica, DataStage, Kettle等软件,采用分布式的/基于共享存储的ETL服务器集群方式部署ETL软件。在执行ETL任务的时候,数据从MPPDB读取出来,数据处理过程在ETL服务器完成,处理完结果再推送到数据库服务器,其中有些操作可以通过SQL Push down在数据库内完成。这种方案的特点在于整个ETL开发和部署过程图形化操作和脚本化操作方式结合,基于工具过程的开发也可以对ETL过程进行基于元数据的血缘分析,影响性分析;作业自动化编排,调度方面ETL工具的功能弱于专业的调度软件。基于ETL工具方案对于ETL开发过程来说需要专业的开发人员,要对ETL工具本身有很深入的了解,从这方面来说,过于专业化的工具门槛不利于企业内部的业务专家和分析人员介入ETL开发过程。
  • [技术干货] 实时数据分析技术
    GaussDB(DWS) 实时数仓新品,其具备快、易、简、省四大特点:1)快:实时数仓时序数据单机入库性能支持每秒10万条数据、每秒60万条流数据持续计算入库,并可线性扩展。2)易:支持基于SQL完成复杂流式计算语义定义,简化开发。以Druid监控的一个场景为例,仅用150行SQL代码实现了原有1900 行Druid脚本同样的功能。3)简:实现了1 = N。在一个平台内,同时实现Flink/Spark Streaming(流数据处理)+Druid(流数据预聚合)+InfluxDB(时序数据处理),简化了开发和运维工作。4)省:时序数据经过实时数仓的自适应压缩算法,最高可达40:1的压缩比,将多维度行列存储优化,数据冷热温自动分区,极大地减少存储空间,节省用户成本。华为云GaussDB(DWS)实时数据分析技术,在已支撑1000+大客户核心业务运行的标准数仓架构上进行演进,具备企业级内核的关键能力(高性能,高扩展,高可用,融合分析,智能运维)。针对实时数据分析场景,在统一架构下增加时序引擎和CEP引擎,实现T+0的实时数据与历史数据关联分析能力。该架构首创性的把多引擎融合在一起协同工作,在OLAP引擎基础上进行扩展,通过插件的方式扩展CEP引擎和时序引擎,使得数据在集群内流动,一数多用,高效多维度分析。在金融、5G、物联网、人工智能等领域,企业可借助华为GaussDB(DWS)实时数据分析技术,实现对时序数据和流数据的实时监控,实时分析,实时推荐等,助力企业在智能数据时代创造更多业务价值。当前华为云GaussDB(DWS)实时数仓已在华为流程IT运维大数据平台上线使用,解决了时序数据和流数据在业务使用中“装不进”“算不动”的挑战,真正做到实时入库持续计算。
  • [技术干货] 数据脱敏执行过程
    GaussDB(DWS)数据脱敏功能,基于SQL引擎既有的实现框架,在受限用户执行查询语句过程中,实现外部不感知的实时脱敏处理。关于其内部实现。我们将脱敏策略(Redaction Policy)视为表对象上绑定的规则,在优化器查询重写阶段,遍历Query Tree中TargetList的每个TargetEntry,如若涉及基表的某个脱敏列,且当前脱敏规则生效(即满足脱敏策略的生效条件且enable开启状态),则断定此TargetEntry中涉及要脱敏的Var对象,此时,遍历脱敏列系统表pg_redaction_column,查找到对应脱敏列绑定的脱敏函数,将其替换成对应的FuncExpr即可。经过上述对Query Tree的重写处理,优化器会自动生成新的执行计划,执行器遵照新的计划执行,查询结果将对敏感数据做脱敏处理。带有数据脱敏的语句执行,相较于原始语句,增加了数据脱敏的逻辑处理,势必会给查询带来额外的开销。这部分开销,主要受表的数据规模、查询目标列涉及的脱敏列数、脱敏列采用的脱敏函数三方面因素影响。GaussDB(DWS)产品数据脱敏功能,是数据库产品内化和夯实数据安全能力的重要技术突破,主要涵盖以下三个方面:一套简单、易用的数据脱敏策略语法;一系列可覆盖常见隐私数据脱敏效果的、灵活配置的内置脱敏函数;一个完备、便捷的脱敏策略应用方案,使得原始语句在执行过程中可以实时、透明、高效地实现脱敏。总而言之,此数据脱敏功能可以充分满足客户业务场景的数据脱敏诉求,支持常见隐私数据的脱敏效果,实现敏感数据的可靠保护。
  • [技术干货] 如何实现动态数据脱敏
    动态数据脱敏,是在查询语句执行过程中,根据生效条件是否满足,实现实时的脱敏处理。生效条件,通常是针对当前用户角色的判断。敏感数据的可见范围,即是针对不同用户预设的。系统管理员,具有最高权限,任何时刻对任何表的任何字段都可见。确定受限制用户角色,是创建脱敏策略的第一步。敏感信息依赖于实际业务场景和安全维度,以自然人为例,用户个体的敏感字段包括:姓名、身份证号、手机号、邮箱地址等等;在银行系统,作为客户,可能还涉及银行卡号、过期时间、支付密码等等;在公司系统,作为员工,可能还涉及薪资、教育背景等;在医疗系统,作为患者,可能还涉及就诊信息等等。所以,识别和梳理具体业务场景的敏感字段,是创建脱敏策略的第二步。产品内置一系列常见的脱敏函数接口,可以针对不同数据类型和数据特征,指定参数,从而达到不一样的脱敏效果。脱敏函数可采用如下三种内置接口,同时支持自定义脱敏函数。三种内置脱敏函数能够涵盖大部分场景的脱敏效果,不推荐使用自定义脱敏函数。MASK_NONE:不作脱敏处理,仅内部测试用。MASK_FULL:全脱敏成固定值。MASK_PARTIAL:使用指定的脱敏字符对脱敏范围内的内容做部分脱敏。不同脱敏列可以采用不同的脱敏函数。比如,手机号通常显示后四位尾号,前面用"*"替换;金额统一显示为固定值0,等等。确定脱敏列需要绑定的脱敏函数,是创建脱敏策略的第三步。
总条数:2323 到第
上滑加载中