读数据自助服务实践指南：数据开放与洞察提效12数据转换服务

1. 数据转换服务

1.1. 传统上业务逻辑通常遵循提取-转换-加载（ETL）或提取-加载-转换（ELT）的模式

1.2. 痛点

• 1.2.1. 数据用户是业务逻辑方面的专家，但是需要工程支持来大规模实现逻辑

  • 1.2.1.1. 随着数据的指数级增长，需要分布式编程模型才能以可靠和高性能的方式实现逻辑

• 1.2.2. 构建实时业务逻辑转换器的需求越来越大

  • 1.2.2.1. 数据用户并不是演进编程模型的专家，尤其是在实时洞察方面

• 1.2.3. 在生产中运行转换需要持续的支持来跟踪可用性、质量、数据源的变更管理和处理逻辑

  • 1.2.3.1. 转换逻辑不是从零开始构建的，而是作为现有逻辑的变体

1.3. 理想情况下，数据转换服务允许用户指定业务逻辑，且不需要具体的实现细节

1.4. 该服务支持批处理和实时处理，并且实现了对可用性、质量和变更管理的监控

1.5. 除了减少构建转换逻辑所需的时间外，该服务还减少了以高性能方式在生产中执行的时间，故可以在生产中大规模运行

1.6. 在从原始数据中提取洞察的过程中，需要根据具有业务领域专业知识的数据用户定义的业务逻辑对数据进行转换

• 1.6.1. 转换在逻辑上是唯一的，但大多由一组公共函数组成，如聚合、过滤、连接、拆分等

• 1.6.2. 转换服务简化了在生产中构建、执行和操作这些转换的复杂任务

2. 路线图

2.1. 转换服务可以帮助数据用户完成与数据报告、用户故事、模型生成等相关的任务

2.2. 转换逻辑是由数据用户在解决问题的上下文中编写的，该逻辑通常随业务定义的变化而演变

2.3. 生产仪表盘和机器学习管道

• 2.3.1. 数据分析师从数据中提取洞察，为关于营销漏斗、产品功能使用、注册和登录、A/B测试等的日常仪表盘生成业务指标

• 2.3.2. 如今，业务定义与实现代码混杂在一起，使得管理和更改业务逻辑变得很困难

2.4. 数据驱动的用户故事

• 2.4.1. 企业正变得越来越受数据驱动，通过连接跨多个孤岛的数据并进行分析来做出决策

• 2.4.2. 用户故事需要在不同的数据存储中高效地处理大量不同格式的数据

• 2.4.3. 随着数据量的增加，在无须分布式处理的情况下，处理可以运行数小时或数天

3. 最小化转换耗时

3.1. 包括实现、执行和操作业务逻辑转换的时间

3.2. 转换实现

• 3.2.1. 转换逻辑的实现包括定义业务逻辑和编写转换逻辑代码

• 3.2.2. 包括适当的测试和验证、性能优化等

• 3.2.3. 挑战

  • 3.2.3.1. 很难将逻辑的正确性与实现问题分开，即逻辑与实现混为一谈

  • 3.2.3.2. 用户不是数据

• 3.2.4. 为了提高生产效率，需要在低级和高级业务逻辑规范之间取得平衡—低级结构很难学习，而高级结构需要有适当的表达能力

3.3. 转换执行

• 3.3.1. 选择合适的查询处理引擎

• 3.3.2. 转换逻辑可以以批处理或流式处理的方式运行，这需要不同的实现

• 3.3.3. 除了核心转换逻辑之外，执行还需要读取数据、应用逻辑并将输出写入服务数据库

  • 3.3.3.1. 数据需要以表、文件、对象、事件和其他形式使用

• 3.3.4. 输出可以写入不同的服务存储

• 3.3.5. 挑战

  • 3.3.5.1. 处理技术过多，数据用户很难选择正确的查询处理框架

  • 3.3.5.2. 与实时处理相反，很难对用于批处理的转换逻辑的不同版本进行一致的管理

  • 3.3.5.3. 每当逻辑发生变化时都需要对逻辑进行数据回填

    3.3.5.3.1. 对于PB规模的数据，逻辑需要在增量处理更新方面很高效并且只应用于新数据

3.4. 转换操作

• 3.4.1. 转换通常部署在遵循SLA的生产中

• 3.4.2. 在生产中操作需要监控、告警和主动的异常检测，以防止发生数据质量故障

• 3.4.3. 生产中的操作转换非常耗时，不容易区分进程是挂起还是执行缓慢，需要手动调试和分析

• 3.4.4. 跨系统的元数据日志记录对于分析根本原因至关重要，并且需要针对不同的数据系统进行单独的日志解析

4. 定义需求

4.1. 根据数据用户的技能、用例类型、构建数据管道的现有过程，转换服务的需求有所不同

4.2. 当前状态调研问卷

• 4.2.1. 实现转换逻辑的当前状态

  • 4.2.1.1. 实现转换逻辑的当前状态

  • 4.2.1.2. 列出了数据湖中正在使用的数据格式

• 4.2.2. 执行转换的当前状态

  • 4.2.2.1. 关键指标包括需要实时转换的用例数量（而不是传统的、面向批处理的转换）​、要读写的数据存储、现有的处理引擎、现有的编程模型以及平均并发请求数

• 4.2.3. 操作转换的当前状态

  • 4.2.3.1. 关键指标包括检测时间、生产问题的调试时间、SLA违规事件的数量以及与转换正确性相关的问题

4.3. 功能性需求

• 4.3.1. 自动转换代码生成

  • 4.3.1.1. 数据用户需要明确转换的业务逻辑，无须担心实现的代码细节

• 4.3.2. 批处理和流式处理的执行

  • 4.3.2.1. 根据用例的需求，允许以批处理或流式方式运行转换逻辑

  • 4.3.2.2. 执行以高性能的方式大规模运行

• 4.3.3. 增量处理

  • 4.3.3.1. 能够记录历史调用中处理过的数据，并对新的增量数据应用处理

• 4.3.4. 自动回填处理

  • 4.3.4.1. 根据逻辑更改，自动重新计算度量

• 4.3.5. 监控可用性和质量问题

  • 4.3.5.1. 监控可用性、质量和变更管理

4.4. 非功能性需求

• 4.4.1. 数据连接

  • 4.4.1.1. ETL工具应该能够与任何数据源通信

• 4.4.2. 可扩展性

  • 4.4.2.1. 能够根据不断增长的数据量和速度进行扩展

• 4.4.3. 直观

  • 4.4.3.1. 考虑到数据用户的广泛性，转换服务应该易于使用

5. 实现模式

5.1. 基本实现模式

• 5.1.1. 简化转换逻辑的规范和实现方法，并根据不断变化的业务需求快速演进

• 5.1.2. 一般方法是让数据用户用标准转换函数（类似于乐高积木）的高级语言来定义逻辑

• 5.1.3. 通过将逻辑规范与实际代码实现分离，这些规范易于管理、修改、协作和理解

• 5.1.4. 这种模式缩短了实现转换的时间，并确保了高质量

• 5.1.5. Informatica PowerCenter

• 5.1.6. Microsoft SSIS

• 5.1.7. Pentaho Kettle

• 5.1.8. Talend

• 5.1.9. Apache NiFi

• 5.1.10. Looker的LookML

• 5.1.11. 用户可以使用DSL语言或拖放式UI来指定转换逻辑

  • 5.1.11.1. 规范是版本控制的，与代码分开管理

5.2. 执行模式

• 5.2.1. 统一转换逻辑的执行方法，允许基于新鲜度要求进行批处理和实时处理

• 5.2.2. 旨在使数据用户能够自助执行业务转换逻辑

• 5.2.3. 执行模式在事件生成和事件处理时间之间的延迟有所不同，延迟范围从每天或每小时（使用批处理）到秒或毫秒（使用流模式）

• 5.2.4. Apache Flink

  • 5.2.4.1. 流式处理演变成按事件处理

• 5.2.5. Netflix的Keyston

  • 5.2.5.1. 简化了从数据源读取事件、执行处理作业以及数据存储（将数据写入接收器）的过程

• 5.2.6. Apache Storm

• 5.2.7. 流式数据模式的工作原理

  • 5.2.7.1. 数据被视为事件

  • 5.2.7.2. 数据集是无界的，并使用窗口函数进行操作

• 5.2.8. 对于批处理，数据（在表中）作为事件在消息总线上重放以进行处理

  • 5.2.8.1. 数据在消息总线上表示为事件

• 5.2.9. 转换逻辑可以对数据事件进行操作

  • 5.2.9.1. 转换可以是无状态的也可以是有状态的

  • 5.2.9.2. 无状态处理是独立处理每个事件

• 5.2.10. 该模式自动执行、缩放、重试、回填以及与执行业务逻辑转换相关的其他任务

5.3. 操作模式

• 5.3.1. 无缝跟踪生产中的转换以满足SLA

• 5.3.2. 此模式提供监控和告警，以确保转换的可用性和质量