2.电子商务BI中的基础思考.ppt

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