读数据自助服务实践指南：数据开放与洞察提效06数据迁移服务

1. 数据迁移服务

1.1. 通常，必须将来自不同数据仓库或应用数据库的数据属性进行聚合以构建洞察
1.2. 数据迁移的痛点

• 1.2.1. 在异构数据源之间协调数据移动、持续验证源数据和目标数据之间的数据正确性以及适应数据源上通常发生的任何模式或配置更改
  

1.3. 确保及时提供不同来源的数据属性是主要难点之一

• 1.3.1. 在获取数据上花费时间会降低生产力，并会影响整体的洞察耗时
  
• 1.3.2. 理想情况下，迁移数据应该是自助式的，这样数据用户就可以选择一个源、一个目标和一个时间表来迁移数据
  

1.4. 此类服务的成功标准是减少数据可用性耗时
1.5. 数据的形式可能是表、流、文件、事件等，根据分析类型的不同，数据迁移可能对刷新延迟和一致性有不同的要求
2. 路线图

2.1. 跨数据源聚合数据

• 2.1.1. 传统上，来自事务型数据库的数据被聚合到数据仓库中用于数据分析
  
• 2.1.2. 数据源的种类显著增加，有结构化数据、半结构化数据和非结构化数据，包括事务型关系数据库、行为数据、地理空间数据、服务器日志、物联网传感器数据等
  
  
  
  • 2.1.2.1. 对数据用户来说，从这些数据源聚合数据难度较大
    
  
  
• 2.1.3. 更复杂的是，随着应用程序设计的微服务范式的出现，数据源变得越来越孤立
  
  
  
  • 2.1.3.1. 在微服务范式中，开发人员可以选择最适合其微服务的不同底层数据存储和数据模型
    
  • 2.1.3.2. 在现实世界中，一个典型的数据用户需要应对不同的数据孤岛，并且通常需要跨团队进行协调，管理产品交易数据、行为点击流数据、营销活动、账单活动、客户支持票据、销售记录等
    

    2.1.3.2.1. 在这种情况下，数据迁移服务的作用是在数据湖中自动聚合数据
    

    
    
  
  

2.2. 将原始数据迁移到专门的查询引擎

• 2.2.1. 越来越多的查询处理引擎针对不同类型的查询和数据工作负载进行了优化
  
• 2.2.2. 简化数据迁移可以为分析作业选择更合适的分析工具
  
• 2.2.3. 在基于云的架构中，查询引擎越来越多地直接运行在数据湖上，减少了迁移数据的需求
  

2.3. 将处理过的数据迁移到服务存储

• 2.3.1. 数据被处理后存储为键-值对，需要由应用程序向数百万个终端用户提供服务
  
• 2.3.2. 为了确保足够的性能和可扩展性，需要根据数据模型和一致性需求选择合适的NoSQL存储作为服务存储
  

2.4. 跨数据源进行探索性分析

• 2.4.1. 在模型构建的初始阶段，数据用户需要探索大量的数据属性
  
• 2.4.2. 探索阶段不需要完整的表，而是需要快速原型设计的数据样本
  
• 2.4.3. 鉴于原型设计工作的迭代性，非常有必要将数据迁移自动化为页面点击可实现的功能
  
• 2.4.4. 此场景是决定需要定期在数据湖中聚合哪些数据集的准备步骤
  

3. 最小化数据可用性耗时

3.1. 数据接入配置和变更管理

• 3.1.1. 数据必须从源数据存储中读取并写入目标数据存储中
  
• 3.1.2. 管理数据存储的源团队需要通过配置来开放数据读取功能
  
• 3.1.3. 通常，必须解决与源数据存储的性能影响相关的问题
  
• 3.1.4. 除非数据迁移是一次性的，否则需要进行持续的变更管理，以确保源数据在目标中正确可用
  

3.2. 合规

• 3.2.1. 在跨系统迁移数据之前，必须先验证数据是否合规
  
• 3.2.2. 带有PII属性的数据必须在传输过程中和在目标数据存储上进行加密
  
• 3.2.3. 根据适用的法规，合规性验证可能会花费大量时间
  

3.3. 数据质量验证

• 3.3.1. 数据迁移需要确保源数据和目标数据的一致性
  
• 3.3.2. 在实际部署中，质量问题可能由于多种原因导致，例如源数据错误、适配器故障、聚合问题等
  
• 3.3.3. 为了确保数据质量问题不影响业务指标和机器学习模型的正确性，必须在迁移数据期间监控数据一致性
  
• 3.3.4. 在数据迁移过程中，目标数据可能是源数据经过过滤、聚合或转换后得到的，因此与源数据并不完全一致
  

4. 定义需求

4.1. 接入模块

• 4.1.1. 负责将数据一次性或持续地从源数据存储复制到目标数据存储
  
• 4.1.2. 从数据存储中读取和写入数据需要一个特定技术的适配器
  
  
  
  • 4.1.2.1. 变化率：根据新增、更新和删除的数量来估计表是否在快速变化
    
  
  
• 4.1.3. 可接受的刷新延迟
  
  
  
  • 4.1.3.1. 对于探索性用例，数据迁移通常是一次性操作
    
  • 4.1.3.2. 批处理操作既可以是表的完整副本，也可以是只拷贝上次变化的增量
    
  • 4.1.3.3. 对于连续拷贝，源数据上的更改将以近实时的方式（以秒或分钟为单位）传输到目标上
    
  
  

4.2. 转换模块

• 4.2.1. 负责将数据从源数据复制到目标数据时进行转换
  
• 4.2.2. 在数据迁移过程中，目标数据可能不是源数据的完整副本
  
• 4.2.3. 格式转换
  
  
  
  • 4.2.3.1. 目标数据最常见的形式是源表的副本
    
  • 4.2.3.2. 目标数据也可以是源数据追加更新的日志，或者是代表表的更新、插入或删除的更改事件列表
    
  
  
• 4.2.4. 自动模式演进
  
  
  
  • 4.2.4.1. 对于预定的数据迁移，源表的模式可以得到更新
    
  
  
• 4.2.5. 过滤
  
  
  
  • 4.2.5.1. 原始源表或事件可能有需要从目标中过滤的字段
    
  
  
• 4.2.6. 聚合
  
  
  
  • 4.2.6.1. 在源数据跨多个孤岛的场景中，转换逻辑会聚合并创建一个单一的具体化视图
    
  • 4.2.6.2. 聚合还可以通过连接不同的数据源来丰富数据
    
  
  

4.3. 合规模块

• 4.3.1. 确保用于分析的迁移数据遵循监管规定
  

4.4. 验证模块

• 4.4.1. 确保源数据和目标数据之间的数据一致性
  
• 4.4.2. 确保源数据和目标数据一致是数据迁移过程的关键
  
• 4.4.3. 根据分析类型和所涉及的数据性质，可以定义不同的一致性检查需求
  
• 4.4.4. 如果检测到错误，应该将数据迁移服务配置为发出告警或使目标数据不可用
  

4.5. 非功能性需求

• 4.5.1. 方便接入新的源数据存储
  
  
  
  • 4.5.1.1. 简化数据源所有者对服务的使用体验，并支持主流的源数据存储和目标数据存储
    
  
  
• 4.5.2. 自动监控和故障恢复
  
  
  
  • 4.5.2.1. 服务应该能够创建检查点并从任何数据迁移失败中恢复
    
  
  
• 4.5.3. 尽量减少对数据源性能的影响
  
  
  
  • 4.5.3.1. 数据迁移不应该降低数据源的性能，因为这会直接影响应用程序的用户体验
    
  
  
• 4.5.4. 解决方案的扩展
  
  
  
  • 4.5.4.1. 考虑到数据的持续增长，该服务应该支持每天数千次的计划性数据迁移
    
  
  
• 4.5.5. 社区广泛使用的开源技术
  
  
  
  • 4.5.5.1. 选择开源解决方案时，请注意有一些是僵尸项目
    
  • 4.5.5.2. 确保开源项目是成熟的，并被社区广泛使用
    
  
  

5. 实现模式

5.1. 批处理接入模式

• 5.1.1. 批处理接入是大数据发展早期流行的一种传统模式，它既适用于一次性数据迁移，也适用于计划性数据迁移
  
  
  
  • 5.1.1.1. 批处理是团队在大数据旅程早期的一个良好起点
    
  
  
• 5.1.2. 批处理指的是将源数据上的更新打包在一起，然后定期迁移到目标数据中
  
• 5.1.3. 批处理通常用于大型数据源的数据迁移，而不需要实时更新
  
• 5.1.4. 通常每6～24小时调度一次
  
• 5.1.5. 分区阶段
  
  
  
  • 5.1.5.1. 要拷贝的源表在逻辑上被分割成更小的块，以并行化数据迁移
    
  
  
• 5.1.6. map阶段
  
  
  
  • 5.1.6.1. 每个块被分配给一个mapper
    
  • 5.1.6.2. mapper触发查询，从源表读取数据并复制到目标表
    
  
  
• 5.1.7. reduce阶段
  
  
  
  • 5.1.7.1. mapper的输出被存储为staging文件，并由reducer合并为目标数据存储上的单个具体化视图
    
  • 5.1.7.2. reducer还可以实现转换功能
    
  
  
• 5.1.8. 优点
  
  
  
  • 5.1.8.1. 一种传统的数据迁移模式，适用于各种源数据和目标数据存储
    
  • 5.1.8.2. 数据源所有者在使用、管理和维护其源数据存储时只需付出极小的成本
    
  • 5.1.8.3. 支持扩展到每天数以千计的计划性数据迁移，还利用MapReduce实现故障恢复
    
  • 5.1.8.4. 内置了对复制后数据验证的特性
    
  
  
• 5.1.9. 缺点
  
  
  
  • 5.1.9.1. 不支持近实时的数据刷新
    
  • 5.1.9.2. 可能会潜在地影响源数据存储的性能
    
  • 5.1.9.3. 用于连接源数据存储的JDBC连接存在潜在的合规问题，而这些数据存储是符合监管规定的
    
  • 5.1.9.4. 对使用硬删除的增量表刷新和数据转换功能的支持有限
    
  
  

5.2. 变更数据捕获接入模式

• 5.2.1. 非常适合快速迁移大批量数据，是最受欢迎的方法之一
  
  
  
  • 5.2.1.1. 要求源数据团队和数据工程团队之间配合顺畅，以确保准确无误地跟踪变更和大规模合并更新
    
  
  
• 5.2.2. 随着团队逐渐成熟，团队不再采用批处理方式，开始转向变更数据捕获（Change Data Capture，CDC）模式
  
• 5.2.3. 源数据更新需要以低延迟（以秒或分钟为单位）在目标数据上可用
  
• 5.2.4. CDC意味着捕获源数据上的每个变更事件（更新、删除、插入）​，并将更新应用到目标数据上
  
• 5.2.5. 这种模式通常与批处理接入结合使用，批处理用于源表的完整副本初始化，而连续更新则使用CDC模式完成
  
• 5.2.6. 产生CDC事件
  
  
  
  • 5.2.6.1. 在源数据库上安装和配置CDC适配器，该适配器是一种特定于源数据存储的软件，用于跟踪对用户指定表的插入、更新和删除操作
    
  
  
• 5.2.7. 发布CDC到事件总线
  
  
  
  • 5.2.7.1. CDC发布在事件总线上，可以被一个或多个分析用例使用
    
  • 5.2.7.2. 总线上的事件是持久化的，在出现故障时可以重新回放
    
  
  
• 5.2.8. 事件合并
  
  
  
  • 5.2.8.1. 每个事件（插入、删除、更新）都应用于目标数据上的表
    
  • 5.2.8.2. 最终的结果是一个具体化的表视图，这个表视图相对于源表延迟较小
    
  • 5.2.8.3. 在数据目录中更新与目标表对应的元数据，以反映刷新时间戳和其他属性
    
  
  
• 5.2.9. CDC接入模式有一种变体，可以直接使用事件，而不是通过合并步骤
  
  
  
  • 5.2.9.1. 通常适用于将原始CDC事件转换为特定业务事件的场景
    
  
  
• 5.2.10. 另一种变体是将CDC事件存储为基于时间的日志，这通常适用于风险和欺诈检测分析
  
• 5.2.11. CDC接入模式的一个流行的开源实现是Debezium与Apache Kafka相结
  
  
  
  • 5.2.11.1. Debezium是一个低延迟的CDC适配器，在标准化事件模型中捕获提交到数据库的变更，并且与数据库技术无关
    
  
  
• 5.2.12. 流行的开源解决方案
  
  
  
  • 5.2.12.1. Apache Gobblin
    

    5.2.12.1.1. 使用MapReduce
    

    5.2.12.1.2. Gobblin中的合并实现包括反序列化/提取、格式转换、质量验证和向目标写入
    

    
    
  • 5.2.12.2. Uber的Marmaray
    

    5.2.12.2.1. 使用Spark
    

    
    
  • 5.2.12.3. Gobblin和Marmaray都是为从任何源数据到任何目标数据的数据迁移而设计的
    
  
  
• 5.2.13. 优点
  
  
  
  • 5.2.13.1. 一种低延迟的解决方案，用于更新目标，且对源数据存储的性能影响最小
    
  • 5.2.13.2. CDC适配器可用于主流的数据存储
    
  • 5.2.13.3. 支持在数据迁移过程中进行过滤和数据转换
    
  • 5.2.13.4. 支持使用增量方式接入大型表
    
  
  
• 5.2.14. 缺点
  
  
  
  • 5.2.14.1. 考虑到选择CDC适配器的最佳配置选项需要较专业的经验，提高了使用的入门门槛
    
  • 5.2.14.2. 使用Spark（而不是Hadoop MapReduce）的合并实现，在处理超大表（大约10亿行）时可能会有一些困难
    
  • 5.2.14.3. 需要一个带有CDC列的表来跟踪增量变更
    
  • 5.2.14.4. 仅能支持有限数据量的数据过滤或数据转换
    
  
  

5.3. 事件聚合模式

• 5.3.1. 事件聚合模式是一种常见的聚合日志文件和应用程序事件的模式，该模式对事件进行持续实时聚合，以用于欺诈检测、告警、物联网等
  
• 5.3.2. 随着Web访问日志、广告日志、审计日志和系统日志，以及传感器数据等日志和数据越来越多，该模式的适用性越来越强
  
• 5.3.3. 该模式涉及从多个源数据聚合，统一为一个单一的流，并将其用于批处理或流分析
  
• 5.3.4. 事件转发
  
  
  
  • 5.3.4.1. 来自边缘节点、日志服务器、物联网传感器等的事件和日志被转发到聚合阶段
    
  • 5.3.4.2. 安装一个轻量级客户端来实时推送日志
    
  
  
• 5.3.5. 事件聚合
  
  
  
  • 5.3.5.1. 来自多个源数据的事件被规范化、转换，并可用于一个或多个目标数据
    
  • 5.3.5.2. 聚合是基于数据流的，事件流被缓存并定期上传到目标数据存储
    
  
  
• 5.3.6. 流行实现
  
  
  
  • 5.3.6.1. Apache Flume
    

    5.3.6.1.1. Flume的源数据组件从源数据中获取日志文件和事件，并将它们发送到聚合代理以进行数据处理
    

    5.3.6.1.2. 日志聚合处理存储在内存中，并通过流传输到目的地
    

    5.3.6.1.3. Flume最初设计用于快速可靠地将Web服务器生成的大量日志文件传输到Hadoop中
    

    
    
  • 5.3.6.2. Fluent Bit
    
  • 5.3.6.3. Fluentd
    
  • 5.3.6.4. 主要被用作日志收集器和日志聚合器
    
  
  
• 5.3.7. 优点
  
  
  
  • 5.3.7.1. 针对日志和事件且被优化的实时解决方案，具有高可靠、高可用和高可伸缩（水平扩展）的特性
    
  • 5.3.7.2. 对源数据性能的影响极小
    
  • 5.3.7.3. 具有高可扩展性和高可定制性，并且开销最小
    
  • 5.3.7.4. 支持在数据迁移过程中进行过滤和数据转换
    
  • 5.3.7.5. 可扩展以支持处理大批量日志和事件数据
    
  
  
• 5.3.8. 缺点
  
  
  
  • 5.3.8.1. 不保证源事件数据有序
    
  • 5.3.8.2. 消息可以至少传递一次（而不是只传递一次）​，要求目标数据处理重复事件
    
  
  
• 5.3.9. 针对日志和事件数据进行了优化，虽然很容易入门，但它是为分析用例而设计的，可以处理无序以及重复的记录
  

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