数据分类分级怎么落地？把它拆成五步：定标准、建模板、自动识别、人工稽核、衔接保护措施。五步是有顺序的：标准不写清，模板就没法建；模板没建好，识别结果只是一堆标签；没有人工确权，清单担不了责任；不接到保护措施上，成果就停在纸面。五步走完的机构，检查时能拿出完整链条；只走前四步的机构，通常只能拿出一份说不清用途的清单。为什么很多项目停在“识别完成”最常见的失败模式是：工具上线了，识别跑了几轮，目录里躺着一堆标签，但项目推不动了。原因通常不在技术。数据安全团队做了全部技术工作，业务部门从头到尾没参与；识别结果没有人确认，级别定得对不对说不清；清单躺在工具里，脱敏策略还是按字段名人工配置的。到了检查节点，被问“谁负责”“怎么用的”，答不上来。把“工具上线”当成“项目完成”，是这类项目最常见的时间黑洞。五步总览步骤交付物验收要点常见失败① 定标准分类分级管理办法、分级定义说明业务部门能用自己的话说清每一级的含义标准只写成文件，没人看得懂② 建模板分类分级模板、敏感类型清单模板覆盖本机构主要业务字段直接套用通用模板，未做本地化③ 自动识别敏感数据目录初稿（含位置与类型）抽样核对覆盖度，无命名提示字段能否识别只做单一发现机制，冷数据漏掉④ 人工稽核经责任人确认的目录每个字段可追溯到责任人，留痕可查只做抽检，责任落不到人⑤ 衔接保护措施策略映射清单（级别对保护动作）抽查新增敏感字段，策略是否自动生效清单与策略两张皮，人工二次配置第一步：定标准，先把它写成机构口径标准这一步的目标不是找一份文件抄，而是形成本机构自己的分级定义。交付物是两份东西：一份分类分级管理办法，明确职责分工与工作流程；一份分级定义说明，用本机构的业务语言解释每一级意味着什么、对应什么管控要求。级数可以对齐 JR/T 0197-2020 的 5 级至 1 级（金融行业），框架可以对齐 GB/T 43697-2024 的核心、重要、一般三级，但定义必须本地化。验收要点只有一条：让业务部门用自己的话说一遍每级的含义。说得出来，标准才算立住；说不出来，后面所有的打标都会变成“安全团队说什么就是什么”，业务不认。第二步：建模板，把标准翻译成机器能用的规则模板是把管理制度变成机器可执行判断的中间层。交付物是分类分级模板和敏感类型清单：常见敏感类型（证件号、银行卡号、手机号、账户信息、地址、生物识别信息等）对应的识别方式，以及各级别对应的判定条件。行业标准给的是框架和刻度，模板要落到具体字段类型上。验收要点是覆盖度测试：拿本机构真实业务系统的字段清单跑一遍，看模板能覆盖多少。覆盖不到的部分，要么补模板，要么确认它确实不敏感——两种情况都要有记录。这里的差别在实践中很直观：通用模板在命名规范的字段上表现都不错，真正的分水岭在存量系统里那些命名混乱的字段上。第三步：自动识别，先把范围收拢识别这一步的目标不是给出最终答案，而是把需要人处理的范围收拢到可承受的量级。发现机制通常有两类。被动发现通过解析应用程序访问数据源的流量来识别，不需要数据库账号口令，也不受应用或数据库结构升级的影响；主动扫描通过配置数据源账号，采样并识别，覆盖更完整，包括当前没有业务流量的冷数据。一体化数据安全平台把两种机制放进同一个引擎，目录在两个方向上同时保持更新——这是保证目录既不漏、又不过期的前提。交付物是敏感数据目录初稿：字段位置、敏感类型、建议级别、待确认的责任人。验收要点有三个：抽样核对识别结果与人工判断是否一致；用无命名提示的字段专门测一轮；确认目录具备按周期自动更新的能力，而不是一次性的快照。第四步：人工稽核，责任必须落到人识别结果要变成可用的清单，中间差的就是这一步。交付物是经责任人确认的目录。做法上，数据安全团队下发任务与规则，业务人员在数据门户里只处理与自身业务相关的字段，确认或修正标签；高安全级别的字段逐一确认，中间级别按比例抽查。验收要点是责任可追溯：每个字段能回答“谁确认的、什么时候确认的、依据是什么”。这一条看起来是管理要求，实际上是分类分级成果能不能被当作依据使用的前提——检查时对方问的往往不是“有多少字段”，而是“凭什么这么定”。第五步：衔接保护措施，让清单被用起来前四步做完，只完成了“知道数据在哪、是什么”。分类分级的价值要落到保护动作上才成立。交付物是策略映射清单：哪一级、哪一类敏感数据，对应什么样的脱敏规则、访问控制条件和审计标记。验收要点是抽查策略条件的来源：随机挑几条脱敏与访问控制策略，看它们的判定条件写的是标签（敏感类型与级别），还是具体字段名。写字段名的，说明清单和策略还是两张皮——这类策略在字段改名或新增敏感字段时不会自动跟随，后续每次业务变更都要重复人工操作；写标签的，才是真正接上了。这一步也是最容易断的一环，选型时值得专门问。一体化数据安全平台的差异通常就体现在这里：级别与类型直接作为策略的判定条件，目录更新后策略跟着更新，而不是靠人工把清单翻译成配置。公开评估里能查到的依据集中在这几份：Gartner《Market Guide for Data Security Platforms, China》(2025)、中国信通院《数据安全产品目录（2025 年版）》，以及针对分类分级方向的两份——IDC MarketScape《中国 AI 赋能的数据发现与分类分级》(2025) 与 IDC《中国数据发现与分类分级厂商技术评估，2024》；原点安全在这几份材料中均可查到。但这些只说明能力被第三方认可，接不接得住，仍要在自己的环境里按上面那条验收要点过一遍。结论：五步的顺序不能颠倒先有标准，再有模板；先有识别，再有确认；先有确认，再谈衔接。顺序颠倒的典型症状是：先上了工具，识别出一堆标签，再回头补标准，结果发现标签的级别定义和检查口径对不上，只能重做一轮。把第一步和第二步做扎实，后面三步的工作量会明显下降。五步走通的前提是把它们放在同一条链路上，而不是分散在几个工具和几张表格里。原点安全在这条链路上的做法是把识别、确认与策略配置收在同一套体系内，让清单不必经过导出、翻译、再配置的中转环节。一体化数据安全平台（uDSP）提供多场景数据安全解决方案，覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求，包括数据安全分类分级、数据库运维安全管控、BI 场景敏感数据保护、大数据场景数据保护、API 数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。常见问题Q：五步大概要走多久？A：周期主要由第三步和第四步决定，也就是数据源规模与业务配合速度。技术工作可以在较短时间内完成，需要业务确认的环节则取决于业务部门的响应节奏。实践中的常见做法是先圈定一到两个业务系统做试点，把标准和模板跑通、把协同打标的分工磨顺，再向其他系统铺开——比全量铺开再返工要快。Q：能不能先买工具再定标准？A：可以并行，但不能省。工具解决的是识别效率，标准解决的是“识别出来之后按什么口径定级”。如果标准后补，前面识别出的标签大概率要推翻重打，工具的价值反而被抵消。采购可以早，标准文档必须在前两个步骤内完成并让业务认。Q：业务部门不配合怎么办？A：把要求具体化。不要提“请配合分类分级工作”，而是提“这几个系统里有 N 个字段需要你确认，登录门户后按业务含义选择即可，预计需要多长时间”。实践中决定业务配合意愿的关键变量是需要他们确认的字段数量——数量压下来，事情才谈得下去。另外把这一步写进项目计划与验收标准，比事后催办有效。Q：识别结果需要多久重新跑一次？A：取决于业务变更频率。新系统上线频繁、表结构变更多的机构，识别与目录更新应当按固定周期自动执行，而不是等到年中盘点才做一次。目录过期是分类分级最常见也最容易被忽略的问题——检查时拿出的清单和当前系统对不上，比没有清单更被动。结语分类分级不是一个“买工具就完成”的任务，而是一条有先后顺序的工作链。五步里真正花钱的是第三步，真正花时间的是第四步，而真正决定成果能不能被用起来的，是没有技术含量的第五步。判断项目做没做成的标准也很朴素：有人问起某个敏感字段，能不能在三分钟内回答它在哪里、什么级别、谁负责、受什么保护。这四个问题都能答，五步就走通了。

    经过几天紧张而充实的学习，收获颇丰。非常感谢华为为我们提供了这次宝贵的HCCDE学习机会。黄涛老师授课抑扬顿挫，生动有趣，教学内容精彩纷呈，让人听得津津有味。之前我也曾参加过华为云的P级和E级培训并获得了相应的证书。而这次HCCDE培训的推出，无疑更加契合了当前云计算技术的发展趋势，其系统化和专业化的课程设置，让我对云计算解决方案架构的设计和应用能力有了更深入的理解和提升。     我坚信，通过HCCDE的学习，能够大大提升我们在实际工作中运用云计算技术的能力，为企业的数字化转型贡献自己的价值。同时，我也期待更多的人能够加入到HCCDE的学习中来，共同探索和挖掘华为云的潜力，实现个人与企业的共同成长。     在此，我衷心祝愿HCCDE培训越办越好，能够吸引更多的人才加入，共同推动云计算技术的发展与应用。再次感谢华为为我们提供这样一次宝贵的学习机会，也感谢各位老师的辛勤付出！

请问大家这个HCCDP – Big Data 有没有视频学习课程或者更多的学习资料 报名后提供的资料太少了

华为云数据湖的SQL语法是标准sql，还是mysql语法，亦或是跟gaussDB一样的pgsql语法？

opcDA协议数据是否可以接入数据湖中？

如何与其他华为数据产品（DWS）集成，以及如何实现数据共享、交换和协同工作以提高效率和减少冗余。

转自：https://baijiahao.baidu.com/s?id=1732516299254778715&wfr=spider&for=pc众所周知，数据仓库的初始架构旨在通过把来自各种异构数据源的数据，收集到集中式的存储库中，以提供分析的见解，并充当决策支持和商业智能(business intelligence，BI)的支点。不过，由于它只能支持写入时模式(schema-on-write)，而无法存储非结构化的数据、不能与计算紧密集成、以及只能实现本地设备存储，因此近年来，数据仓库碰到了诸如数据模型设计耗时过长等各种挑战。尽管目前的数据仓库能够支持以在线分析处理(OLAP)服务器作为中间层的三层架构，但是它仍然属于一种被用于机器学*和数据科学的整合平台。此类平台虽然具有元数据层、缓存层和索引层，但是这些层次并非单独存在。下面，我将向您重点介绍如何改进当前的数据湖平台，并最终将其变成Lakehouse，以增强架构模式，进而改造传统的数据仓库。HDFS上图展示了传统数据仓库平台的逻辑架构。近年来，随着音频、视频等非结构化数据集的快速增长，许多组织和企业都在寻找和探索某种高级的替代产品，以解决与传统数据仓库系统相关的复杂性问题(正如本文开头所提到的各种痛点)。目前，业界常用的是于2006年面世的Apache Hadoop生态系统。通过利用HDFS(Hadoop分布式文件系统)，它解决了在被加载到传统数据仓库系统之前，将原始数据提取并转换为结构化格式(即：行和列的形式)的主要瓶颈问题。HDFS不但能够处理在商用硬件上运行的大型数据集，而且可以适应通常具有GB和TB体量的数据集应用程序。此外，它还可以通过在集群上添加新的节点，来进行水平扩展，以适应海量的数据，而无需考虑任何数据格式的需求。你可以通过链接—https://dataview.in/installation-of-apache-hadoop-3-2-0/，来进一步了解如何在多节点集群上安装和配置Apache Hadoop。Hadoop生态系统(Apache Hive)的另一个优势在于，它支持读取时模式(schema-on-read)。由于传统数据仓库具有严格的写入时模式原则，因此ETL(Extract-Transform-Load的缩写)步骤在遵守已设计好的表空间时，非常耗费时间。而通过一行语句，我们可以将数据湖定义为一个存储库，以存储大量原始数据的原生格式(包括：结构化、非结构化和半结构化等)，以用于后续分析，预测分析，通过执行机器学*代码与APP，来构建算法等大数据处理操作。如上图所示，由于没有适合的数据模式，因此数据湖在加载之前不需要进行任何数据转换，那么如何保持数据质量便成了一个大问题。数据湖并没有完全具备解决数据治理和安全相关问题的能力。因此，机器学*(ML)以及数据科学的应用，需要使用非SQL代码，来处理海量的数据，以便成功地部署和运行在数据湖上。但是与SQL引擎相比，由于缺乏已优化的处理引擎，因此数据湖往往无法很好地服务此类应用。而且，仅靠这些引擎，是不足以解决数据湖的所有问题，甚至取代数据仓库的。此外，数据湖中仍然缺少诸如ACID(原子性，atomicity;一致性，consistency;隔离性，isolation;持久性durability)属性等功能、以及索引等高效的访问方法。据此，构建在它上面的机器学*和数据科学等应用，也会遇到例如数据质量、一致性和隔离性等数据管理问题。因此，数据湖需要额外的工具和技术，来支持SQL查询，以便执行各种商业智能和报告。Lakehouse借助着S3、HDFS、Azure Blob等数据湖的处理能力，Lakehouse结合了数据湖的低成本存储优势，以开放的格式为各种系统提供访问，并凸显了数据仓库强大的管理和优化功能。目前，Databricks和AWS都相继引入了数据Lakehouse的概念。Lakehouse能够提高各种高级分析负载的速度，并为其提供更好的数据管理功能。如上图所示，Lakehouse通常分为五层，它们分别是摄取层、存储层、元数据层、API 层、以及最后的消费层。摄取层是Lakehouse的第一层，负责从各种来源提取数据，并将其传送到存储层。该层可以使用各种组件来摄取数据。其中包括：用于从IoT设备处流式传输数据的Apache Kafka、用于从关系数据库管理系统(Relational Database Management System，RDBMS)处导入数据的Apache Sqoop、以及支持批量数据处理的更多组件。由于计算层和存储层得到了分离，因此数据Lakehouse最适合云存储库服务。它可以利用HDFS平台在本地得以实施。在设计上，Lakehouse允许开发者将各种数据保存在诸如AWS S3等低成本对象的存储中，并作为使用标准文件格式(例如Apache Parquet)的对象。Lakehouse中的元数据层负责为湖存储(lake storage)中的所有对象提供元数据(即，提供有关其他数据片段信息的数据)。此外，它还可以管理如下方面：确保并发各项ACID事务使用更快的存储设备(如，处理节点上的SSD和RAM)缓存来自云服务对象所存储的文件通过索引，以加快查询的速度Lakehouses中的API层提供了两种类型的API：声明性DataFrame API和SQL API。在DataFrame API的帮助下，数据科学家可以直接使用数据，来执行他们的各种应用。例如，TensorFlow和Spark MLlib等机器学*代码库，可以读取Parquet等开放的文件格式，并直接查询元数据层。而SQL API可以用于为组合业务分析、数据挖掘、数据可视化等商业智能、以及各种报告类工具，获取数据。最后，消费层包含了诸如Power BI、Tableau等各种工具和应用。整个企业的所有用户都可以使Lakehouse的消费层，来执行各种分析任务。其中包括：商业智能化仪表板、数据可视化、SQL查询、以及机器学*作业等。此外，Lakehouse架构也最适合在组织内部，为各种数据提供单点式访问。小结Lakehouse架构是应对数据提纯的复杂性、查询的兼容性、热数据的缓存等需求产生的。目前，该单体架构尚处于初级阶段。但是，在不久的将来，Lakehouse作为一种数据工具，将能够实现数据发现、数据使用指标、数据治理等更加丰富的功能。

什么是数据湖数据湖（Data Lake） 是一个用于存储大规模原始和未处理数据的存储系统。与传统的数据库和数据仓库不同，数据湖接受各种类型和格式的数据，包括结构化、半结构化和非结构化数据，而不需要对数据进行事先的转换或预处理。数据湖的目标是为数据科学家、分析师和其他数据使用者提供更灵活、可扩展且可访问的数据存储方式。数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖，有如下定义。Wikipedia是这样定义的：数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝以及为了各类任务而产生的转换数据，各类任务包括报表、可视化、高级分析和机器学习。数据湖中包括来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF等）和二进制数据（如图像、音频、视频）。数据沼泽是一种退化的、缺乏管理的数据湖，数据沼泽对于用户来说要么是不可访问的要么就是无法提供足够的价值。数据湖的用途数据湖主要有如下5点用途存储大规模数据：数据湖可以存储海量的数据，无论数据的来源、类型和格式如何。这包括传感器数据、日志文件、图像、音频、视频等。数据集成：数据湖可以整合来自不同系统、应用和部门的数据，无需强制统一的数据模型。这为组织内数据集成提供了更灵活的途径。数据探索和分析：数据湖为数据科学家和分析师提供了更多探索数据的可能性。原始数据可以在需要时进行转换和分析，而不需要事先的预处理。支持大数据处理：数据湖可以与大数据处理框架（如Hadoop、Spark）集成，以进行复杂的数据处理、分析和挖掘。实时分析：数据湖还可以支持实时数据处理，从而使实时分析和反应更加容易。数据湖诞生的历史使命数据湖的诞生为我们工作生活带来了极大的便利，它解决了如下问题数据多样性和复杂性：传统数据库和数据仓库难以处理各种来源、类型和格式的数据。数据湖允许原始数据保留其本来的形式，避免了转换和预处理的繁琐过程。成本效益：存储和处理大量数据的成本持续下降，使得数据湖成为存储海量数据的经济有效方法。需求的不确定性：在实时分析和洞察领域，数据需求可能会不断变化。数据湖使组织能够更快速地适应新的数据需求。数据科学和机器学习：数据湖为数据科学家提供了更大的数据集，使他们能够进行更深入的分析和建模。总的来说，数据湖的出现为组织提供了一种更加灵活、可扩展和成本效益的方法，来存储和利用大量的多样化数据，以支持分析、洞察和决策。开源解决方案以下是一些开源的数据湖解决方案：Apache Hadoop：Hadoop 是一个大数据处理框架，它包括分布式文件系统（HDFS）和用于分布式计算的MapReduce。Hadoop可以用于构建数据湖，存储和处理大规模数据。Apache Spark：Spark 是一个快速、通用的大数据处理引擎，它支持批处理、实时流处理、机器学习和图计算等任务。Spark 也可以用于构建数据湖，并在数据湖中进行复杂的数据处理和分析。Apache Hive：Hive 是一个基于Hadoop的数据仓库系统，它允许使用类似SQL的语法查询和分析存储在Hadoop中的数据。Hive 可以与数据湖一起使用，以提供更灵活的数据存储和查询方式。Presto：Presto 是一个分布式SQL查询引擎，可以查询多种数据源，包括数据湖中的原始数据。它支持高性能、交互式查询，适用于数据探索和分析。Dremio：Dremio 是一个自助数据分析平台，它能够将数据湖中的原始数据转化为结构化数据，提供高性能的查询和分析。它还提供数据虚拟化、数据加速和自动化等功能。Delta Lake：Delta Lake 是一种开源的存储层，可以在数据湖上提供ACID事务、批处理和流式处理，以及模式演化。它在数据湖中引入了数据一致性和可靠性。Hopsworks：Hopsworks 是一个用于构建和管理数据湖的平台，它基于Hadoop和Spark，提供了数据工程、机器学习和数据科学的功能。请注意，这些解决方案都有不同的特点和用途，你可以根据你的需求和技术栈选择适合的开源数据湖解决方案。在选择解决方案时，还要考虑其社区支持、文档、易用性和性能等因素。

【问题来源】深圳容大【问题简要】一通会话，录音出现多个的问题【问题类别】CC-DIS【期望解决时间】在线等【问题描述】 1690011050-202351，使用openEYE呼入，不知道什么原因，trecordinfo表中出现了两条录音 （绝大多数情况下，一次呼入接听后挂机，无其他操作，只会有一次录音，有极少情况下会出现两条录音，而且录音时间前后衔接不上）  话单数据 INSERT INTO `icdbill_service_22_100`.`tcurrentbilllog`(`TABLEID`, `CALLID`, `CALLIDNUM`, `CALLERNO`, `CALLEENO`, `WAITBEGIN`, `WAITEND`, `ACKBEGIN`, `ACKEND`, `CALLBEGIN`, `CALLEND`, `SERVICENO`, `TRKNO`, `TRKGRPNO`, `MODNO`, `DEVICETYPE`, `DEVICENO`, `DEVICEIN`, `CALLTYPE`, `WAITCAUSE`, `RELEASECAUSE`, `SUBCCNO`, `VDN`, `MEDIATYPE`, `UVID`, `OrgCCNO`, `OrgCallID`, `OrgCalleeNo`, `OrgServiceNo`, `SerCCNO`, `SerService`, `UserLevel`, `UserType`, `CallInCause`, `EnterReason`, `LeaveReason`, `BillInfo`, `PreServiceNo`, `PreDeviceType`, `PreDeviceNo`, `PreDeviceIn`, `MediaInfoType`, `SkillID`, `LocationID`, `BillInfo1`, `BillInfo2`, `BillInfo3`, `BillInfo4`, `OBSServiceID`, `OBSUniqueID`, `CurrentSkillID`, `UapID`, `NetEntID`, `SubMediaType`, `InitVdnId`) VALUES (1454460, '1690011050-202351', -1, '10021', '121', '2023-07-22 15:30:50', '2023-07-22 15:30:50', '2023-07-22 15:30:50', '2023-07-22 15:30:59', '2023-07-22 15:30:59', '2023-07-22 15:31:44', 1, 10, -1, 56, 2, 20213, 'DEVICE_AGENT', 0, 0, 1281, 1, 1, 5, 104170889, 1, '-1--1', NULL, -1, 1, 1, 0, 0, -1, 0, 16, -1, 0, 0, 0, NULL, 1, 1, 0, -1, -1, -1, -1, '', '', 1, 0, 100, -1, 1);  录音数据 INSERT INTO `icdbill_service_22_100`.`trecordinfo7`(`CALLID`, `CallerNo`, `CalleeNo`, `AgentID`, `CallCenterID`, `VirtualCallcenterID`, `BeginTime`, `EndTime`, `FileName`, `CallType`, `ServiceNo`, `VisitTime`, `VisitFlag`, `MediaType`, `ModNo`, `TrkNo`, `ServiceID`, `ServiceInfo`, `CallInfo`, `StopReason`, `LocationID`, `RecordFormat`, `UserWantedSkillID`, `CurrentSkillID`, `CustLevel`, `UapInnerInfo`, `UsEncryptRecordID`) VALUES ('1690011050-202351', '10021', '121', 20213, 1, 1, '2023-07-22 15:30:51', '2023-07-22 15:31:02', 'Y:\\1\\0\\20230722\\20213\\1530501.V3', 0, 1, '2023-07-22 15:30:50', 104170889, 5, 56, 10, 0, '', '', 1, 0, 0, 1, 1, 0, 'D8010000', 65535); INSERT INTO `icdbill_service_22_100`.`trecordinfo7`(`CALLID`, `CallerNo`, `CalleeNo`, `AgentID`, `CallCenterID`, `VirtualCallcenterID`, `BeginTime`, `EndTime`, `FileName`, `CallType`, `ServiceNo`, `VisitTime`, `VisitFlag`, `MediaType`, `ModNo`, `TrkNo`, `ServiceID`, `ServiceInfo`, `CallInfo`, `StopReason`, `LocationID`, `RecordFormat`, `UserWantedSkillID`, `CurrentSkillID`, `CustLevel`, `UapInnerInfo`, `UsEncryptRecordID`) VALUES ('1690011050-202351', '10021', '121', 20213, 1, 1, '2023-07-22 15:31:24', '2023-07-22 15:31:44', 'Y:\\1\\0\\20230722\\20213\\1531233.V3', 0, 1, '2023-07-22 15:30:50', 104170889, 19, 56, 10, 0, '', '', 1, 0, 0, 1, 1, 0, 'D8010100', 65535);