DCM（一个能够改善所有应用数据交互场景的中间件新秀） _数据

宁可枝头抱香死，何曾吹落北风中。这篇文章主要讲述DCM：一个能够改善所有应用数据交互场景的中间件新秀相关的知识，希望能为你提供帮助。

摘要：几乎所有涉及应用数据交互的场景都可以通过DCM来改善应用结构，提升开发与计算效率。

本文分享自华为云社区《??DCM：中间件家族迎来新成员??》，作者：石臻臻的杂货铺。
DCM是什么现代应用无时无刻不在与数据打交道，数据计算无处不在，报表统计、数据分析、业务处理不一而足。当前数据处理的主要手段仍然是以关系数据库为代表的相关技术，虽然使用高级语言（如java）硬编码也能实现各类计算，但远不如数据库（SQL）方便，数据库在当代数据处理中仍然发挥举足轻重的作用。
不过，随着信息技术的发展，存储与计算分离、微服务、前置计算、边缘计算等架构与概念的兴起，过于沉重、封闭的数据库在应对这些场景时越来越显得捉襟见肘。数据库要求数据入库才能计算，但面对丰富的多样数据源时，数据入库不仅效率低资源消耗大，实时性也无法保障，而有的数据只是临时使用却要入库持久化就更得不偿失了。另外对于微服务、边缘计算等需要将计算能力前置到应用端的场景，数据库也很难嵌入使用。
在这样的背景下，如果有一种不依赖数据库、具备开放计算能力、能够与应用嵌入集成使用的数据计算处理技术，那么这些问题就都能够很好地解决，这就是数据计算中间件（Data Computing Middleware，简称DCM）。DCM的应用场景非常广泛，可以说无处不在，在优化应用开发、微服务实现、存储过程替代、数据库解耦、ETL辅助、多样性数据源计算、BI数据准备等等多方面都能发挥重要的作用，几乎所有涉及应用数据交互的场景都可以通过DCM来改善应用结构，提升开发与计算效率。
DCM应用场景优化应用开发
应用中数据处理逻辑只能通过编码实现，使用原生的Java实现由于缺少必要的结构化计算类库往往比较困难，即使用新增加的Stream/Kotlin也并没有明显改善。借助ORM技术可以一定程度缓解开发困境，但仍然缺乏专业的结构化数据类型，集合运算不够方便，同时读写数据库时代码繁琐，复杂计算也难以实现。ORM的这些缺点经常导致业务逻辑的开发效率不仅没有明显提升，甚至还大幅降低。此外，这些实现方式还会导致应用结构问题。Java实现的计算逻辑必须与主应用一起部署导致紧耦合，同时由于不支持热部署开发运维也很麻烦。
如果借助DCM的敏捷计算、易集成、热切换等特性，在应用中替代Java实现数据处理逻辑，就可以很好解决上述问题，不仅开发效率提升，还可以优化应用结构，实现计算模块的解耦，同时支持热部署。

多样性数据源计算
现代应用还经常面临多样性数据源问题，通过数据库处理不仅需要数据入库，效率低下，还无法保障数据的实时性。不同数据源有各自的优势，RDB计算能力较强，但IO吞吐能力弱；NoSQL的IO效率高，但计算能力很弱；而文本等文件数据完全没有计算能力，但使用非常灵活。强迫这些数据入库就会丧失这些原数据源的优势。
通过DCM的多源混算能力，不仅可以直接对RDB、文本、Excel、JSON、XML、NoSQL以及其他网络接口数据进行混合计算，保证数据与计算的实时性，而且还能同时保留各类数据源的优点，充分发挥其效力。

微服务实现
当前微服务实现时仍然大量依赖Java和数据库实施数据处理，Java的缺点在于实现复杂、无法热切换；而数据库由于有“库”的限制，多源数据要入库才能计算，灵活性很低，不仅数据时效性无法保证，也无法充分发挥各类数据源的优势。
将可集成的DCM分别嵌入中台或微服务的各个环节完成数据采集整理、数据处理以及前置的数据计算任务，利用开放的计算体系可以充分发挥多数据源自身的优势，灵活性增强。多源数据处理、实时计算、热部署这些问题均能迎刃而解。

存储过程替代
以往为了实现复杂计算或整理数据常常会使用存储过程，存储过程在库内计算有一定优势，但缺点也很明显。存储过程缺乏可移植性，编辑调试困难，创建和使用存储过程需要较高权限存在安全问题，为前端应用服务的存储过程还会造成数据库与应用紧耦合。
通过DCM将存储过程外置到应用中，可以实现“库外存储过程”，数据库则主要用于存储，将存储过程从数据库中解耦出来就可以很好解决存储过程带来的各类问题。

报表BI数据准备
为报表提供数据准备是DCM的重要场景，以往使用数据库为报表准备数据存在实现难度高、耦合性强等问题，而报表本身计算能力不足又无法完成很多复杂计算。通过DCM的库外强计算能力就可以为报表提供一个专门的数据计算层，不仅可以解耦数据库为数据库减负，还可以弥补报表工具自身的计算能力不足。逻辑上分层后，报表开发维护都很清爽。

中间表消除
有时为了加快查询效率事先将要查询的数据加工成结果表存储在数据库中，这就是中间表。另外，有些复杂计算需要保存中间结果也会存成中间表；多样数据源也要先存成中间表才能在数据库中混合计算。与存储过程类似，中间表一旦建立就可能被多个应用（模块）使用，造成应用与数据库的紧耦合，同时由于中间表无法轻易删除，数量会越积越多。中间表数量过多会引发数据库容量和性能问题，存储中间表需要空间，加工中间表则需要数据库计算资源。
通过DCM可以将中间表外置到文件系统，利用DCM实施计算，解耦数据库减轻数据库存储和计算负担。这里的关键是DCM使得文件也拥有了计算能力，所以才能将库内的中间表置于库外，原来中间表放在库内主要为了获得数据库的计算能力，现在有DCM的计算能力中间表存成什么形式就不重要了，外置到文件系统反而更优。

T+0查询
数据量积累到一定程度时基于生产库查询会影响交易，这时就会将大量的历史数据剥离到其他历史数据库中，进行冷热数据分离。这时如果要查询全量数据就要完成跨库查询、冷热数据路由等工作。数据库对于跨库查询尤其是跨异构库存在很多问题，不仅效率低下，还存在数据传输不稳定、可扩展性低等很多不足，无法很好实现T+0全量数据查询。
而这些问题都可以通过DCM来解决，由于具备独立且完善的计算能力，可以分别从不同的数据库取数计算，因此可以很好适应异构数据库的情况，还可以根据数据库的资源状况决定计算是在数据库还是DCM中实施，非常灵活。在计算实现上，DCM的敏捷计算能力还可以简化T+0查询中的复杂计算，提升开发效率。

ETL
ETL需要对数据清洗转换再加载到目标端，但由于源端数据可能来源多处（文本、数据库、web）加上数据质量参差不齐，因此E和T这两个步骤会涉及大量数据计算。目前除了数据库以外，其他数据源并不太具备这样的计算能力，想要完成这些计算就要先加载到数据库再进行，这就形成了LET。大量无用的数据存储在数据库中会占用大量存储空间，极易引发容量问题。而将清洗和转换的计算工作都压给数据库又会增加数据处理时间，再叠加大量未经清洗转换的原始数据入库时间，有限的ETL时间窗口很可能不够，如果无法在规定时间完成ETL工作就会影响第二天的业务。
在ETL任务中引入DCM就可以按顺序完成清洗E、转换T、加载L，解决LET面临的各种问题。借助DCM的开放计算能力，在库外对多源数据实施清洗转换，DCM拥有强计算能力可以应对各类复杂计算，最后将整理后数据装在到目标端，实现真正的ETL。

DCM特性可以看到，DCM的应用场景非常广泛。那么要很好应对这些场景，一个优秀的DCM应该具备哪些特点呢？
兼容性（Compatible）
首先DCM需要具备很好的兼容性，可以跨平台使用，各类操作系统、云平台、应用服务器下均可以很好运行，这决定了DCM的使用范围。
此外，兼容性还意味着可以兼容多样性数据源，无论何种数据源都可以直接使用并进行混合计算，这要求DCM拥有足够强的开放性。
热部署（Hot-deploy）
数据处理是一种高频且稳定性较差的场景，在业务开展过程中经常要新增修改计算任务，这就要求DCM应该具备热部署特性，修改数据处理逻辑无需重启应用（服务）就能生效。
高性能（Efficient）
计算性能是数据计算场景重点关注的方面，有时会成为最主要的关注点，所谓天下武功无快不破。DCM应该能够高效处理数据，提供诸如高性能计算库、高性能存方案、并行计算等高性能保障机制。
敏捷性（Agile）
敏捷性要求DCM能够快速实现数据处理逻辑，具备完备的计算能力，尤其面对复杂计算场景通过足够简单的编码就能完成数据处理，同时可以高效运行。这需要DCM提供敏捷编程机制和易于使用的开发环境等支持。
扩展性（Scalable）
当计算容量无法满足需要时，DCM应该具备灵活的横向扩展能力。扩展性对当代应用十分重要，扩展能力的好坏决定了DCM的上限。
集成性（Embeddable）
DCM应该能够很好与应用集成嵌入使用，在应用内充当计算引擎，作为应用的一部分随应用一起打包部署。这样应用本身就获得了强计算能力，不再强依赖数据库后，可以很好应对存储与计算分离、微服务和边缘计算等场景。并且，良好的集成性还是敏捷性的另一方面体现，DCM很轻，随时随地都能嵌入与应用结合使用。
如果将DCM这几个特性的首字母组合起来，与CHEESE（奶酪）很接近（CHEASE），而DCM的作用就像夹在汉堡里的奶酪一样，如果缺少，味道和营养都会差很多。

这样能否作为理想的DCM就可以使用CHEASE的标准去考察。这里不妨看一下一些主流技术对DCM的满足情况。
现有技术的情况SQL
数据库是使用SQL的主要阵地，数据库通常具备较强的计算能力，一些头部数据库的计算性能也很强，基本可以满足高性能（E）的需要。而且数据库过于封闭，数据要入库才能计算，无法很好满足多样性数据源场景的需要，兼容性（C）较差。
对于集成性（E），由于绝大部分数据库都是独立使用的，极少数（如SQLite）支持嵌入的数据库往往功能和性能都达不到要求，因此数据库几乎不满足集成性的要求。
而SQL作为专用的集合计算语言，实现简单计算很方便，但复杂计算用SQL表达很繁琐，经常要嵌套多层，实际业务中经常能看到几千行的“长”SQL，不仅难写，维护也不方便，所以SQL不太符合敏捷性（A）的要求。
与数据库类似的Hadoop相关技术也存在同样的问题，封闭性导致兼容性差、敏捷性不足、基本不具备集成性等缺点，虽然在扩展性方面表现要优于数据库，但总体并不符合DCM的要求。Spark的表现要略好，但Scala不支持热部署，实现复杂计算也不够方便，而Spark SQL仍然存在SQL的那些问题。这些技术都过于沉重，很难满足DCM在敏捷性、集成性、热部署等方面的需要。
Java
Java作为原生的编程语言可以很好跨平台运行，也可以通过编码完成多数据源计算任务，因此兼容性（C）很好。而且对于大部分都采用Java开发的应用来说，集成性（E）也不在话下。
但Java的缺点也很明显，作为编译型语言无法实现热部署（H）。由于缺少必要的结构化计算类库完成简单的分组汇总也要几十行代码，就别提复杂计算了。虽然现在微服务架构中也经常使用Java硬编码完成数据处理，但其实计算实现要比SQL复杂得多，没办法，计算前置就不能再用数据库，难写也得挺着，因此敏捷性（A）极其不足。虽然在Java8以后引入了Stream，但计算能力并没有实质改善（Kotlin也存在类似的问题）。
使用Java虽然理论上也能实现各类高性能算法，但是如果只是为某个应用/项目服务，要实现这些高性能算法封装投入就太大了，因此从实际应用角度来看，Java并不具备高性能（E）特性。扩展性（S）也存在同样的问题。因此综合来看，Java很难作为优秀的DCM技术使用。
python
Python作为大火的一类计算技术不得不提一下。Python的兼容性（C）较强，无论是跨平台还是对接多数据源都能支持。尤其是丰富的数据处理包让Python的适用范围极广。
Python在结构化数据处理相比于Java等技术有相当的优势，但却难说很完善，尤其在处理有序分组等复杂计算时会很绕，Python在敏捷性（A）上略有所欠缺。
不仅如此，Pandas的性能（E）也往往达不到要求，尤其针对大数据量计算方面，这跟算法的实现效率有很大关系，敏捷语法可以很方便地实现高性能算法，反之就很困难。同样，在扩展性（S）方面，Python也不尽如人意，本质上来讲作为编程语言的Python要拥有良好的扩展性需要投入大量资源开发完成，这点与Java是一样的。
Python最大的问题是集成性（E），很难与现有应用集成在一起使用。虽然可以通过诸如sidecar模式进行服务间调用，但本质上与DCM要求与应用结合嵌入在一起（同一个进程）相去甚远。Python的主要应用场景并非像Java一样做企业级应用开发，各有用途，勉强不来。归根到底，专业的事儿还需要专业的工具来做。
专业数据计算中间件SPL开源集算器SPL是专业的数据计算中间件，具备不依赖数据库的完备计算能力，同时开放的计算能力可以混合计算多样性数据，同时解释执行的SPL天然支持热部署，良好的集成性可以很方便嵌入应用中，让应用拥有强计算能力，充分发挥DCM的效力。
兼容性
SPL采用Java开发，跨平台能力与Java一致，可以很好运行在各类操作系统、云平台下。而在多数据源支持方面，SPL具备开放的计算能力，可以对接多种数据源，RDB、NoSQL、CSV、Excel、JSON/XML、Hadoop、RESTful、Webservice都可以直接对接并进行混合计算，不需要入库，数据实时性和计算实时性都可以很好保障。

多源计算支持很好解决了原来数据库无法跨源计算、无法计算外部数据的问题，再加上SPL完备的计算能力和相对SQL更简洁的语法，对于应用来说就获得了与数据库相当（超过）的计算能力。
除了原生计算语法，SPL还提供了SQL支持（相当SQL92标准），可以使用SQL查询文本、Excel、NoSQL等非RDB数据源，这样就极大方便了熟悉SQL的应用开发人员。
【DCM（一个能够改善所有应用数据交互场景的中间件新秀）】
DCM只有在开放计算体系的支持下才能拥有足够强的兼容性，才能适应更多的应用场景。
热部署
SPL采用解释执行机制，天然支持热部署。这样对于一些稳定性差经常需要新增、修改计算逻辑的业务（如报表、微服务）非常友好。

高性能
在性能方面，SPL提供了诸多高性能算法与高性能存储机制。在前面提到的DCM消除中间表和ETL场景中，数据往往要落地成文件存储在数据库外，这时采用SPL的文件格式存储可以获得比文本等开放格式高很多的性能。
SPL提供了两种存储类型：集文件和组表。集文件采用了压缩技术（占用空间更小读取更快），存储了数据类型（无需解析数据类型读取更快），支持可追加数据的倍增分段机制，利用分段策略很容易实现并行计算，保证计算性能。组表支持列式存储，在参与计算的列数（字段）较少时会有巨大优势。组表上还实现了minmax索引，同时支持倍增分段，这样不仅能享受到列存的优势，也更容易并行提升计算性能。
SPL还支持各种高性能算法。比如常见的TopN运算，在SPL中TopN被理解为聚合运算，这样可以将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩展应用范围。

这里的语句中没有排序字样，也不会产生大排序的动作，在全集还是分组中计算TopN的语法基本一致，而且都会有较高的性能，类似的算法在SPL中还有很多。
SPL也很容易实施并行计算，发挥多CPU的优势。SPL有很多计算函数都提供并行机制，如文件读取、过滤、排序只要增加一个@m选项就可以自动实施并行计算，简单方便。同时也可以显示编写并行程序，通过多线程并行提升计算性能。

敏捷性
SPL提供了原生的计算语法和简洁易用的IDE环境，在IDE中不仅可以很方便编码调试，过程计算的每步计算结果都可以实时查看，网格式编码代码天然整齐，通过格子名称引用中间计算结果无需定义变量，简单方便。

同时，基于SPL丰富的计算类库实施结构化数据计算更方便，分组汇总、循环、过滤、集合运算、有序计算等应有尽有。

SPL尤其擅长复杂计算，原来SQL要嵌套很多层的计算使用SPL却可以很方便实现。比如根据股票记录计算某只股票最长连续上涨多少天？SPL就比SQL简单很多。

上面SQL嵌套了3层，读起来都很绕就别提写了；下面的SPL完全按照自然思维、简单3行就能实现，高下立判。
良好的敏捷性不仅能提升开发效率，很多高性能算法通过SPL可以很方便实现。算法不仅要能想出来，还要能实现，最好实现还简单，SPL提供了这种可能。
扩展性
对于计算性能要求较高的场景，SPL还可以部署单独的计算服务，同时支持多机分布式集群，支持负载均衡和容错机制，当计算资源达到上限时可以通过横向扩容增加算力，具备良好的扩展性。
在分布式计算中，用户可根据数据和计算任务的特点灵活定制数据分布及冗余方案，有效减少节点间数据传输量，以获得更高性能，实现可控数据分布。
SPL采用无中心集群设计，集群没有永久的中心主控节点，允许程序员用代码控制参与计算的节点，从而有效避免单点失效。同时SPL会根据每个节点空闲程度（线程数量）决定是否分配任务，实现负担和资源的有效平衡。
在容错方面，SPL提供内外存两种数据容错机制，外存冗余式容错和内存备胎式容错。支持计算容错，节点故障时自动将该节点计算任务迁移掉其他节点继续完成。
集成性
作为DCM与应用结合方面，SPL提供了标准JDBC/ODBC/RESTful接口，应用可以像调用存储过程一样请求SPL计算结果。

逻辑上SPL作为DCM介于应用和数据源之间实施数据处理，对上提供计算服务，对下屏蔽多样性数据源差异，充分彰显了DCM的重要作用。
JDBC调用SPL 代码示例：

Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
CallableStatement st = conn.prepareCall("call splscript(?, ?)");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();

综合起来，从DCM的6个特性（CHEASE）来看，SPL在各方面能力综合起来十分均衡，整体远优于其他技术，是DCM的理想选择。

SPL资料