ITPub博客

集算器不仅有大数据计算，还有诗和远方。最近看到不少写诗机器人的新闻，于是尝试用集算器简单地实现一个。这个实现真的很简单，简单到只有10几行代码，请看实现步骤：1下载字典和诗词从网上找一个用于分词的字典文件，里面记录着每个中文词汇的词性。我从GitHub上找了一个，稍微处理之后保存到集文件dict.btx。下载宋词三百首的txt文件，去掉空格和换行，以及其它文字以外的字符，得到一个长字符串。2训练对

5 综合案例实际业务中，多表关联运算十分常见，外键表、同维表、主子表这几种关联类型可能会混合出现。下面我们来看一个综合案例。5.1 表结构和查询目标某电商平台中和订单编号这个字段相关的有6个表，主要表结构如下：他们都靠订单编号字段进行关联，下面是订单表和另外5个表的对应关系：用户表和用户地址表，这两个表是按照用户编号字段1对1的关系，这是同维表情况。商品信息表和类别信息表是通过类别编码进行关联，这

3 半内存时的外键表外键指针化的前提是事实表和维表都可以装入内存，但实际业务中涉及的数据量可能很大，那就不能采用这种方法了。3.1 维表内存化如果只是事实表很大，而维表仍然可以全部装入内存，那么仍然可以采用上面的外键指针化方法处理，只要修改一下对事实表的访问，使用游标的方式取从集文件里分批取数进行处理即可。不过因为这种指针是在游标取数时才临时建立的，所以就不象全内存时那样可以复用已经建立过的指针了

JOIN是关系数据库中常用运算，用于把多个表进行关联，关联条件一般是判断某个关联字段的值是否相等。随着关联表的增多或者关联条件越来越复杂，无论理解查询含义、实现查询语句，还是在查询的性能方面，可以说JOIN都是最具挑战的SQL运算，没有之一。特别是JOIN的性能，一直是个老大难问题。下面我们将基于数据计算中间件（DCM）——集算器，来提供一些提升运算性能的方法。当然，我们不是介绍如何在写SQL语句

JSON作为一种轻量级的数据交换格式，因其易于读写和交互的特点，已逐渐成为主流的数据类型之一。常见的编程语言大多都对 JSON 的读取与解析提供了接口，但是接下来如何把多层 JSON 数据经过筛选、计算并展开成二维数据，就需要开发人员去头疼了。本文就为大家分享一下如何利用集算器 SPL（结构化处理语言）轻松解决 JSON 数据解析入库的问题。JSON 数据文件导入与解析根据 JSON 数据文件的复

上一讲中，我们介绍了如何用SPL将一行日志结构化为一条记录，今天则要说一下多行日志对应一条记录的情况，我们称之为不定行日志。事实上，集算器自己的输出日志就是这种不定行日志，我们来看一下集算器节点机下的一个日志文件rqlog. log，同样摘录两段日志：[2018-05-14 09:20:20]DEBUG: 临时文件过期时间为：12小时。[2018-05-14 09:20:20]DEBUG: Tem

从 SQL 到集算器的基本查询语法迁移（一）单表操作数据库和数据分析领域，有一个强大的存在，大名 SQL，全名结构化查询语言 (Structured Query Language)。从字面上看，这个语言的目标就是把数据“查询”出来，而查询这个词给人的感觉并不是很难。但实际上，为了支持貌似简单的查询，需要进行大量的计算动作，甚至整个过程就是一个多步骤的计算，前后步骤之间还有很强的依赖关系，前面计算的

随着互联网的快速发展，大数据时代的到来，数据资源的处理成了各行各业都面临的热点问题。除了通过特别专业、特别特别昂贵、特别特别特别复杂的分析平台来处理特别 x4 海量的数据外，我们还常常会遇到 Excel（xls，xlsx）文件这样手边能够即时获得的数据文件。使用 Excel 记录、处理和交换数据，是因为这个软件的简单方便，而如果又需要通过一堆外部调用来进行后续的分析处理，那就会显得十分笨拙。现在我

TXT文本文件是我们常用的在应用之间传递数据的途径之一，因为它具有通用、灵活、易维护等诸多优点。不过并不是所有应用都提供了生成txt文件的功能，往往需要额外的程序设计和开发工作才能获得。这时如果能够有一个通用的工具软件，灵活地根据需要生成目标格式的文本，将能够极大地助力我们的业务工作。本文介绍的集算器就正是这样一款高效、灵活的通用工具软件，能够从不同数据源读取、计算并导出txt文件。本文将着重介绍

SQL，在数据处理和分析领域基本上类似“普通话”的地位，几乎是一项必备的能力，但是要使用SQL，又离不开关系数据库系统，也就是RDBMS，这就好比普通话主要还是得在中国说才管用。当然，如果为了去英国美国，学个英语还算值，这就像学个Python、Hadoop，出去找工作也算是个技能。但是如果要在一般的文本数据，或者Excel表格上作分析，就像是去个基里巴斯之类的小国家，为了能够愉快的购物，难道还要卷

数据查询业务中，有时会碰到数据量很大的清单报表。由于用户输入的查询条件可能很宽泛，因此会从数据库中查出几百上千万甚至过亿行的记录，常见的包括银行流水记录，物流明细等。呈现时如果等着把这些记录全部检索出来再生成报表，那会需要很长时间，用户体验自然会非常恶劣。而且，报表一般采用内存运算机制，大多数情况下内存里也装不下这么多数据。所以，我们一般都会使用分页呈现的方式，尽量快速地呈现出第一页，然后用户可以

通常，日志文件都是文本格式，其中的内容是非结构化的文本串。这就使得我们查询日志信息时，一般只能使用文本编辑软件的搜索功能，输入关键字后，靠眼力去侦查每处匹配结果。在日志量不大，或者只是偶尔查一下时，这么操作倒也无妨。不过，再简单的事情也怕多次重复。如果需要频繁查询，量变就可能引起质变。如果每次还都要靠人工搜索，那么就算有再好的视力，也会有头晕目眩的时候。因此，想要轻松查询日志，就必须找到一款合适的

窗口函数是 SQL2003 标准才开始有的一系列 SQL 函数，用于应付一些复杂运算是比较方便。但是普遍使用的 MySQL 数据库对窗口函数支持得却很不好，直到最近的版本才开始有部分支持，这当然就让 MySQL 程序员很郁闷了。实际操作中，我们可以在 MySQL 里用 SQL 拼出窗口函数功能，但是需要使用用户变量以及多个 SELECT 表达式从左到右依次计算的隐含规则。下面我们来看两个例子（为调

IN 和 EXISTS 是 SQL 中常见的复杂条件，在将 SQL（存储过程）转换成库外计算获取高性能时也会面对这些问题。本文将以 TPC-H 定义的模型为基础，介绍如何用集算器的语法实现 IN、EXISTS 并做优化。TPC-H 是 TPC 事务处理性能委员会制定的用于 OLAP 数据库管理系统的测试标准，模拟真实商业应用环境，以评估商业分析中决策支持系统的性能。TPC-H 模型定义了

有时我们需要用程序来自动生成 Excel 文件，但 Excel 本身带的 VBA 并不好用，而集算器作为数据处理工具实现这个需求就会方便很多。本文将介绍如何用集算器生成 Excel 文件，而集算器本身强大的数据计算能力不是本文重点，因此文中只是简单地用文本作为数据源举例，实际应用中可能会从各种各样的数据源中取数，再经过一系列运算得到需要导出的数据。　　本文中用到的函数请参看集算器文档《函数参考》。

使用缓存可以提升报表性能是不争的事实，一般高端报表工具都会提供报表缓存功能，可将整个报表计算结果缓存在文件系统中，以便用户下次访问相同参数的报表时可以快速读取缓存结果进行展现。但有些情况下报表开发人员还希望对缓存的内容进行更准确和灵活的控制，比如缓存的不是整个报表结果而是其中一部分、缓存内容可被其它报表或程序复用，以及对不同的缓存结果设置不同的超时时间，从而应对数据量和实时性方面的不同情况。这时，

问题的提出多维分析（BI）系统后台数据源通常有三种选择。一、普通数据库；二、专业数据仓库；三、BI 系统自带的数据源。但是，这三种选择都有各自的问题。普通数据库一般都是行式存储，很难获得多维分析希望的高性能，只适用较小数据量。专业数据仓库有不少是列式存储的，性能问题不大，但是价格都比较昂贵，建设、扩展和维护成本也都非常高。BI 系统自带的数据源都比较封闭，只能为自家的 BI 前端提供支持，无法为多

提起 Excel 一定都不陌生，尤其是里面的数据透视表，对于需要进行聚合分析的情况，根据原始数据勾勾选选就能完成，用起来是倍儿爽吧。那么，操作起来这么省心的功能要是能移到 WEB 上，嵌入俺的应用程序里，是不是就完美了？so easy! 雷锋同志马上来教你做这事儿。主角登场——润乾报表多维分析！下面就先以 Excel 文件作为数据源，与各位小伙伴分享一下多维分析的应用案例，欢迎各位热烈围观，优雅吐

问题的提出BI 系统的常见结构是：前端是 BI 应用，负责多维分析的用户操作和结果呈现；后台是数据库 / 数据仓库，负责数据计算和存储。前端和后台之间用 SQL 作为接口。实际应用中，常常出现后台数据仓库压力过重的问题。问题表现为前端响应时间过长，数据仓库反应速度变慢。常见的解决方案是在数据仓库和应用之间再增加一个前置数据库。但是前置数据库和后台数据仓库之间很难实现数据的路由和混合计算，例如：访问

多数据集关联报表是很常见的报表形式，它允许开发者分别从不同的来源（表或数据库）分别准备数据形成不同的数据集，在报表端（模板）通过表达式描述数据集间的关系完成关联。这样可以避免在数据准备时写过于复杂的 SQL/ 存储过程，降低维护难度。尤其当报表数据来源于多个数据库时，多数据集的优势更加明显。凡事都有两面性，多数据集为开发带来方便的同时却对性能造成了极大的影响。在报表端进行多数据集关联时要计算关联表