共计 3203 个字符，预计需要花费 9 分钟才能阅读完成。
摘要：在没有 ROMA Compose 之前，实现一个跨数据源的关联查问是一个十分艰巨的工作。
1. ROMA Compose 为何诞生
试想这样一个场景，主管让刚入职的小沛今天上班前给他发一份报表。小沛灰溜溜的关上需要清单一看，好家伙，报表须要连贯各个不必数据源，A 部门提供的数据存在 MySQL、B 部门提供的数据存在 Oracle、C 部门提供的数据存在 Redis、D 部门罗唆数据库也不是了，间接只提供了一系列 API。
思考到后续更新的须要，小沛还须要每天拉取数据同时进行各种过滤操作。数学业余的萌新小沛写 Matlab 是相当在行。然而跨源对数据进行关联查问，同时还须要思考主外键关系、执行效率、数据准确性等问题，着实让小沛头疼不已，无可奈何当场抉择放弃。
与上述场景相似的是，理论生产过程中咱们须要联通各个不同的数据源（数据库、API 等）来获取咱们须要的数据。
在这种状况下，咱们不仅要要去编写各个不同数据源的连接器，而且数据量大的状况下各个数据之间的关系将会变得非常复杂，关联查问各个数据源并且兼顾好效率问题无疑是一个非常让人头疼的工作。更致命的是，数据不是变化无穷的，随时会有新的数据源退出、老的数据源删除，这时候又须要对好不容易理清并优化好的代码进行更改。
上述情况经验老到的程序员死点脑细胞或者也能优雅的解决，但对于个别的业务人员切实是有点强人所难了，偏偏这样的场景又并不少见。
ROMA Compose 通过元数据模型驱动，构建业务逻辑关系，能够优雅的解决这一类问题。在用户抉择要进行关联的数据源和数据源之间的关系后，ROMA Compose 能疾速对数据进行编排，以 API 的模式返回查问接口给用户，用户调用 API 即可实现数据源之间的关联查问，无需任何代码操作。作为一个 NO CODE 平台，ROMA Compose 秉承着将简单留给本人，将不便留给用户的理念，对用户屏蔽了上述所有技术细节，整个操作过程通过利落拽和点击就能实现。
2. ROMA Compose 个性介绍
ROMA Compose 除了数据疾速编排外，还有许多优雅的个性来帮忙用户晋升效率，升高应用门槛，上面筛选几个个性做简略的介绍。
2.1 NO CODE
NO CODE，顾名思义，就是让用户从繁琐的代码中解脱进去，将精力更多的专一于业务细节，是目前软件畛域的次要趋势之一。
正如上文所说，ROMA Compose 对用户屏蔽了所有的技术细节，用户无需编写各个数据源的连接器、无需思考数据源之间的关联关系、查问效率、以及过滤条件等问题。通过网页的点击与托拉拽，用户就能对本人的数据源进行编排并生成 API。用户惟一须要把握的是这些数据源之间的业务知识，通过业务知识设置各个数据源之间的关联关系而后进行编排。
回到文章一结尾的例子，有了 ROMA Compose，小沛只用在数据源的展现界面建设各个数据源之间的关系，在 API 界面抉择入参（查问条件），出参（返回的字段），编辑实现后公布 API，再对 API 进行调用，就实现了各个部门不同数据源之间数据的查问操作。短短几分钟就实现了两天的工作量。
2.2 业务关系梳理
在理论工作中，公司各个数据源不仅数量合起来不可胜数，许多表名和字段名更是不讲武德，命名千奇百怪，置信除了 DBA 外很少有人能厘清这些表与字段的实在含意。
为了解决上述问题，帮用户进一步梳理数据源之间的业务关系，ROMA Compose 做了以下两大个性：
· 基于元数据驱动的利用模型，联合 ROMA Connect 的利用业务模型（Application Business Model，ABM）对数据源进行对立治理。
· 引入利用模型图谱，图谱提供全量数据源展现视图，并反对基于视图的模型关系创立。
2.2.1 ABM
首先是 ABM，ABM 简略来说就是一个专门为数据源服务的注册核心，如果部门外部有数据要向其余部门凋谢，那么他们只须要在 ABM 中注册本人数据源的元数据信息。同时为了防止表名看不懂的可怕景象，ABM 还反对用户上传数据源的业务含意，ABM 能主动将元数据信息与业务信息进行关联。
除了简略的业务含意关联外，ABM 还反对 L1 到 L5 级别的模型分层定义，帮忙用户进一步从业务的角度对数据源进行梳理。
2.2.2 利用模型图谱
除了简略的列表展现数据源、数据源关系外，ROMA Compose 还反对以图表的局势展现以后环境下数据源以及数据源之间的关系，上图中的每个节点示意数据源，节点之间的箭头示意数据源关系，这样做有不少不言而喻的长处：
数据可视化，让数据源和关系更加直观的展现给用户。
数据源关系编辑，除了传统的表单操作外，ROMA Compose 还反对更加灵便的图形界面操作，在数据源视图上通过鼠标点击、拖拽就能设置数据源之前的关联关系、关联字段。
层次化展现数据，以上图为例，用户节点属于主节点，起作用相似于树的根节点，是数据查问的入口。ROMA Compose 依照与主节点间隔的不同对数据源进行分类，让用户对 API 的编排效率有一种更直观的意识，因为间隔越远，阐明要连贯的数据源越多，相应的执行效率也会越慢。
还是以小沛为例，在 ROMA Compose 呈现之前，小沛每天都要跟不同部门的人确认他们是否有本人想要的数据源，这些字段的含意，长度，类型等信息，更致命的是这些信息自身还会随时进行变动，一度让他十分头疼。
2.3 多数据源反对
多数据源反对作为 ROMA Compose 的外围个性之一，在上文曾经呈现了屡次。理论开发过程中，咱们不仅会遇到品种繁多的数据库（不同型号、不同版本），在波及到对外我的项目时，更大可能会只提供一个 API。编写不同数据源的连接器对技术人员而言属于反复造轮子没什么意义的事件，对业务人员就更不敌对了，进一步减少了应用门槛。
因而 ROMA Compose 底层的查问服务器编写了很多目前支流数据库的连接器，以及 API 数据源的连接器，目前也在进一步开发音讯队列等的连接器，力求尽可能多的反对各种数据源。
2.4 业务规定
让咱们持续小沛的例子，小沛之前的工作有相当一部分工夫花在了业务规定的梳理上。有些数据来自用户输出，经常会有很多不合理的数据甚至是空数据，还有些数据属于异样信息与错误信息，这些芜杂的数据从业务逻辑上来讲是齐全不须要的。小沛在拿到数据后第一工夫就是在老板看到之前将这些奇奇怪怪、形形色色的数据毁灭掉。
在理论的 ETL 过程中，相似的场景并不少见，基于业务规定对数据进行梳理往往是咱们从源端拿到数据后的第一步操作。思考这种状况，ROMA Compose 也反对通过业务规定对数据进行筛选。在编排数据源定义 API 阶段，用户能对每个数据源的字段进行业务规定的定义，比方过删除 ID 为空的字段，保留两天内的数据，保留结尾不为 test 的数据等，尽可能的从源头帮用户进行数据筛选。ROMA Compose 目前反对以下业务规定筛选，并且预计在未来还会反对更灵便的业务规定定义。
- 等于、不等于
- 为空、不为空
- 大于、大于等于
- 小于、小于等于
- 蕴含、不蕴含
- 开始蕴含、开始不蕴含
- 完结蕴含、完结不蕴含
同时为了撑持某些特定场合（比方只保留近两天的数据），ROMA Compose 还引入了工夫和字符串处理函数，反对获取以后零碎工夫戳和工夫加减等基本操作。对于字符串则反对 replace，substring 等基本操作。
总结
—
在没有 ROMA Compose 之前，对于小沛这样的业务人员而言，实现一个跨数据源的关联查问是一个十分艰巨的工作。ROMA Compose 让小沛有更多的精力去关注业务细节，解脱繁琐的代码。
同样的，咱们由衷心愿 ROMA Compose 也能帮忙屏幕前的大家，让大家有更多的工夫去思考，而不是浪费时间在反复造轮子上。
秉承将简单留给本人，将简略留给用户的设计理念，置信在大家的帮忙下咱们置信 ROMA Compose 会越做越好。
本文分享自华为云社区《ROMA__新武器上线了 -ROMA Compose__》，原文作者：中间件小哥 _。_
点击关注，第一工夫理解华为云陈腐技术~
