《电子商务BI中的基础思考.ppt》由会员分享，可在线阅读，更多相关《电子商务BI中的基础思考.ppt（25页珍藏版）》请在三一文库上搜索。
1、优秀精品课件文档资料,电子商务BI的基础思考,Bobby Luo 罗如意(） 2011年7月 http:/ BIer之路之二,对于BI认识的两个误区,BI是一个完整的体系,架构规划的实例,如何分阶段实施,关于数据质量的思考,BI到底是什么？,BI已经是现在很流行的概念了（从数据获取信息，产生价值）。 但到底什么是BI？应该怎么样实施？,误区一：BI就是报表和取数,1、在生产系统之外，建立单独的报表库及报表系统，需要时就开发一些特定的报表，或者手工提取数据，再做一些简单分析。 2、一般的需求由业务部门如市场部、产品部发起，BI部门沦为简单的数据提供部门。 带来问题：业务部门一般都是从自己部门角度
2、考虑，同时缺乏对其他部门数据和BI技术的了解，分析一般比较狭窄。而BI部门疲于应付各种取数和开发需求，缺乏对高级BI应用的开发和对整个企业BI分析的规划。,误区二：数据挖掘等高级应用才是BI,1、很多人尤其是领导者一般很容易被现在流行的BI概念所影响，认为只有数据挖掘、精准营销这些相对高级一点的应用才是BI。 2、从而很关心每月做了多少个挖掘或分析，而不愿意做一些基础性的数据整合、模型规划等工作。 带来问题：应用很多，但都是浅尝则止，没有真正地给企业带来多大实际价值。同时应用开发的效率低下，很多数据每个人重复地计算来计算去，结果却各不一致。数据质量问题也影响了分析和挖掘的结果及应用价值。,对于
3、BI认识的两个误区,BI是一个完整的体系,架构规划的实例,如何分阶段实施,关于数据质量的思考,BI是一个完整的体系,数据源,业务用户,ETL,数据集市,抽取,转换,清洗,加载,查询,报表,OLAP,数据 挖掘,数据仓库,信息访问,网络管理 数据库管理 系统管理,元数据 逻辑数据模型 物理数据模型,业务和技术咨询与培训服务,中间件/EAI,可选项,整合的数据基础,良好的层次体系,长远的应用规划,恰当的最终展现,+,+,+,一、要有整合的数据基础,二、要有良好的体系规划及运维机制,三、要结合业务需求做好应用规划,四、需求出发、各尽其用,对于BI认识的两个误区,BI是一个完整的体系,架构规划的实例,
4、如何分阶段实施,关于数据质量的思考,公司的现状,需要考虑的几个关键问题（1/3),1、是否需要将Oracle数据和应用全部迁移到Teradata？ 否。 Teradata是单节点，如果全部迁移到Teradata，随着数据和应用增加迟早也会遇到性能和存储瓶颈；而且现在ORACLE已经有大量的脚本和报表，如果全部迁移的话，需要花费大量精力，数据核对也很复杂。,2、哪是否形成两套独立的系统？老的保留，新的应用全部基于TD。 否。 这样仍存在Teradata瓶颈问题。同时需要维护两套不同的ETL系统，工作量增加，两套系统间的数据一致性也会存在很大问题。 因此最好的方法是充分利用现有Oracle的ETL
5、和汇总数据，形成Oracle和Teradata整合的体系架构。,Teradata和Oracle结合的EDW体系,Oracle,生产库/备库,报表系统,Teradata,Hadoop,分析与挖掘,轻度汇总表,明细数据,整合数据,应用层模型,明细数据,轻度汇总,1、Oracle作为Teradata的主要数据来源，负责对原始数据进行清洗整合，并生成轻度汇总表。之后将清洗整合后的数据送给TD做汇总处理。 2、报表分为两类，明细报表主要从Oracle产生，汇总报表则来源于TD数据仓库。 好处：1、综合利用Oracle的OLTP处理优势和TD的OLAP优势，分散处理，避免单一系统瓶颈。 2、可保证数据的一
6、致性。 3、用Automation统一维护和监控ETL过程。 4、最大限度保留已有的脚本和程序，保护投资，减少重复工作量。,明细报表,汇总报表,* 参考了电信IT体系中的ODS系统,需要考虑的几个关键问题(2/2),3、怎样保证基础建设和应用开发的平衡？ 分阶段实施，以应用触发，在开发的过程中逐步将数据仓库架构、模型体系、ETL开发和维护流程、MSTR开发流程等框架搭建起来，后续再通过新应用将数据不断完善起来。即不专门花时间做基础建设，而是在应用开发过程中将基础建设工作同步完成。 对于模型，想法是先将所有数据抽取到STG层，后续在根据需求逐步分主题设计实体模型和汇总表等。,需要考虑的几个关键问
7、题(2/2),4、模型该怎样设计？,STG 抽取的原始数据,ODS/STG 清洗整合,DW 面向应用的模型,TMP 存放临时数据,VIEW 供访问的视图库,1、分层次的模型体系便于管理和维护。 2、对原始数据进行清洗和整合。 3、分主题建模型。 4、DW层采用维度建模。 5、对于维表设计，考虑同时使用当前表和历史拉链表的形式。大部分情况下直接使用当前表即可，少数情况下需要进行历史分析时使用拉链表。,对于BI认识的两个误区,BI是一个完整的体系,架构规划的实例,如何分阶段实施,关于数据质量的思考,在原来基础上1个多月完成体系框架搭建,共同讨论完成体系架构的规划,完成模型体系和产品、销售主体模型设
8、计,ETL流程、开发和维护机制的建立,MSTR开发出第一个可用的报表和DASHBOARD,基础框架和流程已确定,团队成员慢慢熟悉流程,可以开发更多地应用了,8.31,近几周分别关注的重点,完成ETL流程的整理和调试,7.25-7.29,产品模型设计及新品动销的MSTR报表,财务DASHBOARD的重新设计及上线,8.1-8.5,8.8-8.12,其他报表的迁移,8.15-8.31,每个阶段重点关注某一方面的事情。,Teradata服务器能否到位的影响,Automation安装,抽数测试,定时任务测试,作业配置,模型上线,脚本核查,数据核查,报表开发测试上线,模型上线,脚本及数据核查,界面美化调
9、整,报表开发测试上线,对于BI认识的两个误区,BI是一个完整的体系,架构规划的实例,如何分分阶段实施,关于数据质量的思考,数据质量对于分析的意义,这一部分算凑数的吧。 看到一个微博说做分析时不要太纠结于数据质量，从某种意义上来讲是有道理的，一些小的数据问题不影响大的趋势，以及分析结论。 但个人认为做BI还是要把数据整合、数据模型、数据质量这些基础工作做好。如前所述BI是涉及从报表、KPI到分析、挖掘的完整体系，数据问题必然影响大家对数据仓库使用的信心，乃至整个决策的正确性。同时在大趋势分析时小的数据质量问题是不影响分析结论，但细致分析时可能就是某个小问题恰好能反映背后的故事。 所以作为整个企业
10、的BI来讲，还是从一开始就把数据质量考虑好，否则真就是那句话“rubbish in，rubbish out”了。,不要过度将BI神化,好像现在大家都在说BI，也很关注BI了。 甚至跟数据没啥关系的也都扯上BI分析，其实完全没必要。 我一直认为BI的理念是好的，让大家认识到数据的价值，遵循数据说话、科学决策的思想。但要说通过BI一下子让企业竞争力提升，超越竞争对手是不可能；只能是逐步实施BI的过程提升大家决策的科学性，同时改进生产环节的细节问题，增强管理的规范程度。只能锦上添花，不能雪中送炭。 而且真正要把BI做好也是不容易的，既要考虑做好基础性工作，又要考虑业务的需求，还需要进行长远地规划，最重要的是能够使BI的数据结果能够应用到日常生产中，所有的分析、挖掘都是为企业运营服务的，单纯为了BI而BI，没有任何意义。,END Thanks！,