通过Techopedia Staff，2017年1月25日
总结：主持人Eric Kavanagh与来宾Robin Bloor博士，Dez Blanchfield和IDERA的Bill Ellis讨论了内存计算和SAP HANA。
您目前尚未登录。请登录或注册以观看视频。
埃里克·卡瓦那（Eric Kavanagh）：好的，女士们，先生们。 您好，欢迎再次回来。 现在是东部时间星期三凌晨四点，也就是最近几年，这意味着Hot Technologies再次到了。 是的，确实，我叫埃里克·卡瓦纳（Eric Kavanagh），我将主持您今天的对话。
伙计们，今天我们要谈论一些很酷的东西。 我们将深入内存世界，确切的名称是“进入未来：内存计算的入门”。这些天来非常流行，并且有充分的理由，主要是因为内存比依靠旋转磁盘快得多。 但是，挑战在于您必须重写许多软件。 因为当今的软件（大部分是软件）在编写时就已经考虑到磁盘问题，这确实改变了应用程序的体系结构。 如果将应用程序设计为等待旋转的磁盘，则所做的工作与拥有内存技术的所有功能不同。
确实有一个关于您的地方，在Twitter上打我，@ eric_kavanagh。 每当有人提到我时，我总是会尝试跟进并转发。
就像我说的，今天我们在谈论内存，特别是关于SAP HANA。 去年您真的花了很长时间才真正了解了SAP社区，我必须说这是一个迷人的环境。 向那些执行该操作并处于第一线的人致敬，因为SAP是一项非常出色的操作。 他们真正擅长的是做生意。 当然，他们在技术上也很擅长，并且他们确实对HANA投入了巨资。 实际上，我记得-大概是六，七年前-我们实际上是在为美国空军做一些工作，我们从SAP找来了一个人，让我们尽早了解了HANA和计划的内容。 至少可以说，SAP实验室的工作人员花了很多时间和精力来理解如何构建与传统环境完全不同的架构，因为您拥有所有的存储空间。 因此，他们正在谈论对同一内存数据进行事务和分析，而不是传统方法，即将其拉出并放入一个多维数据集，例如，在那里进行分析，然后再与事务进行分析。发生的方式非常不同。
坦白说，这是一个有趣的空间，我们实际上将向另一供应商IDERA寻求有关所有这些东西将如何工作以及入口的含义的一些信息。 因此，我们将听取The Bloor Group自己的首席分析师Robin Bloor博士的来信。 Dez Blanchfield是我们的数据科学家，后来是IDERA的好朋友Bill Ellis。 因此，我将把钥匙交给Robin Bloor博士，他将把它拿走。
Robin Bloor博士：是的，正如Eric所说的那样，SAP HANA最初向我们通报的时间是很多年前。 但这很有趣，特别的时间很有趣。 我们遇到了一家或两家以某种方式提供内存技术的公司。 很明显，内存将要到来。 直到SAP站起来并突然启动HANA才真正开始。 我的意思是，当我看到SAP这样做时，我感到非常震惊。 就像是震惊，因为我希望它来自其他地方。 我预料会是Microsoft或Oracle或IBM或类似的人。 SAP正在执行此操作的想法令我感到非常惊讶。 我想这不应该是因为SAP是战略供应商之一，而且您知道，行业中发生的大事几乎都来自其中之一。
无论如何，关于内存的全部要点是，我的意思是，我们意识到，我们曾经谈论过这一点，即一旦您真正进入内存，这并不是要在内存中存储数据，而是要提交给内存。内存层是系统记录的想法–一旦将系统记录迁移到内存，磁盘就开始成为一种切换介质，并且它变成另一种事物。 我认为那一开始就非常令人兴奋。 因此，实际上，旋转磁盘已经结束。 旋转盘很快将仅在博物馆中存在。 我不确定很快就会到来，但是基本上，固态磁盘现在处于摩尔定律曲线上，已经比他们现在所说的旋转铁锈快十倍，并且很快它还会更快并且那就意味着磁盘的用例越来越少。
奇怪的是，传统的DBMS，实际上，许多传统的软件都是为旋转磁盘构建的，它假定旋转磁盘。 它具有各种物理级别的功能，这些功能都经过精心编程，以利用旋转磁盘，从而使数据检索尽可能快。 所有这些都被冲走了。 只是消失了，你知道吗？ 然后，很明显，我想，这是非常有利可图的，但最终会赢利的是，这是一个内存数据库的开放，它试图占据Oracle，Microsoft和SQL等大型数据库的地位服务器和IBM的DB2占据了内存中的空间，看着它们前进并做到这一点非常有趣。
让我们谈谈内存级联； 值得一提。 这也是我提到此问题的原因，实际上是让所有人知道，当我在这里谈论内存时，我所谈论的所有这些层实际上都是内存。 但是您突然意识到，这是一个分层存储，而不仅仅是内存。 因此，很久很久以前我们学到的有关分层存储的几乎所有内容也都适用。 而且这还意味着任何内存数据库都必须通过它来导航，某些数据库只是在RAM本身上浏览它。 它变得越来越大，并且现在以兆字节为单位。 但是，您拥有的L1缓存比内存快一百倍，L2缓存比内存快30倍，而L3缓存比内存快10倍。 因此，您知道，有很多技术–相当数量的技术–已采用在执行事物的方式上将这些缓存用作某种存储空间的策略，尤其是数据库技术。 所以，这是一种影响。
然后我们出现了3D XPoint和IBM的PCM。 这几乎是RAM速度，基本上这两个供应商都在吹嘘。 用例可能有所不同。 与此相关的早期实验尚未完成。 我们不知道这将如何影响RAM的使用和内存数据库技术。 然后，您有了RAM与SSD。 目前，RAM的速度大约是300倍，但是，这种倍数正在减少。 如果我理解的话，SSD与磁盘的速度大约要快10倍。 因此，这就是您遇到的情况。 它是分层存储。 从另一种角度来看，内存当然是完全不同的。 因此，最上面的图显示了两个应用程序，它们两个都可能访问数据库，但肯定会访问旋转锈蚀的数据。 而实际上，让事物通过网络流动的方式（取决于周围的依赖性）是拥有ETL。 因此，这意味着，数据进入旋转的铁锈，然后脱离旋转的铁锈，以便到达任何地方，再到达任何地方，回到旋转的铁锈，这是三个动作。 请记住，内存的速度可能比旋转磁盘快十万倍，并且您当然会意识到，将数据存储到内存中会使整个事情变得截然不同。
因此，您可能以为会发生在此处屏幕上的内容，您可能以为ETL实际上会从数据到内存中的数据以某种方式发生。 但是实际上，它可能不会这样做。 实际上，您可能在这里的情况正确，其中两个应用程序实际上可以触发相同的内存。 只要您拥有锁定以及围绕它进行编排的所有其他功能，内存数据库当然可以为您提供该功能。 因此，这不仅会改变事物的速度，还会改变您实际配置应用程序和整个数据流的方式。
因此，这是一种巨大的影响。 因此，内存具有破坏性，对吗？ 我们应该从我所说的中得到答案。 内存中处理目前是一种加速器，但它将成为常态。 它会根据应用程序的价值进行使用和使用，因此，非常有趣的是，SAP实际上会推出其内存中的ERP软件版本。 延迟的提高完全有可能达到三个数量级，而实际上甚至更多，这取决于您的实现方式。 因此，通过进入内存，您的速度得到了极大的提高。 而结果是，SAP HANA的S / 4（他们已经发布了，我认为，人们认为它仍在发布，但肯定是在去年发布的）给SAP客户群带来了改变。 我的意思是，有10, 000家公司正在使用SAP的ERP，几乎所有的公司都是大公司。 因此，他们的想法都有动力进入内存并使用其基本知识，因为ERP几乎始终是企业正在运行的基本应用程序，它只是一个巨大的游戏规则改变者，它将非常有趣。 但是，当然，这一切听起来都很好，但是需要对其进行智能配置并对其进行良好的监视。 这并不像听起来那么简单。
话虽如此，我想我会把球传给谁，这个人是谁？ 哦，澳大利亚人Dez Blanchfield。
Dez Blanchfield：非常有趣。 罗宾·布洛尔博士（Robin Bloor）总是很艰难。 谢谢你今天有我。 因此，一个大话题，但令人兴奋。 因此，当我考虑现代数据湖和企业数据仓库以及我的少量数据宝藏时，我选择了一个经常想到的图像。 因此，在这里，我看到了这个美丽的湖，四面环山，波涛汹涌，而浪花正冲向这些岩石。 这就是我最近在脑海中如何可视化大数据湖中的外观的一种方式。 浪潮是批处理工作，而实时分析则是对数据的抛砖引玉。 当我将其视为一个物理湖泊时，它会带给我一个唤醒的声音，那就是，我们现在正在建立的数据仓库的规模，我们提出这一造币的理由以及数据湖是它们很大而且很深，有时候您可能会遇到暴风雨。 而当我们这样做时，您始终必须解决造成风暴的原因。
因此，以这件事为主题，在我看来，内存计算的警报确实是非常强大的，并且是有充分理由的。 它带来了许多重大的商业和技术收益。 这是另一天几个小时的讨论。 但是向内存计算的普遍转变，首先，我只想介绍一下我们如何到达这里以及如何实现这一点，因为它为某些挑战首先位于何处以及我们需要意识到的问题奠定了基础。想到，在我们的世界中，我们不再使用传统的旋转磁盘来保存数据，而是要在磁盘上进行页面调换，然后移入内存，然后从内存移出并移入CPU，直到现在，我们几乎要删除全部这些层之一是旋转磁盘。 因为请记住，在计算的早期，从体系结构上讲，我们很长一段时间都没有离开大型机或中型设备，而我们最初将其视为核心内存和鼓存储。
正如Robin Bloor博士所说，事实上，几十年来，我们在计算机体系结构中移动数据的方法并没有真正改变。 如果您考虑一下这样一个事实，那就是从技术上讲现代计算已经存在，如果您对双关语感到宽恕，您会知道它已经存在了60多年，甚至更多，而且从某种意义上说，您可以买一个现成的盒子。 当我们从大型机和中型机以及核心内存和鼓存储架构的思考转移到勇敢或超级计算（尤其是Seymour Cray之类的东西）时，我真正想到了向新架构的转变成为一件事。 如今，这已不仅仅是沿底板或母板移动数据的一种途径。 而且，内联内存在这些日子里，人们实际上并没有真正想到当他们说DIMM和SIMM时它实际上意味着什么。 但是，SIMM是单列直插式内存，而DIMM是双列直插式内存，自那以来我们变得更加复杂，并且有数十种用于不同事物的不同存储器类型：一些用于视频，一些仅用于一般应用程序，一些内置于CPU中。
因此，已经发生了巨大的变化，转向了一种新的数据存储和访问方式。 我们将在另一代人中经历同样的转变，但是在硬件本身上并没有那么多，而是在业务逻辑和数据逻辑层中采用硬件，这在我看来是另一个重大的范式转变。
但只是简要介绍一下我们如何到达这里。 我的意思是，硬件技术得到了改善，并且得到了极大改善。 我们从拥有CPU开始，核心的想法是一个相当现代的概念。 现在，我们的电话已经拥有两个或四个核心，而我们的计算机在台式机中具有两个或四个甚至八个核心，而在服务器平台中甚至还有16个和32个核心，我们认为这是理所当然的。 但这实际上是相当现代的事情，内核已成为CPU内部的功能，我们从32位变为64位。 那里发生了几件大事：我们在多个内核上获得了更高的时钟速度，因此我们可以并行执行操作，并且每个内核都可以运行多个线程。 突然之间，我们可以同时在同一数据上运行很多事情。 64位的地址间隔为我们提供了多达2 TB的RAM，这是一个了不起的概念，但是现在已经成为现实。 您知道，这些多路径背板架构是主板，从前，您只能朝一个方向做事：向前和向后。 与Cray计算和当时的一些超级计算机设计一样，现在也出现在台式计算机和常见的现成的台式机级台式PC中，因为实际上，大多数现代PC现在经历了大型机，中型微型台式机的时代，我们已经将它们重新变成了服务器。
超级计算机的许多功能和超级计算机级的设计被推入了通用的现成组件中。 如今，您已经知道了以下想法：将非常便宜的机架式PC放入数百甚至数千个机架中，并在其上运行开源软件（如Linux）并在其上部署SAP HANA之类的软件，知道，我们经常认为这是理所当然的。 但这是一件非常令人兴奋的事情，它具有复杂性。
软件也变得更好，特别是内存管理和数据分区。 我不会对此进行详细介绍，但是如果您查看过去15年左右（甚至更少）的重大变化，将如何管理内存，尤其是RAM中的数据以及RAM中的数据如何分区，因此，正如罗宾·布洛尔（Robin Bloor）博士先前指出或暗示的那样，您可以在不影响彼此的情况下同时进行读写操作，而不必等待时间。 许多非常强大的功能，例如片上压缩和加密。 加密正变得越来越重要，我们不必一定要在软件，RAM，CPU空间中进行加密，因为实际上加密实际上是在芯片上进行的。 这大大加快了速度。 再一次，分布式数据存储和处理，我们曾经假定的东西是超级计算机和并行处理的东西，现在我们把它视为在SAP HANA，Hadoop和Spark等空间中是理所当然的。
因此，整个要点就是这种高性能计算，HPC功能已经进入企业，现在企业正在享受性能收益，技术空间，技术收益和商业收益所带来的好处，因为您知道，缩短的实现价值的时间大大减少了。
但是，我使用的是我前段时间读到的一位绅士用Lego建造PC机箱的故事的图像，因为当我想到其中的某些东西时，总会想到它。 就是说，当您开始构建它时，这似乎是一个好主意，然后您完成了一半，您意识到将所有Lego块放在一起并制造出足够牢固的东西实际上是非常棘手的放入主板等，这将为个人计算机建立一个外壳。 最终，您意识到所有小片段并没有正确地粘合在一起，因此您必须谨慎一点，以使它们紧密结合在一起。 这是一个非常可爱的主意，但是当您走到一半时，这是一个警钟，您会意识到：“嗯，也许我应该买一台300美元的PC机壳，但我现在就完成并从中学到一些东西。”
对我来说，这可以很好地模拟构建这些非常复杂的平台的模样，因为构建它并在一个拥有路由器，交换机，服务器和机架的环境中最终是一件好事。 而且，您已经将CPU，RAM和操作系统集群在一起。 而且，您可以在其之上放置类似HANA之类的东西，以进行分布式内存处理，数据存储和数据管理。 在此基础上构建SAP堆栈，获得数据库功能，然后加载数据和业务逻辑，并开始对其应用一些读写和查询等等。 您必须掌握I / O的顶层，还必须安排事务，管理工作负载和多租户等。 这个堆栈变得非常复杂，很快。 如果仅在一台计算机上，那本身就是一个复杂的堆栈。 将其乘以16或32台机器，将变得非常非常平凡。 当您将成百上千台计算机（从100 TB扩展到PB规模）时，这是一个令人恐惧的概念，而这些正是我们现在要处理的现实。
因此，您最终遇到了几件事，这些事情也帮助改变了这个世界，那就是磁盘空间变得非常便宜。 您知道，曾几何时，您需要在千兆字节的硬盘上花费380至40万美元，而这是一个巨大的鼓，需要用叉车将其捡起。 如今，每千兆字节的商品磁盘空间已降至一美分或两美分。 RAM也做同样的事情。 顺便说一下，这两张图中的这两个J曲线分别是十年，所以换句话说，我们正在看两个10年的块，即20年的降价。 但是我将它们分成两个J曲线，因为最终右边的一个J曲线只是一条虚线，您看不到它的细节，因此我重新缩放了它。 20年前的1 GB RAM大约是六百五十万美元。 这些天来，如果您为通用硬件购买1GB的RAM花费三，四美元以上，就会被抢劫。
在过去的二十年中，价格的大幅下降意味着我们现在不仅可以扩展到磁盘空间，而且可以直接进入RAM，不仅可以达到兆字节级别，还可以达到TB级并将RAM像磁盘一样对待。 但是，这样做的挑战是RAM本身是临时的，这意味着它可以持续很短的时间-因此，我们必须想出办法为该空间提供恢复力。
因此，我的意思是内存计算不适合胆小者。 处理大量的内存数据及其周围的处理是一个有趣的挑战。 正如我之前指出的，这不是为胆小的人准备的。 因此，我们从大规模，高密度内存计算的经验中学到的一件事是，我们构建的复杂性在许多领域都会引发风险。
但是，让我们从监视和响应的角度来看它。 当我们想到数据时，它开始于磁盘空间，它位于磁盘中的数据库中，然后将其推入内存。 一旦将其存储在内存中并分发并且有副本，我们就可以使用它的许多副本，并且如果进行了任何更改，则可以在内存级别反映出来，而不必在两个不同的级别，它进出内存。 我们最终有了这个超大规模硬件平台，该平台使我们现在可以执行此操作。 当我们谈论超扩展时，在可笑的密集级别，超高密度的内存，CPU，核心和线程的超高密度计数方面，这将变得更加困难。 现在，我们已经拥有非常复杂的网络病理来支持这一点，因为如果数据要在节点和群集之间传递，则必须在某个时刻在整个网络上移动。
因此，最终导致设备故障冗余成为一个问题，我们必须监视设备及其部分。 我们必须在该平台中内置可恢复的数据故障冗余并对其进行监控。 我们必须内置分布式数据库弹性，因此我们必须监视数据库平台并在其中进行堆栈。 我们必须监视分布式处理调度，从轮询到查询一直在某些过程中发生的事情，查询所采用的路径以及查询的结构和执行方式。 它是什么样的？有人在“ blah”上执行了SELECT *吗？还是他们实际上做了一个非常聪明且结构合理的查询，将使他们从背板上的体系结构中获得名义上最少的数据？ 我们有多租户工作负载，多个用户和多个组运行相同或多个工作负载，批处理作业和实时调度。 而且，我们将批处理和实时处理结合在一起。 有些事情需要定期运行（每小时，每天，每周或每月），而另一些事情则按需运行。 可能有人坐在那里想通过平板电脑进行实时报告。
再说一遍，我们得出的结论是，这些问题带来的复杂性现在不仅是一个挑战，而且非常可怕。 而且我们进行了现实检查，发现单个性能问题本身就是一个性能问题，可以影响整个生态系统。 因此，我们最终面临着一个非常有趣的挑战，那就是要找出影响在哪里？ 我们面临的挑战是，我们是被动还是主动？ 我们是否在实时观察事物并看到事物“爆炸”并做出响应？ 还是我们已经看到某种形式的趋势并意识到我们需要积极参与其中？ 因为关键是每个人都想要快速，便宜，容易的东西。 但是，我们最终得到了这些场景，我想引用的内容以及我最喜欢的唐纳德·拉姆斯菲尔德难题（在我看来，这适用于所有这些高度复杂的场景），那就是，我们知道，因为那是事实我们设计和建造，并且按计划运行。 我们知道一些未知数，因为我们不知道谁在运行什么，何时何地以及是否按需运行。 而且我们有未知的未知数，这些都是我们需要监视和检查的东西。 众所周知，因为现实是您无法管理无法衡量的事情。
因此，要拥有合适的工具和合适的功能来监视我们的CPU调度，请寻找等待时间，找出为什么事情必须在管道的调度队列中等待。 内存中发生了什么，正在执行哪种利用率，我们从内存中获得什么样的性能？ 东西是否已正确分区，是否已分发，我们是否有足够的节点来保存它的副本以应付正在对其施加的工作量？ 在远离操作系统进程的情况下执行进程会发生什么情况？ 作业本身在运行，各个应用程序和支持它们的守护程序？ 这些流程内部发生了什么，特别是查询的结构以及如何执行和编译这些查询？ 这些进程的运行状况一直都在堆栈中吗？ 再次回到等待时间，是否正确调度，是否必须等待，在哪里等待，是否正在等待网络上的最终用户的内存读取，I / O，CPU，I / O ？
然后回到这一点，我在总结之前很快就提到了，那就是，我们如何处理问题的解决方案和响应时间？ 我们是实时观察并对事情做出反应吗？这是最不理想的情况，但是即使那样，我们还是比不知道并打电话给服务台打电话并说出了问题要好，我们必须对其进行跟踪？ 还是我们正在积极地进行这项工作，是否正在研究即将发生的事情？ 因此，换句话说，我们是否看到内存不足，需要添加更多节点？ 我们在进行趋势分析，在进行产能计划吗？ 在所有这一切中，我们是否要监视历史执行时间并考虑容量规划，还是实时监控并主动重新安排时间并进行负载平衡？ 并且我们是否知道最初运行的工作负载？ 我们知道集群中谁在做什么以及为什么吗？
内存中的计算功能非常强大，但有了这种功能，它几乎就是其中之一，例如，装有枪支，并且您正在玩实弹。 如果您不小心，最终可能会用脚砸自己。 因此，内存中计算的强大功能仅意味着我们可以在非常分散和离散的数据集上更快，更快速地运行。 但随后，最终用户便提出了更高的要求。 他们习惯了这种能力，并且想要它。 他们不再期望工作需要数周的时间来运行，而报告以普通的旧纸出现。 然后，在所有这些内容的基础上，我们围绕补丁，更新和升级进行了日常维护。 如果您考虑使用内存中的计算进行24/7全天候处理，管理该数据，管理整个数据中的工作负载，那么从技术上讲，这些都是内存中的临时平台，如果我们要开始在其中应用补丁，更新和升级的话在那里，还带来了一系列其他管理和监控挑战。 我们需要知道什么可以使离线，何时可以对其进行升级以及何时使其重新联机。 这使我进入了最后一个观点，那就是，随着我们在这些系统中变得越来越复杂，人类不再能够仅仅通过吮吸拇指和拔耳而做。 不再有那种直觉。 我们确实确实需要适当的工具来管理和提供计算和数据管理中的这种高性能。
考虑到这一点，我将交给IDERA的朋友，并听听他们如何应对这一挑战。
Bill Ellis：非常感谢。 我正在分享我的屏幕，然后我们开始。 因此，仅考虑所有技术以及所有在我们之前的人，这真是令人感到羞耻，以使这些东西在2017年可用。 我们将要讨论SAP HANA的工作负载分析-基本上是一种数据库监视解决方案：全面，无代理，提供实时功能并建立历史记录，因此您可以查看过去发生的情况。 SAP S / 4 HANA具有更好，更快和更便宜的潜力。 我并不是说它便宜，而是说它便宜。 传统上，发生的事情是，您将拥有一个主生产实例（可能在较大商店中的Oracle上运行，可能还有SQL Server），然后您将使用该ETL流程，并且将有多个真实版本。 。 这非常昂贵，因为您要为每个单独的环境购买硬件，操作系统和Oracle许可证。 然后，最重要的是，您需要让人们调和真理的一个版本与真理的下一个版本。 因此，这种多版本ETL处理非常缓慢而且非常麻烦。
因此，HANA（基本上是一个HANA实例）可以潜在地替换所有其他实例。 因此，它更便宜，因为它是一个硬件平台，一个操作系统，而不是多个。 因此，S / 4 HANA确实确实改变了一切，并且您基本上正在研究SAP从R / 2到R / 3（各种增强包）的演变。 现在，遗留系统在2025年之前可用，因此您有八年的时间才真正被迫迁移。 尽管我们看到人们知道，但由于他们知道它即将到来，所以他们不知所措，并且最终，您知道，ECC将在HANA上运行，因此您确实需要为此做准备并了解技术。
因此，一个数据库，没有ETL流程，没有必须协调的副本。 因此，再一次，更快，更好，更便宜。 HANA处于内存中。 SAP提供软件，您提供硬件。 没有汇总表。 他们在某种程度上建议您在考虑此问题时提出的一件事是，您不想参与其中，我们将购买最大的可用服务器。 他们建议您提前确定合适的SAP规模，他们基本上说不要迁移20年的数据。 我认为归档在IT中没有得到充分利用，而不仅仅是在SAP工厂中。 因此，接下来的事情是SAP实际上已经花了很多时间重写其本机代码而不使用SELECT *。 SELECT *返回表中的所有列，这在列式数据库中特别昂贵。 因此，对于SAP HANA而言，这不是一个好主意。 因此，对于具有大量自定义项和大量报告的商店，这是您要查找的东西，并且在逐步将所有内容迁移到HANA时将要指定列名。
我们要说的是，HANA不是万能药。 像所有数据库一样，所有技术都需要进行监控，并且如前所述，您需要数字才能管理过剩的测量。 我在IDERA领域中谈论的一件事是，每笔业务交易都与记录系统交互，在这种情况下，它将是HANA。 因此，HANA成为您执行SAP交易和最终用户体验的基础。 因此，至关重要的是要保持高速运行。 它确实成为单点故障，并且在与人们交谈时，这可能会在您拥有最终用户的地方出现，并且可能正在使用实时数据，并且他们具有临时查询，而该查询可能并不完全对。 也许他们不是在联接表，而是创建了外部联接（一种党派产品），并且基本上在消耗大量资源。 现在，HANA最终将意识到这一点，并终止该会话。 因此，我们架构的关键部分将使您能够真正捕捉到历史，从而可以了解过去发生的情况并识别这些情况。
因此，让我们看一下SAP HANA的工作负载分析。 这是版本1，因此我们非常邀请您加入我们的旅程，这是IDERA的产品。 它很全面，但很简单。 实时趋势。 主机运行状况，实例运行状况。 我们跟踪等待状态，SQL查询，内存使用者和服务。 因此，这就是GUI的外观，您可以立即看到它已启用Web。 我实际上打开了在系统上实时运行的解决方案。 您需要看一些重要的事情。 我们已经将其细分为不同的工作空间。 最关键的一种是从CPU利用率和内存利用率在主机级别发生的事情。 您绝对不想达到交换或颠覆的立场。 然后，从响应时间，用户，SQL语句开始，您基本上可以深入研究趋势趋势，即驱动系统活动的因素。
您知道IDERA的一件事是，直到有活动，数据库上什么都不会发生。 该活动是来自应用程序的SQL语句。 因此，测量SQL语句对于能够发现根本原因至关重要。 因此，让我们继续深入。因此，在主机级别，我们实际上可以查看内存，随时间推移进行跟踪以及主机CPU利用率。 退一步，您可以查看COBSQL语句。 现在，您将在架构方面看到的一件事是该信息存储在HANA之外，因此，如果HANA发生了某些事情，我们基本上是在捕获信息，直到上帝禁止，这是不可用的情况。 我们还可以捕获系统上发生的所有事件，以便您清晰可见。 我们要做的一件事是，我们将按加权顺序显示SQL语句。 因此，这将考虑执行次数，这就是资源的总和。
因此，您可以在此处了解各个指标-该SQL语句何时执行？ 然后，资源消耗在很大程度上取决于执行计划，因此我们能够不断地捕获资源消耗。 HANA处于内存中。 这是高度并行的。 它确实在每个表上都有主索引，一些商店选择使用主索引来构建辅助索引来解决某些性能问题。 因此，了解某些SQL语句的执行计划发生了什么可能非常有价值。 我们还将再次查看随时间变化的服务和内存消耗情况。 架构：因此，这是一个自包含的解决方案，您可以从我们的网站下载该架构，并且该架构是基于Web的。
您可以让多个用户连接到特定实例。 您可以监视SAP HANA的本地实例。 而且，我们在存储库中保留了四周的滚动历史记录，并且这是自我管理的。 要部署它，这很简单。 您需要Windows服务器。 您需要下载它。 大多数Windows Server将具有内置的.NET框架，并且与许可证捆绑在一起。 因此，您将转到由Setup.exe驱动的安装向导，它实际上会打开一个屏幕，许可协议，您只需单击“下一步”就可以简化此轮廓。因此，您希望HANA在哪里被安装？ 接下来是数据库属性，这将成为您与SAP HANA的连接，因此这是对HANA实例的无代理监视。 然后，我们基本上会进行预览，这是我们默认情况下进行通信的端口。 单击“安装”，它基本上会启动HANA，然后开始构建历史记录。 因此，仅提供了一些尺码表信息。 我们最多可以监视45个HANA实例，并且您将希望以可变的方式使用它来确定所需的核心数量，内存和磁盘空间。 并假设您有完整的四周滚动历史记录。
因此，快速回顾一下，我们正在研究服务器运行状况，实例运行状况，CPU /内存利用率。 什么是内存使用者，什么是活动驱动程序，什么是服务？ SQL语句至关重要–执行状态是什么？ 告诉我执行计划，什么时候执行，提供趋势？ 这将为您提供实时信息和发生的历史。 正如我提到的那样，由于我们的历史与HANA是分开的，因此我们将捕获那些已超时且已从HANA的历史中删除的东西。 这样，您就可以查看历史记录，从而了解系统上的真实资源消耗。
因此，正如我前面提到的，在IDERA网站的“产品”下，您可以轻松找到它。 如果您想尝试一下，当然欢迎您。 了解它如何为您提供信息，以及该网站上的其他信息。 因此，任何对此感兴趣的人士都非常乐意参加。 现在，在IDERA提供的产品组合产品中，还有一个SAP ECC事务监控器，这称为SAP精确工具。 它的作用是-无论您使用门户网站还是仅使用ECC，它实际上都会捕获从单击到磁盘的整个最终用户事务，一直到SQL语句，并向您显示发生了什么。
现在，我仅向您显示一个摘要屏幕。 我希望您从此摘要屏幕中获得一些好处。 它是Y轴的响应时间，X轴的时间加上日期，在此事务视图中，我们将向您显示客户端时间，排队时间，ABAP代码时间，数据库时间。 我们可以捕获最终用户ID，T代码，并且您实际上可以通过遍历的特定事务来过滤和显示服务器。 因此，许多商店都在VMware下运行前端环境，因此您实际上可以衡量每台服务器上发生的情况，并进行非常详细的分析。 因此，此事务视图适用于整个SAP环境中的最终用户事务。 您可以在我们的网站上的Products APM Tools下找到它，这将是我们拥有的SAP解决方案。 这样做的安装要复杂一些，因此，不仅仅是像HANA一样下载并尝试。 这是我们将共同为您完成，设计和实施整体交易的地方。
因此，它是SAP HANA的第三个快速回顾，工作负载分析，它是全面的，无代理的，实时的，提供了历史记录。 我们提供了下载并在您的网站上试用的功能。
因此，我将把时间花在Eric，Dez和Bloor博士身上。
埃里克·卡瓦那（Eric Kavanagh）：是的，也许罗宾，您有任何疑问，然后是罗宾之后的德兹？
罗宾·布洛尔博士：好的。 我的意思是，我想说的第一件事是我真的很喜欢事务视图，因为这正是我在这种情况下想要的。 我做了很多工作-很好，现在已经很久了-进行性能监视。 那时我们没有图形，但是那是我特别想做的事情。 这样一来，您就可以将自己注入问题发生的任何地方。
我知道的第一个问题是，大多数人都以某种方式或其他方式实现S / 4。 当您参与到S / 4的任何给定实现中时，您是否发现它已被很好地实施，或者最终发现了可能导致客户想要重新配置的东西？ 我的意思是，所有这些如何进行？
比尔·埃利斯（Bill Ellis）：好吧，每家商店都有所不同。 而且有不同的使用模式，有不同的报告。 对于具有临时报告的网站，我的意思是实际上有点像系统上的通配符。 因此，关键的事情之一就是开始测量并找出基准线，特定站点的正常情况，特定站点的位置（基于其使用模式），给系统造成压力。 然后从那里进行调整。 通常，监视优化不是一次性的，它实际上是一种持续的实践，您在监视，调整，磨练，从而使系统更好地适合最终用户社区，从而能够更有效地为企业提供服务。
Robin Bloor博士：好的，所以在实施时–我的意思是，我知道这是一个很难回答的问题，因为它会根据实施规模而有所不同–但是IDERA监视功能需要消耗多少资源，消耗多少资源？ ？ 它对任何事物都没有影响，还是只是某种程度的干扰？ 这是如何运作的？
Bill Ellis：是的，我想说间接费用大约是1-3％。 许多商店非常愿意牺牲这一点，因为您有可能在优化方面将其购回。 它确实取决于使用模式。 如果您要进行全面规划，则确实取决于要监视的单个技术。 因此，里程数确实会有所不同，但是就像我们所说的那样，花一点时间了解发生的事情绝对比盲目奔跑绝对更好。 您知道，尤其是1月，现在进入年终处理，您正在汇总12个月的数据。 您知道，这就是在执行绩效，将报告发送给监管机构，银行和股东，对于关键的业务绩效绝对至关重要。
Robin Bloor博士：对。 从您的角度来看，这是一个快速的过程-因为我猜您已经参与了整个SAP网站系列-SAP客户群向S / 4的转移有多大？ 我的意思是，这是某种原因吗，您知道吗，有一群热情的客户在追求它，或者只是steady花一现？ 你怎么看？
比尔·埃利斯（Bill Ellis）：我想几年前，我会说这是一个脚趾。 现在我要说的是，人们一定要屈膝。 我想，您知道，鉴于时间表，未来几年人们将真正沉浸在HANA中。 因此，我认为大多数客户都是在学习曲线上共同进行监控，转型。 因此，我认为我们并没有像您所说的那样雪崩，但我认为我们正处于向HANA进行重大转型的风口浪尖。
Robin Bloor博士：好的，就您所看到的为此目的而论的站点而言，它们是否还在使HANA适应其他应用程序，或者它们是否以某种方式完全消耗了此功能？东西工作？ 那里是什么图片？
Bill Ellis：是的，通常人们将SAP与其他系统集成，这取决于哪些模块等等，所以有一点。 我还没有真正看到有人在HANA上部署其他应用程序。 当然可以做到。 因此，它更多地围绕着SAP基础架构。
Robin Bloor博士：我想最好把你交给Dez。 我一直在浪费你的时间。 德兹？
Dez Blanchfield：谢谢。 不，那很好。 两种非常快速的方法，只是试图设置主题。 SAP HANA已经问世两年了，人们有机会考虑一下。 如果您要粗略估算经营该产品的人所占的比例-因为有很多人在经营这种产品-您认为您所知道的市场份额目前已经消失了从传统的SAP实施到HANA上的SAP？ 我们在看50 / 50、30 / 70吗？ 您所看到的是那些已经过渡并立即采取行动的人，与仅仅忍受着等待并等待事情好转，好转，变化或其他情况的人所占的市场百分比？
比尔·埃利斯（Bill Ellis）：是的，从我的角度来看，我实际上将这一百分比放在20％左右。 SAP往往是传统企业。 人们往往非常保守，因此他们的人民会拖脚。 我认为，这还取决于您是否已经长期运行SAP，或者您是哪种SMB，也许最近部署了SAP？ 因此，有很多因素，但总的来说，我认为该百分比不是50/50。 我想说至少有50％的人涉足其中，而HANA在其数据中心中的某个地方运行。
Dez Blanchfield：您早些时候给我们带来的有趣的收获是，从某种意义上说这是既成事实，并且时钟在物理上和字面上都在滴答时间。 在此过程中，您认为人们是否考虑过？ 人们普遍认为这是平台的过渡性转变，不只是一种选择，它正在成为默认设置，这是什么？
从SAP的角度来看，我确信他们会这样做，因为在性能方面有明显的竞争优势，但我想，他们也在争夺对平台的控制权，而不是控制权，派对数据库，他们现在将其带回自己的平台。 您认为公司实际上已经收到了该信息吗？ 您认为人们了解这一点，并且现在正在适应吗？ 还是在市场上还是一个不清楚的事情？
比尔·埃利斯（Bill Ellis）：我不认为SAP会害羞于交流，而去过SAPPHIRE的人们却无处不在看到HANA。 因此，我认为人们很清楚，但是人的本质就是某种意义，有些人有点拖脚。
Dez Blanchfield：因为我认为我问这个问题的原因，您必须原谅我，但这是我同意。 我认为他们并没有羞于交流。 我认为信号从很多方面消失了。 我同意您的意见–我不知道每个人都跳了。 您知道，传统企业，正在运行此功能的超大型企业仍在很多方面，虽然并没有拖延脚步，但只是在努力应对转变的复杂性。 因为我认为您的工具（当然还有今天的演示）突出了一件事，对我来说，我希望大家在今天聆听和收听并坐下来并进行反思的一个关键要点是，现在，这个工具简化了我的工作流程。 我认为，有一堆非常紧张的CIO及其团队正在思考：“我该如何从数十年来广为人知的传统RDBMS，关系数据库管理系统过渡到全新的计算和计算范式在我脑海中，存储管理仍处于相对勇敢的位置？ 但这在许多方面都是未知数，在其他领域做出这种转变的人很少，这并不意味着他们已经将另一部分业务转移到了内存计算中。 因此，这在他们心中是全有或全无的举动。
因此，我从这件事中拿走的事情比什么都重要-我将在一分钟内向您提出问题-是我现在以多种方式缓解了恐惧，而在今天之前，如果我正在聆听CIO的话，我会想，“嗯，我将如何过渡？ 我该如何保证我们在关系数据库管理平台中拥有的相同功能以及多年的DBA经验，以及我们目前尚不具备的新平台？”因此，我的问题是，您是否认为人们已经理解您所提供的工具已经存在，并且他们可以深呼吸并松了一口气，认为过渡并不像以前那样可怕该工具可用吗？ 您认为人们已经理解还是只是想解决向内存计算和内存存储的过渡，而不是老式的NVMe，闪存和磁盘的组合？
比尔·埃利斯（Bill Ellis）：是的，毫无疑问，有很多技术和工具可以图形化地显示这一情况，正在发生的事情，并且可以很容易地找到主要的资源消费者。 我的意思是，它确实有助于简化事情，并且确实有助于技术人员很好地掌握。 嘿，他们将能够知道发生了什么，并且能够理解所有的复杂性。 因此，绝对地，市场上的工具绝对有帮助，因此我们为SAP HANA提供工作负载分析。
Dez Blanchfield：是的，我认为您今天向我们展示的内容最重要的是，在监视硬件部分，操作系统部分，甚至监视某些正在运行的工作负载时，正如您所说，我的意思是，工具已经在那里呆了一段时间了。 对我来说，尤其是在HANA之类的地方，是我不一定有能力拿起放大镜来窥视它，并直接查看您的工具如何处理查询的内容以及查询的方式。的结构以及该负载的位置。
到目前为止，您已经看到了这些部署，并且鉴于您实际上是该平台上该领域中最权威的，您已经看到了一些快速获胜的经验–您是否拥有可以与之分享的轶事知识我们围绕着一些eureka时刻，aha时刻，在人们部署IDERA工具集的过程中，他们发现自己所不知道的东西在他们拥有的平台和性能中。 您是否有一些很棒的轶事例子，说明人们刚刚将其部署到哪里，却并不真正知道他们所拥有的东西，然后突然消失了，“哇，我们实际上不知道那儿有东西吗？”
Bill Ellis：是的，因此本机工具的一个很大限制是，如果取消了一个失控的查询，它将刷新信息，因此您基本上没有历史记录。 通过我们将历史记录离线存储，就像失控查询一样，您将拥有历史记录，知道发生了什么，您将能够看到执行计划等等。 这样，您可以从某种程度上帮助最终用户社区更好地运作，更好地编写报告，等等。 因此，历史真是太好了。 我要显示的一件事是，您可以实时查看长达四个星期的实时信息，然后可以轻松放大感兴趣的任何时间范围，然后可以揭示潜在的驾驶活动。 仅仅具有可见性对于了解出现了什么瓶颈非常有帮助。
Dez Blanchfield：您提到过，它是多用户的，一旦部署，它的无代理和有效的零接触在很多方面都给我留下了深刻的印象。 从NOC的网络运营中心向每个人提供工具的部署，然后监视核心基础结构，一直支持群集，直到应用程序和开发团队，这是否正常？ 这是规范，您部署一次，他们会分享吗？或者您是否期望人们可能会有模型实例查看堆栈的不同部分？ 看起来像什么？
Bill Ellis：因此，基础团队通常会对SAP所发生的技术基础非常感兴趣。 显然，有多个团队将支持整个景观。 HANA片只着眼于此。 我将默认作为信息的主要使用者使用SAP基础团队。
Dez Blanchfield：对。 但是，令我惊讶的是，如果我有一个开发团队，甚至不只是在代码级别，但是如果我有一个数据科学家或分析师团队在其中对数据集进行分析工作，尤其是考虑到在我看来，这是对数据科学的重大推动，现在将其应用于组织内部的所有事物；如果我错了，请纠正我。在我看来，这也将使他们也非常感兴趣，因为在许多方面，在数据仓库环境中您可以做的严肃的事情之一就是释放数据科学家，让它开始进行临时查询。 您有没有发生过这样的事例，而商店却让您大吃一惊：传统的运营监控和管理？”
比尔·埃利斯（Bill Ellis）：是的，我想稍微谈一下，减少我的回答，那就是，查看性能，在开发质量检查产品时了解性能，您知道，越早存储，问题就越少，更少你有惊喜。 所以，绝对。
Dez Blanchfield：接下来，我已经使用过很多工具-我确信Robin会同意-这里的很多工具，如果您有大型RDBMS，则需要非常高的熟练，知识渊博，经验丰富的DBA。 SAP HANA附带了一些基础架构和平台要求，因为据我所知，它目前在特定发行版（从特定硬件等）中得到支持。 您知道，有些人拥有数十年的经验，他们并不相同。 不过，我看到的是，此工具不一定是必需的。 在我看来，您可以部署您的工具并将其提供给一些相当新的面孔，并让他们立即拥有能力来查找性能不佳的东西。 是否有很短的学习曲线来加快速度并从部署中获得一些价值？ 您知道，我的一般感觉是，您不必拥有20年的驱动工具经验就能立即看到其价值。 您是否同意这种情况？
Bill Ellis：哦，绝对，就您的观点，我认为部署的许多成功实际上取决于SAP HANA环境的规划和架构。 毫无疑问，这里有很多复杂性，它建立在很多技术之上，但最终只能监视正在发生的事情的使用模式。 因此，尽管它更复杂，但是在某种程度上已经打包并简化了。 那太可怜了。
Dez Blanchfield：是的，所以在我回到Eric之前，是因为我知道他有几个问题，尤其是来自问答环节的一些看起来很有趣的问题，我很想听听答案。 某人的传统旅程-您之前提到过可以获取，下载并尝试。 您能否快速回顾一下，以便今天的听众或以后可能会回放的人们？ 购买副本并部署副本并在其环境中进行尝试的快速的两三个步骤是什么？ 看起来像什么？ 有哪些步骤？
比尔·埃利斯：是的。 因此，请访问IDERA.com，然后转到“产品”，您将看到SAP HANA的工作量分析。 有一个下载页面。 我认为他们会要求您提供一些联系信息，并且该产品仅随附有许可证密钥，因此您可以通过Setup.exe安装它，并且很快就可以滚动使用。
Dez Blanchfield：因此，他们可以访问您的网站，可以下载它。 我记得以前看过它，昨晚我也仔细检查了一下，您可以从内存中请求演示，团队中的某人将在其中进行演示？ 但是您实际上可以免费下载它，并在自己的时间在自己的环境中本地部署，对吗？
比尔·埃利斯：是的。
Dez Blanchfield：太好了 。 好吧，我认为，最重要的是，我个人建议人们做的是从网站上获取一份副本，在那儿获取一些文档，因为我知道那里有很多很好的内容，并尝试一下。 将其放在您的环境中，然后看看您发现了什么。 我怀疑一旦您使用IDERA工具对SAP HANA环境进行了深入了解，就会发现其中实际上并不存在的东西。
看，非常感谢您，也感谢您为与Robin和I进行的问答所付出的时间。Eric，我要回信给您，因为我知道一些与会人员也进行了问答。
埃里克·卡瓦纳（Eric Kavanagh）：是的，这里真快。 因此，其中一位与会者在谈论事物的变化时在这里发表了非常好的评论。 过去曾说过，内存阻塞，由于频繁的分页而减慢，目前CPU阻塞太多的内存数据。 您知道，存在网络问题。 它总是一个移动的目标，对吗？ 对于瓶颈将要出现在何处以及需要引起注意的方面，您最近看到的轨迹是什么？
比尔·埃利斯：是的。 在您测量之前，很难知道。 关于SQL语句的一件事是它们将成为资源消耗的驱动力。 这样，在您遇到大内存或CPU消耗的情况下，您将能够找出导致该资源消耗的活动。 现在，您不一定要杀死它，但您也想知道它，以及某种情况，发生的频率，发生的频率等。 在解决整套或针对不同情况的应对方案方面，我们还是一种新事物。 因此，这是一个很好的问题，时间会证明一切。 随着时间的流逝，我们将获得更多信息。
埃里克·卡瓦纳（Eric Kavanagh）：就是这样。 好吧，你们在一个非常有趣的地方。 我认为您会在接下来的几个月和接下来的几年看到很多活动，因为我确实知道，正如您在我们的内容通话中所建议的那样，SAP为人们提供了一个不错的长期过渡到HANA。 但是，尽管如此，这种上升确实有终点，在某个时候人们将不得不做出一些严肃的决定，所以越早越好，对吧？
比尔·埃利斯：绝对。
埃里克·卡瓦纳（Eric Kavanagh）：好的，我们在Hot Technologies上花了一个小时。 您可以在insideanalysis.com和techopedia.com上找到信息。 在该站点上关注大量有趣的信息，包括这些过去网络广播的所有存档列表。 但是，非常感谢你们所有人，我们在IDERA的朋友，Robin和Dez。 伙计们，下周我们会赶上您。 再次感谢您的时间和关注。 照顾自己。 再见。
