kafka构建数据管道需要注意的问题
- 及时性
- 可靠性
- 高吞吐量和动态吞吐量
- 数据格式
- 转换
- 安全性
- 故障处理能力
- 耦合性和灵活性
{———-}
及时性
- 在业务需求变更时、具有不同及时性需求的数据之间可以方便的进行迁移
- 数据支持实时性处理、也支持延迟批处理
- 消费者可以实时拉取处理、也可以延迟批量处理一批数据
可靠性
- 能够在各种故障中快速回复
- 支持、至少一次传递【本身支持】
- 支持、仅一次传递、避免幂等消费【需结合实物模型或者唯一键特性的外部存储系统】
高吞吐量和动态吞吐量
- 自动伸缩功能
- 管理员可以调整压缩来网络和存储资源的使用【支持多种类型压缩】
数据格式
- avro、xml也可以使用自定义
- 读取数据源schema载入数据
转换
- ETL【提取、转换、加载】
- 过滤掉部分数据、为下游服务过滤不必要数据信息
- 缺点、下游的调整可能需要重新调整数据管道
- ELT【提取、加载、转换】
- 高保真数据管道、数据湖结构
- 占用了目标系统太多的CPU和存储资源、使得目标系统造价高昂、不过也给下游保证了最原始的数据、利于调整需求
安全性
- 支持加密数据、
- 支持认证【SASL实现】、授权消费
- 支持数据追踪、时间来源、事件修改者、日志审计、访问记录
故障处理能力
- 数据保留一周、一月、任意时间以便于追溯
耦合性和灵活性
临时数据管道
- 常用数据管道
- logstash—–> elasticsearch
- flume——> HDFS
- GoldenGate——>Oracle
- mysql【xml】——–>Informatica——->oracle
- 当有新的需求时候有需要重新构建新的管道、增加新技术成本
- 常用数据管道
元数据丢失
- 元数据没有保留schema数据、导致数据交换过程中、没有处理元数据新增字段【因为新的schema中没有该字段】
- 而如果数据管道允许修改schema信息、那么双方只需要修改内部数据处理就可以了
末端处理
- 让下端可以自己决定数据处理、而不是数据管道直接处理、直接处理会对下游数据的完整性造成破坏
同时新的需求更迭、也会造成成本提升
- 让下端可以自己决定数据处理、而不是数据管道直接处理、直接处理会对下游数据的完整性造成破坏