佛山建网站公司,成品网站源码1688自动跳转,佛山龙江做网站的,创建网站的软件什么梦1. 理解BW4HANA是干嘛的
好歹干了这么久的活了#xff0c;从当初的啥也不懂到现在感觉啥都知道点#xff0c;虽然知道的有限#xff0c;但是也不是小白。渐渐的也知道了SAP开发的一些逻辑。本来咱是想当个BW的大牛的。但是现在感觉这条船要沉了是怎么回事。个人才稍微摸到点…
1. 理解BW4HANA是干嘛的
好歹干了这么久的活了从当初的啥也不懂到现在感觉啥都知道点虽然知道的有限但是也不是小白。渐渐的也知道了SAP开发的一些逻辑。本来咱是想当个BW的大牛的。但是现在感觉这条船要沉了是怎么回事。个人才稍微摸到点门道项目整个都要黄了。现在通知说项目要撤了。啥都不说了。
不管以后干不干吧先把知识点总结下。也算给自己有个交代。
虽说BW的船要沉了但是我们做数据建模的我总认为业务对数据分析的需求得基于咱建模的人的熟练技巧咱得把数据给他提出来不管是做格式的调整比如简单的去除前导零重新格式日期做货币转换或者做数据join咱得把数据合并好整理好不是。不是说现在报表能基于数据库强大的功能直接从原始表出就不用建模了的。毕竟架构好数据集保留只需要的数据会极大增强报表性能。
合格的BW得懂数据库表视图函数存储过程。inner join, outer join, union, 星型结构。 必须得懂SQL。不仅要让你的数据无误还得让它高效快速的被整合计算出来。当然还得把数据授权玩明白。
同时也得不停的了解业务业务才是公司存在及发展的基础。
在看BW是什么之前先了解下SAP发展到现在它都有哪些个建模工具了以及分别怎么去部署他们。
SAP它是三层架构数据库层-应用层-前端展示层。部署的时候可能是在本地公有云私有云或者混合云上。
本地表示要自己安装软件维护硬件。
公有云在不独立拥有硬件和软件设施的情况下允许用户使用这些功能而且不用自己去定时更新因为公有云提供自动更新。
私云类似公有云就只是不和其他人一起分享。
混合就是本地和云上都有
以上这几种部署方式SAP都有涉及。
1. SAP HANA
数据库复杂建模工具套装 建在本地私有云公有云我们的HANA架在AWS上我觉得不如本地的打开和运算速度快。HANA建模就是从最底层数据库层开始鉴于HANA的多内存建模在这层数据处理起来非常快。这层主要用calculation view计算视图。计算视图可以搞过滤计算聚集join等等。还可以自己写SQL。
在计算视图往上可以快速集成到SACBW4AFOCrystal Reports等等。
2. BW4HANA
它是本地数据仓库解决方案。主要执行数据分析历史数据存数数据清洗和多数据源数据整合。当然私有云上也能部署。由于它现在底层数据库是HANA了那么HANA上建的计算视图可以直接拿过来混合建模用。咱知道BW本来的数据建模都是在应用层的。和HANA结合可以利用到HANA的强大性能。而且BW有很多预定义好的建模对象可以直接激活使用。建模工作现在是在BWMT里搞了复杂逻辑客制化需要用到的是ABAP代码。但是现在咱也知道BW4在HANA上线之后应用场景可能只有历史数据了。就是说现在需要做历史趋势分析啥的会需要把数据保存在BW里。其他场景的简单实时分析基本上是用不到BW了。BW本来也不好做实时分析的。对于历史数据主要是通过增量抽取。
3. SAP Datasphere
BW4的轻量级云上版本。公有云上的warehouse-as-a-service。
反正SAP就是要这么发展咱也不知道他们的策略。BW反正是干不到2040年。那咱就得还学别的这个SAP Datasphere我也研究了下虽然咱现在没用上。但是了解下总没坏处的。SAP它以后大概率要用Datasphere来代替BW的它提供了把BW4的建模包转移到Datasphere上的一系列工具。不论是谁潮流来的时候要么跟上要么被带上SAP这个也要紧跟潮流都往云上搞。和SAC一样这个Datasphere是架在SAP HANA Cloud上的。不同的租户相同的基础架构。
这个上面的整个建模逻辑其实和BW还是一脉相承的不过更加图形化更加简单。一些公式用到了Python。对于咱一窍不通Python的也要学学了。不学习的话不被潮流卷走咱就得被拍在沙滩上了。
不过我学了一遍所有功能之后发现其实它更简化版本的BW从某种程度上说它并不可能完全替代BW就像是主数据的层级导航属性等等一系列功能。我看都没有当然也许是我看的潦草没看到。。。最好的是这个轻量级的工具给业务人员自己去玩耍而实际的复杂模型仍然是在HANA或者BW4上。讲到这里又得插一嘴BW确实得精通业务知识。
SAP Datasphere的主要用户对象是两种人而且是两个建模层
1.业务人员用业务层直连底层数据层自己独立建模。主攻业务模型的优化。
2.专业建模人员从数据层建模。主攻数据提供和复杂逻辑的实现。
4. S/4HANA
S4支持本地公有云私有云混合部署。
S4内置分析抢了BW一半饭碗。只不过用的不是一种工具他们用的是虚拟数据模型Fiori。
和BW跟HANA不一样的是这个内置分析只能处理SAP ERP本身的数据不能整合其他数据源的数据了。虚拟数据模型主要是靠CDS View,直接在数据库表上架视图进行计算不需要冗余的保存到BW上在应用层搞来搞去了。不过S/4内置分析作为BW部分替代也是在应用层上搞的也就是说CDS view是在应用层上Fiori那肯定是前端的。靠这俩直接进行ERP系统的实时报表分析还用啥BW哦。
5. SAC
SAC踩着SAP Lumira的尸体看都不看一眼Xcelsius就昂首阔步的来了。它扛着BI的大旗发誓要把强大的分析预测企业计划都一揽子包圆。不过实际来看也就是换汤不换药能预测个啥
除了跟自己的SAP系列集成的好市场上也没有干过Power BI。它不是个数据建模工具只是个分析工具。不过它肯定要有点简单的建模工具箱的有时候这两把小刷子能给不需要复杂建模的小企业用的。它的主要功能就是个讲故事的在里面建story。跟一般的dashboard工具一样要图形化分析界面。
SAC是在SAP HANA Cloud数据库上跑的。但是是两个云租户只不过是云上用一套基础架构和资源。
要说到它的建模能力那主要就真的是两把刷子
第一把直连数据从本地或者云数据源连接数据表对于那种有安全权限考虑不能存在SAC上的。进行数据在线分析。
第二把数据导入也就是复制存储。原始数据源的数据更改不会反应到导入的数据上。
当然直接在SAC里数据建模的好处就是能在story和数据模型之间查看不需要再去其他系统看底层模型怎么架构的了。
6. BO Universe
用Information Design Tool来搞的我觉得其实SAP买的这个工具还不错的。也许很多后来SAP开发逻辑也是借鉴了BO的。Universe这个名字就起的很绝宇宙。在宇宙里关联所有数据源SAP的非SAP的都能在此关联。Query也能作为universe的源。Universe可以给BO这个大集团的一众报表工具使用WebI啦Crystal Reports啦。但是毕竟它很老了也许以后SAP也要给它搬到云上了。个人之言BO上的权限管控也是很有巧思的跟BW的权限各有妙法又有相似之处。
总结一下
公有云SAC、SAP Datasphere
本地BO
本地私有云BW4HANA
本地私有云公有云SAP HANA S/4 CDS 具体的上面的几种建模区别看我这一篇SAP提供的几种建模武器 1.1 BW到底是什么里面都有些什么
BW就是个数据仓库business warehouse 不管它这个翻译。实际上现在的BW4HANA就是个部署在本地或者私有云上的数据仓库。SAP说支持到2040年。但是它09年就上线了SAP Datasphere,之前叫SAP Data Warehouse cloud。数据仓库云作为一个公有云的数据仓库解决方案。这个咱也看过了有空来写一篇和BW集成的也挺好。我个人感觉上了S4HANA之后用SAP Datasphere就可以快速出报表了然后直接关联SAC一整套从数据到前端展现快速灵动。不过这个Datasphere的设计逻辑还是很多参照了BW的也就是那一套处理逻辑。暂时还有些功能也不能替代BW。
1.2 BW4HANA是架在什么框架上的整个架构是什么样的到底在数据分析框架的什么位置
BW4HANA和BW相比一个明显的就是架在HANA上了不和其他数据库玩了SAP是说以前在其他数据库上要考虑和他们的集成不好更新新版本用了自己的数据库想怎么更新怎么更新。利用了HANA数据库的特性。建模的对象更少了还能直接和HANA的计算视图结合。用Eclipse这个建模环境和Fiori的用户接口结合起来了要么就是在Eclipse里面拖拖拽拽写写代码要么就是在Fiori里面点点这个点点那个。
BW4HANA之前所有版本BW都是架在SAP NetWeaver上的现在是直接架在一个单独的ABAP应用服务器上的原先的集成在Netweaver组件的代码都被删掉了大概删了五百万条ABAP代码吧一些BW对象也被删掉了。只支持能用HANA数据库的对象了。不过用户管理和授权传输相关的和系统日志追踪啥的都还和以前一样。现在还能看到的组件都是一些基础组件了比如SAP_BASIS,SAP_ABA,SAP_UI... 1.3 HANA在BW里是个什么角色
整个BW4HANA里最重要的部分是数据仓库服务对数据建模抽取数据清洗整理计算都在这里。往上就是支持query的OLAP功能。包括对层级的处理货币转换的处理复杂逻辑的计算。
Content里面就是预定义好的一些建模对象可以拿过来直接用。源数据存储里面就是所有SAP开发的或者是客户自建的对象的目录。Workspace就是用户可以自己存储在这里进行使用的和其他的建模对象独立的一小块自开发空间。openhub用来导出数据到第三方。ODP用来导入SAP系统相关的源数据包括BW4HANA也属于这个SAP框架。 HANA给BW赋能的主要就是两个部分数据加载和报表性能的提升同时能存储巨量数据。
性能上多加了好几个内存和CPU。计算能力增强。告诉多核的CPU能处理更复杂的任务了还能同步处理加快反应时间。而且数据存储都直接放在内存上。不放硬盘上。 在数据处理方面。主要用列式存储压缩增量插入。
列式存储主要对query很友好。因为query只要几个属性。如果行存储去找要遍历所有行上的列。 BW4HANA所有的模型表都是列存储。
列式存储表由于能把列上相同的值给压缩了就会省好多空间。列属性值会进行排序和位编码列的位置上的值有重复的时候会压缩。大幅减少表占用空间。也就是说BW4HANA 能存储更多的数据。 而它在数据进行插入的时候还用了增量插入和压缩。
存储的位置给分成两块分别是主存储和增量存储。 因为列式存储是排序好压缩好了的比如ADSO每天的数据更新。数据进行更新的时候先进入Delta存储。因为那边主存储都是排序好了的压缩好了的列存储啊。你这个先进来。如果要更新到主存储得要再花一阵子时间来重新排序重新压缩。在此期间如果有读数据的操作呢那就从两个部分都出数据。如果还要继续写呢就从增量存储写进去。
一般我们都是在所有上下层的ADSO数据都更新好了在处理链的最后一步搞delta merge。
但是也有把这一步直接放在DTP步骤里的 想要了解具体的HANA的设计的The secret of SAP HANA – Pssst! Don’t tell anyone! | SAP Blogs
HANA的代码下移就是说原先我们是把数据库里的数据拿到应用服务器层进行计算把数据拿来拿去的。但是上了HANA之后只是把指令拿来而在数据库层直接进行计算。
应用服务器层现在主要处理协调和触发数据库内的比如激活ADSO压缩重建选择性删除请求管理数据分层等等的这些活了。还有就是来处理用户定义的开始结束专家例程啥的。AMDP。
HANA是把运算逻辑代码下推到数据库层最后把结果给展现层。不需要把数据带到应用服务器层的。所以它就能快速提升BW里好性能的一些数据处理活动。
比如说ETL的过程ADSO的激活Query的运行还有Planning的一些功能。
同时HANA上直接建的内存式数据模型-计算视图。它也很强大。BW里面的一些建模功能像权限配置啊货币转换啊HANA的计算视图都支持。还有些BW没有的高级排序内置SQL生成数据交集啥的。反正就是SQL有的它都拿来了。 1.4 BW4HANA的设计原理
BW的设计原理有四个
基于这四个原理差不多就能明白BW的初衷和目的。
1. 简单
减少了建模对象的类型和源系统的接口。
维护数据对象和数据量更简单了。
复杂的数据生命周期管理现在是基于多温度的数据概念了。也就是冷-暖-热数据的概念。 2.开放
BW4的模型可以直接开放成外部可用的HANA计算视图可以直接被SAC或其他的应用使用。 同时能和外部数据虚拟集成比如用SDA直接和外部数据库数据连接近乎实时连接数据。
对于云端数据源也能有集成方法。
3.现代化的用户接口
终端用户SAC、SAP BO
建模开发Eclipse里的BW Modeling Tools以及网页单端的BW4HANA Cockpit
管理员网页端的BW4HANA Cockpit不用GUI了
4. 高性能
计算和操作都下推到HANA。
能访问HANA的特定库。
1.5 架在BW4HANA上的BPC计划
现在是BPC2021了和BPC11.1的区别在于可以不用安装BPC组件就能在BW-IPIntegrated Planning上用Planning Application Kit(PAK)计划工具集。但是呢BPC的license还是得单独弄的。
也就是说呢如果你喜欢在本地上搞一个计划那么就可以直接用上了。但是SAP以后肯定是倾向于在SAC上搞计划的。 1.6 BW现在用什么工具做
现在用Eclipse里面的BW Modeling Tools.
还有BW Cockpit, 这个里面也有好多好玩的工具。在里面建处理链创建分析授权有一种现代感。
还能监控处理链修复处理链查看log。
对于数据量还能看到存储空间的使用率。
还能看到ADSO的请求管理啊删除激活请求。归档的请求。请求日志。
信息对象的内容请求等的。主数据展现层级维护query的预览都能行还能增强加一些条件例外啥的。
在上面多看看就熟悉了页面操作了。为彻底脱离GUI做准备。
你还可以加所有的APP。凡是你能找到的都能加上去 咱就是说还记啥Tcode。不过确实有点慢的。 2. BW4HANA中的建模武器库 2.1 InfoObject
第一信息对象。小兵将。哪里需要搬哪里的一块砖。
主要本领搞主数据管理。
地位如下 虽然说现在可以直接基于字段创建ADSO创建Open ODS View了。但是信息对象还是必不可少的。因为信息对象它是一个类似域Domain的概念。哪里都能用能被重复使用。相当于一个全局的可复用的一个单位能保证很多数据的一致性。 2.1.1 基本属性主数据、文本、层级 2.1.2 数据安全属性、计划功能
2.1.3 非累积特性
2.1.4 例外聚集
2.1.5 增强的主数据更新 现在我们建一个新信息对象可以看到属性里有几个新的功能
增强的主数据更新 Enhanced Master Data Update这个的使用场景就是比如你有很多个客户端要向这个主数据加载数据那我们还是一个一个按顺序的加载。并行加载数据是不行的。一般主数据加载我们还都是全量加载。主数据的增量抽取默认不支持的。
而且一般主数据的量都不大数据加载到属性表或者文本表之后就会立刻被激活了没有像ADSO那样需要单独激活的步骤。 那这个增强的主数据更新是干嘛的呢
当我设置了增强的主数据更新也就等于这个信息对象的更新模式变成了ADSO数据加载的过程中会需要激活这个操作了那就会额外多出入栈表激活表和日志表。更新主数据之后需要再来一个激活操作了。既然有了change log表 那就又说明你能在这个信息对象到另一个信息对象之间执行增量抽取的操作了。或者说从这个信息对象到另一个ADSO之中都可以执行增量操作了。
而且也能让你同步从多个数据源端加载数据了。
一旦设置了这个增强的主数据更新你就能看到好几个多出来的新表: 同时因为有了这个入栈表和日志表所以处理链处理的时候要加主数据的激活操作和日志表的删除操作 这个就是在主数据数据量特别大数据来源很多的情况下有用同步抽取更快点上层能执行增量抽取。但是由于还得多一步激活所以如果数据量不是很大的话也没必要搞这个。
而且这个增强的主数据更新只针对于属性和文本不适用于层级。
2.1.6 支持写接口的信息对象
在增强的主数据更新下还有一个写接口。这个是啥呢 这个只有你勾了增强的主数据更新之后才附加出来的一个功能。那么显然是和这个增强的主数据更新有关的。一般写接口的意思就是可以直接更新这个也是一样的。可以在没有数据源没有转换和DTP的情况下让你去直接更新入栈表。啥个意思呢
不是直接手写的意思这个写接口是说让你用一个工具像是SAP Data Services或者是SAP Cloud Platform Intergration(CPI)把数据推进去。同理也是只适用于文本和属性。
这个和ADSO的写接口不一样的。这个信息对象的写接口由于只适用于属性和文本所以它最多可以有两个入栈表就是针对属性和文本的请求的入栈表。
当设置了写接口之后就会发现多了几个URL 这些URL就是来调用写功能的属性和文本都有不同的URL。在function group RSO_PUSH里面能看到这些RFC的功能模块。这些和ADSO的写接口的功能模块是一样的。
只不过参数里面改了object_typeIOBJ/object_subtypeATTR/TEXT。
2.1.7 Odata服务
这个Odata就是说可以让你从外部网页去访问这个Infoobject。通过URIUniform resource identifier来直接访问。这个Odata我们用的多的还是在query上。 这个Odata也是比较有意思的架在ODATAV4网页协议标准上。勾了这个服务然后直接接活就可用了。但是这个Odata对信息对象有种种限制不能是参考特性必须得有属性不能只有文本不能有地理属性。而且Odata读不了层级。如果是时间相关的还得给个时间范围参数。
一般不用。
2.1.8 导航属性和转移属性
特性的属性就是用来描述这个特性的有时候属性还有自己的属性。比如业务伙伴有个国家来描述它国家又有首都这个属性。 这里能看到传递属性是true。我想看首都这个属性是可以通过维护转移属性来把它显示出来的。前提是country国家已经被加到属性里了 那么到这里其实有个问题了作为第二层的国家这个导航属性是可以作为一个独立的特性来在query里查看的。那么这个首都作为国家的传递属性可以也作为一个独立的特性在query里来使用么
答案是可以的因为它在这里就是被勾了作为导航属性。既然作为导航属性那它就可以用来聚集关键值了。其实这个转移属性也就这个应用场景。至于底层的原理就是HANA帮忙搞的了。
有一点就是导航属性要想在query里面用。这个query必须是得架在CP上的。不能是直接从ADSO出来的。只有在CP里才能enable ADSO里面的特性的导航属性。 除了在output的字段里按字段打开还能在senario 里点击ADSO里直接全部打开然后映射到output里 不过信息对象的导航属性虽然无法在ADSO里直接打开但是能用在转换里在规则look up里间接用上也就是说去找这个源字段的属性字段。 2.1.9 时间相关的导航属性
2.1.10 时间特性的导航属性
对于一些时间特性能直接在query里用上他们的导航属性了。 也就是说比如在ADSO里的条目是直接在日期这层上的那么用上日期的导航属性比如月季年。那query里能直接在这些高时间维度上聚集关键值。 2.2 ADSO 新的ADSO能有1000个字段包括字段和信息对象能有120个key。
2.2.1 简单来讲ADSO有四种类型 不同的选项决定了ADSO的功能。以及它里面的表。同时这些ADSO还会有一些附加的功能下下面的特殊属性里。比如说库存功能计划功能写接口功能。
1. 标准
使用的最广泛。主要就两种
1.1 有change log表
change log表就是存储更改变化的有了这个日志表就能看到所有的新加的删除的更改的记录。然后基于此表能往上出delta抽取。有了日志表也能对本身ADSO进行回滚也就是说删除已经激活了的请求。
所以一般一些比较重要的交易数据都用这个标准的有日志表的ADSO。 对于Snapshot快照。 就是如果你的数据源只支持full全量。那么选了快照就可以把从数据源那里删除掉的记录给更新过来要不然。上次存储的下次抽取的时候被源头删了。它还在ADSO就不对了。这个机制就是激活的时候系统会比对激活表里已经有的数据如果这条数据在入栈表里没有那就写到日志表里当成一个反转像。reverse image。再激活的时候就会相当于冲销一样给删掉了。
对于Unique Data Records。单一数据条目主要就是这条数据是没有重复值的。比如说非累积关键值的条目。激活的时候系统检查是不是还有重复条目如果已经有了这条主键了那激活就会被取消并且报错。整个流程就只有插入操作。所以比较快。
1.2 没有change log表
如果说不需要往上层增量抽取数据了那么就直接不要日志表。这种情况也支持单一数据条目。节省系统空间。 2.数据集
业务相关数据集。和infocube一样的。主要用来分析数据和出报表的。
这个ADSO里的所有除了关键值以外的特性都是主键。也就是说你这条记录如果有一个字段改了那么就会有一个新的组合主键生成就会有一个新的条目。不会有特性的更新或者删除所有的更改都会被动保留。
所有的关键值都只能被聚集不能被覆盖。激活的时候到激活表实际是被从入栈表复制过去并且按照聚集的方式来分组相当于压缩操作。此后数据从入栈表删除。没有日志表。
请求在未激活时可以删除激活后由于没有日志表所以是不能回滚的。
往上层的delta抽取是从入栈表出来的。在没激活的时候从入栈表增量提取。
全量和初始化抽取时从入栈表和激活表同时提取的。
报告是从入栈表和激活表组合抽取的。所以不激活入栈表也能看到所有的数据。 2.1 库存ADSO与非累积关键值
库存的ADSO会多出几个表
Validity Table: /BIC/A**4Reference Point Table: /BIC/A**5
添加了库存关键值信息对象后比如说是库存余额系统就会给你加一个新的页签Inventory.非累积关键值一添加自动会添加对应的更改关键值比如说inflow的和outflow的两个关键值进入的发出的。
同时会有两个附加的表生效表4表和参考点表5表。
参考点用来计算非累积关键值的是和日志表一起更新的。
所以说这个数据集的ADSO必须得有一个日志表。而且这个ADSO不支持字段只支持信息对象。
对于库存非累积场景还得看具体的介绍。
3.staging 分段
也就是在数据加载的第一层在inbound表里就需要进行对数据的协调处理或者和其他数据合并了。等于说是在PSA层进行数据的预处理。
选择只有入栈表由于没有激活表所以加载数据非常快。这个就适用于我想快速把大量数据拿过来。 当我想对大量数据基于一些我设置的语义主键进行压缩那我就选上compress data。 压缩过后入栈表会被删除能节省一大部分空间。由于没有日志表只能按需删除特定条目不能回滚删除。 如果选了允许报表有个不同点就是入栈表的数据不会被删掉依然会保留。也就是会有个冗余那么在激活表上可以出报表之后激活表数据删除了还能从入栈表重建。只有激活的表数据能用于报表。不过我觉得这个就只是用来快速查看分析下数据看数据对不对实际建模场景没有广泛使用。
4.直接更新
不需要再有激活的步骤。直接跳过了标准的加载流程中的激活步骤。也没有入栈表直接激活表。 可以直接建标准的转换和DTP来抽数或者通过API RSDSO_DU_WRITE_API / RSDSO_DU_WRITE_API_RFC: 从内表加载数据到激活表。 RSDSO_DU_DELETE_API_RFC: 删除激活表数据可以直接truncate或者选择性删除。 RSDSO_DU_CLEANUP_API_RFC: 删除出错的API请求如果有时候请求发红阻断下一个了那就用这个删除。
4.1 写接口 选择写接口能把数据转移到入栈表也就是PUSH进去。
2.2.2 ADSO中的表 1. inbound表
1表。未压缩表。里面有Request IDData Package,Record number, Record mode。
系统生成技术主键keyREQTSNDATAPAKIDRECORD
2. active表
2表。压缩表。里面有Key 字段1 Key 字段2...Record mode.
用户定义语义主键Key 字段1Key 字段2...
3. changelog表
3表。里面有Request IDData Package,Record number, Record mode。
系统生成技术主键keyREQTSNDATAPAKIDRECORD 除此之外还有6,7,8表
6表 提取视图
7表 报表视图
8表 外部SQL访问视图
由于1,2,3表是不允许外部直接访问的。所以SAP提供了一个8视图来给外部SQL访问。也就是说这样的话在分段ADSO的转换里就能用ABAP的例程或者是AMDP的SQL语法来执行查询操作了。一般我们在例程里也就搞个look-up。
为啥不允许直接访问? 因为ADSO上是有分析授权的。有些权限相关信息对象是用来限制访问权限的。如果开放给外部访问那这些设置岂不是没有意义了。
所以这个8视图有点像External SAP HANA SQL view,开放给外部去除了访问限制。
不过HANA计算视图是可以有访问限制的要配置参数的。
如果说看不到这个8视图重新激活下RSDG_ADSO_ACTIVATE 就可以了。 中间缺的4,5表在库存ADSO里。
9表是数据温度管理的例外更新。更新到外部冷存储里的。
2.2.3 SID的生成
代理键主要是雪花模型用来复用维度信息对象的。
在ADSO中一般是只保存特性的值不保存对应的SID。那么当进行query查询的时候系统就会在query运行时给每一个特性去按值join它的SID表。这样就会导致性能变慢了。如果你这个信息对象在报表内用的很频繁而且可能它有很多值俗称高基数那这种情况下我们就得考虑在ADSO表里给添加一个独立的行来保存SID键值。加快查询的速度不要让它去join了。 至于要不要保留SID键值用这个report来查看就行了SAP_ADSO_DESIGNS 2.2.4 ADSO重构 remodeling
重构也是比较有意思一般新加属性会在激活的时候自动要求重构。ADSO已经有数据了
其他情况下要替换属性也是要重构的。不过替换的话对这个特性有一些限制不能是参考特性啥啥啥的。 重构进行的操作主要就是为了能更快重新激活有大量数据的ADSO。基本上有对ADSO表的读或者写的修改都需要重构。必须对建模属性更改了从staging变成standard了对主键有更改了对planning的切片有更改了或者对数据分层有更改了等等。
重构的请求在RSMONITOR下面能看到。或者直接在网页上看。
重构的ADSO传输到另一个系统也会让你重构要不然激活不了。我一般传输后重构然后再重新传输一遍。
2.2.5 处理链中对ADSO数据加载的处理
触发增量合并把数据从增量存储空间转移到主存储空间。
drop data target删除ADSO的所有内容。
clean up DSO request从入栈表活日志表清除请求。对数据集ADSO还能删除激活表请求。 还有一些有用的管理ADSO的tcode:
RSOADSO:展示数据和数据模型检查激活管理数据条目写传输请求生成where-used列表。
RSDG_ADSO_ACTIVATE:激活ADSO修复一些模型定义中的小问题。
SAP_ADSO_DESIGNS分析ADSO大小计划清理活动。
RSDD_IPRO_KEYFIGURE_CONVERT 货币转换。 2.2.6 ADSO增量数据加载中的delta merge增量合并
由于列式存储主要对读取数据友好但是写入数据那就一塌糊涂了。所以内存式列式存储就给分配了两块空间一块是优化读取的主存储一块是优化写的增量存储。读的时候主存储和增量存储同时发力。写的时候数据库会来执行增量合并的操作。 增量合并就是来把增量存储里的更改转移到主存储里。首先执行一个异步检查看是否有必要进行增量合并。 如果存储阈值被超过了那就会在增量存储里执行一个合并。然后读取操作会从主内存和增量内存里进行结果是被合并过的。 一般是在处理链进行增量合并因为你可能有很多个更新到ADSO的DTP等所有DTP都更新完了之后一次性合并最好。
而且这个合并一定要搞因为HANA的增量存储空间也是每个分区只能20亿条数据如果不搞那数据读取的性能将变的很差。
2.2.7 ADSO中大数据量处理及数据库分区
对于那种ADSO里有巨量数据而且在不断增加的情况。急需要考虑管理数据增加了。
有哪些方式呢
索引附加索引不会减少数据量只是提高访问速度。主要索引会默认生成主要就是给组件特性生成的为了加快主数据表和ADSO之间的join速度。次级索引就是在你需要进行一个非常复杂的需要消耗性能的查询的时候你可以建。建索引当然是要消耗内存的还需要索引服务器的一些更新处理。只有在性能是在需要索引的时候才走这一步。
数据库分区高基数的会自动被分区。我们一般也会按照年份区域对ADSO数据进行分区。每个分区会自动获得20亿条的容量。也就是一个激活表分3个区那能存60亿条数据。 语义分区按照语义组分区也要考虑到。
数据生命周期管理按照数据重要性和访问频率来管理把不经常用到的老数据放到一个外部数据库上面SAPIQ啥的。这样就会导致HANA数据库上的数据量减少。
清理直接把不要的数据删除掉。
2.3 Open ODS View
2.4 Composite Providers
2.5 Semantic Groups
2.6 BAdI Provider
2.7 BW Query
3. 混合建模开发
3.1 在HANA上建Calculation view
3.2 在BW里使用Calculation view
3.3 在BW4HANA的模型上直接生成Calculation view
4. 跳出来看SAP提供的模型开发思路和可用的模板
4.1 LSA 架构
4.2 BW4HANA Content
5. 用ODP来加载数据
5.1 ODP 到底是啥
5.2 ODP-SAP Extractors
5.3 ODP-CDS View Extraction
5.4 BW Infoprovider Extraction
5.5 Calculation view Extraction
5.6 基于SLT的extraction
6. 用HANA把数据导出去
6.1 HANA的数据导出能力
6.2 怎么把HANA当成一个源系统
7. BW4HANA日常运维一个合格的BW运维人员要做啥
7.1 优化数据抽取
7.2 维护处理链
7.3 优化query运行
7.4 统计性数据分析 Statistical Analysis
7.5 授权
7.6 数据的生命周期管理
8. 从BW升级到BW4HANA
8.1 升级的方式选择
8.2 升级工具
