简介面向Oracle数据库、数据仓库与商业智能领域的技术人员这份PPT资源系统讲解Oracle商务智能完整解决方案的架构和核心组件内容覆盖BIEE前端分析平台、Essbase多维OLAP引擎、ODI数据整合工具及GoldenGate实时同步工具并结合典型场景说明各组件如何协同支撑企业级数据分析与决策有助于读者理解从数据获取、信息管理、语义层到信息展现的完整链路。资源为单个PPTX演示文稿大小约10.15MB共1个文件图文并茂便于直接阅读已有150人学习下载。内容从整体架构切入分层讲解数据获取层、信息管理层、商务智能语意层、信息展现层和数据仓库的作用同时重点展开ODI的E-LT架构、事件驱动CDC捕获、声明式设计、知识模块等特性Essbase高性能多维分析与前端展示以及GoldenGate实时同步异构数据的能力可帮助技术选型、方案设计或入门学习快速建立全景认知。 这份PPT讲的是Oracle商务智能全家桶——BIEE、Essbase、ODI、GG四个产品组合在一起怎样搭一套完整的数据分析平台。我做BI项目这么多年四个组件分开见的不少真正捏合成一套的也见过一些。这篇就按我实际做项目踩过的坑和总结的经验把这套组合掰开揉碎聊一聊。1. 为什么是这四个组件从数据采到数据看的一条完整链路很多人一听到Oracle商务智能解决方案第一反应就是BIEE做报表。确实BIEE在这个体系里名气最大但你要是真在项目里只用BIEE会发现很多事情根本做不顺。这套方案的完整形态其实是四个组件各管一段拼起来才是全链路。1.1 四个组件的真实分工先给它们一个清晰的角色定位ODIOracle Data Integrator负责数据抽取、清洗、转换、加载。就是ETL工具但它的ELT思想跟传统ETL不太一样下文细说。GGGoldenGate负责实时数据同步。源库产生的增量日志通过GG实时传到目标端延迟通常在秒级。这就是为什么银行、电信这类对时效性要求极高的系统GG几乎是标配。Essbase这是一个多维数据库专治复杂预算、预测、分摊这类需要高性能计算和灵活回写的场景。它的核心优势是写回这个BIEE做不到。BIEEOracle Business Intelligence Enterprise Edition负责最终的分析、报表、仪表盘展示。它有一个核心中间层RPD逻辑模型在这层统一管理报表层只用拖拽就能出结果。这四个组件的衔接逻辑很清晰ODI做批量的清洗入库GG做实时的增量同步Essbase承接复杂计算场景BIEE提供最终的分析展示入口。没有ODI和GGBIEE和Essbase就成了无源之水没有BIEE前面做再多数据也看不到价值。1.2 为什么ODI采用ELT架构而不是传统ETLODI跟Informatica、DataStage这些传统工具最大的区别在于它不做数据搬家式的处理而是把转换逻辑下推到目标数据库里执行。传统ETL是先把数据抽到自己引擎里转完再装进目标库。数据量大起来中间引擎就成了瓶颈得不断堆机器。ODI的ELT则是把抽和加分开——抽取阶段只做数据移动加载阶段用SET语句把转换逻辑推给Oracle、MySQL这些目标库自身的计算能力去跑。在我经手的项目里同样的转换逻辑用ODI的ELT方式比传统ETL至少省掉一台ETL服务器的采购和运维成本。因为它并不需要大规模的数据处理引擎目标库本身就干了几乎所有重活。2. 数据流向的三种模式批量、增量、实时不能混为一谈搭这套方案第一步要把数据流向理清楚否则后面全是坑。流向上我一般拆成三块来设计批量历史加载、增量日志同步、实时事件推送。2.1 ODIMasterODI CDC的组合节奏批量的活全部交给ODI。最标准的做法是接口表落地数据然后ODI做清洗映射最后加载到数仓的ODS层。这里有个非常容易踩的坑ODI自带的CDCChange Data Capture机制本质上是靠数据库触发器和日志表实现的性能损耗很重。你如果拿它同步高并发的生产表很容易拖垮源库。我见过有项目拿ODI CDC同步订单表结果源库夜间的批处理从1小时变成4小时业务方直接炸了。所以我的建议是ODI主要负责日批、月批这种偏重批量的场景。至于增量如果量不大、时效性要求不高可以开CDC但凡表大、并发高就别用CDC交给GG来做时效性翻倍不说对源库也更友好。2.2 GG最适合的是日志级实时同步GG的强项是从Oracle redo log里直接解析增量不侵入业务表。它的核心机制是部署Extract进程读取源库日志通过Trail文件传输再由Replicat进程在目标端回放。这种机制的优点非常突出对源库性能影响小延迟控制在秒级。而且GG支持异构同步从Oracle导到MySQL、Kafka都可以。实践里我要特别强调一个点GG同步的链路调优最关键的是Trail文件的大小和抽取进程的并发度。Trail文件设太小频繁切换会拖慢抽取速率设太大出现网络闪断时恢复时间又变长。我一般会把Trail文件设成500M左右然后根据源端事务量动态调整Extract的RMTTRAIL参数这样在稳定性和实时性之间能取得一个比较理想的平衡。2.3 实时同步之后还有一个准实时加工问题很多项目GG同步做完了以为实时这块就算搞定。其实GG只解决了数据到达的实时性数据到了目标端后怎么加工、怎么聚合一样要时间。所以在设计里我通常把GG的落地库再挂一层ODI的微批任务——每5分钟或15分钟跑一次增量加工。这样报表看到的虽然不是毫秒级的实时但对大多数经营分析场景来说十几分钟以内的数据新鲜度已经足够了。而且这种架构能省下大量耗时耗力的纯流式计算节点。3. Essbase在什么场景下不得不加进来BIEE自己就是做OLAP分析的那Essbase还有必要存在吗说实话如果你只是做普通的看板、报表、多维拖拽分析BIEE足够了。但一旦涉及到三类特殊场景Essbase的价值就立刻暴露无疑。3.1 预算和回写场景财务部门做年度预算最基本的一个动作是先按去年的实际数拆到每个部门、每个月份各负责人调整后报数最后财务汇总、对比、分析。问题在于负责人调整这个动作。BIEE在分析展示上行但写回非常受限制。Essbase天然支持用户在数据块上直接修改改完立刻能重新计算父级汇总。这种交互体验用BIEE做不了本质上是两个产品的设计理念决定的。实际项目里我更倾向于这样的分工BIEE只提供Essbase的数据分析和展示入口写回的操作直接用Essbase Smart View在Excel里完成。这样财务人员完全不用学新系统直接在熟悉的Excel里做预算改完进BI看分析体验最顺畅。3.2 复杂分摊计算场景集团利润分摊、成本中心分摊、管理费用分摊——这些算起来极其麻烦。总部的费用要怎么按人头、按面积、按收入权重分到各个子公司一条分摊规则可能牵扯十几个维度。Essbase的计算引擎用MDX和计算脚本Calc Script来处理这种多维度分摊。你在Calc Script里定义好分摊逻辑一次计算几百万个数据块几分钟跑完。换成SQL在关系库里做性能往往差一个数量级。3.3 Essbase和BIEE最容易被忽视的语义层对齐很多项目Essbase也上了BIEE也上了但两边各做各的没有通过统一语义层对齐出来的数据对不上。规范的架构是BIEE的RPD模型里建一个指向Essbase的连接让Essbase作为BIEE的一个多维数据源。维度的组合同步对齐后用户拖拽报表时BIEE才真正把查询下发到Essbase执行拿到结果再做展示。这里有个非常关键的优化点对于Essbase源尽量把维度的选择下推到Essbase端去过滤不要让BIEE把全部数据拉回来再筛选。否则一次跨年的季度分析数据量巨大性能能把你卡到怀疑人生。4. BIEE的RPD模型设计一道分水岭BIEE是个好工具但用得好不好90%取决于RPD模型建得好不好。很多团队BIEE报表出得慢、数据对不上根源都在RPD上。4.1 物理层、业务层、展现层必须分离清楚RPD里三层结构——物理层、业务层、展现层很多新手喜欢把三层揉在一层里玩结果模型改一处报表全崩。我习惯的做法是物理层只管建连接三张表就是一种映射关系关注的是怎么从底层取数。业务层是核心所有指标Measure的计算逻辑在这层定义。比如销售额、成本、利润在这层把公式固化报表层只用拖拽不准改公式。展现层只做维度和指标的摆放按部门、按角色分文件夹控制可见性。这样设计最大的好处是业务口径变了只在业务层改一处所有引用该指标的报表全部生效不会出现改了十张报表漏了第十一张的情况。4.2 维度建模的坑不要照搬数据库表结构这是我见过最多人栽跟头的地方。数仓的物理表可能按星型、雪花型设计但BIEE的RPD建模要按分析思维来。比如日期维度物理上可能就是一张date表带日期字段但RPD里我会建三套时间维度签约日期、开票日期、交付日期分别映射到不同的字段。这样用户在报表里就能同时按签约时间和开票时间做对比分析。还有层次结构的坑。比如组织架构物理表是统一的部门表但上级部门和下级部门其实是同一棵树。RPD里做一个递归关联数据才能在上钻下钻时顺畅。4.3 聚合表是个润物细无声的优化数据量到千万级以上RPD里不加聚合表策略报表响应时间就撑不住了。BIEE有一套聚合导航Aggregate Navigation机制你提前建好按月、按季度的汇总表在RPD里注册后用户查季度数据系统自动路由到季度聚合表查月度明细才走明细表。这个优化策略只要配置得当我对用户的承诺是报表打开速度能快一个数量级。5. 真实落地中的坑和解决链路项目做多了你会发现方案设计是一回事落地踩坑又是另一回事。这里挑几个频率最高的问题说下我的解决套路。5.1 GG与BIEE的时序矛盾用GG实时同步完数据BIEE报表却查不到。这是必然的——BIEE的缓存机制会让它在第一次查询后把结果集缓存起来。GG同步的新数据没触发缓存失效报表当然不更新。解决链路在ODI的微批任务跑完后同步触发一个BIEE的缓存刷新动作。用BIEE的nqcmd命令定期执行一个刷新查询或者直接调用PurgeCache API。这样数据一到缓存立即失效重查陈旧数据的问题就解决了。5.2 ODI的CDC和GG的打架问题有的项目贪心同一张表既开了ODI CDC又挂了GG结果两边同时写目标表出现重复数据。解决建议同一张表只选一条同步链路。有GG的系统把ODI CDC关掉没有GG的场景才考虑ODI CDC。架构设计阶段就把这个原则定死后面少很多扯皮的事。5.3 Essbase计算脚本的性能陷阱Essbase Calc Script里最容易出问题的是每维度都写FIX这种方法论。有人担心漏算把每个维都FIX一遍结果计算时间呈指数级上升。Essbase的计算引擎按数据块Data Block组织数据。优化的核心是先用FIX缩定稀疏维度让计算落在一个更小的数据块范围内密集维度就交给引擎全量跑。这个原则对了百万级数据块的计算时间能从30分钟降到3分钟。5.4 版本兼容性问题比想象中更隐蔽Oracle产品的版本兼容不能只看产品版本号一定要看Matrix文档。比如ODI 12c配GG 12c没问题但ODI 12.2.1连GG 12.2.0.1的某些版本会遇到驱动不兼容的问题。BIEE 11g跟Essbase 11.1.2.4的接口是有条件的支持组合。这些细节不查官方兼容矩阵真的上线了才发现连不上项目工期直接被拖垮。我现在的项目启动前第一时间做两件事第一把自己要用的产品版本全部列出来逐一到官方文档站核对兼容矩阵第二先在测试环境按真实的版本组合完整走通一遍全流程不然后面正式环境出问题排查成本高好几倍。6. 拆开看如果不想四个组件全上怎么取舍不是每个企业都需要全套方案不同阶段选不同组件是合理的。我给过一些客户做瘦身版的方案按需取舍6.1 小微企业BIEE单打独斗数据量几百万以内报表需求以日常看数为主一个BIEE视图能解决大部分问题。ODI可以用Oracle自带的SQL*Loader、外部表替代GG也不需要考虑。这个阶段核心是先把数看明白复杂度尽量往后放。6.2 中型企业BIEE ODI有数仓、有ETL需求、有T1报表但预算有限。ODI做日批数据加工BIEE做分析展示这是性价比最高的一档。实时需求少数场景可以用ODI的定时增量任务勉强达到分钟级也能接受。6.3 大型企业或金融级客户BIEE Essbase ODI GG这类企业的特征是有实时风控或运营报表需求、预算体系复杂、数据量及并发高。这时候四个组件全部上场才可能满足业务方的期望。GG保障实时同步ODI负责批量加工Essbase处理预算和复杂算法BIEE输出统一分析交互。各就各位各司其职。7. 我能给的几条落地建议讲完数据和原理结合我自己的实施经验再补几条具体的落地建议先建模后建报表任何BI项目都要先花八成时间把数据模型、指标口径理清楚。模型不对报表都是空中楼阁你后面会一直疲于改报表。元数据管理从第一天做起ODI的映射、GG的同步配置、RPD的指标定义、Essbase的计算规则全部要落到文档和统一的元数据管理工具里。很多人用ODI习惯了边写边忘后期数据审计时根本说不清楚这个数的来源逻辑这是一个隐患非常大的问题。备份策略要单独设计RPD和Essbase的App不能跟普通数据库一样只做数据库备份要单独按版本导出一份RPD文件、Essbase的.app离线备份。这样即使某个版本改坏了也能快速回到上一个稳定版本。性能测试不能只用样本数据我见过数仓数据量几百万时报表秒开一上生产到了几千万直接超时。因为RPD的聚合策略和Essbase的数据块密度都需要在真实数据量下才能验证。发布前一定要用生产量级的数据做一轮完整的性能压测。那套方案的四个产品每一个拎出来都有很长的话题可以聊。但组合起来看真正的价值在于数据从采集到加工、再到多维分析和展示每个环节都有合适的工具各管一段。如果你正在规划一套Oracle体系下的数据分析平台或者手里已经有其中一两套产品、还在纠结要不要补齐其他部分希望这篇能给你一点参考。至少少走点弯路总是好的。本文还有配套的精品资源点击获取