共计 4617 个字符，预计需要花费 12 分钟才能阅读完成。
导读：
本文次要介绍网易数帆 NDH 在 Impala 上实现的虚构数仓个性，包含资源分组、程度扩大、混合分组和分时复用等性能，能够灵便配置集群资源、平衡节点负载、进步查问并发，并充分利用节点资源。
接着上一篇。对于高性能剖析型数仓，除了须要有优良的执行引擎可能让查问尽快实现外，还需防止因为查问间的互相烦扰导致查问性能降落的问题，比方对计算和 IO 资源的竞争等。上节提到 Impala 能够通过资源池来进行计算资源的治理。但在应用时发现光有资源池还不够，依然会呈现不同的资源池竞争同一个计算节点上内存资源等问题。
1 基本概念
“虚构数仓”来源于 Snowflake 的“virtual warehouse”，简称 VW。虚构数仓可能按需进行程度和垂直扩缩容，是一种高效的资源调度办法，是存算拆散设计架构下，计算资源弹性伸缩十分好的验证案例。如下图所示，该 Snowflake 集群有两个虚构数仓，别离服务于 BI 和 ETL 用户。其中 BI 虚构数仓为了应答报表查问的高下峰，采纳了单元化的程度扩缩容模式，ETL 次要关注计算能力，采纳了扭转虚构数仓规格的模式。
NDH 的 Impala 组件也具备相似的能力，在开始之前，先联合 Impala 的理论来介绍两个基本概念，首先是社区版 Impala 已有的 executor group（执行组）。而后是为反对虚构数仓而引入的 node group（节点组）概念。
Executor group
下图是 CDP 文档中对于 Impala 执行组的示意图，执行组是 Impala 进行弹性伸缩的根本单位，用户能够配置执行组规格 (XSMALL, SMALL, MEDIUM, or LARGE)。若启用主动伸缩，则 CDP 每次会按指定的规格扩大或放大 Impala 的 executor 节点个数。
执行组为 Impala 集群提供了程度扩缩容的能力。但与 Snowflake 所述的虚构数仓还是有不小的区别，从目前的介绍看，执行组是对用户通明的概念，用户无奈通过执行组将 Impala 集群划分为不同用处的计算单元，如前述的用于 BI 和 ETL。因而，NDH Impala 引入了 node group（节点组）的概念。
Node group
NDH Impala 集群的 impalad 节点能够被划分成多个独立分组，咱们称之为节点组。节点组能够仅有 executor 组成，也能够有 coordinator 节点。
上图 Impala 集群蕴含 3 个节点组，每个节点组的 impalad 中必须至多有一个 executor 节点。此外还有 2 个 coordinator 节点独立于节点组之外。独立的 coordinator 节点能够将申请路由到任一节点组中的 executor，节点组中的 coordinator 只能将申请分发给本分组内的 executor 节点执行。依据查问路由规定的差别，有两种虚构数仓实现形式。
2 实现形式
NDH Impala 反对两个虚构数仓实现，别离是基于 zookeeper 地址的动态配置计划和基于会话（session）参数的动静配置计划，上面别离开展介绍。
2.1 动态配置
该计划将不同节点组的 coordinator 节点注册到不同的 zookeeper 地址上，Hive JDBC 客户端连贯不同的 zookeeper 地址即可获取到不同业务组的 coordinator，从而进行连贯并下发 SQL 申请。此种形式中每个节点组都会领有本人独有的一到多个 coordinator 节点，负责将 SQL 生成的执行打算下发给组内的 executor 节点执行。
上图所示集群有 3 个虚构数仓：group 1，group 2 和 group 3。它们共用雷同的 statestored 和 catalogd，共用同一份数仓元数据。虚构数仓间的 impalad 资源是物理隔离的，某个虚构数仓的 coordinator 节点只会将查问下发到组内的 executor 节点。在生产环境中，可通过配置多个虚构数仓来接管不同类型业务的查问申请，以便不同业务的查问在计算资源的应用上相互隔离，互不影响，图中 group 1 用于进行 ad-hoc 查问，group 2 用于无数 BI 报表，group 3 用于无数 BI 自助取数。相比多集群形式，多虚构数仓的形式所须要资源更少，配置更灵便。
2.2 动静路由
本计划在会话连贯中减少一个 query option 参数 request_group，通过 set request_group=xxx 语句，coordinator 会主动将查问路由到指定分组上执行。request_group 默认为 default，对应 group_name 的默认值也为 default。换言之，若不指定 request_group，那么查问会下发到默认的 default 分组执行。
在本计划中 coordinator 节点是公共的，仅对 executor 节点进行分组，在实现上更相似 Snowflake 的虚构数仓。如下图所示，有 2 个公共的 coordinator，3 个分组，因为不存在 default 分组，可将默认分组配置为 grp1。能够通过参数动静配置，相比基于 zookeeper 的计划更加灵便，用户可能依据须要自在地将查问在不同的虚构数仓上切换。
上述两种计划均已实现，因为 NDH 的生产环境个别通过 Hive JDBC 连贯 zookeeper 来拜访 Impala，前者的应用办法兼容性更好，目前线上次要应用以该形式部署虚构数仓。本大节接下来介绍的虚构数仓进阶个性也次要围绕前者开展。
3 次要个性
3.1 程度扩大
若虚构数仓的单个节点组资源和并发数曾经达到瓶颈，单纯在组内减少节点无奈无效晋升查问并发数，此时能够新增一个规格雷同或相近的节点组退出该虚构数仓中，需将新节点组中 coordinator 的 zookeeper 地址配置成与原节点组雷同。借助 Hive JDBC 在抉择 zookeeper 下 coordinator 地址时的随机性特点，可将查问负载平衡到新旧节点组上。这种形式能够靠近线性地晋升集群的查问并发数。
上图所示 Impala 集群有 2 个虚构数仓，对应的节点组别离为 group1 和 group3，承接的业务别离是业务的无数 BI 报表和 ABTest 场景。假如 group1 为原分组，有 3 个 impalad 节点（1 个 coordinator，2 个 executor）。新增分组 group2，也是 3 个 impalad 节点，应用与 group1 雷同的配置，即可起到程度扩大的成果。
3.2 通明伸缩
NDH Impala 可依据各虚构数仓的负载状况，在线减少或缩小虚构数仓节点组中的 impalad 节点数，从而实现分组间的资源动静伸缩。通过 Impala 提供的 graceful shutdown 形式下线节点组中 impalad 过程时，会先禁止新的查问申请发送到该 impalad 节点上，并期待其上正在执行的查问片段（fragment）实现后再敞开。因而不会导致其上正在执行的查问异样终止，做到对用户无感。在生产环境中，配置了多个虚构数仓的 NDH Impala 集群，可通过剖析历史查问法则并联合分组中 impalad 节点的零碎负载状况，在虚构数仓间动静增减节点数，以求更充沛得利用各节点资源。
举网易云音乐为例，无数 BI 自助取数（easyfetch）的查问个别产生在工作工夫，无数 BI 报表须要在用户下班前进行大量报表后果预加载操作（提前下发报表查问 SQL 并缓存查问后果从而晋升报表查看体验）。咱们可将 easyfetch 和 BI 报表两种场景配置为同一个 NDH Impala 集群的两个虚构数仓，在下班前，将 easyfetch 虚构数仓的大部分 impalad 节点挪到 BI 报表虚构数仓上，这样能够大大提高报表的预加载效率。
当然，通明伸缩不仅仅实用在虚构数仓之间。对于云上环境，通过 k8s 或相似调度机制，在负载顶峰时能够便捷地申请容器或虚拟机资源，疾速补充到线上。待顶峰过后，再将所减少的资源开释给云厂商。
4 进阶性能
相比 Impala 资源队列，虚构数仓的节点组中 coordinator 节点相对不会应用到其余组的计算资源（executor），资源隔离更加彻底，使得不同业务模块的查问性能不会相互影响。但不同虚构数仓所属的业务会存在负载差别，可能导致资源利用不充沛。为了进步闲暇节点组的资源利用率，对虚构数仓个性做了进一步加强，引入混合分组、分时复用等性能。
4.1 混合分组
混合分组就是让一个 executor 节点同时在 2 个或以上的节点组中，如下图所示。左子图为一般模式，假如 NDH Impala 集群分为无数 BI 报表和 Ad-Hoc 查问 2 个虚构数仓，Ad-Hoc 查问有显著的时间性，查问集中在工作工夫，且查问的并发度较低。通过混合分组，可将虚构数仓部署形式革新为右子图的模式。
图中，n1n2 为 group1 节点组 coordinator 节点，其会注册到 zookeeper 门路 youdata 上，Hive JDBC 客户端从该门路获取任意 coordinator 节点向其提交查问，coordinator 将查问进行解析，优化并指定分布式执行打算，最终下发给 n3n7 执行。n6n7 同时还是 group4 的 executor 节点，group4 的 coordinator 为 n8n9，其会接管从 zookeeper 门路 Ad-Hoc 进入的查问，指定分布式执行打算，并会发送到 n6~n8 上。
4.2 分时复用
分时复用是另一个可能进步资源利用率的进阶性能。通过在特定的时间段主动配置集群的分组资源，缓解某些高负载分组的查问压力，晋升用户体验。
在实现上，反对将同一个 coordinator 注册到多个 zookeeper 地址下，且能够配置注册到每个地址的无效工夫，如上图所示，能够每天晚上八点到早上八点将 Ad-Hoc 虚构数仓的 n8 和 n9 两个 coordinator（或其中一个）注册到 BI 报表虚构数仓雷同的 zookeeper 地址下，摊派 BI 报表的查问负载。
与混合分组相比，分时复用性能仅适宜在规格类似的节点组之间应用，确保不同分组上的查问性能没有显著的差距。
4.3 基于负载的节点抉择
executor 节点会呈现多种起因导致计算资源应用不平衡的问题，比方数据歪斜导致某些 executor 节点须要耗费更多计算资源扫描和解决数据，或引入混合分组个性导致某些节点组上节点负载过低等等。
针对该问题，NDH Impala 进行了两个优化。第一个是反对基于 executor 节点负载的查问分布式执行，实现办法为在为查问 SQL 确定分布式执行打算时，思考 executor 节点以后可用的计算资源状况，剔除可用资源较少的 executor 节点；第二个是存在多队列时，限度同个队列上的查问申请在一个 executor 上的资源应用总量，防止 executor 资源被某个队列独占。
5 小结
本大节次要介绍了虚构数仓概念的起源和实现，重点剖析了 NDH Impala 在虚构数仓这块的摸索、思考和应用。目前虚构数仓在网易互联网业务以及网易数帆的商业化客户集群上均有胜利的利用案例。
笔者认为，虚构数仓应该是新一代剖析性数仓必备的一个能力，它可能剥离简单多样的业务负载，充分发挥执行引擎本身的能力。最初须要指出的是，虚构数仓是一种云原生的个性，计算资源可能灵便伸缩的环境可能最大化其价值。
作者简介
荣廷，网易数帆数据库技术专家，10 年 + 数据库相干工作教训，目前次要负责高性能数仓和云原生数据库研发工作。作者：网易数帆社区链接：https://juejin.cn/post/713350… 起源：稀土掘金著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。
