绍兴电信综合营销系统IMS

附件一绍兴电信综合营销系统IMS方案建议目 录1系统综述62系统总体设计72.1建设策略建议7集中解决目前急需问题7以客户为中心建立数据集市7简化数据来源8功能上应有取有舍8以数据集市为核心组织根底数据82.2系统建设原那么92.3系统的业务架构10以针对性营销为核心的分析架构10以营销自动化为核心的处理架构11以多角色支持为核心的界面架构112.4系统的技术架构12数据获取层13数据存储层13数据展现层14元数据152.5系统功能结构153数据获取层163.1数据源分析16系统接口分析163.2ETL过程19数据抽取20数据转换21数据加载23数据审核23ETL过程管理24ETL具体实现254数据存储层274.1数据仓库信息模型设计原那么274.2模型设计方法274.3数据仓库信息模型294.4数据集市构建方法314.5OLAP分析模型32OLAP分析模型建模方法32OLAP分析技术实现方法32客户情况分析模型34业务开展分析模型34收益情况分析模型35市场竞争分析模型365数据展现层375.1综合查询37自定义查询功能37主题查询功能37即席查询功能385.2统计分析报表39统计报表数据来源40统计报表要素分类415.3预定义报表42省公司报表43本地网报表435.4关键指标展示报表44今日视点44每月聚焦44年度回眸48竞争前沿525.5营销渠道支撑55营销管理平台55片区经理/高级客户经理营销效劳平台55社区经理/客户经理营销效劳平台55系统管理平台565.6话务量针对性营销56客户信息查询56话务量营销支撑57信息反响支撑585.7数据分析支撑OLAP分析59客户情况分析59业务开展分析63收益情况分析64市场竞争分析685.8领导驾驶舱70仪表显示70图表显示716元数据管理726.1ETL、数据仓库、数据集市、前端展现的元数据管理726.2管理对象746.3元数据互联747系统管理75用户管理75用户划分75工号维护75工号密码维护757.2预警管理76预警管理功能描述及标识76系统预警的对象76系统预警的功能767.3系统日志管理77功能描述77子模块功能描述777.4权限管理787.5系统备份788系统平台建议方案808.1综合营销系统平台简介808.2本期系统平台建议818.3设备配置建议82存储系统配置82效劳器系统配置84整体配置方案建议861 系统综述为适应日趋剧烈的市场竞争环境，提升绍兴电信的企业核心竞争力，应充分利用业务支撑系统产生的大量珍贵的数据资源，尽快建立综合营销系统，以便可以进行“保、挖、抢等针对性营销，并支持多层面的用户使用，为市场经营工作提供及时、准确、科学的决策依据。综合营销系统利用先进的计算机和网络技术对营销渠道进行支撑，同时对客户、帐务、计费、结算等业务数据进行多层次、多角度、多种方式的统计分析，揭示客户、业务的内在规律和开展趋势，形成极具管理决策价值的战略信息，使决策者能始终把握大局，沉着应对纷繁复杂、快速多变的电信竞争市场。建设综合营销系统IMS可以到达以下应用目标：l 协助企业进行“保、挖、抢等针对性营销。l 及时提供真实可靠的企业经营信息，为经营管理人员科学地进行决策提供经营信息支持。l 帮助企业建立整体信息视图one view，协调绍兴电信内部各部门之间的合作关系。2 系统总体设计2.1 建设策略建议本着急用先行，简单有效的原那么，我们建议本期系统建设采取如下建设策略：2.1.1 集中解决目前急需问题本期系统应该解决目前绍兴电信面临的最需要解决的问题：即对于全网经营情况的把握和针对性营销的支撑。鉴于急用先行原那么，我们建议本期综合营销系统的目标定位为以下几点：1. 提供对全网市场经营情况的全方位视图；2. 解决目前面对竞争的针对性营销的支撑需求；3. 提供面向营销的各类分析数据。2.1.2 以客户为中心建立数据集市目前企业最缺乏的分析功能，是基于各类客户和客户行为的统计分析，包括营销渠道支撑系统的建立，也表达着以客户为中心进行各种营销和效劳的思想。因此，本期系统主要考虑以客户为中心建立的数据集市，其中的主要内容如下：1. 客户根本信息：包括与经营分析相关的各种客户信息，如客户类别、所属区间、行业、收入、信用度、忠诚度等信息的分析结果；2. 客户拥有的效劳信息：即客户拥有效劳的相关信息，如号码，效劳类别、效劳特性、SLA等信息的分析结果；3. 客户消费行为信息：包括其消费详单、账单、缴费流水、客户的业务受理情况包括新增、拆机等等的分析结果；4. 客户其他行为信息：如投诉、建议、资源、障碍申告等信息的分析结果；5. 客户网间消费行为：如跨网的消费情况从网间数据得到等的分析结果。2.1.3 简化数据来源综合营销系统的上线工作中，各类数据的收集整理占了很大比重。因此，本期系统，应该大大简化系统的数据来源，只对最主要的数据来源进行采集，对不太重要的数据源，可以先放到二期再进行处理。具体地，我们建议把系统的数据来源限定在：1. 计费帐务系统：本期综合营销系统的数据采集重点应该在计费帐务系统中，计费帐务系统提供主要的客户消费行为数据，在营销所需要的数据中，计费帐务系统可以提供80的数据来源；2. 九七系统：要从九七系统中采集客户根本信息和客户效劳信息，以及客户的受理信息收集；3. 网间结算数据：从中抽取各种客户网间消费行为的数据；4. 其他系统：其他系统的信息收集主要考虑以收集客户行为信息为主。2.1.4 功能上应有取有舍完整的综合营销系统可以包含很多功能，尤其有强大的数据采集和管理功能，但是，目前绍兴电信建设这种大而全的综合营销系统并未突出绍兴电信急需的功能。因此，我们建议绍兴电信本期系统在功能方面应有取有舍：一方面，在功能方面，应该对系统管理、数据采集、数据管理等功能，尽可能地进行精简，只留下最小的功能集合，以突出营销分析的主题；另一方面，应该参加领导驾驶舱等功能，以使系统更能支持多角色使用，支撑针对性营销的实际需求。2.1.5 以数据集市为核心组织根底数据在本地网级进行经营活动的各种监控和分析，可以主要是利用统计好的数据而不是清单进行处理。因此，建议本期系统将重点放在建设数据集市方面，系统主要保存统计好的历史数据在集市中，以便进行各种纵向分析和比拟。而对于一些详单的查询要求，可以直接从计费系统中读取，以节省存储空间。2.2 系统建设原那么综合营销系统涉及到数据库、联机分析处理OLAP等多种学科与技术的交叉。在技术实现上涉及到多种系统平台与工具的集成。因此，在系统的技术实现上应充分考虑多种技术和平台的无缝集成。因此，系统建设必须遵循以下要求：1、 开放性：为保证系统的开放性，系统构建中要使用世界主流的硬件平台主机、网络设备等和软件平台，基于业界开放式标准，支持系统建设中涉及的各种网络协议、硬件接口、数据接口等，为未来的系统扩展奠定根底。同时，为了保证系统的开放性，在数据模型建立时，数据存储中应充分考虑对未来业务开展的最大支持如：客户数据/用户数据的处理上考虑较为全面的采集，模型建立中使用独立的客户数据域，为CRM系统使用客户/用户数据奠定根底，使相关系统能够顺利地访问和使用该系统数据。2、 灵活性与可扩展性：全局数据存储模型的设计采用面向企业整体信息的主题域方式，保证信息的完整性和信息主题的稳定性。将来新业务数据和分析需求出现，新业务数据的参加可以按照域归属的方式进行增加，在无主题域可依的情况下，采用建立新域的方式进行数据扩展。分析模型可以通过数据集市对主题域进行屡次重构，系统能保证重构后的分析模型符合数据要求，这样也保证了对未来相关系统的数据支撑。3、 平安可靠性：综合营销系统使用集中的管理模块和集中的数据处理，有利于对系统的整体管理和平安控制。这种平安机制不仅能定义数据的平安性，而且能定义应用级的平安性。系统的平安管理能够通过门户方式与其它应用集成为一体。4、 实用性：结合不同部门、不同的业务需求，合理的构建分析模型按主题、地市、部门建立不同的OLAP分析模型，以及合理地组织数据特别是有效又合理的数据粒度、分析模型的数据总量控制，保证了查询效率与响应时间。对现有业务运营系统影响小，是系统的设计根本要求，采取恰当的数据抽取策略和控制机制晚间自动抽取控制来到达这一目标。系统对大多数使用人员提供通过浏览器访问方式，并且提供多种图表展现方式如：柱状图、饼图、多维透视表等，只要会使用浏览器，就会使用本系统。通过门户与OA融合，向个性化的方向开展，提供短消息以及语音的访问方式，使人机接口、展现方式多样化，实用化，灵活方便。2.3 系统的业务架构系统的体系结构应分为业务架构和技术架构，以下说明系统的业务架构：2.3.1 以针对性营销为核心的分析架构目前，电信市场的竞争已经非常剧烈，移动、联通等运营商通过准单向收费、VPN、大客户打包优惠等方式进行竞争，不但使中国电信在客户方面造成流失，而且也导致了话务量的大量分流。因此，目前的当务之急是要发动中国电信的营销力量，立即展开针对性营销。要开展好针对性营销，综合营销系统的支撑几乎是必不可少的先决条件。首先，要支撑针对性营销，本期综合营销系统必须要能够提供目前各类客户的各种消费情况的分析和波动情况分析，从中发现现有客户的各种异动情况，以及这些异动情况的特点和分布，以便尽早发现各种客户流失或者话务流失的先兆，采取措施尽可能地保住现有客户及其话务量。另外，要完成此目标，系统还必须具备从各本地网的社区营销等系统中提取竞争对手信息的数据进行分析处理，以便针对竞争对手的动态开展有针对性的营销活动；其次，本期综合营销系统还应该能够通过各种过网数据分析和客户的消费分析，发现潜在用户的开展可能方向，并据此得出结论，进而指导营销方案的制订和推广，同时到达挖掘潜在话务量的目的。最后，本期综合营销系统应能整合各类与竞争对手的客户有关的信息源包括网间数据，各类含竞争对手话务的清单数据等，进行综合统计和分析，尤其是发现竞争对手的有价值客户的根本特点和分布情况，以便有针对性地采取营销措施，对竞争对手的客户进行抢夺，力争化被动为主动，最终改变中国电信的竞争态势。以上这些需求，宏智科技的综合营销系统都以专题分析的方式提供了较为完整和体系化的支持，用户能够在这些专题的导引下，方便地进行各种类别的针对性营销分析。2.3.2 以营销自动化为核心的处理架构系统的处理架构应围绕着营销自动化的思路展开，完成发现和确认营销目标(比方要对零费用的所有用户等)分解营销任务分解考核指标实施营销反响营销实施情况分析营销实施效果完成考核这样的一个全流程的管理，其目的是：1. 社区经理/客户经理的工作难度我原先的想法是强调社区经理的主观能动性，主动从数据中挖掘营销目标，降低对他们的要求；2. 分工明确社区经理/客户经理、营销分析人员、营销管理人员职责明确；3. 提高营销过程效率；4. 实现营销过程闭环管理。同时，针对性营销的最终目的要落实到营销方案的制订和推行上，尤其是绍兴电信总部更是要负责制订出营销方案或营销策略的指导意见。因此，系统要能对营销方案进行全流程的监控，包括在营销方案推出前的预评估，营销方案进行中的跟踪以及营销方案定期的效果评估等。比方预评估指的是系统应能预先锁定营销方案针对的客户群、话务集合进行数据统计和分析，得出营销方案涉及的客户数量、涉及的话务量、涉及的金额等，从而方案的盈亏平衡点或者是营销方案的本钱等，从而供决策层进行综合分析和评估。2.3.3 以多角色支持为核心的界面架构综合营销系统将有不同层面的用户进行使用，不同层面用户的要求是不同的，尤其是本系统作为本地网级的综合营销系统，这方面的特点尤其突出。宏智科技建议的三层界面架构如下：例如对于绍兴电信的高层领导来说，他们没有太多精力了解计算机技术，在数据利用的尺度上也比拟宏观，因此系统就为他们专门设计了领导驾驶舱系统，以简单直观的图表方式提供数据的展现，使决策人员能一目了然地发现问题所在，并通过本系统层层深入地发现问题发生的原因，从而做出正确的反响和决策。对于绍兴市电信的中层干部来说，他们需要向下贯彻公司高层领导的战略意图，并指导本部门基层干部将其演变为具体的营销动作或者变为指导各营销渠道的营销策略，同时他们要对本部门所提出的各种营销建议进行决策或提交高层决策。因此，系统界面以表达结果的各类预定义报表为主，但这些报表本身都可以做为分析的起始点进行深度挖掘和分析。使中层干部一开始可以将注意力集中在关心的业务、指标和营销方案实施的根本情况上，但同时也可以对自己关心的数据进行各种联机分析和处理。同时，系统应能够提供对于营销方案制订的全流程支持，使分析的结果能迅速落实为营销方案或营销策略的建议。另外，系统应提供灵活且易用的报表定义功能，使基层干部能够将分析的结果存为报表提供应各层领导做为决策依据和分析的起始点。对于绍兴市电信的基层人员来说，他们需要对自己负责的业务或者客户群进行细致的分析，发现趋势及问题所在，并提出初步的营销方案的建议或者采取具体的销售动作。因此，系统应提供完善的清单功能和统计功能。同时，由于考核指标将是鼓励基层人员的重要手段，因此，应提供围绕考核指标提供各种统计和因素分析支持。2.4 系统的技术架构综合营销系统采用本地网集中的模式，在本地网建立数据中心，再通过这些数据存储提取数据集市进行分析和呈现。综合营销系统从各业务系统、非业务系统中将相关业务数据进行抽取录入、清洗、加工、整理、加载到数据仓库中，在数据仓库中形成根底的分析数据的存储，然后根据业务及管理等实际的需要在数据仓库上建立适合各种应用的数据集市。数据仓库、数据集市中蕴含的信息可以通过报表、OLAP分析、即席查询等形式向综合营销系统使用人员展现。系统体系结构分为三层，即数据获取层、数据存储层和数据展现层，如以下图所示：下面分别对于软件体系结构中的数据获取层、数据存储层和数据展现层进行说明。2.4.1 数据获取层数据获取层功能是将数据从数据源经过必要的抽取、清洗、转换等处理后加载到综合营销系统数据库中，即ETL过程。为保证数据的正确性，在ETL的每一环节都必须对数据进行审计。ETL具有统一调度、监控和管理功能。处理过程支持校验点功能，当因某种原因使处理过程中断时，可以从最近校验点开始恢复处理过程。ETL的日志记录了数据抽取、清洗、转换、加载的历史过程。为提高ETL工作效率，宏智科技开发的ETL工具内嵌的专用脚本语言、存储过程完成综合营销系统复杂的ETL过程。2.4.2 数据存储层数据存储层包括中央数据仓库和附属的数据集市。中央数据仓库是信息的逻辑和物理的存储。在综合营销系统的实施过程中，对于某些主题的业务分析问题，可能会按照主题采用数据集市的方式对数据进行进一步的组织。所以在数据仓库的根底之上根据分析需求创立相应的附属数据集市。2.4.2.1 中央数据仓库中央数据仓库是按照绍兴电信整体的、全本地网一致的信息模型进行构建的，是综合营销系统的核心。由于经营信息需求的不断变化，数据仓库必须采用主题分域的方式和尽可能小的业务单元来进行数据的组织和存储，这样才能满足数据使用的灵活性和信息的完整性，即适应需求的变化，又可保证最少量的数据冗余防止信息的不一致，节约系统投资，并以“元数据驱动、螺旋上升的方法来指导系统建设。2.4.2.2 数据集市中央数据仓库构建是对数据集市的数据支撑，几乎所有的业务分析都需要通过进一步组织数据集市来实现，以满足性能、灵活性的要求。数据集市的建设主要面向部门和重要的领导，根据其关心的主题、数据层次、数据粒度不同，构建相应的数据集市。数据集市的数据可直接来自于中央数据仓库，也可直接进行采集。为一些访问中央数据仓库十分频繁的关键业务部门建立附属数据集市，可以提高查询的反响速度。2.4.3 数据展现层数据展现层的主要功能是通过对数据存储层的数据进行各种加工整理并进行分析预测等操作，然后将获得的数据以文字、报表、曲线和各种图形的方式，简便、快捷地展现出来。主要包括综合查询、联机分析处理OLAP、报表输出、话务量营销和领导驾驶舱功能。用户经过身份平安、权限认证后访问数据和进行各种分析、查询操作，同时预留与信息门户比方OA系统的接口，实现各种功能的无缝连接，并提供集成化的认证、信息发布和管理环境，使综合营销系统使用人员无需关心具体的技术实现途径，即可实现对综合营销系统数据的访问和分析。同时门户站点还可根据不同分析和决策人员的需求，对所需的访问和分析内容进行方便、简捷的定制，以满足个性化信息效劳的需求。2.4.4 元数据元数据是描述数据的数据，用以了解我们有什么信息，信息在什么地方，以及整个综合营销系统中如何利用信息的管理方式。元数据管理在综合营销系统开发建设中有很重要的作用。在综合营销系统建设过程中，根据绍兴电信的业务需求和业务开展，构造全局数据模型，然后以数据模型为指导，分阶段实施，逐步完成综合营销系统的建设，更重要的是，在实施的每个阶段、每一阶段内的每个步骤，都由元数据进行统一的管理和协调。因此，每个新的实施阶段都能和前些阶段通过统一的元数据实现良好的对接和数据共享，保证各建设阶段成果的连续性和有效性。2.5 系统功能结构绍兴综合营销系统功能包含数据获取、静态报表、话务量营销支撑、数据分析OLAP分析支撑、专题分析、领导驾驶舱、系统管理。数据获取是系统的数据接口和ETL功能；报表、话务量营销、OLAP分析、领导驾驶舱表达系统的业务功能；系统管理是系统的平安管理和系统维护功能。3 数据获取层3.1 数据源分析绍兴电信综合营销系统需要从以下数据源获取相关数据：1、业务支撑系统：初期主要从本地计费帐务系统、九七系统提取数据。2、网间结算数据：获取网间话单，市场竞争数据。3、市场调研、社会统计、竞争对手数据：从各种途径获取的社会统计数据、市场调研数据，提供人工录入功能。对于以上需通过人工录入的数据，系统提供相应的工具或接口，并能支持通过Excel、HTML、XML、RTF、TXT等格式文档加载的形式进行数据的批量录入功能。接口方式：l 系统统一采用接口形式进行数据抽取，并建立接口区。设立数据接口区的目的在于对接口数据统一存储。l 接口数据源形式为文本文件。3.1.1 系统接口分析1、综合营销系统从九七系统中提取客户根本资料信息，如客户名称、住址、联系方式、证件号码、客户类型、客户细分等。信息特征：信息量级： 2-3E6单位：记录数周期增量：一般小于10E4单位：记录数周期更新幅度：一般小于10E4单位：记录数接口方式：九七系统在每个周期把本周期新增、变化或删除的客户根本资料信息传递至接口。周期可根据实际情况由两个系统协商确定。周期： 1次/天2、综合营销系统从九七系统提取客户订购资料信息，即每个客户所使用的产品效劳信息。信息特征：信息量级：10E6单位：记录数周期增量：一般小于10E4单位：记录数周期更新幅度：一般小于10E4单位：记录数接口方式：九七系统在每个周期把本周期新增、变化或删除的客户产品效劳信息传递至接口。周期可根据实际情况由两个系统协商确定。周期：1次/天3、综合营销系统从本地网计费帐务系统提取客户帐户资料信息，即客户使用各项产品效劳所所发生费用的付款单位的资料信息。1帐户根本信息信息特征：信息量级：10E6单位：记录数周期增量：一般小于10E4单位：记录数周期更新幅度：一般小于10E4单位：记录数接口方式：计费帐务系统在每个周期把本周期新增、变化或删除的帐户根本资料信息传递至接口。周期可根据实际情况由两个系统协商确定。周期：1次/天2帐户缴费信息信息特征：信息量级：10E6单位：记录数周期增量：10E5单位：记录数接口方式：计费帐务系统在每个周期把本周期新增的帐户缴费信息传递至接口。周期可根据实际情况由两个系统协商确定。周期：1次/天4、综合营销系统从各本地网计费帐务系统提取帐单资料。信息特征：信息量级：10E7单位：记录数周期增量：10E7约为客户资料量级的810倍(记录)建议接口方式：计费帐务系统按周期将周期内数据全部传递至接口。周期：1次/月5、综合营销系统从计费帐务系统提取销帐资料。信息特征：信息量级：10E6单位：记录数周期增量：10E5约为客户资料量级的810倍单位：记录数接口方式：计费帐务系统按周期把周期内数据全部传递至接口。周期：1次/天6、综合营销系统从计费帐务系统提取欠费资料。信息特征：信息量级：10E6单位：记录数周期增量：10E5约为客户资料量级的810倍单位：记录数接口方式：计费帐务系统按周期将周期内数据全部传递至接口。周期：1次/天7、综合营销系统从各本地网计费帐务系统提取呆坏帐资料。信息特征：信息量级：10E5单位：记录数周期增量：10E5单位：记录数接口方式：计费帐务系统按周期将周期内数据全部传递至接口。周期：1次/月8、综合营销系统从计费帐务系统提取长途话单资料。信息特征：信息量级：10E8单位：记录数周期增量：10E7单位：记录数接口方式：计费帐务系统每个周期都将周期内完整信息传递至接口。周期：1次/天9、综合营销系统从计费帐务系统提取本地网话单资料。信息特征：信息量级：10E9单位：记录数周期增量：10E8单位：记录数接口方式：计费帐务系统每个周期都将周期内完整信息传递至接口。周期：1次/天10、综合营销系统从计费帐务系统提取相关配置表信息资料，如帐目类型、话单类型信息、各种分类信息等。信息特征针对每个配置表：信息量级：10E110E3单位：记录数周期增量：10E010E2单位：记录数周期更新幅度：10E010E2单位：记录数接口方式：计费帐务系统每个周期都将完整信息传递至接口。周期：1次/天11、综合营销系统提取网间通话数据资料。信息特征：信息量级：10E8单位：记录数周期增量：10E7单位：记录数接口方式：各本地网计费帐务系统每个周期都将周期内完整信息传递至接口。周期：1次/天3.2 ETL过程数据抽取、转换和加载，是综合营销系统应用过程中，进行数据由数据源系统向数据仓库加载的主要方法。3.2.1 数据抽取为了满足综合营销系统的分析、挖掘的需要，同时保证不能影响业务系统的性能，因此制定适宜的抽取策略、抽取方式、抽取时机和抽取周期非常关键。对于大数据量(如话单)的抽取，采取“数据分割、缩短抽取周期的原那么。接口策略在获取各业务生产系统源数据时，根据各业务系统提供数据的方式可以分为主动数据获取和被动数据获取两种方式。主动数据获取要求综合营销系统专门为各业务生产系统提供数据存放区，并为各业务系统制定所要求的数据内容和格式，要求各业务系统将产生数据定期传送到本系统源数据存放区中。综合营销系统定期对源数据存放区接口区中的数据进行处理。被动数据采集要求各业务系统为综合营销系统开放数据库连接，同时要求业务系统为综合营销系统提供专业系统元数据。综合营销系统通过理解专业系统元数据，直接连接业务系统定期从数据库中取数据，然后在系统内在对专业系统源数据进行处理，例如进行格式、编码转换等。采集周期可以根据具体情况，自行设计。这种方式要求业务系统对所提供的元数据进行版本和发布管理。考虑到被动获取比主动数据获取对综合营销系统性能要求高和对业务生产系统平安和性能影响大等问题，我们采用主动数据获取方式，要求各业务系统定期按要求传送数据到源数据存放区。各业务系统以文本数据文件的方式传送数据。抽取策略：不同特征的数据采用不同的抽取策略，保证减少对生产系统的影响，同时又能提高抽取数据的效率和及时率。具体策略如下：1小数据量的一些管理数据、配置表数据等，可以采用完全抽取方式进行抽取；2大数据量的如帐单、话单数据，按抽取周期采用时间戳来做增量抽取；3如果实在没有时间戳，要进行完全抽取。抽取周期：抽取周期根据源数据的不同性质和实际的分析需求而有所不同，如话单数据可以每天抽取，出帐数据在每一帐务周期的最后一天抽取，而欠费、销帐等信息可以每周抽取。具体的数据抽取周期要依据实际情况和要求协商而定。抽取时机：本操作尽可能在相关业务系统空闲的时段执行。在数据抽取成功后，本抽取周期将不再执行数据抽取操作。3.2.2 数据转换数据转换是指对抽取的源数据根据全局数据模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据和信息模型的一致性和完整性，并按要求装入数据库。根据实际情况，数据转换可以在以下几个环节中具体实现：l 使用异步数据加载，以文件的方式处理；l 在数据加载过程中进行数据处理；l 进入数据库以后再进行数据处理。采用异步数据加载需要以文件方式处理时，必须充分考虑中间磁盘的存储量以及在整个流程中的协调性及文件处理的效率；采用在数据加载过程中进行数据转换时，必须考虑加载性能及效率；采用先将数据装载到数据库后再处理时，必须考虑数据库引擎的海量数据处理能力。执行时机：执行周期根据不同接口数据而有所不同。执行位置：l 从源数据存放区到加载入数据仓库之间，这里存在大量的数据操作， l 数据仓库到加载入数据集市之间，这里主要存在数据转换、汇总等操作，根本没有清洗操作。执行功能：集成、转换、清洗、拆分、汇总等处理l 集成：是将业务数据从一个或几个来源中取出，并逐字段地将数据影射到全局数据的新数据结构上。l 转换：将源数据按照全局数据模型结构进行数据处理，本处描述的转换是简单转换，广义的转换是包括集成、转换、清洗、拆分、汇总等处理。l 清洗：目的是为了保证前后一致地格式化和使用某一字段或相关的字段群。l 拆分：简单转换的一种形式，用于分解源数据中复合含义的数据。l 汇总：把业务环境中找到的细节数据压缩成全局数据环境中的较少数据块，有时进行聚集中的细节数据是为了防止数据仓库存入业务环境中的那样具体的数据，有时那么是为了建立包括数据仓库的聚集副本。l 代码转换：如果是由数据抽取工具来完成数据的集成转换，那么用户自定义的代码转换功能成为系统必须的功能。因为业务系统数据与全局数据的信息因各系统的不同会有较大的差异。客户有能力和手段自己定义数据或代码转换的操作使系统有更大的灵活性。转换技术：l 多线程、多进程技术由于数据清洗转换操作的数据量非常大，要求数据清洗转换程序以及所处的操作系统、主机要支持多线程、多进程的体系结构，以获得最大的数据处理能力。l 散列文件参照机制在数据清洗的过程中，关键的耗时的工作是将输入的数据与系统中的固定数据进行对照，每一条记录都需对数据库进行查询消耗了大量的时间。在ETL过程中，数据集成模块需要提供对固定参照数据的散列查找机制以提供数据清洗的高效实现。l 专用数据库驱动接口或API接口编程l 利用操作系统提供特点进行开发，例如数据上载内存等方式l 采用专用工具进行数据转换数据 根据数据转换审核方案，将转换以后数据进行汇总分类统计，与数据接口区提供的审核资料进行比拟。转换策略：l 使用异步数据加载，以文件的方式处理；l 在数据加载过程中进行数据转换。3.2.3 数据加载数据加载就是将转换后的数据加载到数据仓库中。数据加载采用数据加载工具例如：Warehouse Manager、FastLoad/MultiLoad等，也可以采用API编程进行数据加载。数据加载策略包括加载周期和数据追加策略。数据的追加策略根据数据的抽取策略以及业务规那么确定，一般有以下三种类型：直接追加、全部覆盖、更新追加。直接追加：是指每次加载时直接将数据追加到目的表中。全部覆盖：对于抽取数据本身已包括了数据的当前和所有历史状况，采用全部覆盖方式。更新追加：对于需要连续记录业务的状态变化，用当前的最新状态同历史状态数据进行比对的情况采用更新追加的方式。作用区域：数据加载到数据仓库和数据加载到数据集市的两个区域。执行时机：数据转换成功以后即可以开展，并且要保证加载后业务数据的一致性和完整性。加载技术：数据加载采用数据加载工具加API编程进行数据加载。加载策略：l 加载周期：在保证加载后业务数据的一致性和完整性的根底上，针对不同业务数据设置不同加载周期。l 数据追加策略：根据业务规那么和数据抽取策略，采用直接追加、全部覆盖、更新追加。3.2.4 数据审核数据审核是指在每个数据加载周期中，保证数据仓库中数据同数据源中数据业务意义上的一致性及数据的准确性。审核方法如下：在每个环节处理完成后进行抽样审核从数据源开始，到抽取出来的文本文件，到转换后的文本文件，到装载到数据仓库的数据，到数据集市中的Cube数据，一方面对总量进行审核，另一方面对数据正确性进行验证，分别对每一个维上的数据进行审核。对审核结果进行记录并报告，发现审核错误的数据发Email或SMS通知系统管理员。数据审核程序与ETL模块统一处理，审核程序配合ETL程序自动执行。作用区域：在数据抽取、转换、加载各个局部结束都需要进行数据审核。在一些关键处理过程结束以后，进行自动的数据审核，这样能够及早发现问题，节省数据抽取、转换、加载的时间。执行周期：由数据抽取、转换、加载过程结束以后触发，在一些关键处理过程结束后触发。审核策略：l 通过日志校验；l 通过业务规那么校验，例如：记录数，本月收入合计，某区客户数量等进行源与目标数据的校验；l 通过操作系统级校验，例如：文件大小、奇偶校验常用于接口文件传输。3.2.5 ETL过程管理ETL是一个复杂的过程，需要进行过程管理。ETL的过程管理包括ETL的调度、ETL程序管理、ETL出错处理以及故障恢复。ETL的调度ETL是一批定时运行的后台过程，需要通过一个合理的规划进行自动运行，只有在ETL过程出现异常时，进行人工干预或自动处理。本系统提供系统管理员的控制和管理界面。ETL程序管理ETL过程包括许多程序，这些程序在运行期间对数据进行处理，将这些ETL程序管理起来，可以保证ETL过程的正确及稳定。ETL出错处理及故障恢复在ETL过程中由于数据接口、网络、主机或数据质量等问题，造成ETL过程出现错误，每次数据的处理和装载需要将非法的数据或处理失败的数据输送到专门的出错数据处理区中，一些错误可以通过自动处理进行恢复，一些错误需要人工进行处理。还可以自动将错误信息通过短信、mail等方式通知系统管理员或相关人员。3.2.6 ETL具体实现3.2.6.1 ETL过程需要重视的几个方面通过长期实践，宏智科技总结了以下几个是ETL过程中需要重视的方面：1. ETL时间是有限的，ETL的效率是系统的关键由于各本地网业务支撑系统在白天都在执行关键的联机应用，所以ETL过程通常要在晚上执行，另外由于话单、账单等数据量极大，所以ETL的效率是最为重要的。除了在硬件上提供保证，要充分考虑开发的软件代码效率，更为重要的是要进行ETL的规划、设计和管理，尽可能考虑ETL各过程的并行操作，以充分利用系统资源。2. 数据仓库对数据的正确性要求是很高的，ETL要保证数据的正确性保证数据仓库的正确性，首先需要从全局数据模型入手，只有正确的模型才会有正确的数据存储。ETL是从数据源根据指定规那么将数据转换到数据仓库中的数据迁移过程，在此过程中，每一个步骤都是决定数据质量的关键，所以，要建立完善的过程来保证ETL的正确实施。我们采用以下方法来保证ETL的正确操作。l 严格的设计评审制度l 建立数据审核制度l 数据预警通过与历史数据比拟，检测ETL的输出数据是否存在较大差异，判断是否数据出现错误，由于数据预警操作消耗资源较大，而且检测对象一般是业务系统提供的接口数据，所以，宏智科技建议数据预警操作放置在审核接口数据局部。3. ETL过程中出现的错误需要在适宜的时间内正确处理。ETL过程是非常复杂的过程，其中涉及到业务系统、业务规那么、系统硬件环境、系统管理等各方面，ETL过程出现错误是必然的。在设计、管理中尽可能做周全考虑的前提下，还要考虑ETL过程中出现错误后该如何处理的机制。ETL出现的错误可以分成多种，各种错误对数据仓库的数据造成的影响是不同的，需要解决的迫切程度也有所不同，根据宏智公司的经验，将ETL过程产生的错误分成4个级别：l 严重错误，需要立即解决；l 较严重错误，影响系统局部数据，需要当日解决；l 一般错误，影响系统较小局部数据，且其中没有重要数据，需要解决；l 警告，出现异常或错误，但不影响系统数据，需要管理员注意。4 数据存储层4.1 数据仓库信息模型设计原那么综合营销系统信息模型的设计应该遵循中央数据仓库的稳定性和数据集市的灵活性；数据仓库面向信息主题、数据集市面向分析业务；数据集市的数据来自数据仓库的原那么。综合营销系统的数据存储分成数据仓库和数据集市两个逻辑上独立的存储。数据从数据源经过数据抽取、转换后加载到数据仓库，根据不同主题的数据集市的要求，数据从数据仓库中根据转换规那么将数据加载到指定数据集市。由于综合营销系统的业务需求容易变化，数据仓库中数据的存储必须采用信息主题分域的方式和尽可能小的业务单元保存细节数据来进行数据的组织和存储，这样才能满足数据的灵活性，适应需求的变化，又可保证最小数据冗余，防止数据的不一致。数据仓库数据存储模型的设计采用面向企业整体信息的主题域方式，保证信息的完整性和信息主题的稳定性。将来新业务数据和分析需求出现，新业务数据的参加可以按照域归属的方式进行增加，在无主题域可依的情况下，采用建立新域的方式进行数据扩展。分析模型可以通过数据集市对主题域进行屡次重构，系统能保证重构后的分析模型数据要求，这样也保证了对未来相关系统的数据支撑。4.2 模型设计方法概念数据模型(CDM)概念模型是主观与客观之间的桥梁，它是用于我们为一定的目标设计系统、收集信息而效劳的一个概念性的工具。具体到计算机系统来说，概念模型是客观世界到机器世界的一个中间层次。人们首先将现实世界抽象为信息世界，然后将信息世界转化为机器世界，信息世界中的这一信息结构，即是我们所说的概念模型。由于E-R图具有良好的可操作性，形式简单，易于理解，便于与用户交流，对客观世界的描述能力也较强，在数据库设计方面更得到了广泛的应用。因为目前的综合营销系统数据一般都建立在关系数据库的根底上，为了和原有数据库的概念模型相一致，采用E-R图作为综合营销系统的概念模型仍然是较为适合的。概念数据模型的设计是在较高的抽象层次上的设计，因此在建立概念模型时不必考虑具体技术条件的限制。进行概念数据模型设计要完成以下两个工作：1. 界定系统边界2. 确定主要主题域及其内容逻辑数据模型(FS-LDM)逻辑数据模型是系统体系结构大厦的一块基石，它主要包含实体、属性、实体与实体之间的关系、实体与属性之间的关系。在工程实施过程中模型会被定制、修改、参加新的实体，任何对PS-LDM的更改都将影响到逻辑数据模型设计人员、数据库管理员、应用开发人员、操作人员、业务用户。因此逻辑数据模型包含的实体、属性名称、属性格式、实体与实体之间的关系、实体与属性之间的关系应当参加元数据库中。逻辑数据模型设计要进行以下工作：1. 分析主题域，确定当前要装载的主题2. 确定粒度层次划分3. 确定数据分割策略4. 关系模式定义5. 记录系统定义物理数据模型PDM物理数据由逻辑数据模型按照根本的建模步骤转换而来。物理数据模型为数据库管理员提供了一个数据库的单一视图，将其参加元数据库有重要意义。物理数据模型参加数据库的内容包括： 数据库、表、视图、宏、列名称、格式、属性、约束取值、参照关系等、关系数据库与表、视图、宏，表与列，表与试图等。所谓数据库的物理模型就是逻辑模型在数据库中的实现，如物理存取方式、数据存储结构、数据存放位置以及存储分配等等。物理模型是在逻辑模型的根底之上实现的，在进行物理模型设计实现时，所考虑的因素主要有：I/O存取时间、空间利用率和维护代价；在进行数据库的物理模型设计时，考虑到综合营销系统数据库的数据量大但操作单一的特点，可采取其他的一些提高数据库性能的技术，如：合并表、建立数据序列、引入冗余、进一步细分数据、生成导出数据、建立广义索引等。在物理数据模型设计中主要工作是：1. 确定数据的存储结构2. 确定索引策略3. 确定数据存放位置4. 存储分配4.3 数据仓库信息模型数据仓库信息主题，包括客户、帐务、效劳、结算、产品等局部。数据仓库按照电信信息组成进行前瞻性的结构设计，主要包容了九七、计费等数据。1. 客户主题包含了与客户相关的根本信息，如客户的自然属性姓名、年龄、职业等、客户的分类信息大客、商客、公客、流动客户、客户的重要属性信息信用度、忠诚度、消费层次等。2. 帐务主题中包含了与客户相关的费用信息，如明细账单、综合帐单、帐本、帐户、付费记录、销帐流水等信息。3. 产品主题中包含了产品目录。4. 效劳使用主题中描述客户购置和使用中国电信效劳产品的信息，主要包含了用户、效劳使用记录、清单等。5. 结算主题中包含了结算清单、结算明细账单、合作效劳方等信息。 中央数据仓库信息模型示意4.4 数据集市构建方法数据集市是直接面向分析需求的，在数据ETL结束后通过相关处理生成。在数据集市中保存的数据一般有以下特征：数据一般不能直接从数据仓库中产生，需要进行转换处理，如消费层次等信息；数据集市中的数据较新，局部集市根据分析需求，甚至可以只保存最近几个月的数据；可以集成数据仓库中的多个主题信息而生成新的专题。在实际应用中，我们是按如下方式生成数据集市的：1. 完成数据仓库配置表信息到数据集市的转换，特别要提出的，有一些集市专用配置信息如消费层次配置表、通话时长层次配置表等需要相应配置程序产生和维护而并非来自与数据仓库或业务系统。还需要提醒的是，在这个步骤中，必须根据展示工具的特点对配置表进行处理。2. 完成数据仓库主题信息到数据集市的转换，其中需要把一些量值型信息转化为层次型信息，如通话次数转换成通话次数层次，通话时长转换为通话时长层次等；通过这些转换，我们可以根据集市中的主题信息和配置信息直接建立更好满足分析需求的星型模型或雪花模型。3. 需要根据分析需求建立一些专题，这些专题可能需要几个主题信息进行集成。因此我们在主题信息转换到数据集市中后处理本步骤。4. 集市的建设是由需求驱动的，在系统建设初期，集成商为绍兴电信提供当前所需的数据集市模型和相应的ETL过程。在系统移交以后，根据业务需要，绍兴可以自主建设数据集市的其他主题。只要在深入理解全局模型的前提下，构建所需的数据集市将是快速、有效的。4.5 OLAP分析模型4.5.1 OLAP分析模型建模方法在多维分析模型建设中存在两种模型：星型模型和雪花模型。星型模型的构架非常简单，只有两个根本的表类型：维和事实，维表的主关键字是事实表的外键，而且维只与事实相关联，构成关系数据库中的多维分析空间。通过星型模型，使用者可以更好地理解访问途径，易于使用者使用分析工具进行多维分析。虽然星型模式存在一些数据冗余，不符合数据库设计的范式，但由于它在进行分析操作时数据关联少，因此性能比拟高。另外多维数据模型所提供的操作与关系数据库是不同的，因此并不存在关系数据库中不符合某个范式造成的插入异常和删除异常的问题。雪花模型针对每个维度的每个层次都有一个维度表，每个维度表都有一个主键，并如果有下一层次，那么包含下一层次维度表的外键。雪花模型没有冗余，符合数据库逻辑模型设计理论中的第三范式，但由于特定主题相关的物理实体数量比拟多，会对性能有一些影响。雪花模型主要用于处理多对多关系的结构、非分析性数据和层次结构。在多维数据模型设计中，我们主要采用星型模型进行建模，提高查询效率以及降低建立CUBE所需时间。4.5.2 OLAP分析技术实现方法在多维数据模型中，经常会应用到随时间改变会发生改变的维度， 这就是渐变维，维度信息随着时间推移而变化，需要保存维度的历史信息。可以采用两种方法进行渐变维的处理。1. 采用星型结构表示渐变维，将已经变化的维属性写入事实表中，在当前记录保持最新维信息。优点是处理简单，不需特别维护维表的变化。缺乏之处是无法记录维表中维成员变化。适用于与其他维的关联较少的简单维表。2. 采用雪花型结构表示渐变维，在维表基表中增加时间属性，不需增加事实表具体维的列。优点是可以记录维表变化历史，维护维表的代价较小。缺点是设计比拟复杂，查询效率低。适用于多个叶子级维表与基维表相关。可以采用这样的改良方法：映射当前有效维信息到视图或表中，提高查询性能。多维模型设计中，需要考虑两方面的效率：一、多维数据查询的效率。二、生成多维数据建立CUBE的效率。在这两方面中，当以多维数据OLAP查询的性能作为主要优化对象。在多维模型中我们采用了以下方法进行OLAP查询的优化：1. 识别并标识出dense和sparse维。在多维模型中，维的成员存在稠密分布和稀疏分布，如果将稀疏分布的维作为超立方体存储，多维数据存储将形成稀疏立方体，多维数据存储空间将无法充分利用，造成OLAP查询时要读取大量稀疏立方体，严重影响OLAP查询效率。采用定义dense和sparse维，将sparse维对应的成员作为多立方体存储的依据，将dense维对应成员作为超立方体存储的依据，将大大减少多维数据的存储空间，并有效存储所需的数据，提高OLAP查询的效率。2. 建立属性维，属性维是依赖于指定已经经过计算的维度的属性变化的维度。由于增加一个维度，将增加大量的聚合运算操作，增加的量呈指数级增长，在这样的情况下，采用属性维的方式可以减少聚合运算，因为属性维的聚合运算已经在基维上计算过，不需再次运算。通过采用属性维的方式可以大量减少建立CUBE所需的运算，并能够提供更多的维度用于分析。合理定义预计算和动态计算的维度级别。预计算是多维模型的特点，采用“用空间换取时间的方式，提高OLAP查询效率。由于定义的多维数据模型中，有一些维度的级别是较少使用的，而将这些维度级别定义成预计算的方式必将造成空间的浪费，在这种情况下，可以将这样维度级别定义为动态计算，设定为在查询请求时才进行计算。这样的OLAP查询的效率相对而言是比拟低，只有在相应的OLAP查询发生不频繁时可以采用。还可以将维度级别定义为动态计算存储，这样只要进行过一次相关OLAP查询，就可以存储聚合计算结果，在重复的OLAP查询再次进行是，直接冲存储的聚合结果中取相应结果响应OLAP查询。4.5.3 客户情况分析模型构成客户情况分析模型的维度信息是：时间、地域、年龄组、客户性别、消费层次、客户类型、客户职业、信用等级、呼叫时长层次、呼叫次数层次、在网时间等级、业务品牌、业务种类。指标值是按维度适当汇总的：客户总数、活动客户数、欠费客户数、零次客户数、新增客户数、流失客户数等。客户情况分析模型示意4.5.4 业务开展分析模型构成业务开展分析模型的维度信息是：时间、地域、客户性别、客户年龄组、客户类型、客户职业、消费层次、业务品牌、业务种类、通话时段、呼叫类型。与维度相关的指标：通信时长、通信次数、通信量、MOU、新业务使用量等。业务开展分析模型示意4.5.5 收益情况分析模型构成收益情况分析模型的维度信息是：日期、地域、客户性别、消费层次、客户类型、客户职业、信用等级、业务类别、费用类别。与维度相关的指标：收入总量、收入增量、ARPU、欠费金额等。收益情况分析模型示意4.5.6 市场竞争分析模型构成市场竞争分析模型的维度信息是：时间、地域、业务品牌、呼转时段、对端运营商、客户级别、年龄组、客户性别、消费层次、客户类型、客户职业、信用等级、在网时间。与维度相关的分析指标：呼转计费时长、呼转通话次数、呼入时长、呼入次数等。市场竞争分析模型示意5 数据展现层5.1 综合查询综合查询模块的主要功能是使应用人员可以通过自定义、模糊查询、即席查询等方式，快速方便从综合营销系统取得需要的数据，并对查询结果提供多种可选择的展现方式。综合查询模块应提供向导式界面、联机帮助、提示窗口等，无需经过专业培训，即可通过简单的鼠标拖拉操作或输入关键字方式实现。5.1.1 自定义查询功能实现目标作为用户个性化信息提供模块，可以让用户根据自己的实际情况，从以上各分析模块中挑选出自己比拟关心的分析内容，添加到自定义查询中，类似于收藏夹，以利于日常操作分析。功能描述自定义查询应支持以下方式：1、 用户在以上模块上定制的分析内容可以保存下来，并在以后应用中直接翻开或仅稍做修改就可使用；2、 对于在以上各模块中预定义分析主题不存在的内容，用户也可以通过向导式或图形化界面定制新分析主题，满足分析需求。性能要求对于一般查询，响应时间应小于25秒。5.1.2 主题查询功能实现目标类似Internet上的搜索引擎，提供用户快速定位到相关的分析主题上的功能。功能描述主题查询应提供维度、指标列表及文本框，用户可以通过选择相关维度、指标或输入关键字，搜索到相关的分析主题列表。性能要求响应时间小于10秒。5.1.3 即席查询功能实现目标即席查询应能提供各种简单清晰的界面，实现对后台数据详细信息的查询。功能描述即席查询应支持以下方式：1、 即席查询应具备钻取功能，用户在以上各模块