下载掌阅APP，畅读海量书库
立即打开
从广义来说，容量规划
是确保IT资源足以经济高效地满足目标业务需求而进行的IT资源规划。系统容量是指系统处于最大负载状态或关键指标达到所能接受的最大阈值下对业务请求的最大处理能力。从狭义来说，容量规划主要是根据业务服务需求对计算机与网络系统的CPU、内存、磁盘、网络及其他组成设备等的配置、构成集群的物理或虚拟计算机节点数量等基础设施资源规模，以及软件系统的性能与容量相关设置的规划；在云计算环境中，也包括对支撑业务的云计算服务规模的规划。实际上，容量管理（包含规划）是一个综合领域，涉及服务器性能监测、性能分析、性能调优、对工作负载随服务规模变化的理解、对计算资源需求的影响分析等，本书只局限于对功能范围已经确定的系统的初始容量规划。
本节主要聚焦从企业数据工厂角度的狭义容量规划，重点在系统配置和集群节点数量规划的考虑。主要包括3个步骤，如表2-4所示。① 业务需求获取。包括获取数据的范围、业务增长趋势、业务应用场景、应用用户规模、应用服务可用性及预期界面交互延迟等。② 相关技术指标求值。主要包括根据业务需求进行数据相关指标换算、计算负载分析与指标换算。③ 配置与规模规划。
表2-4 容量规划的典型步骤
一般来说，不同的业务场景在写入与存储、查询分析与计算方面的复杂度和比重各有不同，通常先基于数据指标评估存储相关容量，再进行业务负载分析与测试评估计算资源容量情况。串联上述3个步骤的示意如图2-5所示。下面首先讨论容量规划相关的典型业务需求及体量相关的技术指标，然后在此基础上展开讨论容量规划典型的3个步骤。
图2-5 数据工厂容量规划方法示意
首先，进行容量规划相关的业务需求获取。相关业务需求主要涉及3个方面。
（1）数据方面，包括诸如时序数据相关设备数量、每设备传感器数量、时序数据发送频率、时序数据保留期限，关系数据现存总记录规模、增量情况、单记录平均大小尺寸，文件数据现存总文件个数、增量情况、文件平均大小尺寸，数据保留需求、数据波动周期特征及数据可靠性要求等。
（2）数据处理方面，包括模型计算场景、分析模型规模、预期完成分析时间、数据查询场景及预期响应时间等。
（3）应用方面，包括应用用户规模、在线用户量、应用服务可用性要求、预期界面交互延迟等。
以上3个方面的需求均从价值线和创新线两个维度考虑。在实际情况中，价值线和创新线通常使用独立的IT资源。价值线通常涉及以上全部3个方面的需求收集，而创新线更侧重于计算方面和数据方面，原因是其有大量分析模型试验的需要。
通过基于业务主题场景的方式来收集和预估与数据工厂相关的上下文需求信息。这些需求获取的工作在STEP-DO的“可行性评估”阶段已经进行，包括分析与应用场景评估、企业数据情况评估及企业IT架构评估等过程。
其次，进行容量规划相关的技术指标求值。在相关的技术指标方面，主要包括数据相关技术指标及计算负载相关指标。
数据相关技术指标：在数据工厂中的数据采集、传输、接入、存储及访问等环节中有一系列数据系统和工具。根据业务需求进行数据量等指标的换算和预估是对这些系统和工具进行容量规划的基础。由于不同系统的功能目标和特性不尽相同，导致待预估的数据指标各有差异。如表2-5所示，按照不同的数据系统类别分别列出了相关的典型数据指标。不同类别的数据系统将在第3章进行展开。对价值线和创新线来说，虽然数据体量等具有差异，但数据指标预估方法是相通的，因此统一进行讨论。
表2-5 典型的数据相关技术指标
需要说明的是，由于数据系统工作机制不同，不同系统的相关技术指标并不完全相同，例如，有些系统的容量规划要与文件总数量、表数量、时间序列的个数等规模相关，此处仅列出有一定通用性的典型指标。
计算负载相关指标：在数据工厂中的数据接入汇聚、处理、分析、访问等环节中涉及一系列数据处理和计算、应用交互支撑的系统和工具。为了对它们进行容量规划，先要根据业务需求进行数据处理和数据应用的负载分析和预估。具有不同计算模式的系统（如离线批处理型、流处理型、交互式处理型）的待预估负载指标各有差异。如表2-6所示，按照不同的计算模式分别列出了相关的典型负载指标。关于对计算模式、分析模型构建环境、应用运行环境和低代码工具的相关讨论将分别在第3章、第6章和第7章中展开讨论。
表2-6 典型的计算负载相关指标
续表
不同的数据系统类别、不同的计算模式典型对应着不同的业务需求项和技术指标，在集群配置和规模规划方法方面也不尽相同。下面以2.3.1节介绍的业务需求和技术指标为基础，依照不同系统与不同计算模式分别展开讨论。
1.数据湖
数据湖的主要功能是存储各种类型的数据，包括时间序列数据、关系数据、文件数据等，并提供一个开放式的高吞吐的数据读写通路供计算引擎使用。主要的容量相关指标为数据存储量方面。典型的实现技术包括分布式文件系统（如Hadoop HDFS）、对象存储系统（如MinIO）等。
数据湖相关的业务需求项包括：（时间序列数据）设备数量、每设备平均数值型传感器个数、每设备平均开关量传感器个数、数据平均发送频率、数据保留期限，（文件数据）文件数量、平均文件大小，（关系数据）记录数量、单记录平均大小等。相关的技术指标（主要项参见表2-5）包括存量数据量、数据副本数/数据冗余度、增量数据量、数据保留策略（老化）、数据接入吞吐量、数据读取吞吐量/QPS等。
对集群存储空间总量的估算是数据湖集群配置与规模规划的开始，其是对存储设备（典型是磁盘设备）总容量的估算。为了简单表示，下面将业务需求项与技术指标共同作为输入进行集群存储空间总量的计算，而非严格地将所有业务需求项换算成技术指标，再全部从技术指标计算存储空间总量。
首先，估算存储空间总量（容量），分别从企业数据工厂中典型的时间序列、关系、文件3个类型进行，计算的逻辑如下（其中常量系数等可在实际中根据具体情况调整）。
对上述换算逻辑进行补充说明。① 因系统机制不同，副本数可以表现为数据冗余度。例如，在Hadoop HDFS v2以前考虑副本数（典型值为3），在HDFS v3及MinIO中考虑数据冗余度（大于1）；② 存储膨胀率根据不同的系统机制考虑：数据物理存储格式额外存储开销、统计或索引数据量、系统运行开销如系统日志、压实（Compaction）、混洗（Shuffle）操作等；③ 压缩比是原始数据量与压缩后数据量的比值，典型值大于1；④ 在存储利用率中考虑为保障整个集群稳定运行而预留的存储空间及为操作系统预留的存储空间（存储利用率的值小于1）；⑤ 在上述计算逻辑中，假定在数据存储年限内业务规模稳定，如果业务规模有增速的预期并且业务规模增长会导致数据规模增长，在换算逻辑中还应体现平均的数据增速率；⑥ 上述换算逻辑中未包含基于所存储数据进行加工而得到的派生数据或中间结果数据的分量。在实际建设中，需要根据具体情况进行估算。
上述估算是从原理角度计算的方法，另外一种方法是类比计算方法，即以同类数据的历史情况（例如，计算单位时段内的增量数据规模）为根据，对未来业务需求时段的数据量进行预测估算。在实际建设中，也可以结合上述两种方法的思路综合运用。
其次，规划集群配置和规模。集群配置要结合企业数据工厂建设背景、预算情况、具体系统选型等多种因素联合考虑，并且，因为数据技术生态中的各种工具和系统特性不尽相同，所以从存储空间到集群配置宜结合具体的系统选型进行，可以参考官方文档、业界最佳实践或基于自身实际测试。以Hadoop（2.7版）为例，一个典型推荐数据节点配置为CPU 32逻辑核心、128 GB内存、8或12块SATA磁盘或更多（如每块4 TB或8 TB或更大）、10 Gbit/s网卡。由此，数据节点数量由存储空间总量除以单节点磁盘空间大小得到。需要说明的是，以上举例是在对应软件版本为主流时代的常见经验数值，其会随着硬件水平的提升和软件架构的发展而有所变化。
2.流数据系统（消息引擎）
主要使用场景是针对工业时间序列数据进行流式处理与分析及高吞吐流式数据接入汇聚等。主要的容量相关指标为数据流速与吞吐量方面。典型的实现技术包括Kafka等。
流数据系统相关的业务需求项包括设备数、数据平均发送频率、每天接入的消息量、平均单消息大小、数据保留期限等。相关的技术指标（主要项参见表2-5）包括数据副本数、增量数据量、数据保留期限、数据接入吞吐量、数据读取吞吐量/QPS等。为简单表示，下面将业务需求项与技术指标共同作为输入进行存储空间总量的计算，而非严格地将所有业务需求项换算成技术指标，再全部从技术指标计算存储空间总量。
首先，估算集群存储空间总量（容量）。计算的逻辑如下（其中，常量系数等可在实际中根据具体情况调整）。
其次，估算集群承载的写入吞吐量。计算的逻辑如下（其中常量系数等可根据具体情况调整）。
对上述换算逻辑进行补充说明。① 消息可以是时间序列数据或关系数据，具体根据数据传输情况而定。每天平均新增消息量（在流数据消息引擎中，每条数据记录称为一个事件或消息）可以根据设备数、数据平均发送频率估算（时序数据），或者根据上游关系数据源的平均每日数据记录增量得出（关系数据）。② 存储膨胀率可以根据不同系统机制考虑：数据物理存储格式额外开销、系统运行开销（如系统日志等）。③ 数据写入量波动比（大于0）可以根据上游数据源产生数据及数据传输特性（如链路稳定性等）得出。考虑数据写入量波动率的目的主要是使系统能够容纳和处理写入吞吐波峰，避免在写入吞吐高峰时因容量受限导致写入延迟、拒绝或出错。例如，当假设80%的数据在20%的时间到来时，数据写入量波动比的简易计算方法为80%÷20%-1=3。④ 高峰期写入量占总承载吞吐量的百分比是为保障整个集群稳定运行而预留的能力空间。
最后，规划集群配置和规模。与数据湖方面的规划类似，因为技术生态中各种工具和系统特性不尽相同，所以集群配置宜结合具体的系统选型进行，可以参考官方文档、业界最佳实践或者自身实际测试。以Kafka（2.2版）为例进行分析。
（1）Kafka服务节点（Broker）数量。根据“估算总写入吞吐量”÷“单节点平均可承载写入吞吐量”得到节点的总数量。
（2）磁盘配置。根据将“估算总数据存储空间”÷“节点的总数量”得出每个节点的总磁盘存储空间，然后根据典型磁盘容量和单机位磁盘数量选取合适的值。Kafka系统使用SATA旋转磁盘即可，如果成本允许并且对流处理的延迟（包括流处理任务恢复时重放数据时的追平延迟等）需求敏感时，也可以使用SSD。
（3）内存大小。可以根据Kafka中的主题（Topic）数量及分区（Partition）数量、副本数确定，原则是让一定比例的数据可以缓存在操作系统缓存中。
（4）CPU配置。典型经验是16逻辑核心或以上。
（5）网卡配置。根据每节点高峰期写入吞吐量、副本同步网络流量（与副本数相关）、消费者网络流量计算出网络流量，从而得出网卡带宽。
3.离线批处理型系统
企业数据工厂中的大量数据处理逻辑与数据分析模型属于批处理型计算模式，包括典型的设备健康度评估类、参数寻优类、波动根因分析类分析模型等，也涉及数据的批量清洗、集成、批量特征加工等多种数据处理场景。批处理型计算系统主要的容量相关指标为计算资源消耗量。典型的实现技术包括Spark等。
数据处理和数据分析系统中计算作业的资源消耗量（尤其是内存消耗）、运行时长与处理分析逻辑及数据集密切相关。通过一定的经验，粗估其消耗值只适合作为初始步骤（例如，在Hadoop与Spark等系统中，面向其上负载的一个经验数字是CPU与内存保持1∶4左右的比例关系）。其仍需通过实际运行并测试所使用的典型处理和分析逻辑及数据子集，得出实际资源消耗、实际运行时长结果来作为规划的参照和输入。在选取被测目标逻辑时，可以根据逻辑特点归类分组，并根据典型性从每个类别分组中选取；数据子集也应具有代表性，如果有比较明显的波动周期，宜覆盖完整周期。
相关的业务需求项包括分析模型数量、分析模型运行时限、分析模型平均所使用的数据量等。相关的技术指标包括（主要项参见表2-6）：计算作业/任务数量、批处理作业/任务处理的平均数据量、业务峰值特点等。分析模型的业务逻辑决定了分析模型所使用的数据量规模、涉及的工业设备数量等情况。根据分析模型批量运行的时限需求，基于底层并行化计算技术，进而评估计算并行度与作业/任务数量。
首先，估算集群计算资源总量（容量）。基本的逻辑是通过每天并行运行的计算作业平均数量×每作业的平均资源消耗×（1+并行量波动率）÷（资源利用率）。其中，计算资源主要指CPU和内存；在资源利用率中考虑了为保障集群稳定运行而预留的资源量及为操作系统预留的资源量（资源利用率的值小于1）。
其次，规划集群配置和规模。技术生态中不同工具和系统特性不同，集群配置可以参考具体选型的官方文档、业界最佳实践或自身实际测试。以Spark举例，一般不要低于CPU 8逻辑核心、32 GB内存、4块SATA磁盘（用于支持计算系统本身运行）、10 Gbit/s网卡。当资源管理由Hadoop统一管理时，节点配置宜与Hadoop集群相同。然后，计算节点数量根据集群计算资源总量（CPU、内存）除以单节点资源量得到。
4.流处理型系统
企业数据工厂中流式数据处理与数据分析模型属于流处理型计算模式，主要场景如设备异常告警、质量指标监测等，也包括数据实时抽取、转换与加载等。流处理型计算系统主要的容量相关指标是计算资源消耗量。典型的实现技术包括Flink等。
相关的业务需求项包括分析模型数量、分析模型端到端延迟时限、分析模型平均所使用的数据量等。相关的技术指标包括（主要项参见表2-6）：计算作业/任务数量、流处理作业/任务处理数据的平均吞吐量、作业的并行度、流处理响应延迟、业务峰值特点等。由业务需求指引的分析模型计算逻辑决定了分析模型所使用的数据量规模、涉及的工业设备数量等情况；流式分析模型的端到端延迟时限需求决定了流处理作业并行度。
首先，估算集群计算资源总量（容量）。流处理的计算任务典型与流处理数据源的数据分片数量有关。例如，在Flink的流处理任务中，典型的数据源是Kafka中的流式事件（Event）数据。此时，Flink中的在线流处理任务数量典型等同于Kafka相应数据的总分区（Partition）数量，由此可以根据Kafka中流数据规模及相应的分区设置换算得出。基本的估算逻辑是集群CPU资源总量正比于每天并行运行的流处理任务数量；然后根据经验或者更宜基于实际测试得出CPU与内存的比例关系，进而估算出集群内存资源总量。
其次，在规划集群配置和规模方面，仍可参考具体选型的官方文档、业界最佳实践或者自身实际测试。以Flink举例，如果资源管理由Hadoop统一管理，节点配置应与Hadoop集群相同。通过所得的集群计算资源总量除以单节点资源量得到计算节点数量估算。
价值线与创新线的目标及关键要素各不相同。因此，在容量规划方法时各有侧重。通常情况下，二者是彼此隔离或独立的软硬件环境。
价值线规划的主要侧重点包括如下几项。
（1）高可用。主要包括服务的高可用性、数据处理与分析的容错处理、数据的高可靠性等。在规划时，着重考虑各个组件系统的高可用方式（包括主备、多活、分布式等架构）、数据处理与分析的容错处理配置与规划相关要求、重要数据的冗余度及数据灾备方案等。
（2）高质量。着重考虑数据质量相关的数据处理的负载量情况，质量监控自身的消耗等。
（3）高性能。主要包括系统延迟能力、系统吞吐能力、并行度及性能优化设置等。
（4）可观测。着重考虑系统监控相关的规划。
创新线规划的主要侧重点如下所示。
（1）数据存储。① 全量数据的存储。创新线侧重于让企业人员以自主方式进行数据智能创新，对数据的使用不仅需要近期状态监测或检测信息，还需要历史的运行数据、设备维修记录及历史事件等全量数据。在规划时，还可以从成本角度考虑数据冷热分级存储。② 中间结果数据的存储。创新线典型涉及大量的数据处理和分析模型构建试验，其间生成很多中间结果数据。在容量规划时需要考虑这些数据的存储空间。
（2）多版本。由于创新线分析模型的敏捷迭代开发和反复试验的特点，主要包括数据处理程序、分析模型的多版本能力、数据系统的数据追溯能力等，着重考虑各个组件系统的多版本支持方式及对规划带来的影响。
（3）可观测。创新线的自主性还要求对系统监控、性能监测等相关的规划，以便创新线方便用户观测和验证敏捷开发过程中的数据处理程序、分析模型满足特定指标要求。