Business Intelligence and Data Warehouse-商务智能和数据仓库教学课件.docx

Business Intelligence and Data Warehouse1. 概述（Overview）而今置身于市场经济且面向全球性激烈竞争的环境下，任何商家的优势都不是单纯地取决于产品、服务和地区等方面的因素，而在于知识，在于创新。谁最先获得有用的知识并转化为行动，谁就可能成为赢家。随着企业信息化的普及，承载信息的数据随着时间的推移而不断积累并与日俱增，使得企业难以从大量数据中找到真正有用的决策信息。因此，企业迫切需要新的技术和方法从大量数据中提取有价值的信息和知识。信息技术在商业领域应用的卓越成效经过近20年的信息化建设已经初步显现。企业通过MIS（管理信息系统）快速收集和处理商业信息，通过ERP（企业资源计划系统）准确监控信息流，从而对企业经营的各个方面进行管理。这些系统除了本身的应用外，还积累了大量的数据，如来自业务系统的订单、库存、交易账目、客户和供应商资料，来自企业所处行业和竞争对手的数据，以及来自企业所处的其他外部环境中的各种数据，这是一笔宝贵的财富。信息系统应该具备把这些庞大的数据转化为知识，进而辅助企业经营决策，甚至自动生成商业决策的能力，这就是商业智能。信息系统正在经历着“MISERPBI”的演变过程。1.1. 面临的挑战（The Challenge）企业经营活动包括采购、生产、销售、商贸磋商、价格比较、经营决策、营销策略、推销促销、公关宣传、售前/售后服务、客户关系和咨询服务等。这些活动的背后实际上有3种“流”在支持着整个企业的运转：物流、资金流和信息流。“物流”是从原材料和零配件到成品整个物资流通的过程。它将运输、仓储、加工、整理和配送等整个物资流通过程通过信息有机结合，形成完整的供应和需求链。“资金流”是资金在企业内部和企业之间的流动过程。它包括融资、应收账款和应付账款的管理等，涉及财务的各个方面。“信息流”是企业管理的各个环节产生的信息的规律性流动。如业务运作过程产生的单据及其处理过程；经营管理过程中的成本、收入、利润报表及其相互关联；战略决策规划过程中的产品结构及市场定位信息；企业的经营目标和策略信息等。实际上，每个时期的企业经营活动过程都可以抽象出这“三流”。只不过传统企业管理由于企业规模和经营过程产生的信息量等还不是十分庞大，所以对这“三流”没有进行深入的研究和给予更多的重视。然而，信息时代的企业经营活动在以下2个方面却面临着两个很大的挑战：1.1.1. 商务工具的变迁技术总是不断地影响着商务模式。自从人类社会有商业活动以来，采用新进有效的商业工具往往能在竞争中先发制人。这里不讨论生产工具和交通工具，只着眼于和商业智能关联的信息工具来看现代企业在这方面面临的这一挑战。每一次科学技术的进步，总是会在很短的时间内在商业领域得到普遍的应用。图1-1的上面部分展示了从电报到互联网在不同阶段有代表性的商业工具，伴随着商业工具的变迁，人们处理信息的能力在工具的帮助下变得越来越强大，信息量的增长也越来越快。在此图的下半部分是与商业工具的发展相对应的信息量的增长。可以说，对商业活动影响最大的工具是计算机在商业领域的应用，它标志着商业活动真正进入信息化的时代，这时候的信息处理方式以数据库为主。现阶段企业的很多商业活动的信息化都还属于这个阶段。互联网在商业活动中的应用不仅从某种程度上改变了传统的商业模式，在信息增长和信息处理方式上也发生了前所未有的变化。在这个阶段，伴随着网络的使用，商业信息呈爆炸状增长，企业从以前使用的系统中继承了相当多的数据，如从ERP中继承的生产运作相关信息、从CRM中继承的客户信息和从HR系统中继承得到的员工信息等，这些信息只有共同作用才能发挥其效益，故信息处理方式以数据仓库和数据集市等为主。图1-1 商业工具的发展及其相对应的信息量正是由于信息工具的变化和信息量的不断增长，人们针对这些不同时期的不同信息类型一直在探索管理好它们的方法，也伴随着产生了一些工具。在使用电报、电话和传真等商业工具的阶段，信息量还不是很庞大，人们自身的能力还可以处理它们，这段时间出现的都是手工处理信息的方法，如文件的编目和文件系统的管理等。计算机的商业应用出现后，信息处理的方式发生了革命性的变化，先是商业单据的电子化，即EDI（电子数据交换），然后是MIS（管理信息系统）的广泛应用。随着信息的持续增长，一些新的商业信息处理方式被提了出来，如企业资源规划、供应链管理、客户关系管理和人力资源管理等，对应的商业信息处理工具分别有ERP、SCM、CRM和HR等。这一过程如图1-2所示。图1-2 信息管理工具的演变在这个变化的时代，能适应变化并趋利避害者才能在竞争中取得胜利。对于企业经营管理来说，这既是机遇又是威胁。新的商业工具在成本和效率等方面都有优势，如何使新的商业工具得到使用并使企业快速适应使用这种工具的环境，扬其长避其短，这是企业经营活动面临的一个重要挑战。1.1.2. 信息囚笼、信息孤岛和信息对抗企业里有大量的分布于各个计算机系统的数据，人们使用信息处理工具的目的就是希望把这些数据进行整理和分析，找到其中有价值的信息，为企业的经营决策提供依据。但是实际情况往往和这个愿望大相径庭，在现有的信息传统中，存在着信息化系统与传统业务系统脱节、信息化各子系统脱节、信息化整合传统资源脱节的“三脱节”现象，这直接导致了企业信息囚笼、信息孤岛和信息对抗的问题。在信息化过程中，企业积累了大量的数据，包括生产运作、客户、产品和销售等方面，但这些数据却被深埋在单独的计算机系统中未加以或难以运用，其潜力也不能发挥出来。而另一方面，企业在维护这些计算机设备和数据库系统上进行了可观的投资，很多管理者甚至不无感慨地说：“在信息系统上的投资就像一个黑洞，花了很多钱，却不见成效”。不仅丰富的数据被深埋着，企业自身好像也被这些系统套着，这就是信息的囚笼现象。系统间的相互交互、兼容和集成问题是另一个重要的问题。信息化有一个从初级阶段到中级阶段，再到高级阶段的发展过程。在计算机应用的初级阶段，人们容易从文字处理、报表打印开始使用计算机，进而围绕一项项业务工作，开发或引进一个个应用系统。这些分散开发或引进的应用系统，一般不会统一考虑数据标准或信息共享问题，如某企业财务管理用“管家婆”，生产运作用“用友”，销售管理用“金蝶”，客户关系管理和人力资源管理自己开发，这样，各个系统之间的数据很难进行交换。信息系统往往被其所属的部门隔绝，决策者很难得到一个基于对大量数据进行运算后得到的企业经营运作总体图景，这种现象就称为“信息孤岛”。企业中的信息流、资金流和物流应该能够相互验证，协调一致，但由于数据的分散和不兼容性，不同部门也有各自不同的体制，这样导致信息流所反映的资金流和物流的情况在很多时候还存在矛盾，这必然会导致信息之间的相互对抗。如何解决信息囚笼、信息孤岛和信息对抗的问题是现代企业经营管理中面临的又一个挑战。1.2. 需求（The Requirement）管理就是决策，决策需要信息。决策过程实际上就是一个信息输入、信息输出及信息反馈的循环过程。原来的决策支持系统，现在流行的商业智能，其目的都是为了辅助决策，让管理者从拍脑袋做决策到依据数据和事实做决策。这些依赖的数据和事实来源于两个方面，一是来源于竞争环境，这包括内部信息源（主要是存在于决策主体的经验信息）和外部信息源（主要是决策主体和咨询机构从社会中通过各种渠道获取的信息），另一方面来源于企业多年信息化建设中积累的数据库信息。对于第1个方面，信息的非结构化特征决定了其随意性和不确定性，这是决策理论中研究的问题，而对于第2个方面的信息，即使用存在于数据库中的信息来辅助决策的问题，就是可以通过商业智能从技术上来得到很大程度的解决。要基于计算机辅助决策的软件系统（商业智能系统就是其中最典型的代表）进行决策，需要经过5个步骤：1. 决策信息请求（商务查询需求）的发起。例如，现在某公司的决策层次年度在不同的地区投资的力度，需要知道本年度和前5年华中、华北、华东和华南等区域的销售量和销售额，并且要有很美观的界面和直观的图示来表达这些来源于数据库中的数据，这就为此决策发出了信息请求。2. 调用商业智能应用程序。决策者可以直接使用原来的系统，如ERP和CRM等来访问相关的销售数据，但是，这些数据往往分散在不同的数据库中，原来的系统也可能并没有提供十分富有个性化的查询需求。比如，在上述的决策中，原系统可能只提供了所有年度的销售数据，而不会具体到某一年甚至某一个月，那么这时候要满足决策信息需求就必须使用基于数据仓库技术的商业智能应用程序。3. 基于已发布的模型、规则或是策略确定适当的决策。这一步是用计算机辅助决策的重要步骤。也是智能化体现的地方。决策（特别是结构化决策）是有一定规律的，这些规律可以从以往的决策过程或者从以往的数据中抽象获得，把抽象得到的这些规律放在经过特别组织的库中，可以构成模型库、规则库和策略库，智能决策可以在这些库的基础上获得。4. 发布决策。决策最终是人的行为，计算机辅助了决策过程中信息的提取和规律性决策的结果，但最终的决策行为还是掌握在决策者自己的手中。5. 采取行动。这是检验决策正确性的唯一途径。图1-3是把以上决策过程中对信息的需求和计算机辅助决策的过程及其相互关系进行归纳所得。其中，图的左边部分是决策的信息源，右边部分借鉴了DSS（决策支持系统）的相关理论，表达了计算机辅助决策过程的全貌。图1-3 决策信息源及基于计算机系统的决策过程商业智能系统建设的目标就是要为企业提供一个统一的分析平台，充分利用原有系统中积累的宝贵数据，对其进行深层次的发掘，并从不同的角度分析企业的各种业务指标和构建业务知识模型，进而满足决策的信息需求和实现通过技术辅助决策的功能。1.3. 什么是商务智能商业智能的概念最早是Gartner Group于1996年提出来的。当时将商业智能定义为一类由数据仓库（或数据集市）、查询报表、联机分析、数据挖掘、数据备份和恢复等部分组成的，以帮助企业决策为目的的技术及其应用。而后随着商务环境的变迁和技术的进步，人们对于BI有了更多和更深的认识，下面将从两个方面探索商业智能的内涵：1.1.3. 不同视角的BIBI本身是一个复杂的体系，而且应用环境复杂，这就形成了从不同视角看BI的情况。Gartner Group将商务智能定义为一类由数据仓库（或数据集市）、查询报表、数据分析、数据挖掘、数据备份和恢复等部分组成的、以帮助企业决策为目的的技术及其应用。IDC将BI定义为：商业智能是终端用户查询和报告的工具、OLAP工具、数据挖掘软件、数据集市和数据仓库产品等软件工具的集合。IBM认为：商业智能是一系列由系统和技术支持的以简化信息收集和分析的策略集合，它应该包括企业需要收集什么信息、谁需要去访问这些数据、如何把原始数据转化为最终导致战略性决策的智能、客户服务和供应链管理。Microsoft认为：商业智能是任何尝试获取、分析企业数据以更清楚地了解市场和客户、改进企业流程和更有效地参与竞争的努力。SAP认为：商业智能是一大类收集、存储、分析和访问数据以帮助企业用户更好地进行决策的应用程序与技术。SAS认为：商业智能是关于在组织内部和组织周围正在发生的智能或知识。MSTR认为：商业智能是一系列能够使公司分析数据库中的数据并根据收集的信息获得的洞察力来作决策的软件系统。DWReview认为：从数据分析的观点，商业智能是收集与研究主题相关的、高质量的、有意义的信息、以帮助分析信息、得出结论或做出假设的过程。这些观点代表了最典型的BI视角，有一个名为BI观点的电子期刊也对此进行了研究，把这些对BI的认识由虚到实探索其本质，大致分成如下4类。1 是努力，MS主张的。2 是智能和知识，SAS倡导的。3 是过程，DMReview的定义。4 是工具和技术集合，Gartner、IDC、IBM、SAP和MSTR代表的。1.1.4. 商业智能定义为下列软件工具的集合l 终端用户查询和报告工具。专门用来支持初级用户的原始数据访问，不包括适应于专业人士的成品报告生成工具。l OLAP工具。提供多维数据管理环境，其典型的应用是对商业问题的建模与商业数据分析。OLAP也被称为多维分析。l 数据挖掘（Data Mining）软件。使用诸如神经网络、规则归纳等技术，用来发现数据之间的关系，做出基于数据的推断。l 数据仓库（Data Warehouse）和数据集市（Data Mart）产品。包括数据转换、管理和存取等方面的预配置软件，通常还包括一些业务模型，如财务分析模型。1.1.5. BI=工具+平台+模型2007年3月, Gartner商务智能峰会重新定义BI为分析应用（工具）、基础架构和平台以及良好的实践（模型）。商务智能的发展呈现出“从数据驱动转向业务驱动、从关注技术转向关注应用、从关注工具转向关注工具产生的绩效”的发展特点。商业智能是商业数据海洋中的指南针，它从历史数据中提取信息，搞清楚经营状况，通过信息的分析获取对经营决策有价值的知识，从而帮助用户对自身的业务经营做出正确而明智的决定。比如，通过商业智能可以解决客户在不同地域的分布情况，可以对客户进行各个角度的分类，还可以把客户和订单联系起来，找出其变化趋势。1.1.6. 商务智能应用的5个层次商务智能其实就是通过计算机技术，实现从数据到信息、从信息到知识、从知识到决策、由决策到财富的过程和结果。所谓的商务智能，从应用层次上分为如下五层：第一个层次是告诉企业发生了什么提供事先预制好的报告、企业平衡记分卡或综合管理“仪表盘”，利用集中管理的关键绩效指标(KPI)，解决企业运营绩效问题，监控企业的发展，实现复杂的报告用简单的方式表象出来。当利用“仪表盘”和记分卡时，用户可以扩充到很多的部门和客户，但是发生了什么是了解企业过去干了什么。第二个层次是让企业探索为何发生也叫例外分析，业务部门可以从固定的报表、报告和一些关键的KPI中，可以得到很多相关的信息，但是当他们发现问题时，需要了解为何发生了这些问题。这时，就需要即席查询和在线分析（OLAP）。业务分析员经常需要自己根据问题的需要完成自己的分析和报告。在很多情况下，业务分析员和决策制定者需要一套商务智能的工具，通过访问集成好的数据仓库，获得需要的信息。第三个层次是让用户实时看到现在发生了什么这个层次是实时的信息分析。企业决策层建立当前情况下的业务战略和决策。为了该层次的成功，几乎需要获得实时的数据，查询可以回答及时发生的问题。由此，运营模式和业务流程会发生较大的变化。例如：当客户因某种原因对服务不满时，需要退出服务或者产品时，相关客户服务人员发现这个客户是企业的大客户时，他应该迅速将情况发短信息给该客户的大客户经理，大客户经理很快查找到该客户的消费记录，马上和客户联系，争取挽留客户。而不是当客户流失后才着急和客户联系。第四个层次是帮企业预见即将发生什么客户发现仅仅了解现在还远远不够，将来会发生什么，风险的预测和评估是非常重要的。还需要统计分析的功能，来帮助分析客户的细分、预测客户的行为、预言客户业务的趋势、辨认欺诈行为等等。需要这种模型的客户群是非常大的，由于它需要复杂的算法、统计模型和大量的数据，所以需要支持大数据量的处理能力，像并行算法和网格计算是极其必要的。第五个层次是“我希望发生什么”决策是由系统提供的，系统的数据是由运营系统得到的。例如由Web页获得，或者由基于市场条件和用户需求进行的特价、促销活动得到。所以可以建立清楚的决策和业务政策，让事件沿着正确的轨迹、朝着预定的方向行进，达到预期的目标。1.1.7. BI中的统计、报表与分析、挖掘按照智能应用的范围，商业智能系统可以产生客户智能、营销智能、销售智能和财务智能。这些智能的产生包括3个部分的具体功能：信息处理、分析处理和知识发现。前2个部分是商业智能的前端展现对象，第3个部分则属于数据挖掘层次。信息处理包括查询和基本的统计分析，如使用交叉表、图表或者图进行报表的展示。分析处理是支持基本的OLAP操作，如上钻、下钻、旋转、切片和切块等，其表现形式也以报表为主。既然是“智能”的了，为什么还是报表的天下？实际上，统计和报表在很长一段时间内还是BI的重点，但这里的统计和报表与基于数据库的统计和报表有本质的区别，在BI系统中，报表的数据来源不是关系型数据库，而是从许多来自不同的企业运作系统的数据中提取出的有用数据，同时对这些数据进行清理以保证数据的正确性，然后经过抽取、转换和装载（即ETL过程），合并到一个企业级的数据仓库里，再经过联机分析处理（OLAP）而获得的企业数据的一个全局视图。都是报表，BI系统中的报表往往有很强的自定义功能（如可以针对某一个维度随意上钻和下钻）和很强的表现能力（如可以在不同的图形表现形式上随意切换）。交互性更强BI的应用必须基于数据仓库技术，因为数据仓库够大、够清楚、够全面，并且对统计分析需要的数据源支持得够好，这些优点是传统的数据库没有的。很多BI与DW的初学者对于商业智能和数据挖掘这两者的关系都存在着认识上的误区，他们要么把它们独立开来，要么把它们等同起来。而实际上，通常讲到BI，更多时候指的是前端应用部分，如现阶段声称是BI提供商的，大多数提供的是前端展现工具；而DW更多时候指的是后端部分，包括架构体系的设计和多维模型的建立等。还有一个问题就是数据挖掘（DM，Data Mining），说得学术化一点就是知识发现的问题，这是商业智能过程的第2个层次的应用，通过它可以找出隐藏的模式，进行分类和预测。1.4. 商务智能的架构（BI Architecture）统计报表、多维分析和数据挖掘是BI的3个层面。不管是用什么软件作为商业智能的平台，一个完整的BI应用都遵循统一的一个流程，这就是BI解决方案的体系结构，如下图所示：1.5. 商务智能的结构描述把商业智能系统工作的这一过程进行技术上的抽象，可以把商业智能的体系结构分为源数据层、数据转换层、数据仓库（数据集市）层、OLAP及数据挖掘层和用户展现层。这几层通过密切的协作完成商业智能的功能，它们的相互依赖关系如图1-8所示。在图1-8中可以看到，实现商业智能应用有4个十分关键的环节，包括数据源、ETL过程、数据仓库及其应用和BI前端展现。数据仓库系统的数据来源主要是外部的操作性应用系统，这些数据源包括数据的业务含义和业务规则，表达业务数据的表、字段、视图、列和索引等。图1-8 BI解决方案的体系结构ETL过程即抽取（Extraction）、转换（Transformation）和装载（Load）。ETL过程负责将业务系统中各种关系型数据、外部数据、遗留数据和其他相关数据经过清洗、转化和整理后放进中心数据仓库。数据仓库是商业智能系统的基础，是面向主题的、集成的、稳定的和随时间不断变化的数据集合。数据仓库的应用包括联机在线分析处理（OLAP）和数据挖掘（DM）。通过对数据仓库中多维数据的钻取、切片及旋转等分析动作，可以完成决策支持需要的查询及报表。通过数据挖掘，可以发现隐藏在数据中的潜在规则。前端展现可以提供各种能帮助人们快速理解数据内涵的可视化手段。它是数据仓库的门面，包括各种报表工具、查询工具和数据分析工具以表格或图形化的手段对数据的展现。这是一种具有层次关系的体系结构。实际上，这种结构是极为稳定的，这是自然界的普遍规律，如生态系统中有层次，食物链中有层次，良好的软件构架有层次（如MVC结构）。分层处理的同时也是解决复杂问题的一种基本思考方法，如管理中的层次。基于数据仓库的商业智能和数据挖掘应用采用这种结构已经通过实践证明是可行的。事实上，这一结构图是较为通用的，包括SQL Server 2005在内的很多数据挖掘和商业智能工具都是基于此图所描述的过程来实现其功能的。1.6. 数据挖掘和商业智能工具商业智能具有极为广阔的应用前景，吸引了相当多的软件产商为BI提供解决方案。其中包括软件巨人Microsoft、Oracle、IBM和Sybase等。所以，商业智能工具的选择余地还是很大的。根据BI解决方案的体系结构，一个完整的BI应用需要ETL工具、数据仓库管理工具、OLAP工具、数据挖掘工具和报表查询工具5种工具协同工作。如表1-1所示列出了其中一些软件厂商在这些工具方面的主要产品。表1-1 一些厂商提供的数据仓库工具公司名称ETL工具数据仓库管理工具OLAP工具数据挖掘工具报表工具IBMWarehouse ManagerVisual WarehouseOLAP ServerIntelligent MinerInsight & Qucik viewOracleOracle ETL ServerEnterprise ManagerExpress ServerDarwinExpress AnalyserSybaseReplication Server PowerStageWarehouse StudioWarehouse AnalyzerSASSPSSInfoMakerCAInfoPump PLATINUM ERWinPLATINUM InfoPumpDecisionBase InfoBeaconNeugentAionForest&TreesInfoReportsSAS第三方Warehouse AdministratorSAS MDDBEnterprise MinerEIS ERMicrosoftSSISSQL ServerSSASSSASSSRS目前BI在开放源码方面也有发展，最著名的是Pentaho开源BI系统，该系统的OLAP服务器采用Mondrian，OLAP展示使用JPivot，关系型数据库使用Firebird RDBMS，ETL工具使用Enhydra，服务器使用JBoss，数据挖掘使用Weka，集成管理和开发环境使用Eclipse。这些都是开源项目。1.1.8. 商业智能工具的选择通过上面的讨论，可以看出IBM、Oracle、NCR、CA、SAS和Sybase等著名数据仓库厂商在数据仓库管理、OLAP和报表、数据挖掘方面都提供了丰富的工具。各类产品各有其特点，并且有各自的适用环境，需要从商业需求和技术两个角度来选择。一般来说，产品选择需要进行如下4个方面的基本工作。1了解商业需求了解商业需求首先要了解应用的范围和级别。这需要确定建立企业级数据仓库、部门级数据仓库和个人级数据仓库中的哪一级数据仓库。还需要了解系统预期使用的用户群体是哪些、预期的用户数量是多少、用户在地理上的位置怎样、是集中在一起还是分散在网络的不同位置，然后需要了解建立数据仓库的用途和功能。了解用户想利用数据仓库进行哪些领域的工作，需要哪些功能，是简单的多维查询，还是需要进行多维分析，甚至是复杂的数据挖掘。了解现在进行数据分析的工作人员是如何进行工作的，他们的工作流程是怎样的，在他们的工作过程中遇到了哪些比较棘手的问题和困难。2了解信息系统需求在商业需求的基础上，需要进一步了解信息系统本身的需求。估算系统的数据量，了解数据的稳定性。这是首当其冲的工作。另外，元数据的维护要求也非常重要。如果元数据由专业的技术人员来维护，则可以注重工具的效率；如果元数据由非专业的用户群体来维护，则可以注重工具表达的直观性。还需要了解企业用户现有的技术情况，比如企业现在经常使用哪些工具进行数据处理。在选择工具时，需要考虑选择的工具是否能够同用户已经使用习惯了的工具互通。3工具功能评估在获取上述需求后，应当对各大数据仓库厂商的工具进行客观的功能评估。功能评估可能包括：系统结构（操作系统平台、系统的跨平台性、系统的可靠性、安全性和系统备份恢复的能力等）、数据抽取能力（定时调度的能力、数据抽取的速率和数据转化功能的强弱等）、数据存取呈现能力（支持多维查询的能力、是否具有OLAP分析的功能和是否有良好的客户界面等）、应用支持（是否有良好应用程序开发语言、数据库对存储过程的支持情况、系统提供的可重用软件成分的多少和软件的跨平台性等）、用户接口（用户界面的美观性和对Web平台的支持情况）和工具的互操作性（数据库、数据仓库、OLAP分析、数据挖掘和前端展现工具间的互通情况）。4工具组合和测试在对各种产品进行客观评价后，可以选择某个厂商的产品或者选择多个厂商产品的组合。在选定产品后还需要对产品进行现场测试，看产品是否能够满足实际需求。需要特别注意的是数据仓库将随着时间的推移不断增大。因此，我们在进行产品选择和测试时，必须对将来的情况进行预测。对于数据挖掘工具，第11章介绍的5A模型具有很好的指导意义。5A模型认为任何数据挖掘方法学都由5个基本元素组成，即Assess、Access、Analyze、Act和Automate。在选择数据挖掘软件产品时，要注意某些软件所采用的算法虽然名称可能完全一样，但它们的实现方法通常都不一样。这些算法的不同影响了软件对内存和硬盘的需求不同及性能上的差异。1.7. BI与DW、OLAP、DM商业智能的关键是从许多来自不同的企业运作系统的数据中提取出有用的数据并进行清理，以保证数据的正确性，然后经过抽取（Extraction）、转换（Transformation）和装载（Load），即ETL过程，合并到一个企业级的数据仓库里，从而得到企业数据的一个全局视图，在此基础上利用合适的查询和分析工具、数据挖掘工具、OLAP工具等对其进行分析和处理（这时信息变为辅助决策的知识），最后将知识呈现给管理者，为管理者的决策过程提供支持。数据仓库、数据挖掘及建立在它们基础之上的商业智能就是这种技术之一。数据仓库是一种针对大量数据集中进行数据组织与管理的技术，专门用于支持分析型的数据查询，而数据挖掘是从大量数据中寻找蕴涵在其中但尚未被发现的知识，而商业智能则是把这两者应用于商务领域，提高决策效率。商业智能（Business Intelligence）通常被理解为将企业中现有的数据（这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供应商等来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部环境中的各种数据）转化为知识，帮助企业做出明智的业务经营决策的工具。而商业智能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略层的决策。为了将数据转化为知识，需要利用数据仓库、联机分析处理（OLAP）工具和数据挖掘等技术。因此，从技术层面上讲，商业智能不是什么新技术，它只是数据仓库、OLAP和数据挖掘等技术的综合运用。用图解的方式可以理解为下图：这样不难看出，传统的交易系统完成的是Business到Data的过程，而BI要做的事情是在Data的基础上，让Data产生价值，这个产生价值的过程就是Business Intelligence Analysis的过程。2. 数据仓库（Data Warehouse）数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、稳定的（Non-Volatile）、随时间变化（Time Variant）的数据集合，用于支持管理决策。随着信息技术的不断推广和应用，许多企业都已经在使用管理信息系统处理管理事务和日常业务。这些管理信息系统为企业积累了大量的信息。企业管理者开始考虑如何利用这些信息海洋对企业的管理决策提供支持。因此，产生了与传统数据库有很大差异的数据环境要求和从这些海洋数据中获取特殊知识的工具需要。随着市场竞争的加剧，信息系统的用户已经不满足于仅仅用计算机去处理每天所发生的事务数据，而是需要信息能够支持决策的信息，去帮助管理决策。这就需要一种能够将日常业务处理中所收集到的各种数据转变为具有商业价值信息的技术，传统数据库系统无法承担这一责任。因为传统数据库的处理方式和决策分析中的数据需求不相称。这些不相称性主要表现在决策处理中的系统响应问题、决策数据需求的问题和决策数据操作的问题。数据库数据仓库数据内容当前值历史的、存档的、归纳的、计算的数据数据目标面向业务操作程序、重复处理面向主题域、管理决策分析应用数据特性动态变化、按字段更新静态、不能直接更新、只定时添加数据结构高度结构化、复杂、适合操作计算简单、适合分析使用频率高中到低数据访问量每个事务只访问少量记录有的事务可能要访问大量记录对响应时间的要求以秒为单位计量以秒、分钟、甚至小时为计量单位2.1. 为什么采用数据仓库为什么要在操作型数据库和 OLAP 之间加一层“数据仓库”呢？说一千道一万都计算机资源与效能惹的祸，操作型数据库以快速响应业务为主要目标，而OLAP的时候要占用大量的硬件资源，在OLAP的时候，业务操作很难快速响应，无法保证业务的顺利进行，从业务、数据、数据的价值的逻辑来看，没有业务就谈不上OLAP；零星分散的数据一般存在于多个应用，对应多个业务操作型数据库，访问效能极其低下。综合上述资源与效能的问题，最高效的方法就是将数据先整合到数据仓库中，而由OLAP应用统一从数据仓库里取数，以解决快速响应业务与OLAP的矛盾。但是，多了这么一层，不管ROLAP还是MOLAP都无法查看实时数据，这并不影响BI的应用，90%的BI应用都不要求实时性，允许数据有滞后，这是决策支持系统的应用特点，这个滞后区间就是数据抽取工具工作及OLAP的时间。2.2. 数据仓库有如下4个重要特性l 面向主题的（主题是针对一个决策问题而设置的分析对象，比如一个销售利润分析，如果你在SAP中写过类似报表，你可能需要使用客户，物料，销售订单和客户发票等表加一些数据冗余。不同类型的公司，其主题集合是不相同的）l 集成的（原有数据库系统记录的是每一项业务处理的流水帐，这些数据不适合于分析处理，在进入数据仓库之前必须经过综合、计算，抛弃分析处理不需要的数据项，增加一些可能涉及的外部数据。其二，数据仓库每一个主题所对应的源数据在原分散数据库中有许多重复或不一致的地方，必须将这些数据转换成全局统一的定义，消除不一致和错误的地方，以保证数据的质量。对源数据的集成是数据仓库建设中最关键，也是最复杂的一步。数据仓库的数据来源很广，数据仓库最重要的目的就是为了集成这些不同数据源的数据）l 稳定的（数据仓库的数据一般不可更新，最终用户只能通过分析工具进行查询、分析，一般不允许直接修改其中的数据。和数据库相比，数据仓库通常是以批量方式载入和访问。而且，对于数据仓库中的记录，并不进行一般意义上的数据更新，删除。所有的历史数据都会被保留，通常我们只是不停的批量导入新的数据）l 随时间变化的：操作型数据库系统出于性能上的考虑，并不保存系统投入运行后所产生的所有数据，一般只保留最新的6090 天内所产生的数据记录。而且，通常情况下，操作型数据库中一项业务活动只占用一条记录。当业务状况发生变化后，我们只需更新相应的记录。而为了按时间变化发掘业务活动的时序规律，数据仓库中，该业务活动可能同时存在多条记录，除了相应字段的内容不同外，其业务活动的时间记录也不相同。数据仓库中的数据是一系列在某时某刻生成的复杂的快照，由此可见，数据仓库的数据是高度冗余且必须的。2.3. 数据仓库的概念结构包括以下4种1. 单一数据仓库结构：将所有的主题都集中到一个大型数据库中的体系结构。数据源中数据被按照同一标准抽取到独立的数据仓库中，用户在使用时再根据主题将数据仓库中的数据发布到数据集市中。2. 分布式数据仓库结构：在企业各个分公司具有相当大的独立性时，企业总部设置一个全局数据仓库，各个分公司设置各自的局部数据仓库。局部数据仓库主要存储各自的未经转换的细节数据，全局数据仓库中主要存储经过转换的综合数据。3. 虚拟数据仓库结构：虚拟数据仓库利用描述了业务系统中数据位置和抽取数据算法的元数据直接从业务系统中抽取查询的数据进行概括、聚合操作后，将最终结果提供给用户。4. 数据集市结构：数据集市结构或称为主题结构的数据仓库是按照主题进行构思所形成的数据仓库，没有一个独立的数据仓库。系统的数据不存储在同一数据仓库中，每个主题有自己的物理存储区。2.4. 数据仓库架构而且，由于数据仓库的使用对象不尽相同，数据仓库的设计需要考虑其数据单元的细节程度，即粒度。细节程度越高，粒度级就越低，反之亦然。例如：一个简单的交易处于低粒度级，而每个月所有交易的汇总则处于一个高粒度级。通常，数据分析人员使用的数据粒度较低，而高层管理人员所使用的数据粒度较高。粒度同时决定了数据仓库所占用的物理空间的大小，尽管一条交易记录可能只占用200 个字节，但是一个月所累积的10 万条交易记录就占用了20M个字节。如果按月对每月的所有交易记录进行综合，所得到的记录可能只占用500 个字节。目前混合架构的标准大的结构层次分别有ODS-EDW-CDW-DM四大部分，其中ODS-EDW结构采用了Inmon派的策略，而CDW-DM采用了Kimball派的策略。EDW是近范式模型，CDW属于多维数据仓库，有统一维度建模策略。CDW相当于软件工程的中间件，是未来大型DW的趋势。2.4.1. R：!怎样的架构设计才是真正的数据仓库架构2.4.2. R：数据仓库的架构方式及其比较2.4.3. R：数据仓库架构提前解决未来问题2.4.4. R：几大数据仓库方案特性比较2.5. 清洗、转换、装载（ETL）Extraction：这里对原始表中需要导入到数据仓库的数据有很强的可定制性，对这些已经选择的表中的字段还可以进行筛选和改变，对不需要的字段进行去除操作，这就是所谓的数据清洗。Extraction，Transformation，LoadETL(Extract Transfer Load)提取转换加载，是任何人想做数据分析时必然要遇到的过程，因为数据都在业务系统中，而我又不想直接对业务系统的数据库进行操作，那么我就先把它们拿出来。例如，我把业务数据库备份下来，导到一个空数据库中，再用select语句把想要的内容查出，再在EXCEL表里美化一下。难道你说这不是一个ETL工作吗？并不只是自动生成规范的多维的星型表们，并生成一堆汇总表，才是ETL过程。当早期大型的在线事务处理系统(OLTP)问世后不久，就出现了一种用于“抽取”处理的简单程序，其作用是搜索整个文件和数据库，使用某些标准选择合乎要求的数据，将其复制拷贝出来，用于总体分析。因为这样做不会影响正在使用的在线事务处理系统，降低其性能，同时，用户可以自行控制抽取出来的数据。但是，现在情况发生了巨大的变化，企业同时采用了多个在线事务处理系统，而这些系统之间的数据定义格式不尽相同，即使采用同一软件厂商提供的不同软件产品，或者仅仅是产品版本不同，之间的数据定义格式也有少许差距。由此，我们必须先定义一个统一的数据格式，然后把各个来源的数据按新的统一的格式进行转换，然后集中装载入数据仓库中。其中，尤其要注意的一点时，并不是各个来源的不同格式的所有数据都能被新的统一格式包容，我们也不应强求非要把所有数据源的数据全部集中起来。Why?原因很多。有可能原来录入的数据中，少量的记录使用了错误的数据，这类数据如果无法校正，应该被舍去。某些数据记录是非结构化的，很难将其转化成新定义的统一格式，而且从中抽取信息必须读取整个文件，效率极低，如大容量的二进制数据文件，多媒体文件等，这类数据如果对企业决策不大，可以舍去。其实ETL过程就是数据流动的过程，从不同的数据源流向不同的目标数据。但在数据仓库中，ETL有几个特点，一是数据同步，它不是一次性倒完数据就拉到，它是经常性的活动，按照固定周期运行的，甚至现在还有人提出了实时ETL的概念。二是数据量，一般都是巨大的，值得你将数据流动的过程拆分成E、T和L。ETL的核心还是在于T这个过程，也就是转换，而抽取和装载一般可以作为转换的输入和输出，或者，它们作为一个单独的部件，其复杂度没有转换部件高。2.5.1. R：探索ETL本质？2.5.2. R：ETL 如何找增量数据 总结2.5.3. R：三大主流ETL工具选型2.6. 元数据（Metadata）什么是元数据，元数据就是描述数据的数据（data about data）。最明显的例子是XML Schema，xml schema就是描述xml的数据，所以它是元数据。另一个例子是数据库，比如我们可以查询数据库中有几个表，每个表都有什么字段，这些数据就是元数据。更准确一点说：元数据是描述流程、信息和对象的数据。这些描述涉及像技术属性（例如，结构和行为）这样的特征、业务定义（包括字典和分类法）以及操作特征（如活动指标和使用历史）。电信运营商各部门之间经常就每日用户数这类问题的指标数值不一致而吵得面红耳赤。其实，在其他行业中也都存在着类似问题。简单来讲，这些公司通过各个时期的IT建设，形成了很多个独立分开的系统。以电信运营商为例，就有计费系统、网络系统、OA系统、财会系统和客服系统等等。在这些系统中，存有不同的客户信息，具体体现就是不同格式的表。以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。按照元数据技术的术语来讲，就是在业务元数据上，大家对于业务的认识并不统一。比如：计费部门认为，一个用户当天曾拨打电话，就可以计入到当日用户数；而财务部门则认定，只有在发生费用之后才能计入；至于网络部，则认为当天开机的用户就可以算作当日用户。如此一来，各部门的当日用户数数值自然就不一样：计费中心的系统显示，当日用户数有6000；市场部的系统显示却只有4000；到了财务部门的系统中，显示仅有3000个。在这种情况下，担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字，导致大家对数据仓库系统本身的可信度也就打了折扣。事实上，类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是，原先未能统一的定义导致了某种指标的不一致，而要搞清楚为什么不一致，就得反查数据仓库中的这些表在一开始的时候是如何定义的，表与表之间的联络关系是怎样的。这种反查工作自然要求IT部门的人员就得详细查阅原先软件的设计。但问题是，现在的软件开发一般都是迭代式开发，每个阶段都有不同的人在做。回查一个表，很可能需要涉及到这个过程中的每一个开发人员。事实上，很少有人能做到这一点。即便费尽心机终于查到了，一个月的时间也过去了。元数据管理平台的建设就是为了避免继续出现类似问题。在元数据管理平台建成之后，其一，可以实现对技术元数据的抽取,把相关的字段放到平台上来。在这个平台上，就能清晰地看到这些表或字段之间的关联关系，有一个很清晰的视图。其二,还会把业务元数据抽取出来，确定要做哪些应用，就把相关的指标、流程在平台上建立起来。把这些元数据抽取出来后，用户可以通过平台很方便地修改数据仓库中的数据，调整业务中的统计指标等等。其三，就是要把技术元数据和业务元数据两种数据对应起来。比如对于当日用户数来讲,它在数据仓库中对应的都是哪些表，让技术元数据和业务元数据联系起来。这样，在把各种定义统一之后，元数据管理平台就可以给出一个更为详细的指标。比如在数值之后做出注解，注明具体开机的有多少，发生费用的又有多少。如此，老朱所在公司的争吵也就不复存在了。2.6.1. R：由两个实例看元数据管理2.6.2. R: 元数据管理技术及应用现状什么是元数据，元数据就是描述数据的数据（data about data）。最明显的例子是XML Schema，xml schema就是描述xml的数据，所以它是元数据。另一个例子是数据库，比如我们可以查询数据库中有几个表，每个表都有什么字段，这些数据就是元数据。更准确一点说：元数据是描述流程、信息和对象的数据。这些描述涉及像技术属性（例如，结构和行为）这样的特征、业务定义（包括字典和分类法）以及操作特征（如活动指标和使用历史）。在此前一年中，那家电信运营商各部门之间经常就每日用户数这类问题的指标数值不一致而吵得面红耳赤。其实，在其他电信公司或者其他行业中也都存在着类似问题。简单来讲，这些公司通过各个时期的IT建设，形成了很多个独立分开的系统。以电信运营商为例，就有计费系统、网络系统、OA系统、财会系统和客服系统等等。在这些系统中，存有不同的客户信息，具体体现就是不同格式的表。两年前，公司的数据仓库项目建设完成，本以为这会大步提升IT系统的“智能性”，没想到，基层的反映却是根本没法用。而其中的原因就在于，数据质量没法保证，也即：在业务逻辑上并不准确，各部门对于指标的定义不能统一。以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。按照元数据技术的术语来讲，就是在业务元数据上，大家对于业务的认识并不统一。比如：计费部门认为，一个用户当天曾拨打电话，就可以计入到当日用户数；而财务部门则认定，只有在发生费用之后才能计入；至于网络部，则认为当天开机的用户就可以算作当日用户。如此一来，各部门的当日用户数数值自然就不一样：计费中心的系统显示，当日用户数有6000；市场部的系统显示却只有4000；到了财务部门的系统中，显示仅有3000个。在这种情况下，担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字，导致大家对数据仓库系统本身的可信度也就打了折扣。事实上，类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是，原先未能统一的定义导致了某种指标的不一致，而要搞清楚为什么不一致，就得反查数据仓库中的这些表在一开始的时候是如何定义的，表与表之间的联络关系是怎样的。这种反查工作自然要求IT部门的人员就得详细查阅原先软件的设计。但问题是，现在的软件开发一般都是迭代式开发，每个阶段都有不同的人在做。回查一个表，很可能需要涉及到这个过程中的每一个开发人员。事实上，很少有人能做到这一点。即便费尽心机终于查到了，一个月的时间也过去了。元数据管理平台的建设就是为了避免继续出现类似问题。在元数据管理平台建成之后，其一，可以实现对技术元数据的抽取,把相关的字段放到平台上来。在这个平台上，就能清晰地看到这些表或字段之间的关联关系，有一个很清晰的视图。其二,还会把业务元数据抽取出来，确定要做哪些应用，就把相关的指标、流程在平台上建立起来。把这些元数据抽取出来后，用户可以通过平台很方便地修改数据仓库中的数据，调整业务中的统计指标等等。其三，就是要把技术元数据和业务元数据两种数据对应起来。比如对于当日用户数来讲,它在数据仓库中对应的都是哪些表，让技术元数据和业务元数据联系起来。这