江门学做网站课程,零基础网站建设教学,做网站学什么什么专业,如何在百度上打广告挑战#xff1a;支持多个存储引擎 以下内容并不是新发现#xff1a;行优化存储适用于OLTP和运营工作负载#xff0c;而列存储适用于BI和分析工作负载。频繁写入的工作负载适用于行式存储。对Hadoop而言#xff0c;Hbase适合低延迟工作负载#xff0c;列式ORC文件或Parquet… 挑战支持多个存储引擎 以下内容并不是新发现行优化存储适用于OLTP和运营工作负载而列存储适用于BI和分析工作负载。频繁写入的工作负载适用于行式存储。对Hadoop而言Hbase适合低延迟工作负载列式ORC文件或Parquet适合BI和分析工作负载。业界尤其是内存数据库厂商宣称列结构可以很好地为各种工作负载服务。实际上当相同的数据结构用于处理不同访问模式的工作负载时通常存在性能折中。Cloudera承诺的Kudu存储引擎将能满足混合工作负载的要求但它明确指出低延时性能低于HBaseBI和分析工作负载性能低于Parquet。 NoSQL技术革新已经表明为了满足当今工作负载的不同需求支持多种数据模型是很有必要的。但是为了减少数据的复制和移动理想方案是单个查询引擎可以支持多个存储引擎。数据可以驻留在数据结构/存储引擎中对于所需的数据访问模式而言这种情况是最理想的而且查询引擎可以透明地支持所有这些操作。为此Hive、Impala、Drill、Spark、Presto和其他SQL-on-Hadoop解决方案支持多种数据结构。但是这些查询引擎还不支持OLTP或运营工作负载。 问题不仅在于存储引擎无法服务于多种工作负载而且查询引擎也难以支持多个存储引擎。为了支持混合工作负载可能需要将数据从一个存储引擎转换和迁移到另一个存储引擎但这存在许多挑战接下来我们讨论其中某些挑战。 统计 如前所述为了生成优良的查询计划、或理解工作负载是运行型或分析型我们需要统计信息以支持所有类型的查询工作负载。因此当添加新的存储引擎时您还需要添加对收集统计信息的支持功能。存储引擎有高效机制来对行进行抽样吗通过增量统计计算它是否有一个简单的方法来查询新的数据它是否收集行数和其他可用于快速统计收集的指标为了使查询引擎决定何时对其统计信息做另一次更新它是否收集增删改查记录的计数量您需要回答诸如此类的一系列问题来设置对统计数据的收集与存储引擎高效地工作。 键结构 对于运营工作负载而言键入访问对亚秒级响应时间非常重要。单行访问需要通过键进行访问。由于事务或事实表总是具有多列键理想情况下键值应支持多列键。如果不支持多列键则查询引擎需要将多个主键列映射到单个存储引擎键。此外较短的运营查询通常需要聚集访问来检索少量行。聚集键的范围扫描有助于运营工作负载满足服务级别协议SLA Service Level Agreements。为了实现最高效的访问查询引擎需要了解存储引擎可用的键入访问选项并为其支持的每个存储引擎优化此访问。 分区 对于查询引擎而言了解存储引擎如何跨磁盘和节点对数据进行分区这一点非常重要。它是否支持哈希和/或范围分区或这些分区的组合如何确定这种分区为了平衡各个分区的负载和避免性能瓶颈查询引擎是否需要对数据进行加盐salt data如果需要如何添加一个加盐键salt key例如表格键的最左边的列并且仍然避免全表扫描当集群在扩展或收缩时存储引擎是否重新分区或重新平衡分区或者由查询引擎来执行此操作在对数据重新分区时用户可能需要全盘读取和写入所以这可能会变得非常复杂。如果查询引擎将对来自这些分区的数据执行并行处理那么数据如何在分区间进行传播是非常重要的。它需要尝试将访问本地化减少数据的再分区也称为shuffle或尽可能多地跨节点分布数据。在未理解存储引擎的键和分区结构的情况下不可能有效地处理查询数据。运营查询可能不会经常遇到并行处理数据的一些挑战但是如何对数据进行分区将影响是否能通过访问单个分区、磁盘或节点来处理快速运营查询而不必通过访问多个分区来满足具有严格服务级别的目标。 数据类型支持 查询引擎需要了解存储引擎支持哪些数据类型以及存储引擎对这些类型实施的约束条件以便查询引擎可以执行存储引擎不会执行的任何约束条件。例如在某些情况下如果存储引擎只支持字符串存储那么查询引擎最好将数据存储在自己的编码数据类型中。或者如果查询引擎会强制执行CHECK限制条件那么它是否可以将CHECK约束转包给存储引擎或由查询引擎来执行它们当然存储引擎一般不会支持引用约束检查。如果存储引擎能提供完整的字符集支持那么存储引擎和查询引擎便能通过UTF-8进行通信排序规则也是如此。 存储引擎是否提供压缩或加密支持或由查询引擎提供上述支持查询引擎很可能发出DDL语句创建表格它还需了解哪些选项用于数据块级别压缩和键压缩以及需要向用户公开的其他表结构选项。在一些情况下可能会将存储引擎表格映射到表的查询引擎视图。 投影和选择 大多数存储引擎支持投影存储引擎只返回需要的列否则查询引擎必须解压数据并进行投影。同样需要了解存储引擎是否可以提供谓词求值的能力。 存储引擎能够为哪些谓词、、、、between、LIKE求值它能在多列上评估谓词或评估多列谓词ab5,1吗它能处理IN列表吗支持多长IN列表一般来说它是否能处理ORs和ANDs的组合以及能处理何种复杂级别它能自动确定应用谓词的最有效的顺序例如首先评估能最大程度减少基数的列上的谓词尤其是当存储引擎为列式存储时吗 它能处理涉及同一表格的多个列的谓词例如c1c2吗除了文字能处理字符串表达式STRc13210或日期和时间表达式吗这些表达式有多复杂存储引擎如何处理缺省或缺失值NULLs查询引擎需要了解存储引擎的所有这些方面以确定下推哪些谓词到存储引擎、哪些谓词由查询引擎评估。 内存价格的下降让我们能为每个节点配置大量的内存非易失性存储器的广泛使用也即将实现。为了访问事务和分析工作负载的数据存储引擎不仅在内存中设计高效的结构而且正在实施使投影和选择等操作更高效的技术。存储引擎利用L1、L2和L3 CPU高速缓存来处理数据其速度甚至比主存储器处理数据的速度更快。通过矢量化方法同时处理多组行/列的数值并提出其他的创新方式例如最小化或消除序列化/反序列化的成本最大程度地提高数据处理速度的同时最大限度地利用硬件设施。这样瓶颈将从磁盘移动到主内存最终移动到CPU。高效地使用CPU非常重要查询引擎必须挖掘存储引擎的效率并尽可能地减少CPU使用率。 可扩展性 为了在存储引擎/服务器端实现更多功能一些存储引擎可以运行用户自定义的代码例如在HBase上的协处理器、前触发器或后触发器从而减少信息流量开销并提高效率。 例如如果优化器能将聚合下推到存储引擎则它可能有处理积极聚合的能力。当数据在GROUP BY列聚集或分组数目较小时该方法极为有效。如果存储引擎不支持该操作则查询引擎能使用协处理器来执行相同操作。可以在此层级执行具有表达式和函数的复杂谓词求值、并发连接和索引维护、安全执行和某些ANSI触发器操作甚至事务支持。 安全执行 安全处理是查询引擎和存储引擎之间的信息交互点。存储引擎可能有自己的底层安全实现方式如果它能良好地与SQL模型进行集成则查询引擎可以使用它。否则在细粒度访问控制的情况下查询引擎必须管理schema、表、列和行的权限。它可能需要将自己的授权框架与存储引擎的授权框架进行集成甚至映射。考虑到其他安全问题例如Hadoop安全解决方案Sentry或Ranger管理这些对象查询引擎需要与该安全框架进行集成。根据对安全日志及其他安全信息和事件管理Security Information and Event Management, SIEM功能的支持查询引擎必须能与存储引擎和平台功能进行集成或自身提供相关功能。对于混合事务/分析处理Hybrid Transaction / Analytical ProcessingHTAP而言由于可能需要支持多个存储引擎这将变得更加复杂。 事务管理 假设一个存储引擎提供某种级别的高可用复制、备份和恢复以及某种级别的多数据中心支持。但是事务性支持可以完全不同。事务管理具有ACID模型原子性 [Atomic]、一致性 [Consistent]、隔离性 [Isolated] 和持久性[Durable]以及BASE模型基本业务可用性 [Basic Availability]、柔性状态[Soft-state] 和 [Eventual consistency]。根据搜索引擎提供的支持查询引擎可能需要提供完整的多行、多表格和多语句的事务支持任一时间点的在线备份和事务一致性恢复以及为多数据中心提供双活同步更新和最终一致性的支持。查询引擎需要与预写式日志和存储引擎的其他机制集成以便利用引擎的底层复制和其他高可用性功能。这些可以具有很大差别例如Cassandra、HBase或Hive它们各自都有自己的事务模型。 此外回到存储引擎功能的可扩展性例如HBase的协处理器查询引擎需要实现此事务功能尽可能地与查询引擎接近并进行集成以获得可分布和最佳性能。否则它最终只是一个更通用的、而不是可扩展的和高效的实现方式。 元数据支持 查询引擎需要为正在支持的存储引擎表添加元数据支持。存在可能映射例如目录、名称、位置和数据类型映射针对存储引擎的特定扩展选项例如压缩选项支持多列族 – 例如将数据分区选项映射到底层存储引擎结构例如Hbase regions等。当有人在外部更改存储引擎表时如何更新该元数据或者如何将其标记为无效直到有人修复了差异 实际上如果数据库能访问外部存储引擎那么需要处理大量不可预知的问题例如如何保证事务一致性和数据完整性如果列中的数据与其应该具有的数据类型不一致、或包含无效数据可能它已通过其他方式更新那么查询引擎应如何操作此外您是否允许在此类表格上创建二级索引、视图、限制条件和物化视图等上述情况不仅需要提供元数据支持而且必须解决可能由外部访问引起的潜在的不一致性问题。 运营工作负载与BI和分析工作负载所需的元数据支持存在差异。例如运营功能需要参照完整性、触发器和存储过程而BI不需要运营工作负载不太需要物化视图。 性能、扩展和并发性考虑事项 查询引擎为了支持HTAP负载在和不同的存储引擎集成时需考虑不同存储引擎的性能、扩展性和并发性等关键因素。例如是否有可用的批量加载机制以及它在此类加载期间对事务一致性和可用性有什么影响是否支持批量插入从而可以有效地进行大量插入操作批量提取功能是否可用以在每个缓冲区返回行集而不是一次返回一行的接口是否有更快的扫描选项例如快照扫描当查询引擎了解将会扫描大量数据时可能是针对数据抽取或大型复杂查询能请求预取大块数据吗查询引擎如何进行并行更新和访问存储引擎如果查询引擎支持执行进程进行并行查询那么它如何最高效地访问存储引擎文件/分区和区域存储引擎能支持什么级别的并发访问查询引擎如何最高效地利用存储引擎所支持的功能和填补其不支持的功能这些都很难确定更难以实现。 错误处理 查询引擎可能需要支持HTAP因此每个存储引擎的错误处理方式也不相同。存储引擎提供的错误处理机制是什么如何记录这些错误存储引擎记录错误吗或者查询引擎需要解释每种错误类型并记录它吗需要向用户提供某些重大错误消息和补救指导吗 其他运营考虑事项 除了前文提到的错误处理还需要考虑其他方面。例如HBase的合并或拆分问题。这些对性能和用户工作负载很重要对事务工作负载的影响更大。如何通过查询引擎管理这些以提供最佳客户体验 简单地说支持存储引擎并非一项简单任务。当然您可以走捷径例如支持 InputFormat或OutputFormat甚至使用UDF或某些连接器技术来使查询引擎与存储引擎进行通信。但要真正集成存储引擎让其发挥最佳性能并提供最高效的并行处理需要投入大量的努力。如果您需要支持多个存储引擎以获取在多个存储引擎之上的查询引擎的终极数据库这是非常困难的。 IT行业齐心协力共同为查询引擎创建标准接口例如Java数据库连接Java Database Connectivity, JDBC和开放数据库连接Open Database Connectivity , ODBC。如果不同的存储引擎能为查询引擎提供通用的接口这将是一件非常好的事。查询引擎能通过接口快速省力地识别存储引擎的能力再与存储引擎进行集成并充分利用存储引擎的功能。如果能实现这个目标IT行业将会到达发展的成熟阶段。但目前来看各种存储引擎的API及其功能并不统一。 虽然某些挑战看起来与数据联邦引擎必须应对的挑战极为相似但不同的是查询引擎使用标准JDBC / ODBC接口与数据联邦引擎连接即将查询转包至另一个查询引擎。这种抽象层次与更深层次的集成不同更深层次的集成能大幅提高效率和性能它用于查询引擎和存储引擎之间。试想将一个专有RDBMS例如将Oracle拆分成一个查询引擎和一个存储引擎该方法与联邦引擎连接至Oracle实例的过程不同。 挑战适于所有工作负载的相同数据模型 正如IT行业的许多其他模糊术语一样data model这个术语包含很多不同的含义。在RDBMS背景下数据模型data model是实现的规范化级别。用于运营工作负载的数据是从第一范式到第六范式。对于BI和分析工作负载使用的历史数据您需要不同的数据模型例如星型schema或更复杂的包含维度表和事实表的雪花schema等。数据模型大相径庭以适应在OLTP和运营查询中的不同访问模式这些访问模式侧重于特定实体例如客户、订单、供应商和产品而不是侧重于BI或分析查询的大量历史数据。 HTAP是否无需描述数据模型一些内存数据库供应商声称已经达到这种效果但尚未撰写出任何性能基准报告——人工TPC或真实世界——即BI和分析工作负载在第三范式中性能良好。现在还没有任何数据表明OLTP /运营系统能在星型schema中表现良好不管是内存数据库还是非内存数据库。除了基准外性能还由客户运行的工作负载的种类决定这些工作负载与TPC基准不同甚至不存在一点交集。 因此您明白存在一定级别的数据重复、转换、聚合以及从一个数据结构、数据模型和存储引擎到另一个数据结构、数据模型和存储引擎的移动而且您希望查询引擎能将所有都无缝集成。虽然这很难但还是可以实现。然而完全不同的是您不需要复制、转换、聚合或移动数据也不需要为任何工作负载降低性能。随着Kudu的问世Cloudera希望市场上有需要单一数据副本、愿意降低高端运营和分析性能的需求即为了提高设计、开发和运营简单性他们愿意降低性能。最终结论尚待分晓但是如果IT行业在积极地追寻了NonSQL若干年后又将钟摆摇回预期方向这将非常有趣。如今性能扩展和高并发不仅是一项要求而是唯一要求。 但是如前所述数据模型data model有不同的定义键值、有序键值、Bigtable、文档、全文搜索和图形数据模型。为了实现单个存储引擎的终极数据库人们试图让这些数据模型处理它们本来不擅长的业务从而充分挖掘它们的潜力。因此文档中的整个父-子关系表明不再需要RDBMS功能并且文档的存储能满足所有工作负载要求。或者现在是图形数据库的时代吗我们是否可以在边缘和顶点中填充各种参数以支持各种工作负载事实上即使每个数据模型确实解决了某些问题但它们并不能独立地支持当今企业需要解决的各种工作负载。 文档功能、文本搜索必要时、图形结构需要快速访问的层级或网络类型关系、支持半结构化或非结构化数据的基于键值的模型和完全结构化的关系数据库能针对不同需求给出不同的令人满意的结果。尽管一些查询引擎全力支持但挑战是有效地将存储引擎与查询引擎进行集成。另外为其他数据模型加入标准SQL API实际上它并非标准因为每个数据库有它特有的实施方式和非标准API这也是一项挑战。 无论您怎样理解“数据模型”一词如果HTAP以相同的查询引擎来支持所有企业工作负载的多个非全部数据模型那么它需要克服许多挑战。 挑战企业级能力 大企业开始将BI工作负载扩展至分析工作负载再扩展至高级分析引用例如数据挖掘和机器学习他们最初在专有数据库和平台上运行BI和分析工作负载在Hadoop上运行大数据的其他工作负载。但随后许多企业将某些在专有数据库中运行的部分工作负载迁移至Hadoop上运行一些企业正在提供运行全面的RDBMS OLTP和在Hadoop上运行运营工作负载的能力从而将工作负载类型向混合事务型和分析模型扩展。但要真正处理所有工作负载包括关键任务工作负载则HTAP数据库引擎需要提供企业级能力我们将在以下部分对此进行讨论。 高可用性 对任何数据库而言可用性是一项重要指标。例如您可以通过HBase得到99.99也被称为“4个9”的可用性即每年有约52.56分钟的非计划停机时间。许多关键任务应用都努力实现99.999%也被称为“5个9”即每年5.26分钟的停机时间。当然可用性所增加的成本可能是巨大的。现在的问题是查询引擎与存储引擎结合在一起能提供何种程度的高可用性 通常数据库很难实现高可用性。如果想要实现需要解决以下问题 当需要读写数据在不能停机的情况下您能将底层OS、Hadoop发行版、存储或查询引擎升级至新的软件版本吗——即支持滚动更新吗您可以将数据重新分配到已添加进集群的新的节点或磁盘吗或合并它们以减少节点或磁盘完全在线不停机与此相关的问题是重新分区数据的能力。您是否能在线完成在线意味着在操作期间仅读取数据、或同时读取和写入数据。能在线为数据库更改DDL吗例如在不影响读取和写入的前提下更改列的数据类型数据库能容易地添加和删除非键列。能在线创建和删除二级索引吗支持完全和增量在线备份吗您的应用程序需要上述哪些功能取决于运营和分析工作负载的混合程度以及高可用性对这些工作负载的重要程度。 安全 运营和分析工作负载的安全实现不同。对运营工作负载而言通常在应用程序层管理安全性。应用程序与用户交互并管理数据库的所有访问。另一方面BI和分析工作负载能使最终用户通过报告和分析工具直接访问数据库。在这种情况下可能会将授权推送至数据库查询和存储引擎需要管理安全性。 集成到SIEM系统也适用于分析工作负载但很多运营工作负载需要更高程度的安全控制和可见性。 可管理性 管理数据库及其工作负载的能力非常重要。从图1-9中可以看出可管理性需要很多功能也许仅能实现部分功能 图1-9 数据库管理任务 由于HTAP工作负载的混合特性某些管理任务变得越来越具挑战性特别是工作负载管理。衡量OLTP或运营工作负载时往往需要考虑事务或人机交互的能力。该理念是根据每秒完成的事务来评估服务水平目标。由于此类事务的延迟可能很小所以跟踪每一条SQL语句的性能或每一事务的表现成本将非常高。因此您需要以某个时间间隔来统计信息并计算出平均值。而BI和分析适用于报表或查复杂查询这些查询通常耗时较长它们采集自身的运行指标值并基于查询级别统计信息进行监视和管理以达到良好的性能。 根据优先级和/或资源分配混合工作负载很难达到SLA的要求。分析工作负载的随机特性使其不能很好地融入运营工作负载即使在负载峰值期间运营工作负载也要求亚秒级的响应时间。 如果查询引擎正在与不同的存储引擎进行集成那么获得所有的运行指标也具挑战性。虽然查询引擎可以跟踪一些指标例如存储引擎服务一项请求所花费的时间但可能无法查看底层存储引擎正在使用的资源。另外很难在查询引擎和存储引擎之间细分出重要的CPU、内存和I / O指标以及诸如队列长度和内存交换等信息例如如果您想获得操作符用于查询计划的每一步例如扫描、连接和聚合等和被访问的表在查询中所使用资源的详细信息特别是并发执行和表被分区时这将是一项非常困难的工作除非利用插桩和回调函数收集端到端信息。再例如如何找出遇到数据倾斜或瓶颈的原因 在不久的将来不同类型的工作负载可能在单个平台上运行但这篇报告并没有详尽列举出与企业级运营能力相关的所有挑战。例如与YARN或Mesos的集成它们会尽可能考虑如何管理跨集群的不同应用工作负载的资源。希望这些能帮助您理解目前的挑战。
