暂无个人介绍
数据库和文件系统各有优劣:数据库读写性能较低、结构 rigid,但具备计算能力和数据一致性保障;文件系统灵活易管理、读写高效,但缺乏计算能力且无法保证一致性。针对仅需高效存储与灵活管理的场景,文件系统更优,但其计算短板可通过开源工具 SPL(Structured Process Language)弥补。SPL 提供独立计算语法及高性能文件格式(如集文件、组表),支持复杂计算与多源混合查询,甚至可替代数据仓库。此外,SPL 易集成、支持热切换,大幅提升开发运维效率,是后数据库时代文件存储的理想补充方案。
传统交易型数据库在分析计算中常遇性能瓶颈,将数据迁至OLAP数据仓库虽可缓解,但成本高、架构复杂。SPL通过轻量级列存文件存储历史数据,提供强大计算能力,大幅简化架构并提升性能。它优化了列式存储、数据压缩与多线程并行处理,在常规及复杂计算场景中均表现优异,甚至单机性能超越集群。实际案例中,SPL在250亿行数据的时空碰撞问题上,仅用6分钟完成ClickHouse集群30分钟的任务。
esProc SPL 处理多层 JSON 数据比 DuckDB 更便捷,尤其在保留 JSON 层次与复杂计算时优势明显。DuckDB 虽能通过 `read_json_auto()` 将 JSON 解析为表格结构,但面对深层次或复杂运算时,SQL 需频繁使用 UNNEST、子查询等结构,逻辑易变得繁琐。而 SPL 以集合运算方式直接处理子表,代码更简洁直观,无需复杂关联或 Lambda 语法,同时保持 JSON 原始结构。esProc SPL 开源免费,适合复杂 JSON 场景,欢迎至乾学院探索!
跨库计算是数据分析中的常见难题,尤其涉及多数据库系统时,表间 JOIN 操作复杂度显著提升。esProc 提供了一种高效解决方案,能够简化跨库 JOIN 的实现。例如,在车辆管理、交管和公民信息系统中,通过 esProc 可轻松完成如下任务:按城市统计有车公民事件数量、找出近一年获表彰的车主信息,以及按年份和品牌统计车辆违章次数。esProc 支持不同关联场景(如维表关联与主子表关联)的优化算法,如内存索引、游标处理和有序归并,从而大幅提升编码和运算效率。无论是同构还是异构数据源,esProc 均能灵活应对,为复杂数据分析提供强大支持。
分组是结构化数据计算的常见操作,SQL 和 Python 均支持分组聚合,但功能较为有限。相比之下,esProc SPL 提供了更强大的分组运算能力,尤其在处理分组子集和有序分组时表现出色。例如,SPL 可轻松实现复杂场景如筛选人数大于10的部门员工、计算股票最长连涨天数等。SPL 支持真正的分组子集概念及连续操作,代码简洁易懂,远超 SQL 和 Python。此外,SPL 还提供对位分组、枚举分组等多种独特方法,堪称史上最强。SPL 是开源免费的,欢迎前往乾学院了解更多。[源码地址](https://github.com/SPLWare/esProc)
关系数据库和SQL在企业级应用中面临诸多挑战,如复杂SQL难以移植、数据库负担重、应用间强耦合等。Python虽是替代选择,但在大数据运算和版本管理方面存在不足。SPL(esProc Structured Programming Language)作为开源语言,专门针对结构化数据计算,解决了Python的这些硬伤。它提供高效的大数据运算能力、并行处理、高性能文件存储格式(如btx、ctx),以及一致的版本管理,确保企业级应用的稳定性和高性能。此外,SPL与Java无缝集成,适合现代J2EE体系应用,简化开发并提升性能。
流数据源的动态无界特性使得传统数据库技术难以直接处理,而Heron、Samza、Storm、Spark、Flink等计算框架在流计算领域取得了先发优势。然而,这些框架往往侧重于访问能力,计算能力不足,尤其在高级计算如流批混算、复杂计算和高性能计算方面表现欠佳。esProc SPL作为基于JVM的轻量级开源计算类库,专注于提升流计算的计算能力,支持丰富的流数据访问、灵活的集成接口和高效的内外存存储格式,具备强大的高级计算功能,能够简化业务逻辑开发并适应多样的应用场景。SPL通过专业的计算语言和结构化数据处理能力,为流计算提供了更优的解决方案。
在数据分析领域,Excel 和 BI 工具适合处理简单任务,但面对复杂分析(如跨行数据、滑动窗口等)时显得力不从心。编程语言虽有强计算能力,但交互性差,难以实时反馈结果。SPL(Structured Process Language)则结合了两者的优点,采用网格式编程,支持实时查看中间结果,并具备强大的有序和集合运算能力,使复杂任务变得简单直观。SPL 让数据分析师既能享受 Excel 的交互性,又能利用编程的强大计算能力,解决了强计算与交互性的两难问题。
TP 库与 AP 库的结合虽为业界通识,但在实际操作中面临诸多挑战。引入 AP 库不仅增加成本和运维复杂度,还可能导致 T+0 问题和迁移风险。esProc SPL 提供了一种轻量级、灵活的解决方案,作为专业的计算引擎,它无需数据库的复杂管理,支持高效计算和跨源混合计算,尤其在处理复杂任务时表现优异。SPL 语言简化了开发流程,提高了调试效率,且开源免费,是值得考虑的替代方案。
传统数据仓库基于封闭的数据库体系,继承了元数据管理和数据约束特性,导致其在处理多样化、实时性数据时面临诸多挑战。封闭性使得数据必须预先加载到数据库中才能进行计算,增加了ETL复杂性和延迟,难以满足现代应用对实时数据和跨源计算的需求。此外,封闭性还限制了数据湖的建设,导致中间表累积、资源浪费和运维困难等问题。 相比之下,基于文件系统的开放数据仓库(如esProc SPL)通过去除这些限制,提供了更高的灵活性和效率。文件存储成本低、管理方便,支持存算分离和跨源计算,适合处理大规模、多样化的数据源。 SPL不仅计算能力强,还能实现高效的文件存储和独创的高性能算法,大幅提升了数据分析的速度和实时性。
数据分析师常需处理各种数据操作,如过滤、分组、汇总等,SQL 在这些基本需求上表现得心应手。然而,面对本地文件数据或更复杂需求时,SQL 的局限性显现。SPL(Structured Process Language)则提供了更灵活的解决方案,无需数据库环境,直接从文件计算,代码简洁易懂,调试工具强大,极大提升了数据分析的效率和交互性。
随着数据量的增长和业务复杂度的提升,数据仓库性能问题日益凸显,如查询慢、跑批不完等。传统解决方案如集群、预计算和优化引擎虽有一定效果,但成本高、灵活性差或性能提升有限。esProc SPL 提供了一种新的解决思路,通过非 SQL 的计算体系,结合高性能算法和优化的数据存储,实现更高效的数据处理,尤其适用于复杂计算场景。
现代大数据应用架构中,数据中心作为核心,连接数据源与应用,承担着数据处理与服务的重要角色。然而,随着数据量的激增,数据中心面临运维复杂、体系封闭及应用间耦合性高等挑战。为缓解这些问题,一种轻量级的解决方案——esProc SPL应运而生。esProc SPL通过集成性、开放性、高性能、数据路由和敏捷性等特性,有效解决了现有架构的不足,实现了灵活高效的数据处理,特别适用于应用端的前置计算,降低了整体成本和复杂度。
在大数据领域,尽管非结构化数据占据了大数据平台80%以上的存储空间,结构化数据分析依然是核心任务。SQL因其广泛的应用基础和易于上手的特点成为大数据处理的主要语言,各大厂商纷纷支持SQL以提高市场竞争力。然而,SQL在处理复杂计算时表现出的性能和开发效率低下问题日益凸显,如难以充分利用现代硬件能力、复杂SQL优化困难等。为了解决这些问题,出现了像SPL这样的开源计算引擎,它通过提供更高效的开发体验和计算性能,以及对多种数据源的支持,为大数据处理带来了新的解决方案。
本文探讨了SQL在实际应用中的复杂性和难度,指出教科书中的SQL例句虽然简单,但现实中的SQL查询往往长达数千行,涉及多层嵌套,对程序员构成挑战。文章分析了SQL的两个主要缺陷:集合化不彻底和缺乏有序支持,并通过具体示例展示了这些问题如何影响SQL的编写。最后,文章推荐使用esProc SPL,一种增强的编程语言,能够更自然地处理集合和有序数据,简化复杂查询的编写。
本文探讨了云计算环境下“算力无限”的误区,指出即使云上硬件资源看似无限,但由于网络延迟、算法模型限制及成本等因素,实际运算效率未必能线性扩展。文章强调了提高单机运算效率的重要性,推荐使用SPL等工具优化算法,以实现更高性能。
大数据时代,分布式数仓如MPP成为热门技术,但其高昂的成本让人望而却步。对于多数任务,数据量并未达到PB级,单体数据库即可胜任。然而,由于SQL语法的局限性和计算任务的复杂性,分布式解决方案显得更为必要。esProc SPL作为一种开源轻量级计算引擎,通过高效的算法和存储机制,实现了单机性能超越集群的效果,为低成本、高效能的数据处理提供了新选择。
SQLite 是轻量级数据库,适用于小微型应用,但其对外部数据源支持较弱、无存储过程等问题影响了开发效率。esProc SPL 是一个纯 Java 开发的免费开源工具,支持标准 JDBC 接口,提供丰富的数据源访问、强大的流程控制和高效的数据处理能力,尤其适合 Java 和安卓开发。SPL 代码简洁易懂,支持热切换,可大幅提高开发效率。
SQL 是大数据计算中最常用的工具,但在实际应用中,SQL 经常跑得很慢,浪费大量硬件资源。例如,某银行的反洗钱计算在 11 节点的 Vertica 集群上跑了 1.5 小时,而用 SPL 重写后,单机只需 26 秒。类似地,电商漏斗运算和时空碰撞任务在使用 SPL 后,性能也大幅提升。这是因为 SQL 无法写出低复杂度的算法,而 SPL 提供了更强大的数据类型和基础运算,能够实现高效计算。
SPL(Structured Process Language)是一种专为处理结构化数据设计的开源编程语言,其独特之处在于代码写在格子里,而非传统的文本形式。SPL 的格子代码不仅整齐直观,还支持直接使用格子名作为变量名,简化了变量管理。此外,SPL 引入了函数选项和层次参数,使代码更加简洁高效。相比 Java、SQL 和 Python,SPL 在处理复杂数据计算时表现出色,能够显著减少代码量,提高开发效率和调试便利性。
数据分析编程用什么,SQL、python or SPL?话不多说,直接上代码,对比明显,明眼人一看就明了:本案例涵盖五个数据分析任务:1) 计算用户会话次数;2) 球员连续得分分析;3) 连续三天活跃用户数统计;4) 新用户次日留存率计算;5) 股价涨跌幅分析。每个任务基于相应数据表进行处理和计算。
大型数据库经过多年运行常积累数以万计的数据表,其中很多是中间表,占用大量资源,导致数据库膨胀。这些中间表大多为数据呈现服务,因前端报表频繁修改而不断增加。SPL 通过独立计算引擎,将中间数据移至文件系统,减少数据库负担,提高性能,优化资源利用。
业务系统产生的明细数据需经加工处理以支持企业经营,此过程称作“跑批”,常在夜间进行以免影响生产系统。跑批任务涉及大量数据及复杂计算,导致耗时较长。开源计算引擎SPL可直接基于文件系统计算,提供更优算法与存储机制,显著提升跑批效率。例如,L银行贷款协议跑批任务从2小时缩短至10分钟,性能提高12倍;P保险公司车险业务的历史保单关联任务从近2小时缩短至17分钟,速度提升近7倍;T银行贷款跑批任务提速204倍。
我们通过使用开源 SPL 重写了多个金融行业的 SQL 任务,实现了显著的性能提升,如保险公司团保明细单查询提速 2000+ 倍、银行 POS 机交易报表提速 30+ 倍等。这些优化的核心在于使用了更低复杂度的算法,而非依赖硬件加速。SPL 基于离散数据集理论,提供了丰富的高性能算法,使得复杂任务的优化成为可能。更多案例和详细技术解析可参见乾学院的相关课程和图书。
应用计算困境:Java 作为主流开发语言,在数据处理方面存在复杂度高的问题,而 SQL 虽然简洁但受限于数据库架构。SPL(Structured Process Language)是一种纯 Java 开发的数据处理语言,结合了 Java 的架构灵活性和 SQL 的简洁性。SPL 提供简洁的语法、完善的计算能力、高效的 IDE、大数据支持、与 Java 应用无缝集成以及开放性和热切换特性,能够大幅提升开发效率和性能。
W银行指标查询系统用于计算和展示各类汇总指标,支持银行经营决策。因数据量庞大,系统采用预计算方式,但随着指标数量激增,预计算方式逐渐成为瓶颈。文章详细介绍了系统面临的挑战及优化方案,包括列式存储、有序归并、多线程计算等技术,最终实现了从明细数据实时计算指标的目标,显著提升了系统性能。
A电商公司常用漏斗转化率分析来统计用户购物行为。此过程需处理大量用户会话数据,传统SQL实现复杂低效。文中提供了一种基于SPL的专业数据计算引擎解决方案,通过预先排序数据和有序归并算法,显著提升了计算性能,使14天跨度3步漏斗分析在10秒内完成,远超预期。该方法不仅代码简洁,易于扩展,还大幅降低了内存消耗,适合处理大规模数据集。
SPL(Structured Process Language)是一款开源软件,允许用户直接对CSV、XLS等文件进行SQL查询,无需将数据导入数据库。它提供了标准的JDBC驱动,支持复杂的SQL操作,如JOIN、子查询和WITH语句,还能处理非标准格式的文件和JSON数据。SPL不仅简化了数据查询,还提供了强大的计算能力和友好的IDE,适用于多种数据源的混合计算。
本文探讨了1TB数据量的实际意义,通过对比日常业务量和数据库处理能力,揭示了1TB数据的庞大。文中指出,虽然一些机构拥有PB级别的数据,但这更多是存储需求而非计算需求。文章最后强调,优化TB级数据处理效率,如将几小时的处理时间缩短至几分钟,对于大多数应用场景来说更为实际和重要。
ClickHouse 是一款以速度快著称的分析型数据库,尤其在列式宽表遍历方面表现出色。然而,面对复杂查询和关联运算时,ClickHouse 的性能急剧下降,甚至无法执行某些任务。相比之下,esProc SPL 通过更简洁的 SPL 语法和强大的优化能力,在各种复杂场景下均表现出色,全面超越 ClickHouse。实际案例显示,esProc SPL 在处理大规模数据时,性能提升可达数十倍。
SQL 作为结构化数据计算的主要语言,虽然广泛应用于关系数据库和大数据平台,但在复杂计算场景中表现不佳,如股票连涨天数和大集合中的 TopN 计算。这些问题源于 SQL 的理论基础——关系代数,缺乏必要的数据类型和运算。相比之下,esProc SPL 通过引入“离散数据集”这一新代数体系,能够更简洁高效地处理复杂计算任务。
本文通过对比Java程序从Oracle、MySQL数据库读取数据与读取文本文件的性能,揭示数据库IO速度远低于文件读取的现状。在相同硬件环境下,读取3000万行记录,Oracle耗时280秒,MySQL耗时380秒,而文本文件仅需42秒。此外,通过SPL实现并行处理,可显著提升读取速度,尤其是在处理大规模数据时。实验还探讨了数据库接口慢的问题及其对性能的影响,提出在追求高性能计算时应尽量避免从数据库读取数据的建议。
列存是常见的数据存储技术,说到列存常常就意味着高性能,现代分析型数据库基本都会把列存作为标配, 列存的基本原理是减少硬盘的读取量。一个数据表有多个列,但运算可能只会用到其中少数几列,采用列存时,用不着的列就不必读出来了,而采用行式存储时,则要把所有列都扫描一遍。当取用列只占总列数的小部分时,列存的 IO 时间优势会非常大,就会显得计算速度快了很多。 不过,列存也有另一面,并不是在任何场景下都有优势。
早期应用通常只会连接一个数据库,计算也都由数据库完成,基本不存在多数据源混合计算的问题。而现代应用的数据源变得很丰富,同一个应用也可能访问多种数据源,各种 SQL 和 NoSQL 数据库、文本 /XLS、WebService/Restful、Kafka、Hadoop、…。多数据源上的混合计算就是个摆在桌面需要解决的问题了。 直接在应用中硬编码实现是很繁琐的,Java 这些常用的应用开发语言很不擅长做这类事,和 SQL 比,简洁性差得很远。
关系代数已经发明五十年了,五十年前的应用需求以及硬件环境,和今天比的差异是很巨大了,继续延用五十年前的理论来解决今天的问题,听着就感觉太陈旧了?然而现实就是这样,由于存量用户太多,而且也还没有成熟的新技术出现,基于关系代数的 SQL,今天仍然是最重要的数据库语言。虽然这几十年来也有一些改进完善,但根子并没有变,面对当代的复杂需求和硬件环境,SQL 不胜任也是情理之中的事。
我们介绍的 esProc SPL 是一个数据分析引擎,具备 4 个主要特点:低代码、高性能、轻量级、全功能。SPL 不仅写得简单,跑得也更快,既可以独立使用还能与应用集成嵌入,同时适用于多种应用场景。使用 esProc SPL 实现数据分析业务,整体应用成本将比以 SQL 为代表的传统技术低出几倍。
数据湖有三个重要满足点,既要保持数据的原样(全量信息入湖),也要可以方便计算使用(数据变现),还希望建设成本低廉(显然的)。但是,当前的技术方案无法同时满足这三点。
发明 SQL 的初衷之一显然是为了降低人们实施数据查询计算的难度。SQL 中用了不少类英语的词汇和语法,这是希望非技术人员也能掌握。确实,简单的 SQL 可以当作英语阅读,即使没有程序设计经验的人也能运用。 然而,面对稍稍复杂的查询计算需求,SQL 就会显得力不从心,经常写出几百行有多层嵌套的语句。这种 SQL,不要说非技术人员难以完成,即使对于专业程序员也不是件容易的事,常常成为很多软件企业应聘考试的重头戏。三行五行的 SQL 仅存在教科书和培训班,现实中用于报表查询的 SQL 通常是以“K”计的。