精通数据集成:轻易云数据集成平台应用实战与技术内幕

企业系统中数据交互的重要性不言而喻。一个系统如果孤立运行,即使积累了海量数据,仍然是一座信息孤岛。另一方面,一个积极参与数据交互的系统,成为各系统之间的“交际花”,具备中台的性质。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第1张图片

然而,大多数情况下,系统介于这两种极端之间,需要在自身生产和社交之间取得平衡,实现数据的高效对接。这种对接的核心目标是实现数据信息的传输,为后端产品提供有力支持。在这篇文章中,我们将探讨以下关键主题,重点介绍了轻易云数据集成平台在企业系统数据对接中的作用:

1. 数据传输的场景和意义

1.1 数据传输的应用场景

数据传输在企业系统中有着广泛的应用场景,包括:

  • 前后端数据互动: 企业系统的前端和后端需要不断地交换数据以保持实时性。
  • 内部系统协作: 各系统模块之间需要协同工作,例如订单系统需要与备货系统共享库存扣减数据。
  • 与第三方平台对接: 入驻第三方销售平台后,需要管理自身的订单数据,这需要从第三方平台获取订单数据。
  • 使用公共插件: 利用已有的开放功能插件,如接入百度地图API或进行微信小程序的二次开发。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第2张图片

1.2 数据传输的意义

数据传输的意义在于:

  • 避免资源浪费: 通过数据传输,可以避免重复生产数据库,充分利用已有资源和功能。
  • 统一数据维护源头: 数据传输有助于统一数据维护,防止数据不同步,特别是在不同系统中共享数据时。
  • 复用现有轮子: 利用已有的API或SDK,避免重复开发,提高效率。

2. 数据传输的方式

数据传输方式包括接口传输、中间件传输和消息传输等,每种方式都有适用的场景。

2.1 接口传输

接口传输是一种传统的问答式传输方式,通常用于客户端与服务器之间的交互。这包括HTTP调用、Java远程调用和Web服务等。接口传输的优势在于时效性强,可触发实时交互,同时安全性高,通用性强。

  • 接口的作用: 接口可用于调用第三方功能插件(API接口)或解决特定场景的信息传输问题(HTTP接口)。
  • 接口的创建方: 由被请求的一方创建接口,确保数据源一致。
  • 接口定义: 接口定义包括口令、数据范围、筛选条件、转化规则等。
  • 数据转义: 数据在源头与应用端之间是否需要转化取决于需求和数据复用情况。
  • 主动获取 vs. 对方推送: 根据时效和数据量的需求,可以选择主动推送或请求获取数据。

产品经理在这一过程中需要提供接口定义的规则、传参和返回参数、必传参数、数据流转时效等信息,以及大致方向。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第3张图片

3. 数据传输的处理机制

在定义数据传输方案时,需要考虑数据初始化和同步机制。同步可分为触发式和定时任务式,具体根据需求来确定。

  • 触发式同步: 当参数值满足条件时触发同步。
  • 定时任务同步: 用于处理不定时更新的数据,根据数据更新频率设置定时任务。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第4张图片

4. 数据传输的注意事项

数据传输在企业系统集成中扮演着关键角色,但也需要考虑以下注意事项:

  • 网络带宽消耗: 大数据量传输可能导致网络带宽问题,需要谨慎处理。
  • 服务可靠性: 服务器和客户端必须同时工作,服务器不可用时可能导致数据交互失败。

在实际应用中,如果需要对接多个系统,建议创建一个通用接口,以便其他系统方便接入,减少重复工作和风险。

5. 相关概念扩展

  • API(应用程序编程接口): 预定义函数的集合,无需了解内部工作机制即可调用的对象,用于不同软件系统之间的交互。
  • Open API: 对外开放的接口,例如百度地图API、Facebook的API等。
  • SDK(软体开发工具包): API的集合,提供更丰富的功能。
  • HTTP接口: 基于HTTP协议的传输方式,用于各种应用之间的数据交互。

轻易云数据集成平台在企业数据传输中扮演了重要的角色,支持不同传输方式,帮助企业实现系统间的高效数据交互,促进数字化转型的成功。无论是数据同步、第三方平台对接还是内部系统协作,数据传输都是实现这些目标的关键一环。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第5张图片

数据库对库同步

数据库同步是一种关键的数据集成方式,它允许不同系统之间共享数据,通常发生在企业内部的系统之间,这些系统相互信任并需要实时数据共享。轻易云数据集成平台为这种需求提供了多种解决方案,使数据在不同系统之间轻松同步和共享。

1. 使用中间表

一种常见的数据库同步方法是使用中间表。例如,如果系统B需要使用系统A的数据,可以创建一个新的数据库(DB),然后系统A将数据写入该数据库,系统B可以从中读取数据。这意味着数据存储在一个中间表中,而系统A和系统B都具有对该表的访问权限。这种方法的好处是可以选择性地共享大批数据。

2. 直接调用对方数据表

另一种方法是在系统B的开发中,直接从系统A的数据表中加载数据。这是实时获取对方数据的方式,系统B不会在本地保存数据表副本。尽管这种方法较为高效,但它增加了系统之间的耦合性,因此在数据量较大时并不推荐。

3. 同步对方的数据表

数据库同步的第三种方法是将对方的数据表复制到本地,并保持实时同步。其中,otter技术是一种常用的方法,它可以将MySQL的数据同步至另一个MySQL或Oracle数据库,还支持双向同步和文件同步等功能。这种方法需要数据库的协助配置,通常通过一个带有Web管理界面的MySQL同步平台来实现。在界面上,可以定义映射规则,otter进程会根据这些规则读取binlog并将数据更新到目标库中。

这种同步方式主要适用于内部系统之间的数据传输,特别适合处理大数据量。它的优点在于资源占用较少,交互简单可靠。然而,当连接到系统B的系统数量增多时,数据库连接池是有限的,这可能导致可用的数据库连接不足。在这种情况下,otter是一个较为合适的选择。不过,两个不同公司的系统通常不会开放自己的数据库给对方连接,因为这可能存在安全性方面的风险。

文件包共享方式

在一些情况下,为了保密或其他原因,第三方公司可能不愿提供接口,而是将数据文件存储在类似网盘或网页上供需求方下载。这种情况下,双方系统需要协商文件服务器地址、密码、文件命名规则、文件内容格式等信息,通过上传和下载文件来实现数据交互,尤其适用于处理大数据量。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第6张图片

例如,第三方支付公司可以与需求方约定使用SFTP服务器(一种文件服务器,类似网盘)的账号和密码。支付公司将账单数据上传到SFTP服务器,然后需求方可以使用SFTP客户端登录,下载并解析数据,然后保存和使用。这种方式实现了数据在服务器之间的异步传输,操作各自独立,并且一旦上传,文件可以被多个需求方使用。

这些数据通常是加密的,因此只有经过授权的公司才能解密。长期合作的公司会持续更新数据,授权的公司可以持续下载和解析。通常使用定时任务按一定频率下载数据,同时要考虑丢包的机制。

案例:

假设需求方需要从SFTP服务器抓取并解析WP支付平台的账单明细。方案如下:

  1. 抓取文件路径下前一天的文件,根据修改时间进行筛选。
  2. 打开文件,按照规则解析所需的字段。
  3. 将解析后的数据对应写入本地数据表。

为了防止数据丢失,可以采用断抓补抓机制。例如,如果某天的数据抓取中断,系统将自动在下次尝试重新抓取,直到连续三次未成功抓取为止,以减少数据抓取故障导致的数据丢失情况。

这种方式能够有效降低数据抓取故障带来的风险,尤其适用于需要定期获取外部数据的情况。产品经理在合作中应该提醒开发团队考虑这些机制,以确保数据的完整性和可靠性。

深入理解消息队列MQ(Message Queue)

1. MQ概念

消息队列技术是一种用于分布式应用之间交换信息的技术。它允许应用之间异步通信,解耦各个组件,提高系统的可伸缩性和性能。市场上有多个开源的JMS消息中间件,如ActiveMQ和OpenJMS等,可供选择。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第7张图片

消息队列的工作原理类似于排队进入隧道。一方不断将消息推送到队列中,而另一方则按顺序消费这些消息。消息可以存储在内存中,也可以持久化到磁盘上,直到被应用程序读取。这种方式适用于大规模的企业内部应用,特别是在处理大量规律性强、批量数据交互的情况下。它主要解决了应用解耦、异步消息处理和流量削峰等问题。

2. 以异步处理为例

假设有用户注册功能,需要发送注册邮件和注册短信。传统的处理方式有两种:

  • 串行方式:将注册信息写入数据库后,依次发送注册邮件和注册短信,然后返回给客户端。这种方式的响应时间较长。

  • 并行方式:将注册信息写入数据库后,同时发送注册邮件和注册短信,然后返回客户端。相比串行方式,响应时间有所提升。

然而,在高并发情况下,传统方式可能会面临性能瓶颈。引入消息队列后,可以改进架构如下:

用户的响应时间相当于注册信息写入数据库的时间,即50毫秒。注册邮件和短信被写入消息队列后,系统立即返回响应,因此写入消息队列的速度非常快,可以忽略不计。这样,系统的吞吐量提高到每秒20 QPS,比串行方式提高了3倍,比并行方式提高了两倍。

3. MQ、文件包共享、接口的对比

消息队列在推送消息后不需要等待对方的确认,因为消息已经成功推送到中间站,代表本方已经完成相应的任务。这与接口方式不同,接口需要来回通信以确认成功。

如果必须等待对方的确认,那么就需要实现反向消息队列,相当于另一个独立的MQ。

文件包共享也不需要反馈机制。一旦数据传输到文件服务器,发送方的任务就算完成了。然而,消息队列中的消息只能被消费一次,不同系统无法共同消费一个队列,因此对接多个系统时需要创建多个MQ。而接口可以创建一个,供多个系统调用。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第8张图片

在订单系统对接各个销售网站和平台时,可以采用接口的方式,避免多次对接。文件包共享也可以上传一次,供多个需求方下载。这点与接口有相似之处,但是消息队列无法做到这一点。

探索其他数据传输手段

数据传输不仅限于在线自动机制,还可以采用一些离线方法,特别是在后端产品系统中。

1. 导入导出

场景:

当无法进行系统间集成,但可以在离线环境中获取数据时,可以采用导入导出方式。这适用于数据量较小、结构规则的数据。

实施:

  • 数据通常以CSV格式存储,该格式文件较小且兼容性良好。
  • 需要定义文件与数据字段的映射关系,例如A列对应字段’姓名’,B列对应字段’年龄’。
  • 上传时需要进行文件验证,如格式检查和必填项检查。建议一旦发现错误,立即中止导入并返回错误提示,等待修复后重新导入。
  • 如果数据量较大,可以采用异步上传机制,将上传和数据写入分为两个步骤,后台自动分批写入,提高效率。

2. 爬取

场景:

作为数据需求方,获取数据可以采用多种方法,包括协商接口、SFTP解析,以及直接爬取数据的方式。

实施:

例如,如果需要从第三方网站获取商标库中的最新商标信息,但该网站没有提供开放的接口,可能需要开发爬虫代码进行数据爬取。需要注意

的是,一些商业网站可能设置了反爬机制,需要克服这些障碍。

轻易云数据集成平台在面对不同的数据传输场景时,提供了灵活的解决方案,让企业能够高效地处理数据集成和传输的各种需求。无论是使用消息队列、文件包共享还是接口,都可以借助该平台实现数据的顺畅流动,推动数字化转型的成功实施。

数据同步的触发机制

在数据集成过程中,数据获取的方式与触发机制是至关重要的,它们需要根据具体的应用场景来制定。一般而言,我们通常需要实现持续获取数据的要求。

操作事件触发是一种常见的方式,例如,当用户在页面上点击按钮时,系统会触发数据传递以获取最新状态。这种方式具有较高的时效性,但可能会因并发操作而增加系统负荷。

如果对时效性要求不高,可以采用异步机制。这可以通过使用脚本监控来实现,设置脚本的运行频率,当检测到数据在一定时间内有更新时,捕获并传输数据。定时脚本是一个常见的后端应用方式。

例如,如果需要获取系统A中在过去6小时内更新的数据,每2小时运行一次脚本就可以满足要求。但如果每7小时运行一次,就会错过1小时的数据更新。因此,必须确保每次获取的数据时间区间要大于数据获取的时间间隔。

除了时间维度,更安全的方法是使用标识性字段。例如,每次获取is_got为0的数据,前端可以将is_got作为表索引,这样在数据库遍历时就不会太慢(遍历相当于全表查询)。

判定获取数据的唯一性是关键,以避免数据重复。

是否异步执行数据处理

在获取数据后,如果需要进行规则运算,最好的做法是首先将数据存储到中间表,然后再将其写入最终表,实现异步写入。

举例来说,假设我们需要从物流系统获取按订单和包裹号维度的运费数据,然后在财务系统中进行分摊运费到商品上。这个过程中,分摊规则是一种算法,带有可变动性。如果分摊规则的参数不准确或算法结构发生变化,就会导致最终的运费分摊金额错误。因此,在进行分摊之前,最好将数据先存储到财务系统的临时表(中间表),然后进行数据获取和分摊运费操作。

这种异步操作不仅方便查找错误原因,还确保了较少的偶联,以防止一个环节出错影响其他环节。同时,中间表作为基础数据还可以供其他功能使用。对于大量数据,这种做法是必要的。

判重机制

一旦建立了数据通道,数据流通常是持续不断的,而数据源可能会被不断增删改。因此,在将数据写入本地表时,需要根据特定字段来判断数据的唯一性。

例如,对于员工信息表,可以以(姓名+手机号+性别+家乡+身份证号)作为判重的标识字段。如果某条数据的(姓名+手机号+性别+家乡)这几个字段不一定唯一,但身份证号是唯一的,那么可以以身份证号作为唯一标识。如果获取到的数据中的身份证号在本地数据库中存在,则进行更新操作;如果不存在,则进行插入操作。

有时无法确定哪些字段是唯一的,可以添加一个备用字段,人为定义其取值规则,然后将其用作判重字段。例如,添加一个名为unique_code的字段,取数据源表的主键加上日期,或者直接使用源表的id作为外键。

有了判重字段,可以轻松进行更新、插入或跳过规则的设置。

需要注意的是,如果改变了表的判重规则,历史数据可能会与新数据产生冲突,因为两者的判重维度不同。

获取数据后的处理方式

一种方式是将数据直接显示在页面上,而不保存在本地数据库中。这相当于每次刷新页面都会通过接口重新获取数据进行展示。但这种方式在性能和实际应用场景上比较少见,一般情况下,我们会首先将数据保存在本地数据库中,以便本地调用。

对于首先保存在本地数据库的情况,有两个问题需要考虑:是否异步保存以及如何确保同步。

处理日志

数据日志的目的是记录数据的来源和去向,以便追溯和分析问题。数据日志通常包括三个主要事项:数据源系统是否提供数据、目标系统是否接收到数据、目标系统是否成功写入数据。

在添加数据捕获日志时,需要确定是否将日志存储在数据库中,因为系统通常会有一个类似缓存的日志,但这些日志通常会定期清理,只有保存在数据库中才能持久记录和追溯。

开发后台通常已经具备数据日志功能,使用日志级别如FATAL、ERROR、WARN、INFO、DEBUG等来记录重要信息。通常情况下,开发人员会配置INFO或DEBUG级别的日志,以便查看数据。

但是,代码中的日志保存时间有限,通常会在一个月内清除。因此,如果需要保留更长时间的日志,可以将其存储在本地数据库中。

数据传输的注意事项

目标数据表与中间表的维度一致

当从系统A获取数据并存入系统B时,最好先将数据存储到中间表B,

然后通过一系列运算将数据从中间表B写入中间表B’。确保中间表B和中间表B’的唯一标识字段相对应,以实现异常数据溯源。维度的一致性能够帮助我们轻松追踪数据问题。

不同入口写入同一类型数据的去重

考虑一个场景:有两个不同的写入程序,从不同入口写入数据到利润表,这些数据都属于“退件入库”利润类型。然而,这两个入口各自有独立的去重规则,彼此不通用。

为了避免重复写入,首先需要确定如果一条数据已经从一个入口写入了利润表,那么就不能再从另一个入口写入。其次,如果一条数据从入口1写入后,后续数据更新再次触发写入操作时,也应该从入口1继续写,以确保数据的一致性。

同步基础数据时是否提前过滤

在同步基础数据时,是否应该提前过滤数据是一个需要考虑的问题。例如,系统A维护了员工的基础信息,其中包含一个“是否有效”的状态。只有在状态为有效时,数据才会在整个系统中生效。但系统B需要获取员工信息,但不进行数据维护。

在这种情况下,是否只获取启用状态的数据到系统B,还是无论状态都获取呢?

答案是,在数据量不大的情况下,最好获取全量数据。原因之一是,如果突然将某个员工从系统A中禁用,那么在系统B中可能会出现生产数据报错的情况。通过在中间表中保存全量数据,可以轻松查找问题,而不需要跨系统或跨部门的沟通和确认。

精通数据集成:轻易云数据集成平台应用实战与技术内幕_第9张图片

你可能感兴趣的:(数据集成)