如何套用别人网站做页面,常州网站推广软件信息,做电子书下载网站会不会侵权,做网站如何接单本文是我在实时数据计算系统的设计、开发、运维生涯的一部分经验总结。主要介绍一些设计思路和常见问题的解决方案#xff0c;不关注具体计算框架的使用。本人主要致力于监控系统数据计算方向#xff0c;主要业务场景有#xff1a;监控数据的ETL、数据汇聚、分析、异常检测等…本文是我在实时数据计算系统的设计、开发、运维生涯的一部分经验总结。主要介绍一些设计思路和常见问题的解决方案不关注具体计算框架的使用。本人主要致力于监控系统数据计算方向主要业务场景有监控数据的ETL、数据汇聚、分析、异常检测等。由于监控系统对时效性有较高需求所以我们的计算系统更偏向实时系统根据业务场景的不同延迟从数百毫秒到分钟不等。下文提到的计算架构更多是指整个计算处理通路主要以监控场景下的系统设计为例相信与其他场景下的架构也有相通之处。文章从以下几个方面展开首先在第1节我们简述不同数据规模和场景下监控系统计算架构的可选方案。在公司、业务发展的不同阶段主要矛盾不同能够投入人力物力资源不同需要选择合适的架构方案。实时计算系统的设计有一个核心问题如何同时满足高时效性和数据准确性在现实环境中高时效性和准确性很难同时达到第2节中介绍了Watermark机制以实现两者的平衡。第3节介绍百度监控系统的实时计算系统架构描述了其基本组成、思路和实现中一些常见问题的解决方案。最后简单讨论了实时计算系统可用性建设。监控系统计算架构选型对于包含数百到千级别节点的小集群数据规模有限所有采集、存储、计算逻辑都可以集成在一个模块中实现这种多为领域专用系统。监控系统中典型的有Prometheus其采用单服务节点架构提供简单的HA模式进行容错这种架构的优点是部署使用简单。受限于单机资源适合部署自治的多个实例每个实例监控不同服务。大规模集群情况下要实现全局的监控需要合并多个监控实例的数据在配置分发、可用性、容错、自动化部署管理等方面都需要更多的工作。从开发角度考虑由于功能耦合严重不利于开发升级。比起领域专用系统还有一种架构是使用通用性更强的OLAP系统来实现实时或者近实时的计算功能如TSDB、ElasticSearch等系统都有一定的聚合计算能力。这些分布式系统都有水平扩展能力和容错能力但难以实现复杂业务计算同时延迟不可控复杂查询或大批量数据查询的延迟可能会达到分钟级别。更多的情况下我们采用存储计算分离的方案以便存储和计算的各自演进和平台化。通常由一个提供精细查询能力的存储服务与一个计算模块组成。计算模块根据计算规则从存储系统中拉取数据并进行计算这个架构的瓶颈在于存储系统能够支持的查询规模。根据我们的经验基于精心设计的内存数据库集群能够承受百万级别的并发查询。这种架构下计算任务多为周期性调度当查询性能下降时会造成任务的堆积。这个模型不方便处理延迟数据需要一定机制预测数据完整时间调度任务进行重算任务调度的复杂度高。基于索引查询的计算系统的延迟取决于计算轮询的周期适用于聚合类的涉及时间窗口的运算操作。在更高数据量和计算规则的情况下流式计算是一个自然的选择降低了写存储、索引、查询的消耗计算延迟大幅降低。当数据量进一步上升需要的网络吞吐、计算能力骤增后端的算力难以跟上数据量的增长。这时候可以将计算能力分散到全链路将计算提前到数据产生端。在监控系统中通过在采集端进行预计算和ETL操作提取或整合有用信息对于实时日志采集能大幅度降低传输到后端的数据量。放到更大的视角上这种将算力下放到数据源的思想是目前大热的边缘计算的一个主要思路。近年来Serverless计算架构得到了更多的重视。这个模型将计算抽象为事件以及触发的计算逻辑计算逻辑实际由框架调度、分配资源执行。用户只需要编写计算逻辑而不用关心可用性、可扩展、负载均衡等后端代码极大的降低了开发成本。通过按需调度自动扩缩容业务运维方不再关心容量规划等问题。私以为当前常见计算框架的Serverless化是一个值得尝试的方向。目前的Serverless框架还存在很多问题例如调度初始化虚机、容器的成本高缺乏状态存储等比较适用于无状态的计算。一般来说根据场景需求通常对不同的架构会组合使用。例如百度监控系统内部是以流式计算与近线计算相结合的方式提供服务的近线计算从时序数据库(TSDB)中拉取数据进行计算。对于Trace、在线数据分析等具有比较复杂查询需求但是相对比较低频的操作更适合基于索引查询的架构。准确性与时效性对于实时系统我们对时效性有更严格的需求但是通常高时效性伴随着低准确度二者不可兼得。在分布式环境下天然存在长尾的延迟数据这可能是原始数据自身的延迟也可能是由采集点异常、网络延迟、网络抖动、数据通路中负载等造成的延迟。数据源越多分散的越广这个长尾效应就会越严重等待数据完整所需要的时间也越长。我们需要在最终数据的准确性和时效性间做折中。不同场景对两者的需求不一致通常来说报警、自动止损等操作需要最高的时效性能够容忍一定的精度缺失在审计、订单等数据上我们更多的追求准确性时效性可以适当放宽。解决这个折衷的常用机制是Watermark。Watermark是在数据流中增加标志信息用以指示一个窗口内的数据已经“完全”到达可以进行计算。示例假设我们要统计10s内到达的事件数目以事件时间(Event Time即事件携带的时间多为事件产生时间)作为时间基准。如下图所示横线为Wall Time时间线单位为s。圆球表示事件圆球里面的数字为事件时间其虚线指向产生时间圆球正对的Wall Time时间线上的点为被计算系统处理的时间(Process Time)两个时间之间的差值为实际延迟。每个事件都或多或少存在延迟其中数字为45的圆球延迟最大。对于事件时间[40, 50]这个汇聚窗口假设我们将Watermark线画在53处则我们认为数据在53之前已经完全到达已经接收到的那些数据可以参与汇聚Watermark之后到来的事件则忽略。具体怎么确定Watermark通常取决于需求对于数据点数量级比较稳定的场景可以设置一个到达的数据点的比例在某一个判断周期内只要到达的数据点比例满足阈值则可添加Watermark。主流开源计算框架对Watermark的实际定义不尽相同具体使用参考对应计算框架的定义。私以为Watermark机制隐含的一个重要思想是将数据准确性的定义交还给用户让用户决定。产品或者架构上的功能存在多种方案的情况下选择最泛化的那个方案暴露出参数然后让用户来选择不要自己替用户做决定。当然为了简化实现成本和用户使用成本可以设置固定的一些选项并选择一个需求最大的作为默认值。通常Watermark之后的过期数据点会被丢弃。经常的除了满足高时效性需求外我们也需要在之后保证数据的最终准确性即在一定时间段之后的数据是准确的。常用思路是部署两套计算系统流式计算用以实现低延迟但是准确性低的需求批量计算用于补偿计算数据的准确性这就是Lambda架构。最典型的使用Lambda架构的场景是从日志中统计PV/UV通常是一个流式采集系统和流式计算框架进行实时的PV/UV计算同时有一套离线系统定期拉取原始日志通过批量计算系统统计准确的PV/UV数值。通常这种架构的缺点是两套系统的资源消耗开发运维成本高。当前主流计算框架如Spark和Flink对流式和批量计算进行了统一抽象。可以一定程度降低两套系统的开发运维成本降低了不同框架的开发运维成本两次计算的的资源消耗依旧存在。对于满足交换率和结合率的算子如常见的统计方法(MAX/MIN/SUM/COUNT)在存储侧支持相同运算的情况下可以将两次运算合并成一次。我们内部称这个方案为多版本即数据生产一部分就汇聚一部分每次汇聚产生一个数据版本由存储在写入时合并或者在查询时合并。本质上这是将汇聚的功能迁移了一部分至存储。百度监控实时计算系统架构百度监控系统的实时计算系统承担了监控系统数据处理栈的主要计算功能每天处理数千亿条消息。本节在实际系统的基础上进行了一定的抽象介绍一个较为通用的系统架构。如图所示架构主要包含以下组件接入模块包括数据拉取和数据接收前者主动拉取数据后者接收由上游模块推送的数据。分发模块根据配置的计算规则过滤订阅的数据并根据调度策略、集群状态将规则对应的数据分配到一个或多个处理单元进行计算。处理单元包括一个物理计算模块和对应的输入输出消息队列。物理计算模块执行实际的业务计算逻辑不同处理单元间可以是同构的也可以是异构的根据不同的业务场景和用户需求可以使用不同的技术栈。控制模块接收用户提交的计算规则和管理操作分配调度资源产生对其他模块的控制信息。数据推送模块拉取计算结果根据计算规则将数据分发到下游模块。每个物理计算模块都对应一个输入和输出消息队列以将数据接入、据输出与计算层隔离增加一个新的第三方系统的交互不会影响计算功能。升级变更物理框架不会影响其他组件。由于大数据处理框架在其数据规模、节点数目达到一定规模时其处理性能以及异常恢复速度都会下降。我们将一个固定计算能力以及配套的资源(如消息队列)抽象为一个处理单元每个处理单元处理一部分的数据取决于计算功能的物理实现这个处理单元可以对应一个集群或者一个作业。一个处理单元的具体规模取决于具体的技术选型和硬件条件。确认处理单元的好处是便于容量规划可以以一个处理单元作为粒度进行扩缩容。如果需要嫌粒度过大分层次进行扩缩容先在一个处理单元内部扩展直到极限之后启动一个新的处理单元。实现中需要考虑以下几个点1、负载均衡负载均衡发生在系统的每一个层次。数据接入层与和分发模块之间的采用随机发送的策略以均衡分发模块的压力。数据拉取和数据推送模块需要动态平衡每个实例上的拉取或推送任务常用的策略是一致性哈希以每个任务的实际数据量作为权重。计算过程是最需要考虑负载均衡的场景聚合计算通常会遭遇数据倾斜问题即某些key的数据量远大于其他这就造成汇聚该Key的任务OOM。下面提供几种常用解决思路对于满足交换率和结合率的计算方法如MAX/MIN/SUM/COUNT等可以添加多层预聚合降低最终聚合的数据量。预聚合层次间可以随机方式最终汇聚之前按Key哈希。负载均衡或者说任务调度对应Bin Packing等一系列等价的最优化问题。这些问题是NP-Hard的可以通过近似算法来逼近典型的有First Fit算法。实现时一般需要自定义计算框架的分区逻辑如Spark可以通过自定义Partitioner来实现。2、控制节点扇入扇出规模无论是具备状态副本的分布式存储系统、基于DAG的分布式计算系统还是Stateless的接入集群当集群规模持续增大时节点间交互会显著增大最差的情况下全连接扩容节点会有指数级的连接增长。这会严重影响系统对水平扩容能力扩容带来的收益跟不上单机资源消耗的增长。对于分布式系统通过控制集群或者作业规模可以实现一定程度的控制对于接入模块可以限制下游连接到上限。可用性对于可用性要求高的服务可以多集群热备的方式在上述架构中可以通过运行多个并行的处理单元处理相同的数据流来实现。也可以部署整个集群通过采集端多写的方式复制数据流。最后需要根据输出结果的延迟、准确度等判断策略选择一个计算结果输出。服务无损升级可以通过启动一个新的计算单元并行处理数据待数据“预热”后进行切换。在部署时接入模块尽可能的靠近数据源保证每个地域一套。系统多地域部署每个地域内部模块间尽量自治。接入端发送数据时优先发送本地域异常时尝试其他地域。模块间交互可以打QoS(服务质量)标签增加网络优先级以降低网络丢包。监控上除了基础资源、流量等监控外最重要的是全通路时延监控常见方案是构造业务流量统计在系统中的延迟。这个延迟指标通常是多维度的根据部署和业务使用情况可能需要关注不同地域不同业务不同处理通路的延迟。这些延迟指标可以指示系统进行流量调度或者资源的重分配。总 结本文简单介绍了百度的分布式监控计算系统架构的演进和当前的实时计算架构并提供了部分常见问题点解决思路。架构是不断在演进的我们的系统仅仅是“够用”还有更多的工作需要开展如架构的轻量化统一易用的计算表示层计算的自动优化等。由于个人水平有限如果行文中有错误或者有需要进一步探讨的请在留言中指出。
