1.1. 大部分用于提取洞察的数据都是直接或间接地从客户交互中收集的，所以如果数据集包含客户的详细信息，特别是PII（如姓名、地址、社保号等），则企业需要确保数据的使用符合用户的数据偏好

1.2. 数据权限法规越来越多

1.3. 收集数据的权限

1.3.1. 对收集个人数据和收集的信息类别的知情权

1.4. 使用数据的权限

1.4.1. 限制处理的权限（即数据的使用方式）

1.4.2. 选择不出售个人信息的权利

1.4.3. 向其出售信息的第三方的身份

1.5. 删除数据的权限

1.5.1. 有权删除与应用程序共享的个人数据，以及与任何第三方共享的个人数据

1.6. 获取数据的权限

1.6.1. 获取客户个人数据的权限

1.6.2. 如果数据不准确或不完整，则有权更正

1.6.3. 数据提取权，允许个人获取和重用个人数据

1.7. 确保合规性需要数据用户和数据工程师合作

1.7.1. 数据科学家和其他数据用户希望有一种简单的方法来确定给定用例的所有可用数据，而不必担心违反合规性

1.7.2. 数据工程师必须确保他们已经正确定位了所有的客户数据副本，并以全面、及时和可审计的方式来执行用户的权限

1.8. 合规性是一种平衡，既要利用洞察更好地服务于客户体验，又要确保数据的使用符合客户的意愿—没有简单的启发式解决方案

1.9. 痛点

1.9.1. 很难确保客户数据只用于正确的用例，因为这些用例变得越来越细粒度

1.9.2. 在数据孤岛和缺少用户统一标识（特别是随着时间的推移而获得的标识）的情况下，跟踪适用的客户数据难度较大

1.9.3. 执行客户数据权限请求必须及时和可审计，并且需要采取适当的措施来确保请求不是伪造的

1.9.4. 需要以一种可互操作的格式打包所有客户的个人数据，同时确保内部模式不会被逆向工程破解

1.10. 需要识别可用的数据，所以新用例花费的时间会更长

1.11. 各地新兴的数据法规需要不断地重新评估现有用例的可用数据范围

1.12. 理想情况下，自助式数据权限治理服务能够跟踪数据的生命周期：数据在哪里生成、如何转换以及如何在不同用例中使用

1.13. 该服务能够自动执行数据权限请求，并自动确保数据仅用于正确的用例

1.14. 数据治理是一个平衡的过程，既要更好地提供具有洞察力的客户体验，又要确保数据的使用符合客户的要求

1.14.1. 对于拥有大量SaaS客户的企业来说，数据治理服务必不可少

2.1. 数据是体验的根本，数据权限治理服务的所有阶段都需要数据：发现、构建、训练和部署后的优化

2.2. 数据权限允许用户完全控制与任何企业共享的个人数据

2.3. 客户可能会改变他们对不同用例使用数据的许可，所以治理服务的投入是持续的

2.4. 执行数据权限请求

2.4.1. 个人数据只应存储于有需要的地方

2.4.2. 个人数据应在被请求或关闭账户时删除

2.4.3. 个人数据只有在用户同意的情况下才可以处理

2.5. 数据集发现

2.5.1. 从原始数据中产生的洞察的质量直接依赖于可用的数据

2.5.2. 数据科学家、分析师和更广泛的用户需要了解哪些数据可用于给定的用例

2.5.3. 数据用户希望分析尽可能多的数据，以提高模型的准确性，他们希望根据客户偏好尽快发现和访问可供分析的数据

2.5.4. 客户可能希望从特定用例中排除数据

2.6. 模型重新训练

2.6.1. 客户数据权限偏好可能会不断更改。在刷新模型和其他洞察时，需要考虑这些偏好的更改

2.6.2. 模型训练会根据保留时间窗口逐步添加新样本进行训练，并丢弃旧样本

2.6.3. 在训练过程中屏蔽PII数据，从而免去丢弃数据的步骤

2.6.3.1. 由于存在重新识别风险，屏蔽可能不是一个好办法

3.1. 包括跟踪数据生命周期和客户偏好、执行客户数据权限请求以及确保根据客户偏好使用正确数据等步骤花费的时间

3.2. 跟踪客户数据生命周期

3.2.1. 包括跟踪如何从客户处收集数据、如何存储和标识数据、如何持久化客户偏好、如何与第三方处理器共享数据，以及如何通过不同的管道转换数据

3.2.2. 挑战

3.2.2.1. 客户有多个不同的ID标识，尤其是通过收购整合的企业产品

3.2.2.2. PII数据需要采取适当级别的加密和访问控制

3.2.2.2.1. PII数据需要根据对数据语义（而不仅仅是模式）的理解进行分类

3.3. 执行客户数据权限请求

3.3.1. 包括执行与数据收集、使用、删除和访问有关的客户数据权限

3.3.2. 挑战

3.3.2.1. 需要对请求进行验证，以防止欺诈性请求

3.3.2.2. 需要能够从所有数据系统中删除与客户关联的特定数据

3.3.2.2.1. 鉴于存储格式是不可更改的，删除数据有些棘手，需要了解格式和命名空间组织

3.3.2.2.2. 无法删除的记录需要隔离，而且需要手动筛选异常记录

3.3.2.3. 为了防止内部数据格式被逆向，需要确保在可移植性请求中不泄露知识产权秘密

3.4. 限制数据访问

3.4.1. 包括确保根据客户的偏好将客户数据用于正确的用例

3.4.2. 需要了解用例需要什么数据元素、用例将生成何种类型的洞察，以及是否与合作伙伴共享数据

3.4.3. 将客户偏好匹配到用例需要复杂的访问策略

3.4.3.1. 持久化使用偏好的元数据要能够适应细粒度的用例

3.4.3.2. 元数据需要具有较好的性能，能够适应不断变化的客户偏好，并且每次都需要评估

4.1. 差异

4.1.1. 数据湖和事务型数据库系统中数据管理的成熟度

4.1.2. 不同垂直行业中企业的合规要求

4.1.3. 与数据分析和机器学习相关的用例类别

4.1.4. 用户偏好和数据元素的粒度

4.2. 当前痛点问卷

4.2.1. 该问卷的目标是了解现有数据平台部署中的关键问题

4.2.2. 客户数据的标识

4.2.3. 跟踪沿袭的能力

4.2.4. 用例清单

4.2.5. 管理PII数据

4.2.6. 速度和容量

4.2.6.1. 关键KPI是规范数据集的数量、客户请求的数量以及涉及删除和访问操作的系统的数量

4.3. 互操作检查表

4.3.1. 治理服务需要与现有系统一起工作

4.3.2. 存储系统

4.3.2.1. S3、HDFS、Kafka、关系数据库、NoSQL存储等

4.3.3. 数据格式

4.3.3.1. Avro、JSON、Parquet、ORC等

4.3.4. 表管理

4.3.4.1. Hive、Delta Lake、Iceberg等

4.3.5. 处理引擎

4.3.5.1. Spark、Hive、Presto、TensorFlow等

4.3.6. 元数据目录

4.3.6.1. Atlas、Hive Metastore等

4.3.7. 第三方数据处理器

4.3.7.1. 电子邮件活动管理工具、客户关系管理系统等

4.4. 功能性需求

4.4.1. 当不再需要个人数据或同意撤回个人数据时，从备份或第三方中删除它们

4.4.1.1. 需要能够从所有系统中删除特定的数据子集或与特定客户相关的所有数据

4.4.2. 管理客户对要收集的数据的偏好、行为数据跟踪、数据用例和通信

4.4.2.1. 不要出售数据偏好

4.4.3. 发现违规

4.4.4. 发现还没有在SLA中清除的数据集

4.4.5. 根据用户角色和权限验证数据权限请求

4.4.6. 支持不同级别的访问限制

4.4.6.1. 基本限制（访问数据集是基于业务需求）

4.4.6.2. 默认隐私数据（默认情况下用户不应该访问PII数据）

4.4.6.3. 经许可访问（只有经过用户同意才能访问的特定用例数据属性）

4.5. 非功能性需求

4.5.1. 直观的数据可移植性

4.5.1.1. 当客户请求数据时，以易于获取和广泛适用的可读格式提供数据

4.5.2. 能够处理突发的请求

4.5.2.1. SaaS应用程序可能拥有数百万个客户

4.5.3. 直观地为客户执行数据权限

4.5.3.1. 直观地为客户执行数据权限

4.5.4. 系统的可扩展性

4.5.4.1. 随着新的功能模块被添加到平台中，数据权限治理服务应该能够轻松地实现互操作

5.1. 敏感数据发现与分类模式

5.1.1. 该模式发现客户敏感数据并对数据进行分类，目标是使组织能够定位和标记其最敏感的数据（包含PII数据或商业机密数据），以便正确执行客户数据权限

5.1.2. 数据发现是定位用户数据存储位置，并检测敏感PII数据以确保数据权限合规的过程

5.1.3. 分类是对数据进行逻辑标记，以给出上下文和理解信息类型的过程

5.1.4. 工作原理

5.1.4.1. 数据发现守护进程收集了数百个关于每个数据字段的数据点值，并提取数据指纹

5.1.4.2. 机器学习算法（例如聚类算法）可以对相似的字段进行分组—通常有数百个字段，包括数据的派生字段

5.1.4.3. 当数据字段在元数据目录中被分类时，标签会在所有其他字段中传播

5.1.5. Macie提供了一个内容类型库，每个类型都有一个指定的灵敏度等级分数

5.1.5.1. Macie支持多种压缩和存档文件格式，如bzip、Snappy、LZO等，能持续监控数据访问活动的异常情况，并生成告警

5.2. 数据湖删除模式

5.2.1. 该模式主要用于在数据湖中删除与客户关联的数据

5.2.1.1. 事务性数据存储中的数据接入数据湖中用于下游分析和洞察

5.2.2. 为了满足合规性要求，客户的删除请求需要确保从原始数据集和派生数据集以及数据湖中的所有数据副本中删除数据

5.2.3. 工作原理

5.2.3.1. 当收到客户的删除请求时，它会在事务源中被软删除

5.2.3.2. 在接入过程中，删除与客户相关的记录

5.2.3.2.1. 考虑到数据格式的不可变性，删除会导致大量的写操作（即读取所有记录并重写）

5.2.3.2.2. 删除记录也被发送到第三方处理器

5.2.3.3. 对于历史分区，删除是通过批处理的异步进程处理的

5.2.3.3.1. 多个客户的删除记录在单独的表中进行跟踪，并在批处理操作中批量删除，同时仍然确保合规性SLA

5.2.4. Apache Gobblin

5.2.5. OpenDSR规范为数据控制器和处理器定义了一种通用的方法，用于构建可互操作的系统，以跟踪和完成数据请求

5.3. 用例相关的访问控制

5.3.1. 该模式的目标是确保根据客户的偏好将数据用于适当的用例

5.3.2. 数据用户在提取洞察时不应该担心违反与数据使用相关的合规性

5.3.3. 带外控制

5.3.3.1. 通过对文件、对象、表和列的细粒度访问控制来实现

5.3.3.2. 基于与数据对象关联的属性，将访问限制在与具体用例相对应的团队

5.3.3.3. Apache Atlas

5.3.3.4. Ranger

5.3.3.5. AWS Data Lake Formation

5.3.4. 带内控制

5.3.4.1. 通过访问时从底层物理数据动态生成的逻辑表和视图来实现

5.3.4.2. 实现带内访问控制需要大量的工程投入，在现有客户端和数据存储之间引入一个中间控制层

5.3.4.3. 带内控制更加细粒度、更加可靠，可以对不断变化的客户偏好快速做出反应

5.3.4.4. LinkedIn的Dali