Raqsoft

银行数据查询业务中，经常会碰到数据量很大的清单报表。由于用户输入的查询条件可能很宽泛，因此会从数据库中查出几百上千万甚至过亿行的记录，比如银行流水记录；为了避免内存溢出，一般都会使用关系型数据库的分页机制来做，但结果往往也不尽人意；有些情况下甚至底层采用了非关系型数据库，这更会加剧了问题的复杂度。针对这类场景，集算器能够给你一份满意的答卷！...

大数据的4个V说法在业界已经尽人皆知，这是指的大数据本身的特征。现在我们来考察一下用于处理大数据的技术应该具有的特性。为方便记忆，类似4个V，我们把这些特性总结成4个E，用户在选择大数据技术解决方案时可作为参考。1. Easy 大数据技术要足够简单易用这个E很容易理解。要进行大数据处理的场景很多，涉及工作人员也是各种各样的。如果技术的难度太大，那会导致只有少数人能应用，而且实施复杂度较高，这样大数...

从SQL到SPL基本查询语法迁移 之多表操作上一篇我们针对单表的情形了解了如何把数据计算从SQL查询迁移到集算器，或者更准确地说，迁移到集算器所使用的SPL集算语言。这个迁移过程，既有相同的概念，也有不同的思路。接下来，我们一起针对多表的情况看一下集算器和SPL语言是如何发挥更大的优势的。JOIN连接两个记录在前面的例子中，我们得到了每个雇员的销售额，如果进一步还想知道每个雇员给出的最小折扣，那就...

突然滴，MySQL、Hadoop等开源软件有可能被“闭源”的话题火起来了。听说，活跃在我国境内众多著名商用数据库数据仓库都是从这些开源代码改出来的，这要是被鬼子釜底抽薪，那可如何是好？一时间大家都纷纷表示很揪心，心痛得无法呼吸。表担心，有我润乾软件在！润乾，一家国内的基础软件厂商，一个普普通通的软件公司，很小。2000年开始攻克中国式复杂报表的难题，一个清华计算机系毕业的国际数学奥赛冠军带着一帮年...

现在有个说法，国家对基础软硬件的投入太少，经常会说微软、Oracle、Intel这些巨头每年的研发费有多少多少，我们的投入连个零头都不到，当然做不出什么象样的东西了。看起来还真是，似乎还要再加大投入才行？我不懂芯片的事，不知道是不是需要花很多钱才能建出基本的实验生产环境，但软件的研发成本还是比较熟悉的。在我的意识中，国家在这方面投入的钱并不是太少了，已经足够多了。和国外巨头比研发费，你不能拿微软现...

一家之言，开个脑洞。操作系统在市场上的关键点，并不在于进程管理、文件系统这些看起来很核心的东西，这些东西真地可以抄（借鉴一下没关系的）。操作系统要普及成功，关键在于上面开发技术的方便性，也就是开发工具的易用性以及API的丰富性。开发工具就是操作系统的用户界面，决定了用户体验；下层核心是为上层API服务的，也可以说是被API决定的，而不是倒过来。从这个意义上讲，Windows的成功，是因为Visua...

敏捷BI这个词这两年比较流行，其实深究起来就是自主报表，是希望业务人员自己能完成数据分析和呈现。业务人员经常面对临时性的数据分析需求，比如某区域的电商想搞个促销活动，经常需要一批有针对性的用户数据来分析一下，传统手段一般提交给技术部门去实现，这样显然周期长、效率低，有时获得结果时已经失去促销窗口期了。如果能有一套前端工具让业务人员自己做分析和呈现，那无疑会极大地提高决策效率，敏捷BI中说的敏捷多半...

在我们日常的工作中，常常会遇到很多结构相同，但来源不同的数据。有时，这些数据之间完全独立，互不重叠，例如各个分公司从自己系统中导出的销售数据；但有时，这些数据之间又会有大量的重叠，例如常见的一个完整业务流程中涉及的各个系统、各个环节，都可能根据各自收到的单据进行录入。这时，如何对这些重叠数据进行对比，从而发现和纠正其中的错误，就需要我们常说的“自动对账”操作了。在一般业务系统的设计开发中，这种对账...

蒋步星《JOIN运算的简化与提速》系列技术文章。【数据蒋堂】第29期：JOIN运算剖析【数据蒋堂】第30期：JOIN简化 – 消除关联【数据蒋堂】第31期：JOIN简化 – 维度对齐更多敬请期待…..我们重新审视和定义了等值JOIN运算，并简化了语法。一个直接的效果显然是让语句书写和理解更容易。外键属性化、同维表等同化和主子表一体化方案直接消除了显式的关联运算，

我们再来看重新定义JOIN后如何能够提高运算性能，先看外键式JOIN的情况。设有两个表：products商品信息表id        商品编号name  商品名称price   单价…sales商品销售记录seq            序号date          日期productid  商品编号quantity    销售数量…其中sales表中的productid是指向

我们继续讨论外键JOIN，并延用 上一篇 的例子。当数据量大到无法全部放进内存时，前述的指针化方法就不再有效了，因为在外存无法保存事先算好的指针。一般来讲，外键指向的维表容量较小，而不断增长的事实表要大得多。如果内存还能把维表放下的话，我们可以采用临时指向的方法来处理外键。1. P=file(“products.txt”).import()                读

我们再来看同维表和主子表的JOIN，这两种情况的优化提速手段是一样的。设两个关联表的规模（记录数）分别是N和M，则HASH分段技术的计算复杂度（关联字段的比较次数）大概是SUM(Ni*Mi)，其中Ni和Mi分别是HASH值为i的两表记录数，满足N=SUM(Ni)和M=SUM(Mi)，这大概率会比完全遍历时的复杂度N*M要小很多（运气较好的时候会小K倍，K是HASH值的取值范围）。如果这

润乾报表新版发布，自带开源报表中心，拥有完整BI功能“高大上”的商业智能（BI）系统，一直是某些著名厂商的天下。国外的…和…，价格那是相当的昂贵，国内的…及…，价钱那也是一样的不菲。难道广大非著名中小软件公司就只能望而兴叹？众多的中小企业客户就无法共享BI系统带来的价值吗？这种让人郁闷的日子终于到头了！我们不再需要集齐五颗原石，也无需得到宇宙至尊的无限手套，仅仅凭借一件利器就能简单快速地开发BI系...

在银行、财务、销售等系统中，常常会看到这样一类报表，它们一般是从原来的手工报表年代沿袭而来，需要打印在固定大小的纸张上，有着固定的样式要求。具体的形式包括各种登记本册和票据等。在没有报表工具之前，这类报表大部分使用Excel进行制作，费时费力还不易维护，每次都独自加班到很晚（一首凉凉送给自己）。今天，我要带一带新的节奏，展现一下神操作来制作这类单据报表。这次我们拿公积金单据来进行具体操作演示。下图...

随着数据量的持续增长，并发访问越来越密集；以及业务种类的不断丰富，报表需求还在不断增加，数据库需要不断扩容来应对这些变化。然而，仅仅对数据库本身扩容难免陷入高成本低成效的窘境，企业应当使用库外计算来减轻数据库的扩容压力和吞吐瓶颈！...

随着产权交易所业务的发展和 IT 系统的建设，出现了多个系统同时运行，互不连通的问题。由于新老系统采用独立的数据库存储，数据格式、标准、规范都不相同，跨源计算变成了一大难题，常见办法是搭建前置数据库实现统一存储和计算，但改造和开发成本过高，且让管理和后期维护变得复杂！如何以更低成本、更小代价应对以上问题？本文揭晓答案。...

零售行业门店多、客户多、库存多，经常面临的问题：1、各个业务系统之间彼此不相关联，造成信息孤岛，很难从数据中发现隐藏的问题或商机。2、日积月累，报表查询越来越慢，甚至影响业务，如市场营销、数据整理再汇报。3、维护报表数量多，随着零售行业业务种类的不断丰富，报表数量还在不断增加。如何低成本的应对以上窘迫，该案例中可探索详细答案。...

传统企业大数据架构的问题  上图是大家都很熟悉的基于 Hadoop 体系的开源大数据架构图。在这个架构中，大致可以分成三层。最下一层是数据采集，通常会采用 kafka 或者 Flume 将 web 日志通过消息队列传送到存储层或者计算层。对于数据存储，目前 Apache 社区提供了多种存储引擎的选择，除了传统的 HDFS 文件和 HBase，还提供了 Kudu、ORC、Parquet 等列...

在谈集合之前，需要先谈谈离散性的概念：所谓离散性，是指集合的成员可以游离在集合之外存在并参与运算，游离成员还可以再组成新的集合。从离散性的解释上可以知道，离散性是针对集合而言的一种能力，离开集合概念单独谈离散性就没有意义了。离散性是个很简单的特性，几乎所有支持结构（对象）的高级语言都天然支持，比如我们用Java时都可以把数组成员取出来单独计算，也可以再次组成新的数组进行集合运算（不过Jav...

在业务系统中，经常会看到这样的数据显示需求：明细数据显示时，相邻行显示不同的背景色，也就是我们说的隔行异色，效果如下图所示。这种效果有助于用户横向查看数据时避免错行，更加清晰准确。如果不用报表工具，我们通常需要自己花点时间改页面样式，而通过报表工具我们就可以分分钟实现隔行异色效果了。小老师这次教给大家一个简便方法实现上图效果，现在开始上课，谁的小眼睛还没看老师。小老师使用的道具是：润乾报表（敲黑板...

在银行、销售、仓库管理等的数据查询系统中，我们经常会用到精确查询来准确获取想要的数据，但是很多时候我们并不记得确切的检索条件是什么，这样的话，必然会对我们获取数据造成一定的影响，而此时模糊查询的出现很好的解决了这个难题，因其可以根据用户输入的部分关键词，检索到与之相关联的所有选项数据，从而使用户能够尽可能快地找到所需的数据。与精准查询相比，更灵活、方便、快捷的模糊查询，在sql中常用like条件配...

经常有用户会问这个问题，你家的产品能处理多大数据量？似乎是这个值越大产品就越牛。这个问题，其实没多大意义。能处理多大的数据量，还有个很关键的因素是期望的响应时间，在脱离这个因素单纯谈大数据产品的数据处理量，就不知道怎么回答了。考虑只有单台机器的简单情况。如果是希望秒级响应的OLAP式汇总，那么GB级都是挺大的数据了，几乎不可能有什么产品能处理TB级数据（除非有巨大内存）。而如果是数小时内完成的ET...

2018年5月16日，集算器（仓库版）携带多项黑科技正式发布。在发布之前的应用验证中，仓库版就已经用实力赢得了用户的好评。北京银行用户在评价仓库版时表示：在数据分析实践中，高并发访问、大数据量计算造成的系统响应时间过长的问题，始终没有得到很好的解决。集算器（仓库版）的出现，彻底解决了这个难题！用集算器将高频次热点数据前置，构建数据计算中间层，可以说是最佳解决方案，在很多场景下要优于价值百万的数据库...

我们谈了大清单报表的呈现方法，其实有时候这些报表还需要打印，比如银行打印流水对账单。那么，打印是不是也要像呈现那样做一个缓存机制呢？没有这个必要。打印和浏览不同，一般是从头到尾过一遍就行了，过程中没有翻页的需求。这样，只要流式读入数据逐步生成打印页就可以了，不会发生内存溢出的问题。但这个做法仍然比较麻烦，特别是现代浏览器加强了安全控制，applet等插件经常被禁用，打印功能常常不能直接由报表工具提...

在数据查询时，有时会碰到数据量很大的清单报表。用户输入的查询条件很宽泛，可能会从数据库中查出几百上千万行甚至过亿的记录。如果等着把这些记录全部检索出来再生成报表呈现，那需要很长时间，用户体验恶劣；而且报表一般采用内存运算机制，大多数情况下也装不下这么多数据。所以，我们一般都是使用分页呈现的方式，尽量快速地呈现出第一页，然后可以随意翻页显示，每次只显示一页，也不会造成内存溢出。那么，一般的报表工具或...

大数据的性能是个永恒的话题。不过，在实际工作中我们发现，许多人都不知道如何进行最简单的性能估算，结果经常被大数据厂商忽悠:)。这个办法我在以往的文章中也提到过，不过没有以这个题目明确地点出来。其实很简单，就是算一下这些数据从硬盘上取出来用的时间。除了个别按索引取数的运算外，绝大多数运算都会涉及对数据的整体遍历，比如分组汇总统计、按条件查询（非索引字段）；那么，这些运算耗用的时间，无论如何不可能小于...

【数据蒋堂】第36期：JOIN延伸：维度概念谈到数据分析时常常会用到维度这个词，针对数据立方体的钻取、旋转、切片等操作都是围绕维度进行的，几乎所有的数据分析人员都知道并会运用这个术语，但要问及它的定义，却几乎没有人能给出来。通俗来讲，我们把用来分类的属性（字段）称为维度，比如地区、年度、产品类型等；而另外一些用于聚合运算的属性则称为测度，比如销售额、产量、考试成绩等

有了维度定义后，我们就可以来梳理前面讲过的简化JOIN语法了。先定义字段维度：维度字段的维度为其本身；外键字段的维度为相应外键表中关联字段的维度；测度字段没有维度；这是个递归定义。 然后再严格定义同维表和主子表：同维表：两个表的主键字段维度集合对应相同，则称两个表同维；主子表：某个表的主键字段维度集合是另一个表的主键字段维度集合的真子集，则前

明确维度定义后，还可以换一种更清晰的方式来审视数据库的结构。这是我们常见的E-R图：E-R图是个网状结构，实体（表）之间的外键关系直接画在图上，当实体较多时这个图就会显得非常零乱，关联线很随意，任何两个实体之间都有可能发生关联，表现出来的数据结构耦合度很高。在增加删除实体时就要考虑与之关联的所有其它实体，很可能发生遗漏关联或循环关联的现象。而如果把维度抽取出来之后，

数据统计分析软件有哪些？哪个数据统计分析软件比较好？这是很多人的疑问。其实在报表项目中，常常会碰到数据库压力很大影响整个系统性能的问题。由下面的传统方案的结构示意图可以看出，所有源数据的存储和计算都放在数据库完成。当并发访问量较大的时候，虽然每个报表的数据量不大，还是会造成数据库压力过大，成为性能的瓶颈。多数数据库厂商提供的jdbc接口传输数据比较缓慢，在并发量较大的情况，对报表系统性能的影响也非

桌面端数据分析程序语言，其重点是使用方便且计算能力强。考察某种语言是否适合进行桌面端数据分析，可以用六个指标来衡量：应用环境、文件处理、文本和字符串处理、结构化数据处理、模型预测算法、其他非重点指标。应用环境进行桌面数据分析的用户绝大多数都不是专业程序员，他们更习惯在windows下工作，他们缺乏专业程序员拥有的配置环境的技能，因此桌面端分析程序语言的应用环境应当足够简单，应当支持

报表作为数据统计分析软件，当它出现性能问题需要对数据源计算进行优化时，执行路径难以控制是阻碍报表优化的难题之一。这是由于数据库执行路径不透明，程序员很难甚至无法干预执行路径，也就难以提高数据库的性能。而一般报表工具不具备强计算能力，大部分计算仍然要依靠数据库进行，这就导致很多报表优化效果不理想。不同于一般报表工具，润乾集算报表内置了专门用于数据计算的集算引擎，开发人员可以通过编写集算脚本完成报

填报功能是国内报表工具的一个重要特色。国外的报表工具的英文名称是report，完全没有填的意思，而且报表被归为BI类产品，讲究的是事后分析，也不会管数据的录入。但在国内，报表则天然被认为有填写的功能，即使有强烈BI色彩的报表平台，也需要支持填报功能也方便补录数据。考察报表工具的填报功能时，用户常常会注重“填”，也就是看产品提供了多少种编辑组件，这其实是个误区。把表格作为一个整体来输

所谓数据可视化是指把数据以图形动画以及地图等形式呈现出来，这样即直观又美观，易于理解从而看出数据背后的问题。　　要做好数据可视化，需要两方面的能力。一是“艺术”能力，即知道什么样的数据用什么形式去表现最合适，该用柱图时不能用饼图，颜色搭配也要合理，...;另一个是“技术”能力，设计好的呈现方案还要能真地做出来，并且要把成本控制在可接受范围内。这里我们不深入讨论“艺术”问题，来看

这里有点标题党，为了对仗把题目写成这样。其实自助报表和敏捷BI深究起来是一回事，都是希望业务人员自己能完成数据分析和呈现，叫得通俗些是自助报表，洋气一些就是敏捷BI了。经营分析软件中大都会提供丰富的固定报表，能够处理较复杂的计算需求，但毕竟死板。业务经营中常常会有临时性的数据分析需求，传统手段一般提交给技术部门去实现，这样显然周期长效率低，有时获得结果时已经失去意义了。如果能让业务人员自己

报表工具是解决数据呈现问题的，而手机是很方便的数据呈现载体，那么报表工具显然应当提供移动端APP？其实不然，报表工具并不该直接提供移动端APP。更严格的说法：不只是不该有，而且是不能有！​为什么不能有？道理很简单，作为中间件的报表工具是需要被集成的，已经做成APP了咋集成？终端用户采用的移动端APP需要做好用户登录、权限管理等功能，而这些在不同用

产品发展润乾公司在润乾报表3.x中首次应用了非线性报表模型，并在该版本的实践过程中积累了丰富的工程化经验。在这些基础上开发出的润乾报表5.x，实现了理论模型和工程实践的完美结合，不仅保持原有的开发高效性，运算性能指标也有了大幅度提高，成为一款经典的报表工具软件。产品在应用过程中不断有新的需求加入，而且在完善过程中也难以对仍在快速积累中的需求进行深入梳理，润乾报表5.x逐步发展成融合了固定报

SQL的批量结构化数据计算能力是完备的，也就是说找不出什么SQL无法计算的东西。但是其支持层面过低，会导致实际应用时十分繁琐。      具体表现为如下四个方面：计算不分步：SQL要求计算在一个语句内写出，必须采用存储过程才能实施分步计算。不分步不仅造成思维困难，而且难以利用中间

OLAP是商业智能的重要组成部分。从字面上理解，OLAP是在线分析的意思，也就是由用户面对实时的业务数据进行分析操作。但是，当前OLAP概念被严重狭义化了，仅指基于多维数据（或模拟出的类似结构）进行钻取、聚合、旋转、切片等操作，也就是多维交互分析。这种OLAP的应用，需要事先建好

发明SQL的主要目的是为结构化数据提供一种屏弊数据物理存储方案的访问方法，因而在SQL中大量使用了和类英语的词汇和语法以降低其理解和书写困难。而且，作为SQL基础理论的关系代数是个完备的计算体系，原则上可以计算一切。这样看来，我们理所应当地用SQL完成各种数据计算需求。但是，尽管