1、 外文翻译 原文 Enterprise Data Management in Mixed Workload Environments Material Source: Proceedings of 2009 IEEE the 16th International Conference on Industrial Engineering and Engineering Management Author: Jens Krueger Enterprise applications are presently built on a 20year old data management infrast
2、ructure that was designed to meet a specific set of requirements for OLTP systems. In the meantime, enterprise applications have become more sophisticated, data set sizes have increased, requirements on the freshness of input data have been strengthened, and the time allotted for completing business
3、 processes has been reduced. To meet these challenges, enterprise applications have become increasingly complicated to make up for short-comings in the data management infrastructure. This paper outlines the characteristics of enterprise application with regards to the underlying data management lay
4、er. We also propose a database design perfectly fit to the demanded requirements of enterprise applications. Nowadays, enterprise applications for large and mid-size companies are subject to tied conditions. Rarely any company can manage daily business and offer its services at a certain level of qu
5、ality without the extensive use of comprehensive software systems throughout all departments of the company. enterprise applications are presently built on a 20-year old data management infrastructure that was designed to meet certain set of requirements for transaction processing systems. In the me
6、antime, enterprise applications have become more sophisticated, addressing for example legal regulations, governmental compliance, new accounting principles, and global supply chains. In addition, data set sizes have increased, requirements on the freshness of input data have been strengthened, and
7、the time allotted for completing business processes has been reduced. To meet these challenges, enterprise applications have become increasingly complicated to make up for shortcomings in the data management infrastructure. These complications increase the total cost of ownership of the applications
8、 and make them harder to use. Companies like SAP offer standard software solutions for a wide range of different industries and application domains. It is a fact that the system landscape in most companies is very heterogeneous. Different operating-and database systems have to be taken into account
9、when developing enterprise applications for a wide range of potential customers. Often, the decision to choose a certain database, operating system or the combination of both is of political or historical origin leading to a mismatch of the data management with regards to actual requirements of the
10、applications. The extended life cycle of enterprise applications with evolutionary changes corroborates this effect as well. The remainder of this paper is structured as follows: Firstly, section II will address the requirements for data management derived from enterprise applications such as the mi
11、xed workload. Also, the results of analyzing customer data will be described. Then in section III database technologies, which impact the data management for enterprise applications will be reviewed. Consequently, section IV points out the feasibility and improvements of applying those technologies
12、in combination. Section V surveys the related work conducted in this area. Finally, a conclusion will be provided in section VI. This section presents issues to concern about when looking at requirements for enterprise application specific data management. A. Mixed Workload In the context of enterpr
13、ise data management database systems are classified being optimized either for online transaction processing (OLTP) or online analytical processing (OLAP). In fact, enterprise applications today are primarily focused on the day-to-day transaction processing needed to run the business while the analy
14、tical processing necessary to understand and manage the business is added on after the fact. In contrast to this classification, single applications such as Available-To-Promise (ATP) or Demand Planning exist, which cannot be exclusively referred to one or the other workload category. These applicat
15、ion initiate a mixed workload in terms of that they process small sets of transactional data at a time including write operations and simple read queries as well as complex, unpredictable mostly-read operations on large sets of data with a projectivity on just a few columns. Having a mixed workload
16、is nothing new and has been analyzed on database level a decade ago by French-the insight that it is originated by a single application is new. Given this and the fact that databases are either build for OLTP or OLAP, it is evident that there is no database management system that adequately addresse
17、s the needed characteristics for these complex enterprise applications. For example, within sales order processing systems, the decision of being able to deliver the product at the requested time relies on the ATP check. The execution of this results in a confirmation for the sales order containing
18、information about the product quantity and the delivery date. Consequently, the checking operation leads to a database request summing up all available resources in the context of the specific product. Apparently, materialized aggregates could be seen as one solution to tackle the expensive operatio
19、n of on-the-fly aggregation. However, they fail in processing real-time order rescheduling due to incoming high priority orders leading to a reallocation of all products. Considering this operation as essential part of the present ATP application encompasses characteristics of analytical workloads w
20、ith regards to low selectivity and low projectivity as well as aggregation functionality is used and read-only queries are executed. Along the afore mentioned check operation the write operations to declare products as promised to customers work on fine-granular transactional level. While looking at
21、 the characteristics of these write operations it is obvious that they belong to the OLTP category. B. The Mismatch The afore mentioned, simplified example of a complex enterprise application shows workload characteristics, which match with those associated with OLTP and OLAP. As a consequence, nowa
22、days database management systems cannot fulfill the requirements of specific enterprise applications since they are optimized for one or the other category leading to a mismatch of enterprise applications regarding the underlying data management layer. Mainly because conventional RDMBSs cannot execu
23、te certain important complex operations in a timely manner. While this problem is widely recognized for analytical applications, it also pertains to sophisticated transactional applications. To meet this issue, enterprise applications have become increasingly complicated to make up for shortcomings
24、in the data management infrastructure. One of these solutions packaging the operations as long-running batch jobs. Consequently, this approach slows down the rate at which business processes can be completed, possibly exceeding external requirements. Maintaining pre-computed, materialized results of
25、 the operations are another solution. Materialized views in data warehouses for analytical applications are an example of this approach, which makes applications less flexible, harder to use, and more expensive to maintain. To address this mixed workload the database management layer has to be aware
26、 of this fact and optimized towards these contradicting workloads by leveraging nowadays advances in hardware such as the availability of huge amounts of main memory. Additionally and presented by Schaffner et al. in, recent trends in data management, like storing data in a column-wise fashion and l
27、ight-weight compression algorithms, support the feasibility of building a enterprise application specific data management layer. C. Data Characteristics Give the mixed workload characteristics, data managements systems optimized for analytic-style queries seem to be the best match. However, fast rec
28、onstruction of complete tuples is still an essential requirement of OLTP workloads. While ERP data schemas consist of very wide relations due to inherent complexity this operation can be expensive. For example, in a large enterprise system the accounting document has 98 attributes while the correspo
29、nding line item contains 301 attributes. Consequently, in order to make an assumption of whether a row-or column-oriented oriented database is better suited for an ERP system, the usage of each attribute of a table is explored. The main focus in this evaluation are the distinct values of each column
30、. While taking the most common applications in enterprises, the financial accounting and sales order processing have been analyzed. It is assumed that the type of data characteristics and structure can be applied to other application domains as well. Traditionally, enterprise applications store thei
31、r data in a conventional RDBMS. These originated from the System R in the 1970s. In order to fulfill the requirements of OLTP applications these days row-oriented database management systems were developed. There the data is organized logically and physically in tables containing rows. Each table re
32、presents all entities of a certain type and each row represents a single entity where the specific columns represent attributes of each entity. Given the fact, that most of the described data access characteristics of OLTP applications are accessing a full relation and storage is assumed as disk-bas
33、ed this storage layout is preferable. A. Column Database While conventional RDMBS store data in a row-wise fashion, which has advantages for OLTP applications, this physical data representation is not optimized for read-mostly, analytic-style queries where typically only a few columns are projected.
34、 Following the trend of specialized database data management system have been developed organizing data along columns. While the logical data layout still remains as before, meaning that the data is still organized in tables, the physical layout now differs from this. 译文 企业数据管理的混合工作负载环境 资料来源 : 2009
35、年国立清华大学第 16 届工业工程与工程管理国际会议 作者： Jens Krueger 目前企业应用程序 仍然 建立在二十年旧的数据管理基础架构 之上 ，旨在满足 OLTP 系统 具体 要求 的各项 措施 的实施 。在此期间，企业应用变得更加复杂，数据集大小的增加，对输入数据的 更新速度和及时性 的要求也得到了加强 ，而且分配用于 完成业务流程的时间 也要 减少。为了迎接这些挑战，企业 对 应用 系统的要求 日益复杂， 对 短期的数据管理基础 的 设施 有了更多的需求和要求 。本文概述了企业应用方面的特点，对基础数据的管理层。我们也提出了一 种 数据库 模式 ，设计 尽量接近完备 ， 更 适合
36、 现代 企业应用所 需求 的 目标 。 如今，大型和中型公司的企 业应用程序都受到 很多 条件 的束缚 。很少有公司 在功能不完备的应用系统软件提供的服务下，能管理好公司日常业务并同时也使得公司各个部门也能被提供良好的服务水平 。目前企业应用 基本 建立在一个 20 岁 左右 的数据管理架构 之上 ，旨在满足对某些事务处理系统的要求 而 设置的 。在此期间，企业应用变得更加复杂，例如法律法规，政府规定，新会计准则，与全球供应链解决。此外，数据集大小的增加，对输入数据的 及时性和更新速度 的要求也得到了加强，并 且给予 完成业务流程 而 分配的时间 却大大的 减少 了 。为了迎接这些挑战，企业
37、对 应用 的需求 日益复杂，使 得 数据管理 基础设施 显得尤为 不足。这些 问题的日益尖锐 并发 的使得另外附加的信息数据更加难以处理 ，使 整个数据管理变得复杂而难以统一 。如 SAP 公司提供的 在 不同行业和应用领域广泛 应用 ， 统一 标准的软件解决方案。这是一个事实 证明 ，在大多数公司 里 系统环境是很不均匀 的 。 不同的操作系统和数据库系统都必须考虑到会 不会 有更广泛的 潜在 的使用者将会在 企业 里 应用 到 它们 。通常情况下，决定选择某个特定数据库，操作系统或两者的结合， 是政治或历史渊源导致了 它们与数据管理方面的应用程序的实际需要 的 不匹配 ，不能及时更新的情况
38、 。 面 对企业应用与发展变化的生命周期 延长，以及证实这种效果 发生的情况 。本文的其余部分的结构如下： 第一，第二节将处理从企业得到 系统 应用 效果的详情，如数据管理在 混合工作负载 情况下 的 应用 要求。此外，客户 所提供的 数据 进行分析以得到 结果 而进一步进行 说明。然后，在第三节 关于 数据库技术 说明时 ，阐述此技术对 企业应用数据管理 的巨大影响并 将 其在企业中应用的结果 进行审查。因此，第四部分 针对之前提出 的可行性和应用 到的相关 技术的改进相结合进行论述 。第五节调查这方面的工作进行 情况 。最后，结论将 在 第六节 总结得出。 本节 所介绍 ， 是 关注于 发
39、现和研究 企业应用程序 对于 数据管理 特定的 要求。 1 混合工作负载环境 在企业数据管理数据库系统的范围内优化要么被归类为在线交易处理 要么就是 联机分析处理。 而 事实上，今天的企业应用主要集中在 广泛的 营运所需的日常 交易业务 上 ，同时 需要处理一些简单 的分析，了解 日常运营情况 和管理 日常 业务，增加对 日后总结 加工的事实 材料 。与此 不同 的分类 方法 ，如单个应用程序 可以给企业提供或者承受的 供承诺量 而得出的 需求规划， 就 完全 不能 称为是一个或者一系列合理的 工作量分类 方法 。 这些应用程序在启动方面的混合 应用 而产生的共同的 工作量 和传递共享 过程中
40、 产生 的小数据集，包括 的操作主要是对一些少量 简短的输入数据的输入读取 和查询 ， 以及 对一些更为 复杂 的 不可预测的 大量数据集的重点 阅读与 分析，尤其是对这项工作的时间控制 。 然而 是否 真的 存在类似 新的混合工作负载 状况 呢？利用 法国 十年前数据库技术来进行观察推测证明， 它 是独特单一 的应用 系统全新的 起源。鉴于这点， 在实际操作中不论在 建立数据库 时是应用 OLTP 还是 OLAP， 显然 没有 相关的 数据库管理系统 能 完全 解决这些复杂的 功能 。例如，在销售订单处理系统 中 ， 要求在 固定时间 内 提供产品 ， 而做出的 相关的 决策 需要 依赖于
41、ATP 检查 系统 。 在一个 完整的销售 流程中应该包含 产品质量和交货日期 等 信息 来确认 订单执行 的 结果 。 因此，检查 相关系统 操作 而对 数据库 发出 请求 的情况可以 总结 出不同的 产品 所需要的 所有可用的资源 和资料 。显然，物化总量 算法 可以作为一种解决方案 用以对付 以上类似的 的 需要 即时 进行集中程度高涉及成本高 的操作。然而， 他们未必 能在 实时 处理订单 时 重新 考虑 安排 新传入 的 高优 顺序 而 导致了所有产品 需要重新分配 的情况 。考虑到这一行动作为本 ATP 的应用程序的必要组成部分 并 包括 了 与有关 负荷低 ， 选择性 低， 投射
42、 低的 分析工作的 特性 ，以及聚集功能的使用 性 和只读查询被执行 时的特性 。除了前述各种有关检查操作提到的 输入 操作需要 为 向客户承诺 详细 事务 型的 工作产品 说明 。 然而只要从 这些 输入 操作的特征 区别 ，很明显，他们 是 属于 OLTP 类别 的 。 2 不匹配 性 之前述说了各种相关的系统工作特性，其中有 提到 系统 简化了复杂的企业应用 需要更多的 实例 数据来 表明工作量 的 特点，这 是对 OLTP 和 OLAP 不同特性进行的 相关 比较 。 然而 ， 对于 现在的数据库管理系统不能满足企业应用的具体要求 这一情况 ，因为他们 本身也 是其中的一个类别，导致企
43、业应用管理方面的基础数据层优化 工作有了不能与系统相匹配的情况 。主要 的原因归结到底 是因为传统的 关系型数据库 不能及时执行某些重要 的复杂 操作。 这个问题 不仅仅在分析应用中 被广泛认可 和统一意见 ， 同时因为 它也涉及到复杂的事务处理 ，所以在 应用 关系层也被时常关注着 。 由此可见 ，企业应用日益复杂，使 得 数据管理基础设施 渐渐力不从心，难以满足 企业的 需求 。 其中 一种封包数据 ，只 需要运行批处理作业的操作方案。因此，这种方法 减少 了在 某些 业务流程 内部 就可以完成 而对 外部 业务流程需求的可能性和必要性 。 而用 来 维护 计划预算了的物化的业务 流程的过
44、程 则 需要 另一种解决方案。在 数据 库 仓储 物化视图 管理时的 分析应用 就是 利用了相同 的方法，它使应用程序灵活 度下降 ， 成为 难以 调节利用的模板 ， 并且需要 更 昂贵的维护。为了解决这种混合层的工作量 大而难以管理的情况 ， 在进行 数据库管理 时就 必须意识到这一事实，并通过利用时下 先进技术 ，如 提供大量的更新并改进了的主内存和硬件来解决缓解 这些矛盾 实现对 工作负载 的进一步 优化。此外， 同时 提出由夏弗纳等 人 在 数据库管理方面的最新 研究成果 的趋势 也是一种 明智的时尚 行为，用重量轻存储数据压缩算法来支持建立一个企业应用程序 ，使更有针对性的数据管理的
45、产生有了 可能 性。 3 数据的特点 对于 混合工作负载 的 特性，数据管理人员解析式的查询 和 优化系统 的方式似乎是 与之 最佳匹配 的 。然而， 快速及时的重建 完整元 组 数据 仍是 OLTP 工作负载的基本要求。虽然 ERP 数据模式非常广泛的 被应用 ， 但是 由于 系统应用中存在 固有的复杂性 较高的技术部分， 此 改进更新 操作可能 需要 很昂贵 的代价 。例如，在大型企业制度 下编排 的会计凭证属性 时 ，同时有 98 个项目， 包含 了相应细分项目属性 301 个 。因此，按行或列导向型 的 数据库 的建立需要 利用 ERP系统 ， 用于 实际 比较 贴 合 的模拟方式对
46、每 张 表的 属性和 使用 进行 探讨。在 这种时候 重点 需要放在 每个列的重复值 上 。 在 企业 业务中财务会计和销售订单的处理分析显然是 最常见的应用 。 这是假设固定了数据的特点和结构类型时可以应用到其 他应用领域的情况。传统的企业应用程序在传统关系型数据库 存储 数据的方式 源自 20 世纪 70 年代 。为了满足 当时的 OLTP 应用程序的行式数据库管理系统开发的要求。有数据的组织逻辑上和物理行的表中包含。每个表代表了某些类型的所有实体，每行代表 了 一个实体 ，而相对应的 特定的 那 列代表 了 每个实体的属性。 所有与以上描述类似 的数据访问特性 与 大多数 的 OLTP 应用程序 相匹配，由此不难看出 一个完整 的系统关系的数据 存储是基于磁盘的存储布局 的 。 在常规 关系型数据库管理系统中列出 行 是正确 的， OLTP 应用程序存储数据的优势 也在此 ，物理数据 的 主要 读取 方式 是 分解式 ，通常只有几列 预测内 的查询 行为 。 目前 专业数据库数据管理系统的发展趋势 延续了之前已经存在的 数据组织 方式的模式 。逻辑数据布局不变， 数据 有 组织 性 ， 但是 现在的物理布局 不仅限 于此。存储模式 改进 为分解存储模型 和垂直分布存储 。
