SAP HANA智能数据平台已经提供了八年，并且随着时间的推移，我们继续看到越来越多的创新。随着HANA 2.0 SPS04的发布，您可以在接下来的几周内看到同样的情况。不过，我想借此机会回顾一下SAP HANA的一些"基础知识"——2011年是什么让它与众不同，以及这种差异如何在2019年及以后继续增值。这是由两部分组成的系列文章的第一部分，另一篇博客文章计划在下周发表。现在，我将重点介绍SAP HANA的内存和列结构，以及它通过虚拟数据模型实现的价值。
内存和列结构
我不打算深入了解SAP HANA的技术细节和内部结构，因为有大量的帮助文档。值得一提的是，SAP HANA率先提出了在内存和列结构中拥有单个数据拷贝的概念，并继续在这一领域保持市场领先地位。我的语句中的"单拷贝"部分是SAP HANA的真正区别，这意味着我们不必在基于行的结构中进行事务处理，然后在基于列的结构中重新持久化相同的数据，大数据人工智能，从而产生冗余和延迟。随着SAP HANA技术的进步，我们能够直接在内存中的列结构上进行事务处理，并立即获得好处。这使得事务性和分析性工作负载都能获得最佳性能。即使我们不直接在saphana上进行事务处理，它也可以处理事务复制的负载。这意味着我们可以从其他数据库实时复制到这个内存列结构中，而不必像过去那样使用ETL工具对数据进行批处理（不过，如果您愿意，我们也可以这样做；可能是因为源代码无法处理负载）。归根结底，内存中的列式技术是SAP S/4HANA和SAP BW/4HANA等应用程序改进的关键促成因素，但它在这些应用程序之外也有优点，这是我接下来要讨论的。
虚拟数据模型
在SAP HANA正式上市的前6-9个月，以及在HANA上的BW出现之前，靠谱云服务器，确实存在一些问题只是一个用例：SAP HANA作为数据集市解决方案。当然，我们给它起了一些其他的名字，比如"侧车"、敏捷数据集市、运营报告和应用程序加速器，但最终所有这些都依赖于将数据加载到平台中，淘客查询，将数据建模到一个很好的分析结构中，然后连接应用程序或BI工具来读取数据。这在概念上听起来很简单，但不同的是我们是如何用SAP-HANA实现这一点的。为了解释这一部分，我将尝试使用我自2012年以来一直使用的相同类比…
这可能会与我的一些千禧一代和Z一代朋友失之交臂，但成长于80年代和90年代（Xennials法则！）我对"混合磁带"并不陌生，如果我想为我的女朋友编一部"情歌"，或为我的朋友编一部"Raver's Beats"，那是一个很大的努力。步骤如下：
这是一个真正的爱的劳动，在某些方面我怀念它。随着时间的推移，随着双卡带、CD、MP3和Napster的推出，游戏变得简单了一些（我承认没有错）……但2001年苹果推出iTunes和iPod时，游戏完全改变了。从那时起，我就可以轻松地在网上购买我的音乐，只需将它拖放到一个自动同步到我的设备的播放列表中。重要的是，与此类似，数字播放列表并不是制作歌曲的物理副本，而是简单地将指向该副本的指针存储在库中或设备上。如果我觉得自己的口味变了，只需按一下按钮就可以轻松调整。我可能不会像以前的混音磁带那样为相同的主题制作播放列表，但是现在维护我的"Running Music"和"Childs Songs"肯定很容易。
虽然这对我来说是80/90年代的一个有趣的小消遣，但我在SAP HANA的背景下提出来一定有原因。在我看来，2011年SAP HANA在商业数据领域的引入与2001年iTunes在消费音乐领域的引入类似。从数据和业务分析的角度考虑一下。我可以很容易地将我的"混合磁带"的步骤与业务分析项目中涉及的高级步骤进行比较：
与SAP HANA的区别在于引入虚拟数据模型的步骤3-5。从事过数据集市/仓库项目的每个人都知道，上述步骤中包含的绝大多数工作都是为了准备数据以满足业务需求。使用SAP HANA，我们改变了游戏规则如下：
获取数据–简化流程，仅应用逻辑（如筛选条件）或排除字段（如果特定要求（即安全性）要求这样做，则直接从源到目标进行1:1复制。我建议客户建立一个原则，即数据在saphana中"以最原始的格式存储一次"。重组数据以供使用—这不是SAP HANA的秘密；由于前面提到的技术，好评返现模板，我们现在可以构建一个完全虚拟的数据模型（又名播放列表）。saphana中的graphicmodeler允许我们构建一个信息模型（特殊类型的视图），该模型将所有原始数据集成到一个虚拟结构中，以供使用。这意味着任何聚合、计算、转换、联接等（包括经常请求的货币转换、度量单位转换和层次结构）都是在访问时动态发生的。In-memory columnar支持这种动态处理，其结果是我们已经消除了进程中的延迟和冗余—数据以原始格式落地时就可以使用了。[注：我认识到仍有可能需要持续进行成本极高的处理，当然我们需要管理这些处理……但只能在例外情况下进行！]返工–虽然我喜欢上面的项目符号，但这是让我对虚拟数据模型最感兴趣的项目。我的一位前任经理曾经谈论过如何用SAP-HANA"快速失败"。这听起来有悖常理，要求你失败，但现实是，业务用户很少确切地知道他们第一次尝试需要什么。使用虚拟数据模型，我们可以快速地在用户面前获得模型，识别差距（失败），并梳理出真正的业务需求。这种灵活性来自于虚拟数据模型的动态特性，避免了等待一整夜的批处理ETL作业完成。此外，因为我们已经从源代码中引入了所有字段，所以请求新的数据元素时就不是问题了——这与过去我们可能还必须更改提取作业时的经历截然不同。这些变化的结果是，开发人员和业务用户坐在一起，以灵活的方式应对挑战变得更加现实。
