Essbase - 简单介绍

Essbase产品的体系结构

维（Dimensions）和成员（Members）是商业智能中重要概念，理解了维和成员，将有助于理解多维数据库的威力。维代表了你的商业计划组件的 核心，一般和部门的功能相关，有代表性的维时间、帐目，产品线、市场和部门等等。维一般是静态的，一旦定义好数据库的维后，在应用的生命周期里一般都不会 改变。

成员是一个维的单独的组件，例如ProductA、Product B、Product C是Product的成员。每个成员有一个独一无二的名字，一个维可以包括无限多个成员。多维性是OLAP的关键属性，系统必须提供对数据分析的多维视图 和分析，包括对层次维和多重层次维和完全支持，事实上，多维分析是分析企业数据最有效的方法，是OLAP的灵魂。

（1）在层次结构（Hicrarchies）里安排维所有的Essbase database应用都以定义一个database outline开始。

一个database outline：

·在一个Essbase database里定义成员之间的结构关系。
·组织在数据库里的数据。
·在成员之间定义聚合及数学关系。

Essbase用成员表示数据的层次关系。每一个维包括许多成员，顺序地，成员也可以包括许多成员。例如时间维包括四个季度，每个季度又包括三个月。

Essbase不限制每个维的成员的数目，可以定义很少的成员，也可以定义成百上千的成员一切都根据需要。

（2）成员关系（Member Relationships），代（Gencrlations）和层（Levels）

Essbase用层次，家族来描述一个Outline里成员的角色和关系描述梅一个成员的位置通过以下几个途径：

·父亲（Parents）、孩子（Chileren）和兄弟（Sibling）。父亲是一个有分支的成员，如Marging是Soles和cost of goods Scld的父亲。一个孩子是一个有父亲的成员，如sales，costof goods scld是Margin的孩子。一个兄弟是指一个和其它成员在同一个分支里的孩子成员，如sales和cost of goods scld是兄弟。

·子孙（Descendants）和祖先（Ancestors）：子孙是在父亲下的所有成员，例如Profit、Invenory、Ratos是 Measures的子孙，它们的孩子也是Measures的子孙。祖先是一个分支里在一个成员上面的所有成员，例如Magin和Profit是Sales 的祖先。

·根（Root) 和叶(Leaves) :根是指在一个分支里的第一个成员，例如Measures是Prodift、Inventory它们的根。叶成员是没有孩子的成员，如Adcitions是叶结点。

·层（Levels）和代（Generlations）：代是从根节点到叶节点；层是从叶节点开始一直到根。

（3）多维数据的执行动作：有上钻、下转、切片、切块、旋转等。
Essbase的基础结构原理

3.1 稀硫维（Sparse Dimensions）和密集维（Dense Dimensions）

大多数多维数据应用集有以下特征：

·数据不是平滑的而是随机分布；
·数据有可能不存在多数成员组合中，如有所有的产品不一定在国家的每一地区都销售。

Essbase将应用的维分为两种：衡疏维和密集维，通过这样，Essbase可以取得最优化的性能，存取空间最小，速度最快。

稀疏维是指一个具有很低的数据填允率的维如市场维和产品选择稀疏维，因为不是每一样产品在所有的市场都销售一个密集维是指一个具有很高的数据填充率的维。如Measures维选择为稠密维，因为Accounts里几乎填满了数据。

3.2 数据块（Data Block）和索引系统（Index System）

Essbase用两种内在的结构来存储和访问数据：数据块和索引。

Essbase为稀疏维（至少包括一个数据值）成员的独一无二的联合建立一个数据块，数据决也描述了所有密集维的成员。

Essbase为每一个数据块建立一个索引入口。

每一个独一无二的数据值在数据块里以一个数据格子的形式存在。当Essbase搜寻一个数据值时，它用索引定位数据块，用数据值定位格子。索引入口提供了一个数据块的指针，索引处理稀疏维特别有效，因为它仅仅是已存在的数据块的一个指针而已。

每一个数据块都是一个多维数组，它包括了固定的、有序的定位，为密集维成员之间的可能的联合，它不通过索引搜寻数据，它的存取和访问速度几乎是瞬间的。Essbase在数据块里定义数据格的顺序是通过你的outline database里密集的成员的顺序。

在定义outlined atabase是选择一个维是稀疏维还是密集维时，要根据需要来定。当全为稀疏维时索引多，查找慢；全为密集维时定义了许多空的数据格子，浪费资源，要根据情况而定。

HW - DELL OptiPlex 755 存储系统配置

zz: http://hi.baidu.com/chgel

1、Q35概述
该型号PC采用了 Intel Q35 Express 芯片组。
2、ICH9（Intel I/O Control HUB 9）
ICH9的技术细节及其参数请参考
http://download.intel.com/design/chipsets/datashts/31697202.pdf

ICH9 提供四个版本
• Intel® 82801IB ICH9 (ICH9)
• Intel® 82801IR ICH9 RAID (ICH9R)
• Intel® 82801IH ICH9 Digital Home (ICH9DH)
• Intel® 82801IO ICH9 Digital Office (ICH9DO)

3、DELL OptiPlex 755 存储系统配置
存储控制功能就是所谓的ICH9R (I/O Control Hub 9) 提供。
ICHR9 提供最多6个SATA借口，支持AHCI，并支持多种RAID.
AHCI Operation (Advanced Host Controller Interface (AHCI)串行ATA高级主控接口

AHCI 模式
AHCI通过包含一个PCI BAR（基址寄存器），来实现原生SATA功能。由于AHCI统一接口的研发成功，使得支持串行ATA产品的开发工作大为简化，操作系统和设备制造商省去 了单独开发接口的工作，取而代之的是直接在统一接口上进行操作，可以实现包括NCQ（Native Command Queuing）在内的诸多功能。

一直以来SCSI硬盘在多任务负载下的表现能力为人称道，其根本的原因除了SCSI接口惊人的接口速率外，便是它的指令排序功能。以往的 PATA、SATA硬盘也正是因为缺少一种指令优化执行功能而在性能上落后于SCSI硬盘。针对这一困境，Intel的AHCI 1.0规范首次引入的NCQ（Native Command Qu），它的应用能够大幅度减少硬盘无用的寻道次数和数据查找时间，这样就能显著增强多任务情况下硬盘的性能。


AHCI defines transactions between the SATA controller and software and enables
advanced performance and usability with SATA. Platforms supporting AHCI may take
advantage of performance features such as no master/slave designation for SATA
devices—each device is treated as a master—and hardware assisted native command
queuing. AHCI also provides usability enhancements such as Hot-Plug. AHCI requires
appropriate software support (e.g., an AHCI driver) and for some features, hardware
support in the SATA device or additional platform hardware.

ATA模式

将SATA硬盘映射到系统的IDE通道上，故又称兼容模式

如果是ICH9R芯片组，启用RAID后，还可以支持下列模式
RAID AHCI 模式
RAID ATA 模式

Comment:
AHCI，RAID 需要软件的支持。vista, CentOS/Redhat 5.1等版本已经内置支持。其他系统需要安装驱动程序。
如果客户没有最新的XP光盘（已集成SATA AHCI驱动）， 但是却想使用硬盘AHCI的功能怎么办？
support1.ap.dell.com/cn/zh/forum/thread.asp

J2EE - Ioc模式(又称DI：Dependency Injection 依赖注射)

板桥里人 http://www.jdon.com 2004/01/31

分离关注（ Separation of Concerns : SOC）是Ioc模式和AOP产生最原始动力，通过功能分解可得到关注点，这些关注可以是 组件Components, 方面Aspects或服务Services。

　　从GoF设计模式中，我们已经习惯一种思维编程方式：Interface Driven Design 接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：

　　AInterface a = new AInterfaceImp();

　　AInterfaceImp是接口AInterface的一个子类，Ioc模式可以延缓接口的实现，根据需要实现，有个比喻：接口如同空的模型套，在必要时，需要向模型套注射石膏，这样才能成为一个模型实体，因此，我们将人为控制接口的实现成为“注射”。

　 　Ioc英文为 Inversion of Control，即反转模式，这里有著名的好莱坞理论：你呆着别动，到时我会找你。后被Martin Fowler改名为 Dependency Injection 依赖注射，也就是将类之间的关系通过第三方进行注射，不需要类自己去解决调用关系。

　 　其实Ioc模式也是解决调用者和被调用者之间的一种关系，上述AInterface实现语句表明当前是在调用被调用者AInterfaceImp，由于 被调用者名称写入了调用者的代码中，这产生了一个接口实现的原罪：彼此联系，调用者和被调用者有紧密联系，在UML中是用依赖 Dependency 表示。

　　但是这种依赖在分离关注的思维下是不可忍耐的，必须切割，实现调用者和被调用者解耦，新的Ioc模式 Dependency Injection 模式由此产生了， Dependency Injection模式是依赖注射的意思，也就是将依赖先剥离，然后在适当时候再注射进入。

Ioc模式（Dependency Injection模式）有三种：

第一种类型	从JNDI或ServiceManager等获得被调用者，这里类似ServiceLocator模式。	1. EJB/J2EE 2. Avalon（Apache的一个复杂使用不多的项目）
第二种类型	使用JavaBeans的setter方法	1. Spring Framework, 2. WebWork/XWork
第三种类型	在构造方法中实现依赖	1. PicoContainer, 2. HiveMind

　　有过EJB开发经验的人都知道，每个EJB的调用都需要通过JNDI寻找到工厂性质的Home接口，在我的教程EJB是什么章节中，我也是从依赖和工厂模式角度来阐述EJB的使用。

　　在通常传统情况下，为了实现调用者和被调用者解耦，分离，一般是通过工厂模式实现的，下面将通过比较工厂模式和Ioc模式不同，加深理解Ioc模式。

工厂模式和Ioc

　　假设有两个类B 和 C：B作为调用者，C是被调用者，在B代码中存在对C的调用：

public class B{ 　　 private C comp; 　　...... }

　　实现comp实例有两种途径：单态工厂模式和Ioc。

工厂模式实现如下：

public class B{ 　　 private C comp; 　　private final static MyFactory myFactory = MyFactory.getInstance(); 　　public B(){ 　　　　this.comp = myFactory.createInstanceOfC(); 　　} 　　 public void someMethod(){ 　　　　this.comp.sayHello(); 　 } 　　...... }

特点：

• 每次运行时，MyFactory可根据配置文件XML中定义的C子类实现，通过createInstanceOfC()生成C的具体实例。

使用Ioc依赖性注射( Dependency Injection )实现Picocontainer如下，B类如同通常POJO类，如下：

public class B{ 　　 private C comp; 　　public B(C comp){ 　　　　this.comp = comp; 　　 } 　　 public void someMethod(){ 　　　　this.comp.sayHello(); 　　 } 　　...... }

假设C接口/类有有一个具体实现CImp类。当客户端调用B时，使用下列代码：

public class client{ 　　 public static void main( String[] args ) { 　　　　DefaultPicoContainer container = new DefaultPicoContainer(); 　　　　container.registerComponentImplementation(CImp.class); 　　　　container.registerComponentImplementation(B.class); 　　　　B b = (B) container.getComponentInstance(B.class); 　　　　b.someMethod(); 　　 } }

　　因此，当客户端调用B时，分别使用工厂模式和Ioc有不同的特点和区别：

　　主要区别体现在B类的代码，如果使用Ioc，在B类代码中将不需要嵌入任何工厂模式等的代码，因为这些工厂模式其实还是与C有些间接的联系，这样，使用Ioc彻底解耦了B和C之间的联系。

　　使用Ioc带来的代价是：需要在客户端或其它某处进行B和C之间联系的组装。

　　所以，Ioc并没有消除B和C之间这样的联系，只是转移了这种联系。
　　这种联系转移实际也是一种分离关注，它的影响巨大，它提供了AOP实现的可能。

Ioc和AOP

　　AOP我们已经知道是一种面向切面的编程方式，由于Ioc解放自由了B类，而且可以向B类实现注射C类具体实现，如果把B类想像成运行时的横向动作，无疑注入C类子类就是AOP中的一种Advice，如下图：

　　通过下列代码说明如何使用Picocontainer实现AOP，该例程主要实现是记录logger功能，通过Picocontainer可以使用简单一行，使所有的应用类的记录功能激活。

首先编制一个记录接口：

public interface Logging { 　　public void enableLogging(Log log); }

有一个LogSwitcher类，主要用来激活具体应用中的记录功能：

import org.apache.commons.logging.Log; public class LogSwitcher { 　 protected Log m_log; 　 public void enableLogging(Log log) { 　　　　m_log = log; 　　　　m_log.info("Logging Enabled"); 　　} }

一般的普通应用JavaBeans都可以继承这个类，假设PicoUserManager是一个用户管理类，代码如下：

public class PicoUserManager extends LogSwitcher { 　　..... //用户管理功能 } public class PicoXXXX1Manager extends LogSwitcher { 　　..... //业务功能 } public class PicoXXXX2Manager extends LogSwitcher { 　　..... //业务功能 }

注意LogSwitcher中Log实例是由外界赋予的，也就是说即将被外界注射进入，下面看看使用Picocontainer是如何注射Log的具体实例的。

DefaultPicoContainer container = new DefaultPicoContainer(); container.registerComponentImplementation(PicoUserManager.class); container.registerComponentImplementation(PicoXXXX1Manager.class); container.registerComponentImplementation(PicoXXXX2Manager.class); ..... Logging logging = (Logging) container.getComponentMulticaster(); logging.enableLogging(new SimpleLog("pico"));//激活log

　　由上代码可见，通过使用简单一行logging.enableLogging()方法使所有的应用类的记录功能激活。这是不是类似AOP的advice实现？

　　总之，使用Ioc模式，可以不管将来具体实现，完全在一个抽象层次进行描述和技术架构，因此，Ioc模式可以为容器、框架之类的软件实现提供了具体的实现手段，属于架构技术中一种重要的模式应用。J道的Jdon框架使用了Ioc模式，JiveJdon3.0是一个IOC/DI成熟应用。

DW - ETL的主要步骤

zt: ETL的主要步骤

ETL(Extract Transform Loading, 数据抽取转化装载规则)是负责完成是数据源数据向数据仓库数据的转化的过程。是实施数据仓库中最重要的步骤。可以形象的说，ETL的角色相当于砖石修葺成房子的过程。在数据仓库系统设计中最难的部分是用户需求分析和模型设计，那么工作量最大的就是ETL规则的设计和实施了，它要占到整个数据仓库设计工作量的60%-70%，甚至更多。
　　下面是本人对ETL的几个重要步骤理解，和大家分享！

一、ODS区的数据采集：　　最主要作用为了尽量减少对业务系统的影响。表结构可以不必和DW一致。根据具体业务需求和数据量情况，将数据源的数据放入ODS有各种不同的方法，比如Oracle的数据库链路，表复制，SQL*LOADER，Teradata的Fastload，Sysbase的BCP等等。

　　需要解决的问题包括：
a、数据的时间差异性问题
　　在抽取旧有数据时，要将不同时期的数据定义统一，较早的数据不够完整或不符合新系统的数据规范，一般可以根据规则，在存入中转区的过程中予以更新或补充。

b、数据的平台多样性问题
　　在抽取旧有数据时，大部分数据都可采用表复制方式直接导入数据中转区集中，再做处理，但有部分数据可能需要转换成文本文件或使用第三方工具如Informatica等装载入数据中转区。这部分数据主要是与数据中转区数据库平台不一致的数据库数据，或非存储于数据库内的文本、excel等数据。

c 、数据的不稳定性问题
　　对于重要信息的完整历史变更记录，在抽取时可以根据各时期的历史信息，在抽取需要信息等基本属性的旧有数据时，要与相应时段的信息关联得到真实的历史属性。

d 、数据的依赖性问题
　　旧有业务系统的数据关联一般已有约束保证，代码表和参照表等数据也比较准确，但仍有少量数据不完整，对这部分数据，需根据地税的需求采取清洗策略，保证数据仓库各事实表和维表之间的关联完整有效。
　　数据仓库各事实表和维表的初始装载顺序有先后关系，要有一个集中的数据装载任务顺序方案，确保初始数据装载的准确。这可以通过操作系统或第三方工具的任务调度机制来保证。

二、数据转换、清洗：
　　将ODS中的数据，按照数据仓库中数据存储结构进行合理的转换，转换步骤一般还要包含数据清洗的过程。数据清洗主要是针对源数据库中出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据数据进行统一的处理，一般包括如：NULL值处理，日期格式转换，数据类型转换等等。在清洗之前需要进行数据质量分析，以找出存在问题的数据，否则数据清洗将无从谈起。数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。

　　数据质量问题具体表现在以下几个方面：
a、正确性（Accuracy）：数据是否正确的表示了现实或可证实的来源?
b、完整性（Integrity）：数据之间的参照完整性是否存在或一致?
c、一致性（Consistency）：数据是否被一致的定义或理解?
d、完备性（Completeness）：所有需要的数据都存在吗?
e、有效性（Validity）：数据是否在企业定义的可接受的范围之内?
f、时效性（Timeliness）：数据在需要的时侯是有效的吗?
g、可获取性（Accessibility）：数据是否易于获取、易于理解和易于使用?

　　以下综合说明数据仓库中数据质量要求，包括格式、完整性要求。
a、业务描述统一，对数据模型的不同版本融合、映射为唯一版本。包括：
　　1、在业务逻辑没有变化的前提下，旧的业务数据映射在新模型上。
　　2、 遗留系统的人事信息、考核相关信息与业务系统、行政其他模块要一致。
b、信息描述规范、完整。
　　1、不存在格式违规
　数据类型不存在潜在错误。
　　2 、参照完整性未被破坏
　数据不会找不到参照。
　　3 、不存在交叉系统匹配违规，数据被很好集成
　相同的数据存在于多个系统中，数据之间要匹配。
　　4 、数据在内部一致
　同样的纪录字段在同一个表中重复出现，不能有差别。

　　以下是对主要数据质量问题的清洗策略：

主要问题	表现形式	产生原因	清洗策略
数据完整性问题	大量的空值字段的出现	原OLTP系统中对很多字段没有做非空限制	1. 交由OLTP系统重新录入, 补齐 2. 在数据仓库对应的维表中建立一个新的字段, 将这些空值字段的值统一的赋值
	超出字典表范围	填写这些值的时候是直接让用户填写而非下拉框选择	1. 交由OLTP系统重新录入, 补齐 2. 在数据仓库对应的维表中建立一个新的字段, 将这些空值字段的值统一的赋值
数据一致性问题	一个特定的字段在不同的表中内容不同	录入, 同步的问题	1. 选取最可靠的表中的字段为确定值
	应该成为主键的值不唯一	原OLTP系统中未建立有效的主键关系	1. 消除错误, 重复的主键

三、数据加载：
　　将转换和清洗完的数据按照数据仓库的结构进行数据加载。需要考虑初始数据装载、数据刷新、加载顺序等等问题。
　　a、针对数据现状，初始导入有这样一些问题需要考虑：
1、如何解决时间差异性？
2、如何解决平台差异性？
3、如何适应数据的不稳定性？
4、如何解决数据依赖性？

　　b、数据刷新的策略要根据业务需求和应用系统的承受能力和数据情况决定。主要有这样一些问题需要考虑：1、如何解决时间差异性？
2、如何适应数据的不稳定性？
3、如何解决平台差异性？
4、如何解决数据依赖性？
5、如何减少对业务系统的影响？

　　c、不同的刷新任务类型，对业务系统的影响不同，刷新任务有以下种归类特性：
1、刷新频率：
实时刷新、每数小时、每日、每周、每月、不定期手动刷新。

2、刷新方式：
数据库表复制、文本文件ftp再装载、物化视图、数据库trigger。

3、数据加工方式：
简单插入更新、增加计算项字段、多表关联更新、汇总、多表关联汇总计算。

　　并可针对各种异常情况做处理：回滚，重新装载，断点重新装载等等，还可在任务完成后（或失败后）将日志以Email方式发给数据仓库管理人员。
四、汇总层、CUBE加载：
　　ODS加载进入数据仓库的数据只是底层详细层数据，还需按定义的汇总规则进行汇总，生成数据集市用的汇总表或CUBE。ETL流程是指完成每个维表数据及事实表数据导入的顺序, 其包括两个部分, 初始导入数据时的ETL流程, 及增量导入时的ETL流程。

初始导入数据时的ETL流程
第一步: 自动生成维的数据装载
　　自动生成维一般来说就是日期，年度月份，年度等时间类维度（年度月份，年度其实都是日期维的一个层次，但某些事实表中没有日期信息，只有月份信息，所以需额外建立此二维度），几乎数据仓库中每个数据模型都需使用时间类维度，在加载其它维度和事实之前，需要先将时间维度生成出来。

第二步: 手工维护维度装载
　　实际数据仓库开发中，很可能会有些维度的数据在业务系统中无发得到，典型的是一些外部信息指表的类型代码，是由数据仓库开发人员设计的。所以需要手工方式建立这些信息，然后导入数据仓库。

第三步: 缓慢变化维表数据装载
　　这些维度可以从业务系统中找到来源，但变化比较缓慢。对于初始装载时，需要考虑对缓慢变化维的处理方式要和增量刷新方式一致。
　　在装载事实表数据之前，需要先装载这些维表。需要注意的是，有些维本身就是事实表，其所依赖的维必须先装载完成。

第四步: 事实表数据装载
　　然后是初始装载所有的事实表数据。事实表之间也有依赖关系，某些事实表需在其他事实表装载之前装载。（如果ETL程序已保障了数据的完整性，也可以在将关联约束禁用的情况下不考虑先后顺序，但一般不建议）。

第五步：聚合表初始生成
　　许多数据仓库的前端应用，并非直接使用主题星型模型中的事实表数据，而是聚合表中汇总，运算好的数据。（Oracle OLAP Service所建立的ROLAP 和数据集市实际上也是使用一系列的经过大量预先计算得到的聚合表）

增量导入
第一步: 缓慢变化维表数据装载
　　每天将所有变化过的维度信息刷新到数据仓库中，维表数据的刷新必须现于事实表。

第二步: 事实表数据装载阶段
　　每天新增事实数据的导入，如同初始化导入一样，需要考虑任务之间的先后顺序。

第三步: 数据汇总和聚合
　　根据设定的聚合规则和时间段对数据进行聚合。

第四步: 作业调度和异常情况处理


五、任务调度策略
驱动策略
前导Job驱动：只有满足另外一个JOB成功后，自己才运行。文件驱动：当下传的文件到达，并经过检验准确后JOB才运行。时间驱动：当到达某个时点时，Job便开始运行。事件驱动：如人工参与，导致JOB执行。
通知设计：重要信息（成功/失败）的通知
1、成功退出
　　分段提交方式，当分段提交的当次任务都正确完成，即Job运行状态临时表中登记的作业状态全部为完成时，退出ETL调度。
　　自动提交方式，当当期所有的任务都正确完成，即Job运行状态表中登记的作业状态全部为完成时，退出ETL调度。
2、失败退出
　　关键作业异常，关键作业运行异常时，影响剩下的作业不能运行时，则退出ETL调度。
　　超过ETL时限，当超过预先设定的ETL?时限时，退出ETL调度。
　　数据库异常，当不能正常操作数据库时，退出ETL调度。
　　操作系统异常，当发生操作系统异常，导致程序不能正常运行，如文件系统异常导致读写文件错时，需要退出ETL调度。

3、手工退出，需要人为干预ETL调度的时候，能以手工操作的方式退出ETL调度。作者：
Keith

DW - Introducing Oracle Data Integrator Enterprise Edition

Introducing Oracle Data Integrator Enterprise Edition

By dain.hansen on January 30, 2009 12:19 PM

Oracle has unveiled that it will now include both Oracle Data Integrator and Oracle Warehouse Builder Enterprise ETL, formerly an add-on option to Oracle Database, as the two components of Oracle Data Integrator Enterprise Edition (ODI-EE). Going forward, these products will merge into a single unified data integration technology platform. This strategy fully preserves any existing development investments of all Oracle data integration customers and will provide a seamless, easy upgrade path from the current components to the unified platform. Customers can safely choose either component as the basis for implementations today. More information is available on this Oracle Data Integration Statement of Direction.

You can continue to get fantastic amounts of detailed technical product information about either component of ODI-EE on our OTN pages: Oracle Warehouse Builder Enterprise ETL and here for more information on the Oracle Data Integrator.

I also encourage you to attend an upcoming webinar on February 9th, 9AM PST. Listen in on the cost savings benefits of Data Integration and real-world examples of Oracle Data Integrator Enterprise Edition in action. Register now for this upcoming webinar, tell us what you're doing with Oracle Data Integrator Enterprise Edition and participate in the conversation with us.

Recording to the webinar is now available here.