ITPub博客

问题介绍要在 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，如下图：科目字段的值实际上是一个分层的代码，而前面表里上百

2.4 有序计算方案在充分利用遍历一次的特点进行优化后，可能我们还会觉得计算性能有点慢，希望有进一步优化的空间。由于每次只需要取出总数据量的很小一部分 (100 个指标涉及的所有科目号大概几百个，即在几百万记录中取几百条)，这时我们通常能想到的是：如果能利用数据有序直接进行有序查找(若源数据有序，可以快速定位到这几百条记录，不需要遍历几百万记录甚至更多的数据)，将能够获得更好的查询效率。我们可以利

Oracle 支持一些独特的语法和函数，在移植到 MySQL 上时或多或少给程序员造成了困扰，下面我们针对 Oracle 的一些特殊用法举例并讲解如何用集算器来完成同样功能。这些方法当然也不限于针对 MySQL，对于所有其它数据库也能支持。 1、         递归语句a)  &nbsp

在报表的数据统计中，常常会根据精度呈现或者单位换算等要求，需要对数据执行四舍五入的操作，这种操作称为舍位处理。简单直接的舍位处理有可能会带来隐患，原本平衡的数据关系可能会被打破。为了保证报表中数据关系的正确，就需要调整舍位之后的数据，使得数据重新变得平衡，这样的调整就叫做舍位平衡。在这里我们就讨论一下如何利用集算器来处理舍位平衡问题。舍位处理往往会采取四舍五入计算，这时就会产生误差，而如果报表中有

在《秒级展现的百万级大清单报表怎么做》中，我们介绍了无论 RDB 还是非 RDB，润乾报表都能够通过异步线程实现秒级海量大清单报表（以下简称：大报表）。实际业务中，除了查询明细，有时还要展现全量汇总数据，或者查询分组明细和计算分组汇总。本文就将介绍这些带有汇总和分组的大报表的开发方法。带汇总的大报表       在大报表中计算汇总值与常规

1.    简单合并（FROM）       所谓跨库数据表，是指逻辑上同一张数据表被分别存储在不同数据库中。其原因有可能是因为数据量太大，放在一个数据库难以处理，也可能在业务上就需要将生产库和历史库分开。而不同的数据库，可能只是部署在不同的机器上的同种数据库，也可能是连类型都不同的数据库系统。&n

概述：运行在 JVM 上的 SQL 函数和存储过程总所周知，有些数据库没有强大的分析函数（eg. Mysql）, 有些数据库没有存储过程（eg. Vertica），当遇到复杂的数据计算，往往只能通过 Python,R 等外部脚本来实现，但这些脚本语言和主流工程语言（Java）集成性不好，如果直接用工程语言实现类似 SQL 函数和存储过程的功能，经常只是针对某个计算需求编写冗长的代码，代码几乎不可复

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