自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(23)
  • 资源 (2)
  • 收藏
  • 关注

原创 数据仓库实践杂谈(十九)——数据挖掘

我们经常说,数据统计是根据已有规律的进行计算得到结果,比如特定产品销量的地区分布或时间分布,因为我们都知道销量和地区、时间肯定是关联的。而数据挖掘则是发现未知的规律。比如传说已久的“啤酒与尿布”的故事,就是数据挖掘的一个成功的典型范例。虽然不存在普适性,但针对沃尔玛在当时特定的场景确实揭露了未知的、实际存在的规律。

2020-03-28 15:52:59 1972

原创 数据仓库实践杂谈(十八)——关于报表

报表绝对是让人痛苦的东西。格式复杂、需求多变,没事就增加几个。虽然说起报表感觉很老土,但确实是需求量最大的一个东西。貌似做报表多的人,基本上都会做一个自己的工具,至少也会做一个引擎,按照自己的理解用一种结构化加动态的方式去定义所需要的报表,可以灵活的选择所需要的数据,设计展现样式生成报表。当年有幸开始给银行做报表,一不小心做了很多年,也算是总结出一套报表处理的机制。

2020-03-16 16:23:40 3329

原创 软件开发随笔系列二——关于架构和模型

这篇文章基本上不涉及具体的技能、工具,更多是我对“如何设计好一个软件”这个问题多年来的思考和总结。要回答这个问题,我觉得第一是要说清楚这个软件究竟是什么样的。我自己的答案就是上面描述的“3+1”模型:> 3:(功能模型+流程模型+数据模型)> 1:技术实现一般人都说做软件是一个逻辑性特别强的工作,确实也如此,尤其是在设计业务逻辑,算法上,人类需要用到的所有逻辑方法,都需要用上——演绎和归纳。但就是因为太过抽象,所以我们需要各种工具(流程图、脑图,甚至用图画工具画画,用笔画画)来努力让软件变得具现化

2020-03-14 11:59:55 3563

原创 软件开发随笔系列一——分布式架构实现

文章总结了自己从业以来关于分布式架构的积累,技术日益发展,总在积累和创新。从二十多年前写第一行BASIC程序到现在,对于软件开发技术不断发展,最大一个感受就是,各种可复用的开源组件越发丰富,很多以前自己想做但没做,或者做不出来的,甚至没想到的,都有了,而且都做的很好。以至于到了现在,有些人认为没用过或者不会用某些开源组件,就是不懂技术,或者不懂架构了。诚然,熟悉众多开源组件,用搭积木的方式快速构建软件的技术原型会节省很多时间。但软件并不是靠搭积木就能搭出来的。

2020-03-01 18:39:46 5246 1

原创 数据仓库实践杂谈(十七)——数据回滚

在OLTP系统,数据回滚一般直接依赖于数据库的事务机制,出现问题直接执行回滚操作即可。但在数据仓库中,是无法使用数据库的事务机制的。对于使用关系数据库加载数据的情况,往往会关闭事务以提高效率。毕竟,需要批量加载很多张数据量很大的表的情况下,如果要在一个事务里面完成所有数据的加载,除了对服务器要求很高(undo表空间巨大)之外,一旦出意外,只能全部回滚,不能实现断点恢复。另外,Hadoop生态的平台并不支持事务。这种情况下,就需要自己记下来所做的操作,或者仓库中表的初始状态,以便出问题之后恢复。

2020-02-29 19:42:00 2616 2

原创 数据仓库实践杂谈(十六)——渐变维

渐变维也叫缓慢渐变维度。这个概念提出来,其实也就直接意味着,我们分析的角度并不是一成不变,而是会变化的。前面谈增量/拉链的时候,更多讨论“事实”数据的变化。业务每天都在发生这个是必然的。但对应的分析维度也一定会变化。

2020-02-29 19:29:59 2270

原创 数据仓库实践杂谈(十五)——维模型

前面说到过,维模型的典型结构就是维表+事实表。一个事实表+关联的多个维表,组成一个星型模型。多个事实表+多个可能共享的维表组成星系模型。

2020-02-21 17:36:15 1855

原创 数据仓库实践杂谈(十四)——数据模型参考

众所周知,信息系统最重要的作用就是处理并保存信息,尤其在商业应用中。以银行记账为例,最重要的是账本,不管前面的流程如何,只要记下来张三某年某月存入100元,业务就算完成了。当然,不是说业务流程的实现不重要,更便捷的流程,能提高业务效率。但核心的部分,是先要把事情做正确。

2020-02-17 10:21:33 2281

原创 数据仓库实践杂谈(十三)——逻辑数据模型(数仓模型)

曾经有几年逻辑数据模型很火热,大家都研究这个。道理上来说,逻辑数据模型并不仅仅是用在数据仓库。在OLTP系统中建立良好的数据模型更加重要。但只不过这东西从实践上被推广开来,很大程度是原NCR/Teradata适用于金融行业的数据模型在某大型国有银行项目实施后传播开来。确实是好东西,感觉一下子给我打开了天眼,原来系统设计还能这样做。

2020-02-16 22:59:38 6260 1

原创 数据仓库实践杂谈(十二)——列式存储

每个数据库都有自己特有的文件存储方式。对于一般的关系数据库,从逻辑上按列(字段)定义表的结构,按行存储每一条数据。很多年前,大概2004年,Sybase IQ就提出了专用于联机分析(OLAP)的列式存储机制。这是我记得最早采用列式存储的数据库了。之后,各数据库厂商,以及后来的开源大数据平台,在针对关系模型存储,或者类似关系模型存储都采用了列式存储方案。

2020-02-02 18:19:21 1799

原创 数据仓库实践杂谈(十一)——分布式处理增量

面向大量数据的时候,想极大提高处理效率,最简单的办法就是增加处理的服务器。当然,从根本上来说,优化算法得到的提升可能是指数级的,通过横向扩展计算节点的提升只能是倍数级的,而且远达不到N个节点处理时间是1/N的效果。但目前的分布式计算框架都支持廉价的服务器和存储,因此很可以通过很低的成本获得极大的性能提升。

2020-01-26 18:11:07 1517

原创 数据仓库实践杂谈(十)——拉链处理

现代业务系统处理的数据越来越大,尤其大型金融机构、电商平台等,账户表,订单表都是庞大的。数据仓库要保留历史变更情况,需要每天加载当天的变更数据到仓库。相比整个全量数据来说,每天变化的数据还是属于少数的。比如千万账户级别的银行每天交易量一般也就是几十万条,也就意味着账户表中涉及变动的记录最多也就是几十万条。电商订单表可能数千万条,但每天新增以及之前订单变化的,可能不到一百万条。这种情况下,拉链方式做增量存储是最合适的方法。

2020-01-20 23:43:17 3980

原创 数据仓库实践杂谈(九)——增量/全量

数据仓库的两个重要的概念是:- 进入仓库的数据不可变;- 记录数据的变化历史。如何理解呢?不可变,意味着进到仓库的数据就类似归档了。原则上,不能对仓库里面的数据进行修改;如果随意的对仓库里面的数据进行修改,这个“仓库”就和交易系统没区别了,无法起到正确反映业务过程的作用。此外,适合于数据仓库的存储服务,如早年Oracle和DB2都有针对数据仓库的Data Warehouse产品,以及Hadoop体系的一系列组件,都是针对“批量插入,无更改或少量更改”而专门设计的,所以才能达到查询效率的最优化。也因此

2020-01-08 15:23:51 8415 3

原创 数据仓库实践杂谈(八)——去重

数据重复是一个比较麻烦的事情。从正常逻辑上来看,如果应用系统和数据卸出的程序没问题,不应该存在这个问题。但实际情况来看,确又时有发生。一旦确定数据源的数据会有重复的可能,就需要专门进行去重处理。

2019-12-24 14:52:21 2811

原创 数据仓库实践杂谈(七)——数据标准化

数据标准化是数据仓库建立过程中的另一个难点和重点。可以说如果企业没有建立自己的数据标准,基本上是无法建立统一的、整合的数据仓库模型的。数据标准有很多理论标准的,比如,国家标准有一个叫《数据元的规范与标准化》。这里叫数据元,不是我们前面讨论的元数据,虽然有点接近。简单的来说,这个标准就是描述了如何描述一个数据。比起对表和字段的描述更基础了一层。本人之前有一段时间专门为几个银行做了数据标准的事情。对此工作深有体会,发现这是一个非常繁琐的工作,而且业务不断发展,不断会有新的数据进入,标准交付物维护难度也非常高。

2019-12-19 16:43:40 5859 4

原创 Docker 安装使用实践

Docker 安装使用实践文章目录Docker 安装使用实践安装MAC OScentos设置加速源基本命令关于镜像容器数据卷检查对象信息几个常用镜像包的使用制作镜像文件导出镜像和容器docker 网络docker-compose安装MAC OS现在在Mac上安装Docker很简单,brew就可以。brew cask install docker貌似没有装cask的,会自动初始化,直接...

2019-12-16 09:36:12 499

原创 数据仓库实践杂谈(六)-数据校验

从数据源卸载出来的数据,进入仓库之前的第一个步骤就需要进行数据校验。数据校验的前提是在元数据中建立一套合适的数据标准。而其中,最重要的是确定每个字段的取值范围。基于这个数据标准,同步建立一套程序用于检查将要进入仓库的数据的有效性。

2019-12-12 16:32:06 6843 2

原创 数据仓库实践杂谈-(五)-ETL

ETL是建立数据仓库的核心,也是工作量最大的部分。所谓ETL,前面也提到过:Extract-Transform-Load的缩写。抽取-转换-加载。也就是从源系统抽取出来,经过一系列的加工(变形),最后加载到数据仓库中。只要做过数据加工的人都会知道,这个Transform(转换)过程实际上是由很多处理步骤有顺序、有条件的组成的。

2019-11-28 09:50:16 2996 3

原创 数据仓库实践杂谈-(四)-元数据

不管在数据仓库还是大数据领域中,元数据都是最重要的一个东西。元数据被定义为:描述数据的数据,对数据及信息资源的描述性信息。

2019-11-11 08:07:39 3292 2

原创 Mac安装以太坊、remix-ide和智能合约初步

Mac安装以太坊、remix-ide和智能合约初步前提条件安装好brewbrew类似apt-get一样,在mac方便的安装各种软件。安装golang我以前是下载代码编译的,一段时间没用,估计版本升级的比较厉害。不能用。直接从新用brew安装了golang。安装geth踩坑先开始按照网上提示,直接用brew安装以太坊环境。brew tap ethereum/ethereumbr...

2019-11-05 18:03:09 1958 1

原创 数据仓库实践杂谈-(三)-整体实现框架

从获取数据到最后呈现结果的整个过程,称为数据处理过程,一般简称ETL(Extract-Transform-Load,即提取、转换和加载)。但实际上,可能会转换很多次,也会加载很多次。下图是一个基于大数据的完整的数据处理架构与流程。很简单的图,能看出整体的架构和处理流程。先记住整个过程都应该在“元数据”的管理和控制之下进行。

2019-11-03 22:23:46 2797 1

原创 数据仓库实践杂谈-(二)-数据分层

数据仓库实践杂谈-(二)-整体数据分层对于数据仓库的整体框架,我们用一种称作“从端到端”的流程框架描述,即从数据源头到用户使用的全流程。上图是一种典型的基于数据整合、加工,并为客户提供数据服务的场景。简单来说,就是用户到平台来查询某些数据,而这些数据从多个源头聚集在一起,并且经过了整合加工。用户的查询一般来说有两种方式:查询明细。这种服务就是把来自数据源的数据直接提供给客户即可,基本不需...

2019-10-31 10:15:29 6296 2

原创 数据仓库实践杂谈-(一)-概述

数据仓库是一个老概念,但在大数据时代焕发出新的活力,以前各种很难做到的事情在大数据时代都能做了。但数据仓库究竟是什么,怎么做,怎么把大数据技术和数据仓库结合起来。在IT应用水平高的行业或企业中,交易系统和数据分析系统是两个重要的部分。比如在银行,交易系统是以核心业务系统(Core Banking System)为主加上各业务系统(信贷系统、中间业务系统、支付系统等)和渠道系统组成。而数据分析体系则是以数据仓库为核心众多分析、报表系统,如总账分析、客户风险、监管报送、管理会计等。

2019-10-30 10:18:43 5249 1

新巴塞尔协议-银监会公布

银监会公布的新巴塞尔协议文件。不错的东西。

2011-07-13

ISO+20022-1-2004.pdf

ISO20022的基本资料,英文的,有学习价值。

2009-12-01

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除