datax 数据写入oracle报错缺失表达式_DB 与 Elasticsearch 混合应用之数据离线同步

最新推荐文章于 2024-07-10 14:22:05 发布

weixin_39778150

最新推荐文章于 2024-07-10 14:22:05 发布

阅读量223

点赞数

文章标签： datax 数据写入oracle报错缺失表达式

本文链接：https://blog.csdn.net/weixin_39778150/article/details/112112783

版权

作者

李猛

Elastic Stack深度用户

Elastic认证工程师

序言

首先解释下即时、实时与离线概念定义，最近碰到很多的认知误区，需要纠正下。

即时概念

当数据变更之后马上就可以查询变更，内部采用事务隔离机制，查询的数据必须阻塞直到数据更新完毕，如单实例关系数据库数据发生变更后，然后马上可查询到。

实时概念

在数据同步场景中，包括异构数据源和同构数据源之间，泛指在可接受的很快时间范围内同步完成，一般的认知是秒级左右，也可以毫秒或者微秒，依据业务需求与实现能力定义。如 MySQL 主从同步也做不到即时性，只能实时性，业务系统如果做读写分离，也仅限非即时数据。

离线概念

相比实时定义，离线没有很强的时间即时性要求，一般强调数据的吞吐量，一般常规定义分钟级、小时级、自然天。如大数据BI应用中，数据同步要求普遍T+1。

前一篇文章《DB与ES混合应用之数据实时同步》，我们主要分享了实战项目中基于CDC机制构建的数据实时同步技术方案，整体技术栈链路长，中间环节多，需要复杂的代码编程，投入成本高，不利于快速投入生产应用。实际在多数业务系统场景中，离线同步需求占比最高，下面这篇文章，我们主要探讨DB到ES的数据离线同步问题。

背景要求

DB到Elasticsearch离线同步的业务应用场景有很多，相比实时同步业务应用场景，更能体现选择Elasticsearch替代DB作为查询引擎的优越性，以下介绍几个离线同步的业务场景。

历史数据查询

在电商或者物流行业，日均会产生很多订单数据，未完成的订单数据实时性查询频率高，需要做很多上下游的数据流转处理；相反已经完成的订单数据查询频率不高，但是日积月累的历史订单数据会增加很快，若系统架构设计将实时数据与历史数据合并一起等同对待，那么运行一段时间数据系统会出现很多致命的性能问题，如实时数据查询更新会变慢，用户体验下降，历史数据查询量大，一次查询可能会将系统严重阻塞。

常规的做法是将实时数据与历史数据分离设计，实时数据查询频率高，单次查询数据量小，系统响应快；历史数据查询频率低，单次查询的数据量多，系统响应稍慢，甚至可以接受慢一些。

介于传统关系型数据库的局限性，同样采用 Elasticsearch 应对此系统场景，实时数据查询走Elastic实时集群，历史数据走Elastic历史集群，实时数据同步可以使用CDC机制，历史数据同步得需要专用离线通道方法。

业务技术重构

随着公司业务调整与业务发展，业务系统也需要相应持续的重构，不仅业务模型要重构，技术架构也需要重构，由于人的原因或者技术发展的原因，原有的数据库系统难以满足业务需求，此时需要更换到更合适的数据库系统。

如很多基于Mongodb存储的业务系统，其实切换到Elasticsearch更加合适，速度更快，成本更低(后续案例在编辑...)，那么系统重构之后就需要将数据从Mongodb全量同步到Elasticsearch，这也属于离线同步场景。

关系性数据库局限性就不用说了，大名鼎鼎的Mongodb其实也有很多业务应用短板，或者应用误区，如很多基于Mongodb存储的业务系统，其实切换到Elasticsearch更加合适，速度更快，成本更低，切换成本也很低(详细见另一篇文章《为什么要从Mongodb迁移到Elastic》)，那么系统重构之后就需要将数据从Mongodb全量同步到Elasticsearch，这也属于离线同步场景。

技术产品

离线同步相比实时同步，技术复杂度降低很多，场景苛刻需求也要小很多，因此技术方案的选择度更多，有很多非常优秀的专用工具产品，只需要稍微配置即可启用，下面我们介绍几个当下很流行的产品(个人喜好问题)，简要分析它们的优秀特性以及架构原理。

Logstash

Logstash是Elastic官方产品，掌握Elastic-stack必备之一

• 基于Jvm平台JRuby语言开发，开源免费
• 产品架构设计简洁优秀，模块设计层次分明， input -> filter -> output
• 支持pipeline模型，且多个pipeline之间可以相互依赖
• 产品功能丰富，支持的数据源众多，也支持自定义编辑，其中包括Ruby脚本
• 支持泛JDBC协议，采用SQL表达式，从DB抽取数据到ES，支持CRON定时，可做实时同步
• 与Elastic-stack可集成一体，在Kibana可以查看监控数据
• 单实例运行模式，多实例之间无集群通信，不支持集群，易掌握部署
• 非平台型工具，轻量级

Logstash 在开发圈中流行度不大，但在运维圈流行度很高，主要得益于ELK组合的概念普及，其实在数据同步方面，是最简单的最实用的产品工具之一。

Data X

DataX是阿里出品的数据同步工具，定位多种数据库之间离线数据同步

• 基于Java开发，插件机制
• 产品架构设计简单，两大概念模块，reader->writer
• 支持DB到Elastic数据同步，采用SQL表达式，仅限制离线同步
• 单实例运行模型，多实例之间无集群通信，无集群模式支持，易掌握使用
• 非平台型工具，轻量级

DataX工具称不上优秀，得益于阿里巴巴的名气，使用简洁与性能吞吐好，获得开发圈很大的支持，在很多一次性离线数据同步项目中，应用很广。

NiFi

NiFi是Apache的顶级产品项目之一，由美国军方早期开发捐献开源，定位数据同步领域。

• 基于Java语言开发，插件机制，支持自定义开发
• 产品架构设计优秀，Processor 核心模块概念，
• 功能强大，支持复杂的脚本功能，包括java，javascript，python，ruby等
• 支持DB到Elastic数据同步，可采用SQL表达式方式，也可以采用CDC机制
• 即可实时同步，也可离线同步，且可支持多种Processor组合
• 友好的操作界面，可视化配置
• 平台型产品，支持集群部署
• 入门简单，精通门槛高

NiFi虽然历史悠久，但在国内知名度却不高，不如Hadoop圈的Sqoop等，不过CDH已经在最新版中集成。个人非常喜欢这款产品，因为其平台化的系统架构，前面介绍的DataX与Logstash都属于雕虫小技的工具。

Flink

Flink是当前大数据圈最有人气的流式处理产品，在实时计算领域应用最广。

• 基于Java语言编写，平台型产品
• 分布式架构设计，机制功能丰富，支持检查点机制，程序容灾、状态持久等
• 丰富的编程模型，层次分为 Streaming->Dataset->Table->SQL
• 支持流式计算与离线计算，其中支持泛JDBC数据源离线同步到Elastic
• 集群化运行模式，需要自主编写数据处理代码。

Flink虽然定位在实时计算领域，但由于其底层架构设计的特点，离线计算支持也非常好，提供了友好的编程模型，可快速开发部署，类似的产品还有Spark，这里就不做更多的展开讨论。

ETL工具

专业ETL产品太多了，就不展开讨论了，由专业的BI从业人员讲述更合适。

• Kettle
• DataStage
• Informatica

技术平衡

以上我们介绍了好几种当下流行的数据同步工具，有的支持离线同步，有的也支持实时同步，其实还有更多其它不错的工具产品，每一种工具产品都有它的局限性与优越性，千万不可一概而论，也不可全都上，需要综合业务与技术平衡。

客观认知

每种工具产品都有它的定位，需要客观的认知评估。在业务系统中数据离线同步场景需求多种多样，没有一个完美的产品可以应对所有场景需求。

如DataX属于直接型同步工具，中间没有数据处理功能，其Mysql模块虽然支持所谓的增量型同步，但分批次的连续型同步方式需要借助人工触发，这会造成一些不方便，但是数据吞吐量很好。

有一次客户现场服务说Logstash居然不支持JDBC写入数据的插件，然后得出结论此工具产品做的不好，理由是不满足多个数据库之间数据同步，考虑到他们属于传统实体企业就没有做过多的讨论，实际上Logstash已经做的非常好，适合的数据同步场景很多，相比DataX多了一个分批次连续的定时机制，不知道要减少多少工作量。