泰康人寿BI应用实例.docx
- 文档编号:29514942
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:20
- 大小:29.44KB
泰康人寿BI应用实例.docx
《泰康人寿BI应用实例.docx》由会员分享,可在线阅读,更多相关《泰康人寿BI应用实例.docx(20页珍藏版)》请在冰豆网上搜索。
泰康人寿BI应用实例
泰康人寿以BI实现战略转型
泰康人寿以BI实现战略转型
泰康人寿保险公司从建立之初,就意识到信息化建设对企业发展的重要性。
为促进业务的开展,泰康人寿已经建立有多个业务信息系统,主要包含:
财务系统、个险系统、团险和银行险系统,呼叫中心以及用于开展电子商务的泰康在线交易系统。
这些系统从企业不同需求层面很好的支持了泰康人寿的业务运营。
但由于各个系统都有自己的数据,如何将分散在不同系统的客户数据集中起来有效使用,为各部门提供数据分析能力,为决策提供依据,成为目前需要解决的问题。
为此,泰康人寿希望建立一套以CRM为核心的商务智能系统(BI),使公司管理人员能够对与客户(现有客户以及潜在客户)有关的各种要素(需要、方式、机遇、风险、代价等)和企业运营当中各项关键指标(KPI)做出分析与评估,以便于为本企业赢得最大的回报。
泰康人寿商务智能项目最终选择了Sybase寿险行业IWS解决方案,并以此为基础整合原有的五大业务系统,实施九项业务分析主题。
在实施方法上,泰康保险采用了增量式开发,也就是整体设计、分布实施的策略,这可以使泰康人寿能够边实施边见效,并且使用过程中的反馈信息将有助于下一步的开发工作,因此极大地提高了开发的效率。
BI项目分成两个主要阶段:
第一阶段,完成BI项目的一个或二个分析主题。
第二阶段,以第一阶段建立的分析环境为原型,进行更进一步的需求调研,完善和明确BI项目的业务需求,全面地进行IWS的客户化工作。
商务职能系统能够使泰康人寿在成本、收入和战略方面获益。
成本方面:
借助商务智能系统,泰康人寿可以得到完整的视图,来分析成本构成,改变成本管理现状,降低业务运作成本。
通过CRM系统提供的各项分析数据,泰康人寿能在商业活动中,以更低的风险,做出最明智的决策。
收入方面:
通过对营销员和营销机构产能的分析、利润的分析,可以大大改进泰康人寿在营销过程中的效率,加速产品上市时间,获得更精确更全面的市场和客户信息,实现与合作伙伴之间更好的合作,提高团队效率,保证将重要客户信息提供给需要方而提升交叉销售业绩。
战略方面:
借助商务智能平台,泰康能对不断变化的市场环境、客户需求做出更快的反应。
从历史数据中选择不同的角度考察消费行为,评估客户价值,细分客户群;针对不同的客户群发掘消费特点,建立数据模型,对不同的客户群做出预测;估计对收益或利润的影响,对市场活动的效果进行预测,通过设置商业规则,进行复杂的市场划分;最终帮助泰康实现从以产品为中心的战略,转换到以客户为中心的战略。
Session1:
医院智能分析业务与需求
Session2:
解决方案技术框架与Demo效果;
Session3:
关键技术和实现;
商业智能系统应具有的主要功能:
读取数据——可读取多种格式(如Excel、Access、以Tab分割的txt和固定长的txt等)的文件,同时可读取关系型数据库(对应ODBC)中的数据。
分析功能——关联/限定关联分析主要用于发现不同事件之间的关联性,即一个事件发生的同时,另一个事件也经常发生。
关联分析的重点在于快速发现那些有实用价值的关联发生的事件。
数据输出功能——打印统计列表和图表画面等,可将统计分析好的数据输出给其他的应用程序使用,或者以HTML格式保存。
定型处理——所需要的输出被显示出来时,进行定型登录,可以自动生成定型处理按钮。
以后,只需按此按钮,即使很复杂的操作,也都可以将所要的列表、视图和图表显示出来。
以国外的一个BI系统为例,我们来介绍一个BI系统的主要功能,这个系统主要包含数据仓库管理器(WarehouseManager)、数据复制(DataPropagator)、多维数据库(OLAPServer)、前台分析工具(WiredforOLAP)以及数据挖掘(IntelligentMiner)、OnDemand。
数据仓库管理器(WarehouseManager)
它主要由以下几部分功能组成:
数据访问,数据转换,数据分布,数据存储,靠描述性数据查找和理解数据,显示、分析和发掘数据,数据转换过程的自动化及其管理。
它缩短了复杂的海量数据与有洞察力的商务决策之间的差距,有助于公司更进一步了解其业务、市场、竞争对手和客户。
数据复制(DataPropagator)
DataPropagator提供的复制功能允许从一个数据源读取数据并把它送到另外一个地方,而且可以是双向的。
当发生冲突时,可自动检测出来并进行补偿。
此外,它还有以下特色:
1)PullArchitectureThroughStagingTables(分级表牵引式体系结构):
二个组成部分---- Capture和Apply。
Capture部分在源数据库服务器上运行,它捕获要被复制的数据,并把数据放入服务器分级表中;Apply部分在目标机上运行。
在用户定义的时间间隔里或某个事件发生后,它连到源数据库中,并从分级表中抽取所需的数据。
这种被动的“牵引式”体系结构减少了数据源的额外开销,能够支持数据源及目标机的独立运作性以及新一代流动计算机作为目标机的数据复制。
这种体系结构还支持中介分级表,其中最初的源可以复制到区域目标中,然后再复制到各区域内的目标机上。
(2)支持更新和修正:
既支持更新也支持修正复制。
Apply可以完全替换目标数据或者仅仅修正上次复制以来所发生的改变。
(3)改变事务运行记录的Capture:
捕获数据修改。
它从数据库运行日志(LOG)中读出修改,从而抓取用于复制的数据修改,进而安排好这些数据。
这就减少了对源的额外开销,不需要另外处理如触发器。
甚至可以直接从内存中读运行记录,以减少I/O。
(4)加工数据:
数据首先要从运行记录移到分级表,所以能在复制之前加工或处理它;由于分级表是数据库表,使用标准SQL就能定义加工处理功能。
除了通过SQL来构造子集,汇总并连结表以外,分级表还能提供基于时间分析源数据改变的方法。
这要考虑到整个新一类的应用包括检查跟踪,历史分析,"asof"查询等等。
( 5)GUI管理机构:
通过图形用户界面可以定义和管理数据拷贝,定义代码和触发器没有专门语言。
这样最终用户就有权定义和管理,而不仅仅是DBA和程序员的范围。
多维数据库服务器(OLAPServer)
该工具在商务智能中扮演着重要角色,可以深入最终用户的业务,对桌面上的数据进行实时操作,能够快速地分布传统监视和报告范围之外的应用程序数据。
数据挖掘工具(IntelligentMiner)
当用户的数据积累到一定数量时,这些数据的某些潜在联系、分类、推导结果和待发现价值隐藏在其中,该工具帮助客户发现这些有价值的数据。
WiredforOLAP
使用该功能可以提高信息技术组织的效率。
信息技术人员可以让用户利用分析和报表的功能获得他们所需的信息,而不会失去对信息、数据完整性、系统性能和系统安全的控制。
(1)强大功能的报表
繁忙的信息技术部门可以在几分钟内创建用于在企业中分发的完善的报表。
,决策人员可以从该Web页面上找到可用的一系列报表。
(2)图形化分析
远远超出对数据的静态图形化视图,提供强壮的图形化OLAP分析。
决策人员可以根据需要排序、分组数据并改变“图表”(Chart)的类型(直方图、饼形图、线图、堆积图)。
图表中的元素可以被“钻取”到其他的细节层次,并可以返回来恢复一个概要性的视图。
(3)多种图表视图:
直方图、线图、组合图、饼形图、堆积图和离散点图
(4)可在任何地方“钻取”没有路径的预先定义
(5)完善的报表:
复合报表通过用各种不同的形式(交叉表、图表、表格或以上几种形式的组合)来表现分析结果,对工作进行概括;优美格式的商用报表。
(6)交互式的、立即的“所见即所得”(WYSIWYG)显示
OnDemand
该工具提供给客户一套高性能的解决方案来进行在线捕获、存储和重取计算机输出的文档。
它使得落后的纸张文件搜索和使用缩微胶片阅读器搜索称为历史。
有了OnDemand,客户可以立刻发现特定的信息并且很容易地浏览它,而不用在庞大的数据和纸张中苦苦寻找;存储、重取和分发企业产生的信息比以前更加方便和易于接受。
ETL-数据探索阶段的主要目的
Whataretheprimarygoalsofthedatadiscoveryphaseofthedatawarehouseproject?
在数据仓库项目中,数据探索阶段的主要目的是什么?
答:
在逻辑数据映射进行之前,需要首先对所有的源系统进行分析。
对源系统的分析通常包括两个阶段,一个是数据探索阶段(DataDiscoveryPhase),另一个是异常数据检测阶段。
数据探索阶段包括以下内容:
1.收集所有的源系统的文档、数据字典等内容。
2.收集源系统的使用情况,如谁在用、每天多少人用、占多少存储空间等内容。
3.判断出数据的起始来源(System-of-Record)。
4.通过数据概况(DataProfiling)来对源系统的数据关系进行分析。
数据探索阶段的主要目的是理解源系统的情况,为后续的数据建模和逻辑数据映射打下坚实的基础。
ETL-如何确定起始来源数据
Howisthesystem-of-recorddetermined?
如何确定起始来源数据?
答:
这个问题的关键是理解什么是System-of-Record。
System-of-Record和数据仓库领域内的其他很多概念一样,不同的人对它有不同的定义。
在Kimball的体系中,System-of-Record是指最初产生数据的地方,即数据的起始来源。
在较大的企业内,数据会被冗余的保存在不同的地方,在数据的迁移过程中,会出现修改、清洗等操作,导致与数据的起始来源产生不同。
起始来源数据对数据仓库的建立有着非常重要的作用,尤其是对产生一致性维度来说。
我们从起始来源数据的越下游开始建立数据仓库,我们遇到垃圾数据的风险就会越大。
ETL-逻辑数据映射
WhatisalogicaldatamappingandwhatdoesitmeantotheETLteam?
什么是逻辑数据映射?
它对ETL项目组的作用是什么?
答:
转换方法:
需要对源数据做的操作,如Sum(amount)等。
逻辑数据映射应该贯穿数据迁移项目的始终,在其中说明了数据迁移中的ETL策略。
在进行物理数据映射前进行逻辑数据映射对ETL项目组是重要的,它起着元数据的作用。
项目中最好选择能生成逻辑数据映射的数据迁移工具。
逻辑数据映射(LogicalDataMap)用来描述源系统的数据定义、目标数据仓库的模型以及将源系统的数据转换到数据仓库中需要做操作和处理方式的说明文档,通常以表格或Excel的格式保存如下的信息:
目标表名:
目标列名:
目标表类型:
注明是事实表、维度表或支架维度表。
SCD类型:
对于维度表而言。
源数据库名:
源数据库的实例名,或者连接字符串。
源表名:
源列名:
-----------------------------补充:
逻辑数据映射分为两种:
1:
属性映射
一对一:
源实体的一个数据属性列只对应目标实体的一个数据属性列。
如果源类型与目标类型一致,则直接映射。
如果两者间类型不一样,则必须经过转换映射。
一对多:
源实体的一个数据属性列只对应目标实体的多个数据属性列。
在同一个实体中,常常出现会一个源属性列拆分为目标的多个属性列情况。
在不同实体中,结果会对应到不同的实体的属列。
一对零:
一个源实体的数据属性列没有与目标实体的数据属性列有对应,它不在我们处理的计划范围之内。
零对一:
一个目标实体的数据属性列没有与任何一个源数据属性列对应起来。
例如只是根据设计考虑,维表和事实表中的时间戳属性,代理健等。
多对一:
源实体的多个数据属性列只对应目标实体的一个数据属性列。
多对多:
源实体的多个数据属性列对应目标实体的多个数据属性列。
2:
模型映射:
从源模型到DW目标模型之间的映射类型有:
一对一:
一个源模型的数据实体只对应一个目标模型的数据实体。
如果源类型与目标类型一致,则直接映射。
如果两者间类型不一样,则必须经过转换映射。
一对多:
一个源模型的数据实体只对应多个目标模型的数据实体。
在同一个数据存储空间,常常出现会一个源实体拆分为多个目标实体的情况下。
在不同的存储空间中,结果会对应到不同的存储空间的实体。
一对零:
一个源模型的数据实体没有与目标模型的数据实体有对应,它不在我们处理的计划范围之内。
零对一:
一个目标模型的数据实体没有与任何一个源数据实体对应起来。
例如只是根据设计考虑,时间维表等。
多对一:
多个源模型的数据实体只对应一个目标模型的数据实体。
多对多:
多个源模型的数据实体对应多个目标模型的数据实体。
作用:
1为开发者传送更为清晰的数据流信息。
映射关系包括有关数据在存储到DW前所经历的各种变化的信息,对于开发过程中数据的追踪审查过程非常重要。
2把ETL过程的信息归纳为元数据,将数据源结构,目标结构,数据转换规则,映射关系,数据的上下文等元数据保存在存储知识库中,为元数据消费者提供很好的参考信息,追踪数据来源与转换信息,有助于设计人员理解系统环境变化所造成的影响;
开发设计者可以轻松的回答以下的问题:
1、这些数据从那里来?
2、这样的结果通过什么样的计算和转化得来?
3、这些数据是如何组织的?
4、数据项之间有什么联系?
5、如果源发生变化,有那几个系统,目标受影响?
ETL方案的选择应考虑以下方面:
●数据操作效率;
●数据操作时间周期;
●定制的灵活性。
对ETL来说,数据操作的效率是最重要的考虑因素。
对效率的考察,应包括以下几点:
1.是否支持复杂的数据操作;
2.是否支持多任务并行操作;
3.是否符合系统对数据处理时间窗口的要求。
数据操作时间周期的支持包括:
1.是否支持各种数据处理时间周期的混合操作;
2.是否支持数据的小批量持续加载;
3.是否支持数据的大批量定时加载。
定制灵活性包括:
1.是否支持数据依赖的建立;
2.是否支持数据流的建立;
3.是否支持操作定时启动;
4.是否可扩展;
5.开发环境是什么,开发是否简单、灵活。
对于ETL流程的建立,通常有以下两种方式:
●利用数据库系统、业务子系统工具自行开发
●购买现成的ETL工具
通常情况下,ETL方案中,以上两种方式是同时存在的。
一般情况下,利用各个子系统提供的工具进行自行开发,可充分利用子系统的优化操作,提高数据处理效率,但其灵活性和可扩展性欠佳;购买现成的ETL工具(如EAI、Informatic等厂商的ETL工具),可灵活定制数据处理流程,简化数据开发,缩短ETL方案实施周期,但其处理效率较低。
因此,建议读者应结合以上的ETL建立方式,在保证ETL性能的前提下,购买合适的ETL工具。
利用UDF来调用操作系统命令和DB2的常用命令
由于DB2是不支持复合SQL语句内不支持调用操作系统命令,所以一些对应我们常用的一些语句如数据导入,导出是命令行而不是SQL语句,都不能在存储过程中调用,必须写一些SHELL或者BAT文件,进行脚本编制来进行。
但是在我们的这种BI应用中,ETL过程中的E过程,数据的导入是一件必不可少的过程,通过脚本的控制,比较麻烦和整个过程有点不是很完整。
找寻是否有其他的解决方案。
不过据说在新版本的DB2上是可以支持的。
但是我们都是用V8.1
之前看了IBM网站的一篇文章,提到可以利用UDF来执行纯SQL中不可用的操作。
因为UDF可以用外部语言(即,SQL以外的其它语言,如JAVA,C)编写,并可以通过使用CREATE语句向数据库注册,这样我们就可以编写一个JAVA应用程序来调用操作系统命令和DB2的常用命令。
当这个外部函数注册后,
我们就可以在存储过程中可以使用该函数,进行数据的导入,导出。
参见资料“另一篇有关高级脚本编制的文章”和“如何注册JavaUDF”
步骤:
1、编写一个JAVA程序(os_cmdUDF.java)
importjava.io.*;
importCOM.ibm.db2.app.UDF;
publicclassos_cmdUDFextendsUDF{
publicstaticintos_cmd(Stringcmd){
Runtimert=Runtime.getRuntime();
Processp=null;
intsuccess=0;
try{
p=rt.exec(cmd);
}
catch(IOExceptione){
success=-1;
}
return(success);
}
}
2、运行javacUDFLogs.java编译
javacos_cmdUDF.java
产生的结果是一个称为os_cmdUDF.class的文件,
随后需要将该.class文件复制到sqllib\目录
3、运行jar打包UDFLogs.class为os_cmdUDF.jar
jarcfos_cmdUDF.jaros_cmdUDF.class
4、连上数据库,运行安装.jar文件到数据库
db2connecttotestsuuserdb2admin
db2"CALLsqlj.install_jar('D:
\IBM\SQLLIB\java\jdk\bin\os_cmdUDF.jar','os_cmdUDF')"
之后os_cmdUDF.jar安装到D:
\IBM\SQLLIB\\jar\DB2ADMIN\的路径下。
5、运行create建立函数
DROPos_cmd;
CREATEos_cmd(INVARCHAR(1000))
RETURNSINTEGER
EXTERNALNAME'os_cmdUDF:
os_cmdUDF!
os_cmd'
LANGUAGEJAVA
PARAMETERSTYLEJAVA
NOTDETERMINISTIC
NOSQL
EXTERNALACTION
;
6、测试os_cmd函数是否可用
db2"valuesos_cmdUDF('db2cmd.exe')"
返回结果,
1
-----------
0
1条记录已选择。
函数可以用。
7、建立调用os_cmd函数的存储过程。
CREATEPROCEDUREDB2ADMIN.sp_exec(
--输入参数
INloadstrvarchar(1024),
--输出参数
OUTo_err_msgvarchar(1024)
)
--支持语言
LANGUAGESQL
P1:
BEGIN
--临时变量,出错变量
declareSQLCODEintegerdefault0;
declarestmtvarchar(1024);
declarestatevarchar(1024)default'AAA';--记录程序当前所作工作
DECLAREstatusINTDEFAULT0;
--声明出错处理
DECLAREEXITHANDLERFORSQLEXCEPTION
begin
seto_err_msg='处理'||state||'出错'||'错误代码SQLCODE:
'||CHAR(SQLCODE);
end;
--程序开始
SETstatus=os_cmd(loadstr);
if(status<>0)then
seto_err_msg=stmt;
endif;
ENDP1
8、调用存储过程
callsp_exec('db2cmd.exeE:
\work_file\济南商行\测试\DB2测试\DBCONN_space.bat');
DBCONN_export.bat的作用(清空一个表):
DB2CONNECTTOtestsuUSERdb2adminusingdb2admin/
db2"loadfrom'E:
\work_file\济南商行\测试\DB2测试\space.dat'OFDELMODIFIEDBYNOROWWARNINGSMESSAGES'E:
\work_file\济南商行\测试\DB2测试\space.log'REPLACEINTOjxdx_ckzhmx"
DB2CONNECTRESET
9、验证存储过程调用的结果。
db2selectcount(*)fromjxdx_ckzhmx
注意:
在测试这个功能的时候有一些细节没有注意,导致函数注册后不能调用。
1、编译JAVA源文件的编译器和执行的JVM的版本必须一致的
DB2V8.2安装时带的"1.4.1";
而本机又另外装了一个"1.5.0_05"
之前没有注意,直接使用命令javac来进行编译,用的是默认1。
5版本的
函数注册后,调用出错,提示SQL4304reasoncode"1"的错误信息;
而给出的提示是说CLASSPATH有问题,所以注意力一直放到这个方面找问题所在
后来才发现真正的问题是出现在版本上。
最好直接在\SQLLIB\java\jdk\bin的目录下编译后再COPY。
2、设置Java环境
几个关键的设置:
参见文档:
《解决DB2UDBJava存储过程的常见问题》
JDK_PATH:
这是一个数据库管理器配置(DBMCFG)参数。
这个参数指出用来执行Java存储过程的JVM或JavaDevelopmentKit(JDK)的位置。
这是一个非常重要的参数。
它的值应该设置为包含JVMJava可执行文件的“bin”目录的上一级目录的完整路径。
在Windows?
平台上的一个例子是C:
\ProgramFiles\IBM\SQLLIB\java\jdk。
UNIX?
例子是/usr/java1.3.1。
JVM级别也非常重要,因为根据使用的db2level和平台级别,DB2UDB只支持某些JVM级别。
JAVA_HEAP_SZ:
这是一个数据库管理器配置(DBMCFG)参数。
这个参数决定为Java存储过程和UDF服务的Java解释器所使用的堆的最大大小。
为了避免在Java存储过程中耗尽内存,可以增加这个值。
但是,如果在环境中要调用许多存储过程(即,每个JVM都会分配这么多堆空间),
那么分配太多内存也是有害的。
一般规则是保持JAVA_HEAP_SZ为默认设置,即512(4K页)。
其他相关内容:
一、如何安装jar文件到当前数据库:
db2"CALLsqlj.install_jar('D:
\IBM\SQLLIB\java\jdk\bin\os_cmdUDF.jar','os_cmdUDF')"
二、如何更新当前数据库中的jar文件:
db2"CALLsqlj.remove_jar('os_cmdUDF')"
三、如何替换当前数据库中删除jar文件:
db2"CALLsqlj.replace_jar('D:
\IBM\SQLLIB\java\jdk\bin\os_cmdUD
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 人寿 BI 应用 实例