读数据工程之道：设计和构建健壮的数据系统05底层设计（上）

1. 主要底层设计

1.1. 以前的数据工程周期只关注技术层，而工具和实践的持续抽象和简化已经改变了这一重点
1.2. 数据工程现在包含的不仅仅是工具和技术

• 1.2.1. 该领域现在正在向价值链上游移动，将数据管理和成本优化等传统企业实践与DataOps等新实践相结合
  

1.3. 底层设计

• 1.3.1. 安全
  
• 1.3.2. 数据管理
  
• 1.3.3. DataOps
  
• 1.3.4. 数据架构
  
• 1.3.5. 编排
  
• 1.3.6. 软件工程
  

2. 安全

2.1. 安全是第一个底层设计的原因

• 2.1.1. 安全必须是数据工程师的首要考虑因素，忽视安全的人将会面临危险
  

2.2. 数据工程师必须了解数据和访问安全，运用最小特权原则

• 2.2.1. 最小特权原则意味着只允许用户或系统访问基本数据和资源以执行预期的功能
  
• 2.2.2. 我们在缺少安全经验的数据工程师身上看到的一个常见反模式是向所有用户授予管理员访问权限
  
• 2.2.3. 只为用户提供他们今天完成工作所需的访问权限
  
• 2.2.4. 查询具有较小角色的表时，不要使用数据库中的超级用户角色
  
• 2.2.5. 将最小特权原则强加给我们自己可以防止意外损坏，并使你保持安全第一的心态
  

2.3. 数据工程师必须是称职的安全管理员，因为安全属于他们的领域

• 2.3.1. 数据工程师应该了解云和本地部署的安全最佳实践
  
• 2.3.2. 了解用户和身份访问管理(Identity Access Management，IAM)角色、策略、组、网络安全、密码策略和加密是很好的起点
  

2.4. 人和组织结构始终是任何公司中最大的安全漏洞

• 2.4.1. 往往会发现公司中有人忽视了基本的预防措施，成为网络钓鱼攻击的受害者，或者采取了其他不负责任的行为
  

2.5. 数据安全的第一道防线是创建一种贯穿整个组织的安全文化

• 2.5.1. 所有有权访问数据的个人都必须了解他们在保护公司敏感数据及其客户方面的责任
  

2.6. 数据安全还与时间有关

• 2.6.1. 为需要访问数据的人和系统提供数据访问权限，并且仅在执行工作所需的时间内提供数据访问权限
  
• 2.6.2. 应通过使用加密、令牌化、数据屏蔽、混淆和简单、强大的访问控制来保护数据，使数据无论是在运行中还是在静止状态都不可见
  

3. 数据管理

3.1. 数据管理已经存在了几十年，但直到最近才在数据工程中得到很大的关注

• 3.1.1. 数据治理、主数据管理、数据质量管理、元数据管理
  
• 3.1.2. 数据工具变得越来越简单，数据工程师要管理的复杂性也越来越低
  

3.2. 数据工程师管理数据生命周期，而数据管理包含数据工程师将用于在技术和战略上完成此任务的一组最佳实践

• 3.2.1. 如果没有管理数据的框架，数据工程师只是在真空中操作的技术人员
  
• 3.2.2. 数据工程师需要更广泛地了解数据在整个组织中的效用，从源系统到最高管理层，以及两者之间的所有地方
  

3.3. 数据管理表明数据对日常运营至关重要，就像企业将财务资源、成品或房地产视为资产一样
3.4. 数据管理实践形成了一个每个人都可以采用的有凝聚力的框架，以确保组织从数据中获取价值并适当地处理它
3.5. 内容

• 3.5.1. 数据治理，包括可发现性和问责制
  
  
  
  • 3.5.1.1. 数据治理首先是一种数据管理功能，可确保组织收集的数据的质量、完整性、安全性和可用性
    
  • 3.5.1.2. 有效的数据治理是有目的的开发并得到组织的支持
    
  • 3.5.1.3. 数据治理是数据驱动业务实践的基础，也是数据工程生命周期的一个关键任务部分
    
  • 3.5.1.4. 当数据治理得到很好的实践时，人、流程和技术就会协调一致，将数据视为关键的业务驱动力，如果数据问题出现，则会及时得到处理
    
  • 3.5.1.5. 数据治理的核心类别是可发现性、安全性和可问责性
    

    3.5.1.5.1. 发现性
    

    3.5.1.5.1.1. 在数据驱动型公司中，数据必须可用且可发现
    

    3.5.1.5.1.2. 终端用户应该能够快速可靠地访问他们完成工作所需的数据
    

    3.5.1.5.1.3. 他们应该知道数据的来源、数据与其他数据的关系，以及数据的含义
    

    
    
  
  
• 3.5.2. 数据建模和设计
  
  
  
  • 3.5.2.1. 为了通过业务分析和数据科学从数据中获得业务洞察力，数据必须采用可用的形式
    
  • 3.5.2.2. 将数据转换为可用形式的过程称为数据建模和设计
    

    3.5.2.2.1. 固件工程师为IoT设备开发记录的数据格式
    

    3.5.2.2.2. Web应用程序开发人员设计对API调用
    

    3.5.2.2.3. MySQL表模式的JSON响应
    

    
    
  • 3.5.2.3. 由于新数据源和用例的多样性，数据建模变得更具挑战性
    
  
  
• 3.5.3. 数据血缘
  
  
  
  • 3.5.3.1. 数据血缘描述了数据在其生命周期中的审计跟踪记录，跟踪处理数据的系统和它所依赖的上游数据
    
  • 3.5.3.2. 数据血缘有助于数据和处理数据的系统进行错误跟踪、问责和调试
    
  • 3.5.3.3. 具有为数据生命周期提供审计跟踪的明显好处，并有助于合规性
    
  • 3.5.3.4. 数据血缘在具有严格合规标准的大公司中已经存在了很长时间
    
  • 3.5.3.5. 数据可观测性驱动开发(Data，Observability Driven Development，DODD)
    

    3.5.3.5.1. DODD一直观测其血缘的数据
    

    3.5.3.5.2. DODD的目的是让数据链中的每个人都能看到数据和数据应用程序，以便数据价值链中的每个人都能够从获取到转换再到分析的每个步骤中识别数据或数据应用程序的变化，以帮助解决或防止数据问题
    

    3.5.3.5.3. DODD专注于使数据可观测性成为数据工程生命周期中的首要考虑因素
    

    
    
  • 3.5.3.6. 在开发、测试和最终生产过程中应用此过程，以提供符合预期的质量和一致性
    
  
  
• 3.5.4. 存储和操作
  
• 3.5.5. 数据集成和互操作性
  
  
  
  • 3.5.5.1. 数据集成和互操作性是跨工具和流程的集成数据的过程
    
  • 3.5.5.2. 随着我们从单一栈分析方法转向异构云环境，该环境中的各种工具按需处理数据，集成和互操作性占据了数据工程师工作的越来越大的比重
    
  • 3.5.5.3. 集成越来越多地通过通用API而不是自定义数据库连接进行
    
  • 3.5.5.4. 通过与人的数据系统对话的相对简单的Python代码来管理，而不是直接处理数据
    
  
  
• 3.5.6. 数据生命周期管理
  
  
  
  • 3.5.6.1. 数据湖的出现鼓励组织忽视数据归档和销毁
    
  • 3.5.6.2. 数据越来越多地存储在云端
    

    3.5.6.2.1. 味着我们有即付即得的存储成本，而不是本地数据湖的大量前期资本支出
    

    
    
  • 3.5.6.3. GDPR和CCPA等隐私和数据保留法律要求数据工程师积极管理数据销毁，以尊重用户的“被遗忘权”​
    

    3.5.6.3.1. 数据工程师必须知道他们保留了哪些消费者数据，并且必须具有销毁数据的程序以响应请求和合规性要求
    

    
    
  • 3.5.6.4. 数据销毁在云数据仓库中很简单
    

    3.5.6.4.1. SQL语义允许删除符合where子句的行
    

    3.5.6.4.2. 数据销毁在数据湖中更具挑战性，其中一次写入、多次读取是默认的存储模式
    

    3.5.6.4.3. Hive ACID和Delta Lake等工具可以允许大规模删除事务的轻松管理
    

    
    
  • 3.5.6.5. 新一代元数据管理、数据血缘和编目工具也将简化数据工程生命周期的结束
    
  
  
• 3.5.7. 用于高级分析和机器学习的数据系统
  
• 3.5.8. 道德与隐私
  
  
  
  • 3.5.8.1. 数据会影响人
    
  • 3.5.8.2. 数据工程师需要在没人注视的时候做正确的事，因为总有一天每个人都会关注
    
  • 3.5.8.3. 数据工程师需要确保数据集掩盖个人身份信息(Personally Identifiable Information，PII)和其他敏感信息，可以在转换数据集时识别和跟踪偏见
    
  
  

4. 元数据

4.1. 元数据是“关于数据的数据”​，它支撑着数据工程生命周期的每个部分

• 4.1.1. 元数据正是使数据可发现和可治理所需的数据
  

4.2. 自动生成的和人工生成的

• 4.2.1. 现代数据工程围绕自动化展开，但元数据收集通常是手动的且容易出错
  
• 4.2.2. 自动化元数据工具不应将人完全排除在外
  
• 4.2.3. 工具可以爬数据库以查找关系并监控数据管道以跟踪数据的来源和去向
  

4.3. 低保真手动方法使用内部主导的努力，其中各种利益相关者在组织内众包元数据收集
4.4. 元数据成为数据和数据处理的副产品

• 4.4.1. 元数据工具的好坏取决于它们与数据系统的连接器及其共享元数据的能
  

4.5. 数据具有社会元素

• 4.5.1. 每个组织都在积累社会资本和关于流程、数据集与管道的知识
  
• 4.5.2. 以人为本的元数据系统关注元数据的社会方面
  

4.6. 文档和内部wiki工具为元数据管理提供了重要基础，但这些工具还应该与自动数据编目相集成

• 4.6.1. 应提供一个公开数据所有者、数据消费者和领域专家的场所
  

4.7. 业务元数据

• 4.7.1. 业务元数据与数据在业务中的使用方式相关，包括业务和数据定义、数据规则和逻辑、数据的使用方式和位置，以及数据所有者
  
• 4.7.2. 业务元数据为数据工程师提供正确的上下文和定义以正确使用数据
  

4.8. 技术元数据

• 4.8.1. 技术元数据描述了系统在整个数据工程生命周期中创建和使用的数据
  
• 4.8.2. 包括数据模型和架构、数据血缘、字段映射和管道工作流
  
• 4.8.3. 数据工程师使用技术元数据在数据工程生命周期中创建、连接和监控各种系统
  
• 4.8.4. 技术元数据类型
  
  
  
  • 4.8.4.1. 管道元数据（通常在编排系统中产生）
    

    4.8.4.1.1. 编排是协调跨各种系统的工作流的中央枢纽
    

    4.8.4.1.2. 编排系统可以提供操作元数据的有限情况，但后者仍然倾向于分散在许多系统中
    

    4.8.4.1.3. 在编排系统中捕获的管道元数据提供了工作流计划、系统和数据依赖性、配置、连接细节等的详细信息
    

    
    
  • 4.8.4.2. 数据血缘元数据
    

    4.8.4.2.1. 数据血缘元数据跟踪数据随着时间的推移的起源和变化，以及它的依赖性
    

    4.8.4.2.2. 随着数据流经数据工程生命周期，它会通过转换和与其他数据的组合而不断发展
    

    4.8.4.2.3. 数据血缘提供了数据在各种系统和工作流中移动时演变的审计线索
    

    
    
  • 4.8.4.3. 模式元数据
    

    4.8.4.3.1. 模式元数据描述了存储在数据库、数据仓库、数据湖或文件系统等系统中的数据结构
    

    4.8.4.3.2. 是不同存储系统的关键区别之一
    

    4.8.4.3.3. 模式元数据必须在元数据存储中进行管理
    

    4.8.4.3.4. 云数据仓库在内部管理模式元数据
    

    
    
  • 4.8.4.4. 操作元数据
    

    4.8.4.4.1. 操作元数据描述了各种系统的运行结果，包括进程统计、作业ID、应用程序运行日志、进程中使用的数据和错误日志
    

    4.8.4.4.2. 数据工程师使用操作元数据来确定流程是成功还是失败，以及流程中涉及的数据
    

    4.8.4.4.3. 对更高质量的操作元数据和更好的元数据管理的需求是下一代编排和元数据管理系统的主要动机
    

    
    
  • 4.8.4.5. 参考元数据
    

    4.8.4.5.1. 参考元数据是用于对其他数据进行分类的数据，也称为查找数据
    

    4.8.4.5.2. 参考数据的标准示例是内部代码、地理代码、测量单位和内部日历标准
    

    4.8.4.5.3. 大部分参考数据完全在内部管理，但地理代码等项目可能来自标准外部参考
    

    4.8.4.5.4. 参考数据本质上是解释其他数据的标准，因此如果它发生变化，则这种变化会随着时间慢慢发生
    

    
    
  
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！