ITPub博客

【摘要】        MongoDB提供的 lookup 对多表关联实现了基本的支持，但面对一些比较复杂的关联情况，往往会遇到 shell 脚本过于复杂的问题。而集算器 SPL 语言，则因其离散性、易用性恰好能弥补 Mongo 这方面的不足。若想了解更多，请前往乾学院!      &nb

【摘要】  关键词：集算器、SPL、数据脱敏、报表 1）、数据脱敏是“指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全技术之一。” 2）、本文介绍的脱敏数

1、    生成连续整数序列MySQL8:  with recursive t(n) as (select 1union allselect n+1 from t where n<7)select * from t;Oracle：select level nfrom dual connect by level<=7;集算器 SPL：A1：构造从

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

【摘要】基于数据库系统的 T+0 全量实时查询，在数据量很大时一般只能进行数据库扩容（包括分库手段），成本高昂；如果采用文件系统和生产数据库混合运算，就可以实现低成本高性能的 T+0 查询，而热导出机制则是这个方案的基础！一 问题背景在报表的应用系统中，用户越来越关注数据的实时性，希望最新发生的数据能在报表中体现出来，也就是我们常说的T+0场景, 以此及时辅助决策、驱动运营。比如交通大数据应用的场

中间表的由来中间表是数据库中专门存放中间计算结果的数据表。报表系统中的中间表是普遍存在的。那么，这些中间表是如何出现的？为什么中间表会越来越多？中间表会给项目组带来什么样的困扰，如何解决这些困扰？这里我们就尝试探讨一下这个问题。中间表出现的典型场景主要有三个：一步算不出来。数据库中的原始数据表要经过复杂计算，才能在报表上展现出来。一个 SQL 很难实现这样的复杂计算。要连续多个 SQL 实现，前面

MongoDB属于 NoSql 中的基于分布式文件存储的文档型数据库，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。Mongo 最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，但是写起来并不简单。若能集算器 SPL 语言结合，

问题介绍要在 Java 代码中实现类似 SQL 中的 GroupBy 分组聚合运算，是比较繁琐的，通常先要声明数据结构（Java 实体类），然后用 Java 集合进行循环遍历，最后根据分组条件添加到某个子集合中。Java 8 有了 Lambda（stream）代码简洁了许多，分组后往往还要跟着聚合操作，仍然需要单写聚合函数 sum(),count(*),topN()等。这些还都是最常规的分组和聚合

识别手写的阿拉伯数字，对于人类来说十分简单，但是对于程序来说还是有些复杂的。不过随着机器学习技术的普及，使用10几行代码，实现一个能够识别手写数字的程序，并不是一件难事。这是因为有太多的机器学习模型可以拿来直接用，比如tensorflow、caffe，在python下都有现成的安装包，写一个识别数字的程序，10几行代码足够了。然而我想做的，是不借助任何第三方的库，从零开始，完全自己实现一个这样的程

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

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

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

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

1. 问题背景在日常工作中我们经常遇到具有相同表头的 Excel 文件，需要将它们合并到同一个工作表中再进行分析。当文件比较多时，手工合并表格通常是件很麻烦的事情，而如果数据量很大，用 Excel 自带的 VBA 来处理也会经常卡死。今天我就来分享一个专业的外部数据工具——集算器，掌握了集算器处理 Excel 多表合并的方法，就不用再编写复杂且低效的 VBA 代码了，简单的几行 SPL(Struc

有关国际象棋的问题很多，八皇后问题就是其中相当著名的一个。在 8×8 的国际象棋棋盘中，放入 8 个皇后，使它们不互相攻击，共有多少种方法呢？国际象棋中皇后的威力巨大，攻击范围是同一行、同一列以及同一斜行，因此，符合条件的 8 个皇后必须都不在同一行、同一列或者同一斜行上。由于每一行中只能放入一个皇后，所以可以使用一个长度为 8 的序列，依次设入每行中皇后所在的列数，以此来表示皇后的放置状态。当某

内存计算指数据事先存储于内存，各步骤中间结果不落硬盘的计算方式，适合性能要求较高，并发较大的情况。HANA、TimesTen等内存数据库可实现内存计算，但这类产品价格昂贵结构复杂实施困难，总体拥有成本较高。本文介绍的集算器同样可实现内存计算，而且结构简单实施方便，是一种轻量级内存计算引擎。下面就来介绍一下集算器实现内存计算的一般过程。一、     

1. 问题背景在日常工作中我们经常遇到具有相同表头的 Excel 文件，需要将它们合并到同一个工作表中再进行分析。当文件比较多时，手工合并表格通常是件很麻烦的事情，而如果数据量很大，用 Excel 自带的 VBA 来处理也会经常卡死。今天我就来分享一个专业的外部数据工具——集算器，掌握了集算器处理 Excel 多表合并的方法，就不用再编写复杂且低效的 VBA 代码了，简单的几行 SPL(Struc

一 问题背景绝大多数的应用系统中，一开始数据的存储和计算基本都是由数据库来完成的，同时服务于业务交易和报表查询；不过在经过几年信息化建设和数据积累后，常常都会遇到数据库压力变大，从而导致性能瓶颈的问题。 究其原因，往往发现针对历史数据查询的报表在其中占了很大比重。进一步分析会发现，这类报表通常都有如下特征： 1、数据变化小：供查询的历史数据几乎不再发生变化； 2、数据量大：数据量随时间不断增加；

【报表查询性能】1. 数据量大或并发多导致的查询性能低下，BI 界面拖拽响应很慢通过集算器编写更为简单高效的算法加速计算进程，提升查询性能采用集算器可控存储和索引机制，为 BI（CUBE）提供高速的数据存储2.T+0 实时全量查询报表涉及数据量大，影响生产系统运行，而分库后又难以实施跨库混合运算将冷热数据分离，仅将当期热数据存放在数据库中，冷数据存储在文件系统或数据库中，通过集算器完成跨源（库）计

一 问题背景我们先来看一张资产负债表:这是一个典型的中国式复杂报表格式，其复杂并不在于布局，而在于其中“期末余额”的每个单元格都是一个需要独立计算的指标，互相之间几乎没有关系，事实上就是一个各种指标的汇总清单，而这些指标往往会有上百个之多。在源数据表结构中，有一个字段称为科目，其长度总是固定的 10 位，如：1234567890，如下图：科目字段的值实际上是一个分层的代码，而前面表里上百