1. 数据域1.1. 设计面向领域架构的过程被称为领域驱动设计(DDD)是一个非常困难和耗时的过程1.2. 分析数据应由与之关系最密切的业务领域拥有领域分为数据源或主要消费者1.3. 面向源领域的数据1.3.1. 是与数据来源的业务源头密切对应的分析数据1.3.2. 数据从源应用程序的业务数据库复制到域中并转换为协作分析数据1.3.3. 面向源的域可以有一个或多个来源数据通常来自该域的业务系统但也可能是其他域的运行或分析数据1.4. 汇总的域数据1.4.1. 汇总的域数据是组合或集成了其他域数据的分析数据通常用于提升查询性能1.4.2. 可将生产领域和销售领域的数据组合便于简单快速生成损益表或便于与消费者使用的数据模型1.5. 面向消费者的域数据1.5.1. 面向消费者的领域数据是经过转换的分析数据以满足一个或多个特定部门或用例的需求1.5.2. 面向消费者域几乎总是从源对齐域接收数据1.6. 非供应商的人员很难理解供应商的源对齐域因此而独立创建了供应商的消费者对齐域1.6.1. 在供应商的消费者对齐域中数据模型被简化供应商术语易于理解2. 不同拓扑2.1. 网格类型12.1.1. 所有域使用相同的拓扑2.1.2. 逻辑上每个域都有自己的数据湖但从实体上而言所有域的数据在一个数据湖中2.1.3. 当多个实体数据湖相距几公里会存在进行数据合并的性能问题2.1.4. 拥有一个物理数据湖可以大大简化数据的安全和监控以及灾难恢复备份工作2.2. 网格类型22.2.1. 域使用与网格类型1相同的技术2.2.2. 不是所有域共有一个企业数据湖而后各自有自己的数据湖2.2.3. 所有数据湖使用相同的技术2.2.4. 这使得基础设施真正实现了去中心化但也带来了连接所有数据湖的技术挑战以及合并来自多个域的数据性能问题2.3. 网格类型32.3.1. 每个域可使用任何技术和任何云提供商并拥有自己的数据湖3. 数据网格与数据编织3.1. 数据网格和数据编织都是重要的概念但它们扮演着不同的角色不应被混淆3.2. 数据编织的核心是一个架构框架设计用于数据网格内的一个或多个域3.3. 数据网格则是一个整体概念包含技术、战略和方法、战略和方法3.4. 数据编织的技术构架基础可以量身定制以支持数据网格中各种错综复杂的组件3.4.1. 它们之间的关系不是竞争或互换而是协同作用3.4.2. 一个数据网格可能包含多个数据编织每个数据编织都是根据各自领域的独特需求量身定制的3.5. 可以将数据网格中的每个域视为自己的生态系统3.5.1. 域可以建立、完善和运行自己的数据结构、确保其符合特定要求和目标3.5.2. 数据网格为分散和面向域的数据方法提供了蓝图而数据编织则为这些域提供了架构和技术基础设施3.5.3. 将它们结合起来使用可以实现更集成、更高效的数据基础设施3.5.4. 也适用于将数据网格与现代数据仓库或数据湖仓架构相结合4. 神话4.1. 使用数据网格是快速解决所有数据难题的灵丹妙药4.2. 数据网格将取代数据湖和数据仓库4.3. 如果数据仓库都失败数据网格将解决该问题4.4. 构建数据网格代表一切进行了中心化4.5. 可使用数据虚拟化创建数据网格4.5.1. 真正的数据网格方案与使用了数据虚拟化的数据编织之间是有巨大区别的5. 疑虑5.1. 哲学和概念问题5.1.1. 为了将团队统一到一个公共的数据网格认识上来需要考虑成立一个跨职能的管理委员会来决定功能定义和标准5.1.2. 可以采用利益相关者研讨会和形成文件的定义方式确保所有人一致5.1.3. 小规模试验项目可对这些定义进行实际性测试进而判断是否采用5.1.4. 在实现数据网格时开放社区和定期审查有助于维护该统一战线5.1.5. 拥有一份真实单一数据来源从而使组织的决策建立在可靠数据上不存在数据真实性的模糊或者分歧的情况5.1.6. 每人都基于相同信息组合进行工作使得业务更高效、更有成果5.1.7. 在数据网格中数据可从一个域读入、转换被另外一个域存储5.1.7.1. 这种动态拓扑极大增加了维护单一真实来源的难度5.1.8. 如果组织建立严格的数据管理制度以及采用中心化的数据目录​那么完全可以实现数据网格5.1.8.1. 伴随着跨域数据质量标准以及数据域之间的强力合作不仅仅单一真实数据源是可行的也增强了网格灵活性和扩展性5.1.9. 实现一个数据网格有着巨大风险尤其是相比数据仓库的公认成功来看5.1.10. 数据网格的前提是每个源系统可动态拓展来满足顾客需求5.1.10.1. 当某些数据资产成为生态系统中的“热点”​查询或使用量激增时这一点就会变得特别具有挑战性5.2. 在去中心化环境中组合数据5.2.1. 总是需要从多个域进行数据组合以便进行查询或生成报告5.2.2. 每个域往往只关注满足自己分析需求的数据产品5.2.3. 数据所有者会忘记思考将自己的数据与其他域的数据结合的方法也对自己的数据模型域与其他的融合投入很少5.2.4. 为防止CDM中的ID在多个域中重复*可以使用全局唯一标识符(GUID)或建立集中式ID管理系统来分配唯一ID5.2.5. 随着域构建其产品和数据模型其他域和消费者将使用他们的数据并根据这些数据模型组合来自多个域的数据5.2.6. 要解决跨域数据清理不一致的问题可以建立一个集中管理框架为清理或标准化数据设定标准定义5.2.6.1. 提供数据清理模板或共享库以节省时间并确保统一性5.2.6.2. 治理委员会或数据管理员可以帮助执行这些标准从而更容易地将来自多个域的数据合并在一起而不会出现问题5.3. 去中心化的其他问题5.3.1. 聚合域和消费者对齐域见第13章并不是去中心化的5.3.2. 要创建聚合域就需要从多个域中获取数据并将这些数据集中起来5.3.3. 为了使聚合域和消费者对齐域能与数据网格的原则相协调应考虑共享治理和专门数据管理员来管理这些域5.3.4. 利用数据虚拟化尽量减少重复并实施API层进行抽象5.3.4.1. 通过强大的元数据和审计跟踪保持透明度5.3.5. 在中心化构架中一个团队负责所有数据的安全5.3.6. 跨域时很难选择和实施相互一致的技术5.4. 复杂性5.4.1. 数据网格背后的理念非常复杂5.4.2. 数据网格的支持者声称数据网格的复杂性与组织的复杂性正好相反但这种复杂性也延伸到了组织的复杂性上5.4.3. 分布式团队涉及了更多人员而且他们不一定能有效沟通5.5. 重复5.5.1. 不可能总是直接从这些不可变数据访问原始数据因为通常存在安全或即时检索的问题5.5.2. 要想对源数据做任何处理就必须复制一份数据并将其存储到数据湖中5.5.3. 数据网格可能会导致更多数据副本因为域可能需要从其他域复制数据以完成其数据产品或创建聚合或面向客户的域5.5.4. 复制数据的问题延伸到数据产品5.5.4.1. 如果数据产品被复制其元数据也会被复制这样就会产生多个需要保持同步的相同元数据副本5.6. 可行性5.6.1. 迁移到数据网格是一项艰巨的任务需要在组织变革和技术实施方面投入巨资远远超过其他数据架构5.6.2. 导致更高的成本和更长的时间线可能需数月甚至数年后才能投入生产5.7. 人员5.7.1. 需要为每个域寻找和聘用高级工程技术人员以及其他技术工人5.8. 域层面的障碍5.8.1. 该域主管与中央IT部门制定了在未来几个月内创建分析功能的计划5.8.2. 提供可信的激励措施以弥补额外的工作、麻烦和延误5.8.3. 获得每个域对实施数据网格的支持5.8.4. 获得高层管理人员的支持5.8.5. 传达清晰的愿景展示每个域的益处5.8.6. 开展试点项目展示新方法的有效性5.8.7. 提供经济和非经济奖励鼓励参与5.8.8. 建立持续沟通的透明渠道5.8.9. 通过标杆域提供支持6. 成功实施数据网格的建议6.1. 如果已有数据解决方案并决定构建一个数据网格建议你采用中心辐射模式将数据网格作为中心式数据解决方案的扩展来构建6.2. 可以使用新数据创建新的数据网格但要根据业务需求使用当前的集中式数据解决方案对这些域进行补充6.3. 随着时间的推移不断将新数据中添加更多新域慢慢地将集中式数据迁移到数据网格中不要试图一下子就将所有集中式数据转换成数据网格6.4. 逐步实施数据网格的方式有助于管理对现有数据架构进行彻底改造带来的风险6.5. 逐步实施新领域的方式可以一边吸取经验教训一边据此做出必要的调整并将这些经验教训应用到后续的可以创建一个更强大的系统6.6. 随着时间的推移中心辐射式方法为企业文化转变铺平了道路促进了数据产品负责人、工程师和业务利益相关者之间的跨职能、领域驱动型合作6.7. 零散的数据网格实施是一种战略方法可以进行仔细规划、风险管理并与业务目标保持一致