为什么我基于开源包建的模型效果不好?
机器学习发展到今天已经有众多优秀前辈给我们贡献了各种各种现成的开源包以最流行的 Scikit-learn 为例,提供了包括回归 (Regression)、降维(Dimensionality Reduction)、分类(Classfication)、聚类(Clustering) 等方法的开源包,使用者可以灵活的实现各种建模操作。但是也有人发现了,同样的开源包不同的人建出的模型效果是不一样的,甚至大相
给一句 SQL 就能做多维分析
多维分析程序支持对任何数据库做 SQL 数据集多维分析,只需先把数据源配置好,然后程序猿啪啪几下敲下需要进行多维分析的 SQL 语句就可以,灵活便捷。
把 Excel 透视表搬到 WEB 上
Excel 透视表 - 只要遇见就不曾忘记!根据原始数据勾勾选项拖拖拽拽,分析数据嗖一下就出来了,这么好用的东西怎么能移到 WEB 上呢?
程序数据集上的多维分析
当数据源不是来自文件和 SQL,而是由程序现计算出来的,这种情况在许多 BI 系统中都会出现,BI 系统自己管理数据模型,把数据库挡在后面,不会直接开放 SQL,更不会提供文件让你直接访问,访问数据都要通过程序接口(比如 JavaAPI 或 Webservice)——这样一来,想要对这些程序接口返回的结果集做多维分析看似就有些困难了。没关系!润乾多维分析分分钟就能帮您搞定!
如何才能导出和打印 Echarts 图形?
地球人都知道,报表工具一般都有导出和打印的功能,不仅可以将图形在页面上显示,还可以导出到 WORD、PDF 等文件中提高逼格,或者直接打印出来以供参考。So,每个 baby 都希望被集成的 Echarts 图形也可以,也可以和报表工具本身的那些美腻图形一样被导出打印。但是,没那么简单!Echarts 图形是由 Javascript 亲自在前端网页上绘制的,需要从浏览器中截取图形才能导出和打印,而报
建模高手与初学者的差别在哪里?需要什么样的人来建模?
我们知道,数据挖掘的基本流程包括:(1)业务理解、(2)数据理解、(3)数据准备、(4)数据预处理和建模、(5)模型评估、(6)模型部署应用。其中第 4 步,数据预处理和建模是整个流程的核心部分,其他的步骤都是围绕的该步骤进行的。建模高手和初学者的差距也往往在这里,建出一个模型很容易,快速高效的建出一个好的模型却不容易。机器学习发展到今天已经有众多优秀前辈给我们贡献了各种各种现成的算法包,例如在
完成一个预测建模项目一般需要多长时间?
为了回答这个问题,我们先来了解一下建模的流程,通常一个完整的数据挖掘项目包含以下流程(1)业务理解、(2)数据理解、(3)数据准备、(4)数据预处理和建模、(5)模型评估、(6)模型部署应用。这个流程的操作性很强,也是业界公认标准。业务理解的主要工作有需求调研,了解商务背景;明确业务目标和成功的标准。数据理解和业务理解一般是同时进行的,主要内容包括确定建模所需要的数据,描述数据,探索数据,检验数据
有没有简单易用的数据挖掘工具?
当前用于数据挖掘的工具软件主要有两类,早期都是有图形化界面的商用软件,比如 SAS 和 SPSS,此类工具历史悠久,性能稳定。图形化的操作界面基本以拖拽填写为主,配合少量脚本编程,使用较为方便。不过,此类工具的价格也比较高,一般只有大型企业在用。近年来,随着人工智能的普及,出现许多开源编程类工具,以 Python 和 R 为代表,此类工具操作灵活,支持多种数据挖掘相关拓展库。而且,因为开源而完全免
做人工智能为什么经常要学 python?
当前,提到人工智能、数据科学几乎就一定会提到 Python,很多人工智能相关的课程实质上也都在大篇幅的讲 Python,有的初学者甚至认为人工智能和 Python 是划等号的,随着人工智能概念的火热几乎掀起了一股全民学 Python 的热潮。那么,作为一种计算机程序语言,Python 到底有何魅力,如此受到人工智能的喜爱。总结下来,主要就是两点:(1)丰富的类库支持Python 从面世以来逐渐发展
数据挖掘建模需要什么样的数据?多大量?
数据挖掘通常需要结构化数据才能建模,而不是近些年来热闹的非结构化数据,预测建模仍然是结构化数据上的运算!所谓结构化数据,是指表现为二维形式的数据,一般特点是:数据以行(也称样本)为单位,一行数据表示一个实体的信息,每一行数据的属性(也称字段或列)是相同的。结构化数据可以来自于数据库,也可以来自于文本文件或 Excel。例如预测 titanic 幸存者数据见下图,就是一个结构化数据,数据的每一行表示
数据挖掘是什么?能解决什么问题?
数据挖掘其实是个“古老”的技术,已经有几十年历史了,近年来红火的人工智能又让这个古老技术有了更多关注。那么,到底什么是数据挖掘呢?它又能做什么事呢?傍晚小街路面上沁出微雨后的湿润,和煦的细风吹来,抬头看看天边的晚霞,嗯,明天又是一个好天气。走到水果摊旁,挑了个根蒂蜷缩、敲起来声音浊响的青绿西瓜,心里期待着享受这个好瓜。由路面微湿、微风、晚霞得出明天是个好天气。根蒂蜷缩、敲声浊响、色泽青绿推断出这是
润乾报表多维分析功能漫游
你是否也在苦苦找寻一个处理大量数据特别迅速的报表工具?你是否还在为成千上万数据的复杂计算感到头晕?润乾报表的多维分析功能漫游为您提供有效的解决方案:润乾报表多维分析功能漫游!
润乾报表 dashboard 分析
在《润乾报表多维分析功能漫游》一文中我们已经见识了润乾报表分析控件的妙处:可视化的拖拽模式,灵活的计算方式,脱离敲打复杂多变的查询语句,只需要动动鼠标就可以获取所需要的数据。除了多维分析外,润乾报表还有dashboard分析界面那就是仪表盘,简称DBD,即大屏和分析控件的结合。  
银行业多用户大数据量自助分析提速方案
【摘要】银行自助分析系统用户多,数据量大,系统速度还要求飞快。与此同时,后台数据仓库却已经负担了太多的应用,无法为大量连接提供高性能查询。点击银行业多用户大数据量自助分析提速方案,去乾学院看看集算器如何解决这个矛盾,为自助分析提速! 本文是真实案例,预计阅读时间 3 分钟。方案文件下载
银行业大数据量清单报表案例
【摘要】银行数据查询业务中,经常会碰到数据量很大的清单报表。由于用户输入的查询条件可能很宽泛,因此会从数据库中查出几百上千万甚至过亿行的记录,比如银行流水记录;为了避免内存溢出,一般都会使用关系型数据库的分页机制来做,但结果往往也不尽人意;有些情况下甚至底层采用了非关系型数据库,这更会加剧了问题的复杂度。针对这类场景,集算器能够给你一份满意的答卷!银行业大数据量清单报表案例【下载附件】银行业大数据
银行可视化大屏后端计算案例
【摘要】随着信息化建设的快速发展,可视化大屏需求越来越普及,然而大屏的背后意味着多样性数据源,传统的解决办法总是需要如下一些工作:ETL 工具先抽取清洗 DW 中的数据;文本文件需导入数据库中赋予计算能力后才能计算;开发对接第三方 API 数据接口,需写很多代码才能构造统一对外服务平台接口;这样的模式终将让开发和维护成本变得高昂!银行可视化大屏后端计算案例【下载附件】银行可视化大屏后端计算案例
数据中台技术的利与弊
伴随信息时代的发展,新技术、新框架、新语言层出不穷,解决问题的技术视角其实从来没有改变。所有应用都需要和存储系统相关联,无论存储是 SQL 还是 NOSQL 的。业务系统和数据库遵循不同的开发规范,为了让开发更容易,有一类框架专门帮助解决从应用层到数据库的转换,著名的 ORM 类框架就是其中之一。实际上数据中台技术主要面临的挑战主要也是计算服务和各种数据存储如何便捷的统一起来,并通过服务化 API
合并 mongodb 子文档
【摘要】 Mongodb 的 BSON 存储格式灵活多样,有助于 MongoDB 的入门学习。有集算器 SPL 语言支持后,Mongodb 能实现像数据 SQL 那样的方便查询。若想了解更多,请前往乾学院:合并 mongodb 子文档!  
海量账户大并发实时查询解决方案
【摘要】手机银行查流水、网上银行查收入、游戏账号查明细、手机营业厅查充值记录等等都属于海量账户查询场景。此场景的特点是:访问人数特别多,全量数据超大,而且不能让用户等待!点击海量账户大并发实时查询解决方案,去乾学院看看在大并发海量账户查询场景中,如何用集算器实现秒级的查询速度!方案文件下载
利用集算器实现分库汇总
当单台数据库的数据量太大而影响性能时,可以把数据拆分到多台服务器上,每台服务器只承担部分计算压力,再由SPL合并计算结果。特殊地,数据可拆分为历史数据库和当前实时数据库,由SPL实现T+0计算。下面用几个典型例子来说明分库汇总的用法。过滤订单表orders分库存储在两个Oracle数据库中,数据源名分别为orclA、orclB,请过滤出金额amount大于等于10000的订单。SPL代码如下:排序