基于数据仓库的商业智能——CRM的本质

第一篇：基于数据仓库的商业智能——CRM的本质

基于数据仓库的商业智能——CRM的本质

在当今竞争日益激烈、信息日益膨胀的市场经济环境中，大家都希望能够从浩如烟海的商务数据中发现带来利润的商机，商业智能已经成为公司使用电子商务投资创造更大利润的一个重要步骤，因此，越来越多的管理者开始借助商务智能技术来发现商务运营过程中存在的问题，找到有利的解决方案。与此同时，在信息技术领域，成功的数据仓库正在为许多企业提供实实在在的投资回报，并且使企业以一种崭新的更加细致的方式检查企业的运营状况。数据仓库所提供的洞察力不仅使企业更加高效，而且使企业能够对客户的需求做出更迅速准确的响应。商业智能与数据仓库技术的结合形成了增强企业竞争力的强大工具——客户关系管理CRM。

一、数据仓库与商业智能

数据仓库与传统的数据库系统相比有着本质的区别，数据库是一种通用平台，建立于严格的数学模型之上，用来管理企业数据，进行事务处理；而数据仓库没有严格的数据理论，更偏向于工程，是企业数据一个日积月累的建立过程，它的应用对象是不同层次的管理者，它的数据源可能是多种数据库，主要是进行大规模查询和分析，因此要求有大量的历史数据和汇总数据。数据仓库之父W.H.inmon这样定义：“数据仓库是支持管理决策过程的、面向主题的、集成的、随时间而变的、持久的数据集合。”

数据仓库的特点之一是能够整合来自于大量异构系统的数据，包括外部数据。通过整合来自多个接触渠道的客户数据，数据仓库向企业展示客户的属性、所有历史行为记录等信息。许多企业正在通过数据仓库在客户行为分析领域获得丰厚的利润，这个分析领域属于客户关系管理(CRM)的一部分。正因为客户关系分明一个企业成功的重要方面，因此本文对此进行讨论。

意识到CRM是当务之急的事，这就需要一个桥梁——商业智能工具，不仅联接分离的技术，而且通过进入商业的核心而使其与传统的以技术为中心的竞争对手区别开来。商业智能工具可以集合、分析、管理这些智能元素用以探索、展示与挖掘客户信息资产。企业以一个预先架设的桥梁开始，可以大大减少风险而且可以更快获得成功，换句话说，一个预先架设的桥梁不仅仅是一系列有数据导人与数据标准化功能的设计和维护工具，更重要的是一个已完成的包含了行业特定数据模型与资产报告，只需装入企业自己数据即可运行的分析型应用系统。

二、企业客户关系管理的发展

从中国目前的市场来看，数据仓库/商业智能已经浮出水面，从概念走到了实施的阶段。在过去的十年中，已建立的企业业务多数都集中提高他们核心业务流程的效率上，然而，ERP(Enterprise Resource Planning企业资源计划系统)主要关注的是企业业务流程或者供应链的效率，换言之，这种效率出自增加内部控制、削减成本以及使消耗更少产出更多，然而，电子商务的出现预示着企业进人了新一轮的更新，客户成为新的核心，企业关注的焦点跳出了企业自身的范围，更多地以客户为中心。

企业的CRM应该是个企业与客户关系的全面整合管理，通过CRM为维系并巩固既有客户，赢得并发展新客户，同时增进客户的忠诚度和利润贡献度。其核心内容是发现“金牌”客户、维系“利润”客户和分化、改造一般客户。它具体可以分为四个方面：

● 客户信息管理 ● 营销管理 ● 销售管理

● 服务管理与客户关怀

具体而言，CRM系统使得公司能够管理客户相关的信息和数据；全面自动管理横跨销售、营销与服务的前端办公业务流程；优化跨渠道的客户交易与互动;并理解和响应客户的行为模式。

三、有效的商业智能解决方案的要求

专家在分析我国软件市场发展趋势时认为，在中国应用软件市场上，管理软件的市场前景最为看好，其中，企业对CRM的潜在需求日益增加，并且企业对有效的商业智能解决方案的要求是：

(一)全面的解决方案

随着IT企业持续不断的并购行为的发生，反映信息系统中表现为对多种工具和技术平台的使用，所以一个全面渗透的开放文化是很重要的，尤其是在与软件工具的接口能力、技术平台、可以访问和支持的数据源。

(二)基本性能要求

为了与实际需要的解决方案保持一致，CRM必须基于特定行业的实践和知识。特别地，它必须综合：

● 能够快速实施的、无须大量重新配置即可扩展的解决方案和框架。

● 数据模型、预格式化的报表与流程，符合最佳实践行业准则，提供快速部署与加速投资回报的基础。

● 软件工具，允许业务人员根据需求进行分析的拓展商业智能，无须专门的专业IT人员进行干预。

(三)解决方案发布支持功能

正像一个预先设置的行业数据模型跨过了数据定义与收集阶段，一个详尽的实施框架可以节省出几周的时间来做支持计划，而经验是确保这个框架的完整性的最主要的成分。预定义的商业解决方案、发布计划共同为企业提供了一个加速应用发布的机会，从而加速了数据仓库投资的回报。

第二篇：智能商业读后感

智能商业读后感

当阅读完一本名著后，大家心中一定有不少感悟，让我们好好写份读后感，把你的收获和感想记录下来吧。那么你会写读后感吗？以下是小编为大家收集的智能商业读后感，欢迎大家借鉴与参考，希望对大家有所帮助。

曾鸣教授是我做战略的诸多老师之一，他关于战略的论述，一度是我反复揣摩学习的教材。

阿里巴巴是一家以战略见长的公司，能够在这样一家公司任参谋长，肯定得有几把刷子。

马云是个“大忽悠”,能让马云欣赏并邀请加入阿里，斯人功力可见一斑。

刚巧，我主要的工作，也是战略设计。于是乎，我就关注了“曾鸣书院”公众号，下载了“湖畔”APP,也收听了曾教授在得到的“智能商业二十讲”.自曾老师宣布要写这本书开始，我就一直关注着这本书的进程。先是得知这本书的英文版本已经出了，无奈我英语差，不能先睹为快。后又获悉这本书由中信出版集团出版，于是就在中信的购书小程序上预定了这本书。本以为这本书要等很久才能收到，没想到才过几天，就到手了。（截至目前，京东还没上架这本书的中文版。）

书是昨天下午到的，刚到手，就一口气看了一半。

这本书对我的帮助非常大。我就在做关于公司的战略计划，也在做公司的智能系统建设。这本书和我的很多想法不谋而合，让我引以为豪；另外，这本书还讲了很多我没注意到的问题，给了我不少启示。我是一边看，一边和公司的实践比较验证，偶有所感，就随笔记录。有些地方看得茅塞顿开，有些地方看得拍案叫绝，有些地方看得一阵后怕——怕什么？怕要是没看到这本书，自己岂不是犯了大错？

——真是开卷有益——尤其是开高人的卷！

《智能商业》这本书主要讲的就是智能商业。曾教授说，这是未来的商业范式。

智能商业的落脚点在“智能”二字。这两个字将智能商业与非智能商业区别开。意思是：符合智能商业逻辑的商业模式是智能商业，不符合这个逻辑的，是传统商业；智能商业代表了未来，如果你的商业模式与智能商业无关，那么很可能你就与未来无关。

这倒不是危言耸听。

那么，智能商业的智能主要体现在哪里呢？曾教授总结是：网络协同+数据智能。

什么是网络协同？我的理解是，你要用互联网技术构建一张网，将你的产品和服务搬到线上来（或者至少要有和线上交互的界面），然后把整个服务流程（产业链）的参与者也搬上来，让参与者们在线上自主办公、协同作业。当参与的角色足够多，每个角色的用户数足够大，在线协同作业的频率足够高，这个协同网络的包容性、自生性就足够强。

像蜘蛛一样先织一张网，然后把所有参与者一网打尽，这些参与者通过网络协同作业，会不断编织这张网，将网的深度和广度都极大地延展。这是一张可以自生长的网，有多少用户涌入，就有多少个节点，有多少个节点，这张网就有多大。这张网几乎可以无限延伸。它不是物理世界，它是互联网世界、信息化世界，是新的社群组织形态。

以上是我对协同网络的粗浅理解。那么，什么又是数据智能呢？

我理解的数据智能是供给链智能化。

怎么讲？

所有商业的原点，都是用户需求，不同的生产力阶段有不同的供给系统。这里面，用户的需求是相对恒定的，是所有商业行为的目标，但是供应能力不同，所能提供的解决方案就不同、方案的'成本不同、满足用户需求的程度也不同——很多需求不是说你有了解决方案用户才有，而是因为你没有解决方案所以这个问题一直得不到解决用户也就不奢望解决了——另外，很多需求不是原生性需求，而是基于解决方案衍生出来的需求——比如手机贴膜不是原生性需求，手机才是原生性需求；或者说手机不是原生性需求，准确讲，手机应该是一种解决手段，用户需要入网联系进行信息互通才是需求——我们经常犯的错，就是错把手段当需求，不能从原点出发去创新。

绕远了。扯回来。

工业时代生产力的特征是批量生产、标准化。这时候能供给的是大批量的标准化产品。满足的是用户对产品的普遍需求，不是个性需求——记住个性需求是一直存在的，只是当时的供给能力只能满足小部分人的个性定制需求。随着工业化的不断发展，标准产品进入了产能过剩的阶段，用户也进入了标准产品信息泛滥的时代，这时候的市场矛盾，变成了用户个性化需求的增长和市场个性化定制能力薄弱之间的矛盾。本质上讲，是机械化工业生产形式无法满足用户个性化的需求。

这个矛盾成了我们这个时代亟需解决的问题。

怎么办呢？答案就是数据智能。

数据智能是用互联网技术重构供给链系统，让高效的柔性生产成为可能，从而满足用户个性化的定制需要。

如何满足？

首先是万物互联，一切在线。也就是所谓的物联网（IoT）。物联网的意义在于所有产品都成了数据终端：既是数据输入终端也是数据输出终端，更是人机交互终端。在物联网的前期，你至少要开发出一个界面，让你的产品或服务能够与用户互动。这个环节，曾教授讲叫产品化。

有了交互终端，第二步是一切行为数据化。所有的动作，行为，都可以成为数据的字节，被储存下来。这个数据有类型的数据，更有个别的数据（数据库建模时建的表单不同，数据类型就不同）。这些数据你不用它，它就毫无价值。但你只要用它，它就变成了财富。最重要的是这个财富不是消耗品，可以无限复制，越用越有用。

将用户的一切行为数据化，这个在技术上并不难——只要联网在线，用户只要触网，就会形成数据。只是一般人没有注意到这个动作的意义，所以在系统开发的时候，没有开发并迭代优化这部分功能。

数据化以后，是建立算法。算法就是建立数据规则，程序指令。什么样的数据触发条件（输入加上数据分析）会形成怎样的输出，这是算法逻辑。数据量不大，分析维度不多，这个事情就简单。但当数据维度足够丰富，数据量足够大，算法足够多，运算量足够大，这时候，就不是人力能搞定的了，只能求助于机器运算。而且一般的机器作业还不行，得借助云计算的力量。

这样耗心费力的运算，目的何在？目的在于给协同网络的每个参与者更好的体验，满足其个性化需求，让其可以高效决策高效作业。

协同网络是一张横向铺开的网，网络里的每个参与者都是这张网的服务对象，没有数据智能的协作，这些参与者的作业是笨拙的，协同是低效的，有了数据智能，网络的参与者才能真正受益，体现出智能商业的用户价值

所以曾教授讲，协同网络和数据智能是构成智能商业DNA的双螺旋，缺一不可。有了这两个螺旋，你的商业模式就是智能商业，没有，就是传统商业。最后赢的，不是新的，是先进的。智能商业代表的是先进的理念和先进的生产力。革故鼎新，变革的阀门早已开启，唯有洞悉未来的发展趋势，才能提前布局，捕捉未来。

未来还没来，但是通往未来的因已经种下。我们有幸生在这个时代，可以参与或见证这个时代的变革。想想二十多年前中国的互联网什么样，再想想现在中国的互联网什么样，你还会觉得未来很遥远吗？

面向未来，掌握事物发展的原理，因缘聚合的原理，这样我们才有机会成为未来的开创者。

感谢曾教授！

第三篇：《智能商业》读后感

读《智能商业》有感

原创： 萧翔峰

一口气读完了《智能商业》，很多过往经历的事情与书中内容对照了起来，摘选其中部分与大家分享感悟。

网络协同效应

曾鸣用一句话讲明白了滴滴今天为什么会出现美团入场后促手不及的局面——没有网路协同效应，单靠规模经济无法形成垄断。

以前只知道打车是资本密集型行业，核心竞争力是资本；但是为什么是资本？并不明白。

原来是因为在线打车在需求端没有形成网络协同效应，即使供给端的规模效应强大，但司机和平台只是简单的分成关系，通过砸钱就可以让用户迁移了，也就不存在壁垒。所以美团打车的进攻策略还是通过城市逐步切入，给司机高于滴滴的补贴，粗暴有效。

回想当年在线音乐行业，网易云能崛起这么迅速，其实是个性化+歌单的模式，让产品具备了协同效应，用户越多，体验越好。而评论的互动又强化了协同，奠定了整个产品的独特调性。这与当时酷狗、QQ 音乐、百度音乐等产品的分类目录查找型体验，是质的差异。所以，网易云音乐的用户在早期版权不受限时能迅速滚起来。但其后正版化+腾讯大力投入垄断版权后，用户的基础需求（热门歌曲）无法满足，网易云音乐上涨的势头就被迅速压制了。

数据智能

大数据、人工智能，这是时下的行业流行词。过往也在想，在未来智能时代产品经理的价值是什么？这次在《智能商业》里看到了一个很系统的阐述，给了自己很大的启发。

产品是将“云上”的数据智能传递给用户、为用户带来价值的通道。数据闭环靠产品互动实现，而产品体验依赖于数据智能，数据和产品合二为一。一切的数据智能体系，都必须最终融合在功效直接、交互友好、价值明确的互联网产品上，其智能的价值才真正的体验出来。互联网产品是一种包含了“云”的智能和“端”的体验的完整互联网服务。

因此，互联网产品经理作为负责定义、优化互联网服务的角色，价值会更大。在智能时代里，一个优秀的互联网服务，离不开产品经理或实际的产品设计者，通过创造性的产品设计，既把数据智能的价值不折不扣地传递给用户，又使用户低成本、高频度地进行反馈，从而使数据智能持续提升。

这其中，产品经理的工作小到功能交互、大到定义产品场景，既包含前端（用户侧）的直接用户体验与交互，也包含后端（云）的数据智能引擎（例如推荐算法）的目标定义、指标优化。一个同时具备前端、后端工作能力的产品经理，是未来的标配。而纯 APP 功能产品经理的价值会继续的下降，因为行业的配套中台能力越来越成熟强大了。

未来的新产品，一定是针对某个用户问题/场景，定义了全新的用户体验方式，同时启动了数据智能的引擎，形成了数据、算法、产品的反馈闭环，进而持续提升用户体验。我们现在看到的字节跳动系产品，就是这一类产品的当下典型。

成为新智人

谈到这，我们自己其实也是一家企业，以经营自我、提升自我价值为商业目标的企业。但有多少人，在这个互联大时代里，还是一个单点？离线的工作、学习着？不能具备协同效应，没有给自己建立数据输入->输出的反馈闭环的人，无法放大自己的价值，也会在未来更快的面临职业上升天花板，这是未来协同的组织中对人的更高要求。

新的一年，把自己当做一个产品，找到自己的定位点，与所在的线去结网，建立所在面中的反馈闭环，在时代的大环境中继续向前。

第四篇：《智能商业》读后感

《智能商业》读后感

原创： 李日白

曾鸣教授是我做战略的诸多老师之一，他关于战略的论述，一度是我反复揣摩学习的教材。

阿里巴巴是一家以战略见长的公司，能够在这样一家公司任参谋长，肯定得有几把刷子。

马云是个“大忽悠”,能让马云欣赏并邀请加入阿里，斯人功力可见一斑。

刚巧，我主要的工作，也是战略设计。于是乎，我就关注了“曾鸣书院”公众号，下载了“湖畔”APP,也收听了曾教授在得到的“智能商业二十讲”.自曾老师宣布要写这本书开始，我就一直关注着这本书的进程。先是得知这本书的英文版本已经出了，无奈我英语差，不能先睹为快。后又获悉这本书由中信出版集团出版，于是就在中信的购书小程序上预定了这本书。本以为这本书要等很久才能收到，没想到才过几天，就到手了。（截至目前，京东还没上架这本书的中文版。）

书是昨天下午到的，刚到手，就一口气看了一半。

这本书对我的帮助非常大。我就在做关于公司的战略计划，也在做公司的智能系统建设。这本书和我的很多想法不谋而合，让我引以为豪；另外，这本书还讲了很多我没注意到的问题，给了我不少启示。我是一边看，一边和公司的实践比较验证，偶有所感，就随笔记录。有些地方看得茅塞顿开，有些地方看得拍案叫绝，有些地方看得一阵后怕——怕什么？怕要是没看到这本书，自己岂不是犯了大错？

——真是开卷有益——尤其是开高人的卷！

《智能商业》这本书主要讲的就是智能商业。曾教授说，这是未来的商业范式。

智能商业的落脚点在“智能”二字。这两个字将智能商业与非智能商业区别开。意思是：符合智能商业逻辑的商业模式是智能商业，不符合这个逻辑的，是传统商业；智能商业代表了未来，如果你的商业模式与智能商业无关，那么很可能你就与未来无关。

这倒不是危言耸听。

那么，智能商业的智能主要体现在哪里呢？曾教授总结是：网络协同+数据智能。

什么是网络协同？我的理解是，你要用互联网技术构建一张网，将你的产品和服务搬到线上来（或者至少要有和线上交互的界面），然后把整个服务流程（产业链）的参与者也搬上来，让参与者们在线上自主办公、协同作业。当参与的角色足够多，每个角色的用户数足够大，在线协同作业的频率足够高，这个协同网络的包容性、自生性就足够强。

像蜘蛛一样先织一张网，然后把所有参与者一网打尽，这些参与者通过网络协同作业，会不断编织这张网，将网的深度和广度都极大地延展。这是一张可以自生长的网，有多少用户涌入，就有多少个节点，有多少个节点，这张网就有多大。这张网几乎可以无限延伸。它不是物理世界，它是互联网世界、信息化世界，是新的社群组织形态。

以上是我对协同网络的粗浅理解。那么，什么又是数据智能呢？

我理解的数据智能是供给链智能化。

怎么讲？

所有商业的原点，都是用户需求，不同的生产力阶段有不同的供给系统。这里面，用户的需求是相对恒定的，是所有商业行为的目标，但是供应能力不同，所能提供的解决方案就不同、方案的成本不同、满足用户需求的程度也不同——很多需求不是说你有了解决方案用户才有，而是因为你没有解决方案所以这个问题一直得不到解决用户也就不奢望解决了——另外，很多需求不是原生性需求，而是基于解决方案衍生出来的需求——比如手机贴膜不是原生性需求，手机才是原生性需求；或者说手机不是原生性需求，准确讲，手机应该是一种解决手段，用户需要入网联系进行信息互通才是需求——我们经常犯的错，就是错把手段当需求，不能从原点出发去创新。

绕远了。扯回来。

工业时代生产力的特征是批量生产、标准化。这时候能供给的是大批量的标准化产品。满足的是用户对产品的普遍需求，不是个性需求——记住个性需求是一直存在的，只是当时的供给能力只能满足小部分人的个性定制需求。随着工业化的不断发展，标准产品进入了产能过剩的阶段，用户也进入了标准产品信息泛滥的时代，这时候的市场矛盾，变成了用户个性化需求的增长和市场个性化定制能力薄弱之间的矛盾。本质上讲，是机械化工业生产形式无法满足用户个性化的需求。

这个矛盾成了我们这个时代亟需解决的问题。

怎么办呢？答案就是数据智能。

数据智能是用互联网技术重构供给链系统，让高效的柔性生产成为可能，从而满足用户个性化的定制需要。

如何满足？

首先是万物互联，一切在线。也就是所谓的物联网（IoT）。物联网的意义在于所有产品都成了数据终端：既是数据输入终端也是数据输出终端，更是人机交互终端。在物联网的前期，你至少要开发出一个界面，让你的产品或服务能够与用户互动。这个环节，曾教授讲叫产品化。

有了交互终端，第二步是一切行为数据化。所有的动作，行为，都可以成为数据的字节，被储存下来。这个数据有类型的数据，更有个别的数据（数据库建模时建的表单不同，数据类型就不同）。这些数据你不用它，它就毫无价值。但你只要用它，它就变成了财富。最重要的是这个财富不是消耗品，可以无限复制，越用越有用。

将用户的一切行为数据化，这个在技术上并不难——只要联网在线，用户只要触网，就会形成数据。只是一般人没有注意到这个动作的意义，所以在系统开发的时候，没有开发并迭代优化这部分功能。

数据化以后，是建立算法。算法就是建立数据规则，程序指令。什么样的数据触发条件（输入加上数据分析）会形成怎样的输出，这是算法逻辑。数据量不大，分析维度不多，这个事情就简单。但当数据维度足够丰富，数据量足够大，算法足够多，运算量足够大，这时候，就不是人力能搞定的了，只能求助于机器运算。而且一般的机器作业还不行，得借助云计算的力量。

这样耗心费力的运算，目的何在？目的在于给协同网络的每个参与者更好的体验，满足其个性化需求，让其可以高效决策高效作业。

协同网络是一张横向铺开的网，网络里的每个参与者都是这张网的服务对象，没有数据智能的协作，这些参与者的作业是笨拙的，协同是低效的，有了数据智能，网络的参与者才能真正受益，体现出智能商业的用户价值

所以曾教授讲，协同网络和数据智能是构成智能商业DNA的双螺旋，缺一不可。有了这两个螺旋，你的商业模式就是智能商业，没有，就是传统商业。最后赢的，不是新的，是先进的。智能商业代表的是先进的理念和先进的生产力。革故鼎新，变革的阀门早已开启，唯有洞悉未来的发展趋势，才能提前布局，捕捉未来。

未来还没来，但是通往未来的因已经种下。我们有幸生在这个时代，可以参与或见证这个时代的变革。想想二十多年前中国的互联网什么样，再想想现在中国的互联网什么样，你还会觉得未来很遥远吗？

面向未来，掌握事物发展的原理，因缘聚合的原理，这样我们才有机会成为未来的开创者。

感谢曾教授！

第五篇：ETL学习心得：探求数据仓库关键环节ETL的本质

做数据仓库系统，ETL是关键的一环。说大了，ETL是数据整合解决方案，说小了，就是倒数据的工具。回忆一下工作这么些年来，处理数据迁移、转换的工作倒还真的不少。但是那些工作基本上是一次性工作或者很小数据量，使用access、DTS或是自己编个小程序搞定。可是在数据仓库系统中，ETL上升到了一定的理论高度，和原来小打小闹的工具使用不同了。究竟什么不同，从名字上就可以看到，人家已经将倒数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。

其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。

现在有很多成熟的工具提供ETL功能，例如datastage、powermart等，且不说他们的好坏。从应用角度来说，ETL的过程其实不是非常复杂，这些工具给数据仓库工程带来和很大的便利性，特别是开发的便利和维护的便利。但另一方面，开发人员容易迷失在这些工具中。举个例子，VB是一种非常简单的语言并且也是非常易用的编程工具，上手特别快，但是真正VB的高手有多少？微软设计的产品通常有个原则是“将使用者当作傻瓜”，在这个原则下，微软的东西确实非常好用，但是对于开发者，如果你自己也将自己当作傻瓜，那就真的傻了。ETL工具也是一样，这些工具为我们提供图形化界面，让我们将主要的精力放在规则上，以期提高开发效率。从使用效果来说，确实使用这些工具能够非常快速地构建一个job来处理某个数据，不过从整体来看，并不见得他的整体效率会高多少。问题主要不是出在工具上，而是在设计、开发人员上。他们迷失在工具中，没有去探求ETL的本质。

可以说这些工具应用了这么长时间，在这么多项目、环境中应用，它必然有它成功之处，它必定体现了ETL的本质。如果我们不透过表面这些工具的简单使用去看它背后蕴涵的思想，最终我们作出来的东西也就是一个个独立的job，将他们整合起来仍然有巨大的工作量。大家都知道“理论与实践相结合”，如果在一个领域有所超越，必须要在理论水平上达到一定的高度

探求ETL本质之一

ETL的过程就是数据流动的过程，从不同异构数据源流向统一的目标数据。其间，数据的抽取、清洗、转换和装载形成串行或并行的过程。ETL的核心还是在于T这个过程，也就是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件，其复杂度没有转换部件高。和OLTP系统中不同，那里充满这单条记录的insert、update和select等操作，ETL过程一般都是批量操作，例如它的装载多采用批量装载工具，一般都是DBMS系统自身附带的工具，例如Oracle SQLLoader和DB2的autoloader等。

ETL本身有一些特点，在一些工具中都有体现，下面以datastage和powermart举例来说。

1、静态的ETL单元和动态的ETL单元实例；一次转换指明了某种格式的数据如何格式化成另一种格式的数据，对于数据源的物理形式在设计时可以不用指定，它可以在运行时，当这个ETL单元创建一个实例时才指定。对于静态和动态的ETL单元，Datastage没有严格区分，它的一个Job就是实现这个功能，在早期版本，一个Job同时不能运行两次，所以一个Job相当于一个实例，在后期版本，它支持multiple instances，而且还不是默认选项。Powermart中将这两个概念加以区分，静态的叫做Mapping，动态运行时叫做Session。

2、ETL元数据；元数据是描述数据的数据，他的含义非常广泛，这里仅指ETL的元数据。主要包括每次转换前后的数据结构和转换的规则。ETL元数据还包括形式参数的管理，形式参数的ETL单元定义的参数，相对还有实参，它是运行时指定的参数，实参不在元数据管理范围之内。

3、数据流程的控制；要有可视化的流程编辑工具，提供流程定义和流程监控功能。流程调度的最小单位是ETL单元实例，ETL单元是不能在细分的ETL过程，当然这由开发者来控制，例如可以将抽取、转换放在一个ETL单元中，那样这个抽取和转换只能同时运行，而如果将他们分作两个单元，可以分别运行，这有利于错误恢复操作。当然，ETL单元究竟应该细分到什么程度应该依据具体应用来看，目前还没有找到很好的细分策略。比如，我们可以规定将装载一个表的功能作为一个ETL单元，但是不可否认，这样的ETL单元之间会有很多共同的操作，例如两个单元共用一个Hash表，要将这个Hash表装入内存两次。

4、转换规则的定义方法；提供函数集提供常用规则方法，提供规则定义语言描述规则。

5、对数据的快速索引；一般都是利用Hash技术，将参照关系表提前装入内存，在转换时查找这个hash表。Datastage中有Hash文件技术，Powermart也有类似的Lookup功能。

探求ETL本质之二（分类）

昨在IT-Director上阅读一篇报告，关于ETL产品分类的。一般来说，我们眼中的ETL工具都是价格昂贵，能够处理海量数据的家伙，但是这是其中的一种。它可以分成4种，针对不同的需求，主要是从转换规则的复杂度和数据量大小来看。它们包括

1、交互式运行环境，你可以指定数据源、目标数据，指定规则，立马ETL。这种交互式的操作无疑非常方便，但是只能适合小数据量和复杂度不高的ETL过程，因为一旦规则复杂了，可能需要语言级的描述，不能简简单单拖拖拽拽就可以的。还有数据量的问题，这种交互式必然建立在解释型语言基础上，另外他的灵活性必然要牺牲一定的性能为代价。所以如果要处理海量数据的话，每次读取一条记录，每次对规则进行解释执行，每次在写入一条记录，这对性能影响是非常大的。

2、专门编码型的，它提供了一个基于某种语言的程序框架，你可以不必将编程精力放在一些周边的功能上，例如读文件功能、写http://rad.17luntan.com/ClickPortal/W...&alliedsiteid=0“);” onmouseout=“isShowAds = false;isShowAds2 = false;”>数据库的功能，而将精力主要放在规则的实现上面。这种近似手工代码的性能肯定是没话说，除非你的编程技巧不过关（这也是不可忽视的因素之一）。对于处理大数据量，处理复杂转换逻辑，这种方式的ETL实现是非常直观的。

3、代码生成器型的，它就像是一个ETL代码生成器，提供简单的图形化界面操作，让你拖拖拽拽将转换规则都设定好，其实他的后台都是生成基于某种语言的程序，要运行这个ETL过程，必须要编译才行。Datastage就是类似这样的产品，设计好的job必须要编译，这避免了每次转换的解释执行，但是不知道它生成的中间语言是什么。以前我设计的ETL工具大挪移其实也是归属于这一类，它提供了界面让用户编写规则，最后生成C++语言，编译后即可运行。这类工具的特点就是要在界面上下狠功夫，必须让用户轻松定义一个ETL过程，提供丰富的插件来完成读、写和转换函数。大挪移在这方面就太弱了，规则必须手写，而且要写成标准c++语法，这未免还是有点难为最终用户了，还不如做成一个专业编码型的产品呢。另外一点，这类工具必须提供面向专家应用的功能，因为它不可能考虑到所有的转换规则和所有的读写，一方面提供插件接口来让第三方编写特定的插件，另一方面还有提供特定语言来实现高级功能。例如Datastage提供一种类Basic的语言，不过他的Job的脚本化实现好像就做的不太好，只能手工绘制job，而不能编程实现Job。

4、最后还有一种类型叫做数据集线器，顾名思义，他就是像Hub一样地工作。将这种类型分出来和上面几种分类在标准上有所差异，上面三种更多指ETL实现的方法，此类主要从数据处理角度。目前有一些产品属于EAI（Enterprise Application Integration），它的数据集成主要是一种准实时性。所以这类产品就像Hub一样，不断接收各种异构数据源来的数据，经过处理，在实施发送到不同的目标数据中去。

虽然，这些类看似各又千秋，特别在BI项目中，面对海量数据的ETL时，中间两种的选择就开始了，在选择过程中，必须要考虑到开发效率、维护方面、性能、学习曲线、人员技能等各方面因素，当然还有最重要也是最现实的因素就是客户的意象。

探求ETL本质之三（转换）

ETL探求之一中提到，ETL过程最复杂的部分就是T，这个转换过程，T过程究竟有哪些类型呢？

一、宏观输入输出

从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：

1、大小交，这种处理在数据清洗过程是常见了，例如从数据源到ODS阶段，如果数据仓库采用维度建模，而且维度基本采用代理键的话，必然存在代码到此键值的转换。如果用SQL实现，必然需要将一个大表和一堆小表都Join起来，当然如果使用ETL工具的话，一般都是先将小表读入内存中再处理。这种情况，输出数据的粒度和大表一样。

2、大大交，大表和大表之间关联也是一个重要的课题，当然其中要有一个主表，在逻辑上，应当是主表Left Join辅表。大表之间的关联存在最大的问题就是性能和稳定性，对于海量数据来说，必须有优化的方法来处理他们的关联，另外，对于大数据的处理无疑会占用太多的系统资源，出错的几率非常大，如何做到有效错误恢复也是个问题。对于这种情况，我们建议还是尽量将大表拆分成适度的稍小一点的表，形成大小交的类型。这类情况的输出数据粒度和主表一样。

3、站着进来，躺着出去。事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。大家对Decode肯定不陌生，这是进行宽表化常见的手段之一。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字段上。

4、聚集。数据仓库中重要的任务就是沉淀数据，聚集是必不可少的操作，它是粗化数据粒度的过程。聚集本身其实很简单，就是类似SQL中Group by的操作，选取特定字段（维度），对度量字段再使用某种聚集函数。但是对于大数据量情况下，聚集算法的优化仍是探究的一个课题。例如是直接使用SQL的Group by，还是先排序，在处理。

二、微观规则

从数据的转换的微观细节分，可以分成下面的几个基本类型，当然还有一些复杂的组合情况，例如先运算，在参照转换的规则，这种基于基本类型组合的情况就不在此列了。ETL的规则是依赖目标数据的，目标数据有多少字段，就有多少条规则。

1、直接映射，原来是什么就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算。

2、字段运算，数据源的一个或多个字段进行数学运算得到的目标字段，这种规则一般对数值型字段而言。

3、参照转换，在转换中通常要用数据源的一个或多个字段作为Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。这个关联数组使用Hash算法实现是比较合适也是最常见的，在整个ETL开始之前，它就装入内存，对性能提高的帮助非常大。

4、字符串处理，从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。而且，经常会有数值型值以字符串形式体现。对字符串的操作通常有类型转换、字符串截取等。但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。

5、空值判断，对于空值的处理是数据仓库中一个常见问题，是将它作为脏数据还是作为特定一种维成员？这恐怕还要看应用的情况，也是需要进一步探求的。但是无论怎样，对于可能有NULL值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，目前我们的建议是将它转换成特定的值。

6、日期转换，在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用8位整型20040801表示日期。而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为8位日期值、6位月份值等。

7、日期运算，基于日期，我们通常会计算日差、月差、时长等。一般数据库提供的日期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必须有一套自己的日期运算函数集。

8、聚集运算，对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为SQL标准中，包括sum,count,avg,min,max。

9、既定取值，这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值。

探求ETL本质之四（数据质量）

“不要绝对的数据准确，但要知道为什么不准确。”

这是我们在构建BI系统是对数据准确性的要求。确实，对绝对的数据准确谁也没有把握，不仅是系统集成商，包括客户也是无法确定。准确的东西需要一个标准，但首先要保证这个标准是准确的，至少现在还没有这样一个标准。客户会提出一个相对标准，例如将你的OLAP数据结果和报表结果对比。虽然这是一种不太公平的比较，你也只好认了吧。

首先在数据源那里，已经很难保证数据质量了，这一点也是事实。在这一层有哪些可能原因导致数据质量问题？可以分为下面几类：

1、数据格式错误，例如缺失数据、数据值超出范围或是数据格式非法等。要知道对于同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例如字段约束等。他们尽可能将数据检查在入库前保证，但是这一点是很难确保的。这类情况诸如身份证号码、手机号、非日期类型的日期字段等。

2、数据一致性，同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束，这通常会导致数据不一致。例如在帐务表中会出现一个用户表中没有的用户ID，在例如有些代码在代码表中找不到等。

3、业务逻辑的合理性，这一点很难说对与错。通常，数据源系统的设计并不是非常严谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在多个用户ID也是有可能发生的。对这种情况，有什么办法吗？

构建一个BI系统，要做到完全理解数据源系统根本就是不可能的。特别是数据源系统在交付后，有更多维护人员的即兴发挥，那更是要花大量的时间去寻找原因。以前曾经争辩过设计人员对规则描述的问题，有人提出要在ETL开始之前务必将所有的规则弄得一清二楚。我并不同意这样的意见，倒是认为在ETL过程要有处理这些质量有问题数据的保证。一定要正面这些脏数据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错误会逐渐放大，抛开数据源质量问题，我们再来看看ETL过程中哪些因素对数据准确性产生重大影响。

1、规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，在探求之三中，提到规则的分类。但是规则总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员能够使用某种规则语言来描述，那么我们的ETL单元就可以自动生成、同步，省去很多手工操作了。

2、ETL开发错误。即时规则很明确，ETL开发的过程中也会发生一些错误，例如逻辑错误、书写错误等。例如对于一个分段值，开区间闭区间是需要指定的，但是常常开发人员没注意，一个大于等于号写成大于号就导致数据错误。

3、人为处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的理解去运行，发生的错误可能是误删了数据、重复装载数据等。

探求ETL本质之五（质量保证）

上回提到ETL数据质量问题，这是无法根治的，只能采取特定的手段去尽量避免，而且必须要定义出度量方法来衡量数据的质量是好还是坏。对于数据源的质量，客户对此应该更加关心，如果在这个源头不能保证比较干净的数据，那么后面的分析功能的可信度也都成问题。数据源系统也在不断进化过程中，客户的操作也在逐渐规范中，BI系统也同样如此。本文探讨一下对数据源质量和ETL处理质量的应对方法。

如何应对数据源的质量问题？记得在onteldatastage列表中也讨论过一个话题－“-1的处理”，在数据仓库模型维表中，通常有一条-1记录，表示“未知”，这个未知含义可广了，任何可能出错的数据，NULL数据甚至是规则没有涵盖到的数据，都转成-1。这是一种处理脏数据的方法，但这也是一种掩盖事实的方法。就好像写一个函数FileOpen(filename)，返回一个错误码，当然，你可以只返回一种错误码，如-1，但这是一种不好的设计，对于调用者来说，他需要依据这个错误码进行某些判断，例如是文件不存在，还是读取权限不够，都有相应的处理逻辑。数据仓库中也是一样，所以，建议将不同的数据质量类型处理结果分别转换成不同的值，譬如，在转换后，-1表示参照不上，-2表示NULL数据等。不过这仅仅对付了上回提到的第一类错误，数据格式错误。对于数据一致性和业务逻辑合理性问题，这仍有待探求。但这里有一个原则就是“必须在数据仓库中反应数据源的质量”。

对于ETL过程中产生的质量问题，必须有保障手段。从以往的经验看，没有保障手段给实施人员带来麻烦重重。实施人员对于反复装载数据一定不会陌生，甚至是最后数据留到最后的Cube，才发现了第一步ETL其实已经错了。这个保障手段就是数据验证机制，当然，它的目的是能够在ETL过程中监控数据质量，产生报警。这个模块要将实施人员当作是最终用户，可以说他们是数据验证机制的直接收益者。

首先，必须有一个对质量的度量方法，什么是高质什么是低质，不能靠感官感觉，但这却是在没有度量方法条件下通常的做法。那经营分析系统来说，联通总部曾提出测试规范，这其实就是一种度量方法，例如指标的误差范围不能高于5%等，对系统本身来说其实必须要有这样的度量方法，先不要说这个度量方法是否科学。对于ETL数据处理质量，他的度量方法应该比联通总部测试规范定义的方法更要严格，因为他更多将BI系统看作一个黑盒子，从数据源到展现的数据误差允许一定的误差。而ETL数据处理质量度量是一种白盒的度量，要注重每一步过程。因此理论上，要求输入输出的指标应该完全一致。但是我们必须正面完全一致只是理想，对于有误差的数据，必须找到原因。

在质量度量方法的前提下，就可以建立一个数据验证框架。此框架依据总量、分量数据稽核方法，该方法在高的《数据仓库中的数据稽核技术》一文中已经指出。作为补充，下面提出几点功能上的建议：

1、提供前端。将开发实施人员当作用户，同样也要为之提供友好的用户界面。《稽核技术》一文中指出测试报告的形式，这种形式还是要依赖人为判断，在一堆数据中去找规律。到不如用OLAP的方式提供界面，不光是加上测试统计出来的指标结果，并且配合度量方法的计算。例如误差率，对于误差率为大于0的指标，就要好好查一下原因了。

2、提供框架。数据验证不是一次性工作，而是每次ETL过程中都必须做的。因此，必须有一个框架，自动化验证过程，并提供扩展手段，让实施人员能够增加验证范围。有了这样一个框架，其实它起到规范化操作的作用，开发实施人员可以将主要精力放在验证脚本的编写上，而不必过多关注验证如何融合到流程中，如何展现等工作。为此，要设计一套表，类似于DM表，每次验证结果数据都记录其中，并且自动触发多维分析的数据装载、发布等。这样，实施人员可以在每次装载，甚至在流程过程中就可以观察数据的误差率。特别是，如果数据仓库的模型能够统一起来，甚至数据验证脚本都可以确定下来，剩下的就是规范流程了。

3、规范流程。上回提到有一种ETL数据质量问题是由于人工处理导致的，其中最主要原因还是流程不规范。开发实施人员运行单独一个ETL单元是很方便的，虽然以前曾建议一个ETL单元必须是“可重入”的，这能够解决误删数据，重复装载数据问题。但要记住数据验证也是在流程当中，要让数据验证能够日常运作，就不要让实施者感觉到他的存在。总的来说，规范流程是提高实施效率的关键工作，这也是以后要继续探求的。

探求ETL本质之六（元数据漫谈）

对于元数据（Metadata）的定义到目前为止没有什么特别精彩的，这个概念非常广，一般都是这样定义，“元数据是描述数据的数据（Data about Data）”，这造成一种递归定义，就像问小强住在哪里，答，在旺财隔壁。按照这样的定义，元数据所描述的数据是什么呢？还是元数据。这样就可能有元元元...元数据。我还听说过一种对元数据，如果说数据是一抽屉档案，那么元数据就是分类标签。那它和索引有什么区别？

元数据体现是一种抽象，哲学家从古至今都在抽象这个世界，力图找到世界的本质。抽象不是一层关系，它是一种逐步由具体到一般的过程。例如我->男人->人->哺乳动物->生物这就是一个抽象过程，你要是在软件业混会发现这个例子很常见，面向对象方法就是这样一种抽象过程。它对世界中的事物、过程进行抽象，使用面向对象方法，构建一套对象模型。同样在面向对象方法中，类是对象的抽象，接口又是对类的抽象。因此，我认为可以将“元”和“抽象”换一下，叫抽象数据是不是好理解一些。常听到这样的话，“xx领导的讲话高屋建瓴，给我们后面的工作指引的清晰的方向”，这个成语“高屋建瓴”，站在10楼往下到水，居高临下，能砸死人，这是指站在一定的高度看待事物，这个一定的高度就是指他有够“元”。在设计模式中，强调要对接口编程，就是说你不要处理这类对象和那类对象的交互，而要处理这个接口和那个接口的交互，先别管他们内部是怎么干的。

元数据存在的意义也在于此，虽然上面说了一通都撤到哲学上去，但这个词必须还是要结合软件设计中看，我不知道在别的领域是不是存在Metadata这样的叫法，虽然我相信别的领域必然有类似的东东。元数据的存在就是要做到在更高抽象一层设计软件。这肯定有好处，什么灵活性啊，扩展性啊，可维护性啊，都能得到提高，而且架构清晰，只是弯弯太多，要是从下往上看，太复杂了。很早以前，我曾看过backorifice的代码，我靠，一个简单的功能，从这个类转到父类，又转到父类，很不理解，为什么一个简单的功能不在一个类的方法中实现就拉到了呢？现在想想，还真不能这样，这虽然使代码容易看懂了，但是结构确实混乱的，那他只能干现在的事，如果有什么功能扩展，这些代码就废了。

我从98年刚工作时就开始接触元数据的概念，当时叫做元数据驱动的系统架构，后来在QiDSS中也用到这个概念构建QiNavigator，但是现在觉得元数据也没啥，不就是建一堆表描述界面的元素，再利用这些数据自动生成界面吗。到了数据仓库系统中，这个概念更强了，是数据仓库中一个重要的部分。但是至今，我还是认为这个概念过于玄乎，看不到实际的东西，市面上有一些元数据管理的东西，但是从应用情况就得知，用的不多。之所以玄乎，就是因为抽象层次没有分清楚，关键就是对于元数据的分类（这种分类就是一种抽象过程）和元数据的使用。你可以将元数据抽象成0和1，但是那样对你的业务有用吗？必须还得抽象到适合的程度，最后问题还是“度”。

数据仓库系统的元数据作用如何？还不就是使系统自动运转，易于管理吗？要做到这一步，可没必要将系统抽象到太极、两仪、八卦之类的，业界也曾定义过一些元数据规范，向CWM、XMI等等，可以借鉴，不过俺对此也是不精通的说，以后再说