kafka构建数据管道需要注意的问题

发表于 | 更新于 | 分类于 ， ， | 阅读次数：

kafka构建数据管道需要注意的问题

  • 及时性
  • 可靠性
  • 高吞吐量和动态吞吐量
  • 数据格式
  • 转换
  • 安全性
  • 故障处理能力
  • 耦合性和灵活性

{———-}

及时性

  • 在业务需求变更时、具有不同及时性需求的数据之间可以方便的进行迁移
  • 数据支持实时性处理、也支持延迟批处理
  • 消费者可以实时拉取处理、也可以延迟批量处理一批数据

可靠性

  • 能够在各种故障中快速回复
  • 支持、至少一次传递【本身支持】
  • 支持、仅一次传递、避免幂等消费【需结合实物模型或者唯一键特性的外部存储系统】

高吞吐量和动态吞吐量

  • 自动伸缩功能
  • 管理员可以调整压缩来网络和存储资源的使用【支持多种类型压缩】

数据格式

  • avro、xml也可以使用自定义
  • 读取数据源schema载入数据

转换

  • ETL【提取、转换、加载】
    • 过滤掉部分数据、为下游服务过滤不必要数据信息
    • 缺点、下游的调整可能需要重新调整数据管道
  • ELT【提取、加载、转换】
    • 高保真数据管道、数据湖结构
    • 占用了目标系统太多的CPU和存储资源、使得目标系统造价高昂、不过也给下游保证了最原始的数据、利于调整需求

安全性

  • 支持加密数据、
  • 支持认证【SASL实现】、授权消费
  • 支持数据追踪、时间来源、事件修改者、日志审计、访问记录

故障处理能力

  • 数据保留一周、一月、任意时间以便于追溯

耦合性和灵活性

  • 临时数据管道

    • 常用数据管道
      • logstash—–> elasticsearch
      • flume——> HDFS
      • GoldenGate——>Oracle
      • mysql【xml】——–>Informatica——->oracle
      • 当有新的需求时候有需要重新构建新的管道、增加新技术成本

  • 元数据丢失

    • 元数据没有保留schema数据、导致数据交换过程中、没有处理元数据新增字段【因为新的schema中没有该字段】
    • 而如果数据管道允许修改schema信息、那么双方只需要修改内部数据处理就可以了

  • 末端处理

    • 让下端可以自己决定数据处理、而不是数据管道直接处理、直接处理会对下游数据的完整性造成破坏
      同时新的需求更迭、也会造成成本提升
相关文章