文章目录
-
- DCM是什么
- DCM应用场景
-
- 优化应用开发
- 计算多样性数据源
- 微服务实现
- 替换存储过程
- 报表BI数据准备
- 中间表消除
- T 0查询
- ETL
- DCM特性
-
- 兼容性(Compatible)
- 热部署(Hot-deploy)
- 高性能(Efficient)
- 敏捷性(Agile)
- 扩展性(Scalable)
- 集成性(Embeddable)
- 现有技术
-
- SQL
- Java
- Python
- 中间件的专业数据计算
-
- 兼容性
- 热部署
- 高性能
- 敏捷性
- 扩展性
- 集成性
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天然支持热部署,良好的集成性可以很方便嵌入应用中,让应用拥有强计算能力,充分发挥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只有在开放计算体系的支持下才能拥有足够强的兼容性,才能适应更多的应用场景。
热部署
SPL采用解释执行机制,天然支持热部署。这样对于一些稳定性差经常需要新增、修改计算逻辑的业务(如报表、微服务)非常友好。
高性能
在性能方面,SPL提供了诸多高性能算法与高性能存储机制。在前面提到的DCM消除中间表和ETL场景中,数据往往要落地成文件存储在数据库外,这时采用SPL的文件格式存储可以获得比文本等开放格式高很多的性能。
SPL提供了两种存储类型:集文件和组表。采用了压缩技术(占用空间更小读取更快),存储了数据类型(无需解析数据类型读取更快),支持可追加数据的倍增分段机制,利用分段策略很容易实现并行计算,保证计算性能。支持列式存储,在参与计算的列数(字段)较少时会有巨大优势。组表上还实现了minmax索引,同时支持倍增分段,这样不仅能享受到列存的优势,也更容易并行提升计算性能。
SPL还支持各种高性能算法。比如常见的TopN运算,在SPL中TopN被理解为聚合运算,这样可以将高复杂度的排序转换成低复杂度的聚合运算,而且很还能扩展应用范围。
A | ||
---|---|---|
1 | =file(“data.ctx”).create().cursor() | |
2 | =A1.groups(;top(10,amount)) | 金额在前 10 名的订单 |
3 | =A1.groups(area;top(10,amount)) | 每个地区金额在前 10 名的订单 |
这里的语句中没有排序字样,也不会产生大排序的动作,在全集还是分组中计算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的理想选择。