1.背景与挑战随着银行数据业务的快速发展，传统的数据仓库也面临着越来越多的挑战。提高了数据的时效性要求。同时，新技术不断涌现，技术架构从单一的数仓集群转向功能拆分，即将单一的数仓拆分分解为不同功能定位的数仓集群，从而提前感知业务变化，快速响应。准确使用资源和其他目的。对于数据仓库的运维，“一个数据仓库可以容纳全行业务数据”和“只需要维护一个数据仓库”的日子一去不复返了。传统的“人肉运维”已经不能满足当前和未来的运维需求。传统运维工具在某些场景下可以快速处理已知问题和故障，恢复生产，但终究还是属于被动运维的范畴。在当前数据仓库不断扩容、业务需求不断提升的背景下，业务中断越来越不能接受，最终的结果将是累死被动运维。在数据仓库发展的大背景下，保证业务的正常开展，保证业务的连续性将是数据仓库运维的首要职责。2、响应与解决方案运维是为了保证业务的正常运行和发展，而不是出现问题后“堵洞”。虽然运维的经验告诉我们：由于各种天灾人祸，“堵洞”肯定少不了，但很大一部分事故故障是有先兆的。海恩定律表明，29起小事故、300起事故征兆和1000起潜在事故会导致一场大事故。魏堤薄弱环节和隐患，制定完善的应对预案，提前加固，消除隐患。随着银行数仓的不断发展，运维的思路也在不断演变，逐渐从被动运维向主动运维转变，结合现有运维经验，推动主动运维在数据仓库领域。经过多年的经验积累，G行已经形成了较为成熟的数字仓运维方案，即主动运维与应急响应相结合。“主动运维”可以提前发现问题，消除隐患。快速响应，业务恢复，为数据业务保驾护航。3.数据仓库运维实践不同于传统业务数据库。数据仓库具有独特的条件。数据仓库是所有业务数据存储、分析和处理的核心。数据仓库可以通过本地资料收集、归纳、归纳、存储自己所有的运行数据。通过数据仓库的数据存储、分析和处理能力，可以对数据仓库的各种运行数据进行采集和处理。最终形成有效的数仓运行数据，实现数仓运维数字化。GBank数仓运维的探索与实践，始终基于容量管理等日常生产运维需求场景，以保障业务连续性、释放人力资源、故障准确定位、业务快速恢复等为目标、故障处理等。采集应用业务运行、底层资源消耗、数仓运行监控等各种运行数据，建立多维度的数仓运行模型，可以准确记录每个时间点的运行状态和多个维度。综合运营数据采集包括底层资源数据、数仓系统运营数据、业务运营数据等诸多方面。底层资源数据：包括CPU、内存、IO、网络、系统层各个进程的资源消耗，尤其是底层资源的横向对比。数据仓库最大的特点就是中心化，而中心化最大的隐患就是一触即发，牵一发而动全身。资源节点瓶颈大概率会降低整个数据仓库的处理性能。就运维体验而言，除了全局的性能问题，“木桶效应”的局部故障导致的大概率性能下降或整体性能下降等问题，局部故障可以从横向获取全球基础资源的比较或历史。资源消耗纵向对比，快速本地化，快速处理恢复企业生产。数据仓库操作数据：数据仓库的操作不同于常规数据库的操作。常规数据库的运行情况可以根据QPS、TPS等指标综合判断，而数据仓库受限于其运行的业务场景特点。很难梳理出一两个指标来判断操作。现状，并且由于处理数据规模和场景的复杂性，通常一条常规的SQL也会导致数据仓库整体运行压力暴涨。这就是数据仓库操作和业务数据库操作的区别。业务运营数据：业务运营数据也是不可或缺的一部分。不同于单一的业务系统数据库，数据仓库往往是基于复杂的多业务场景，必须适应所有连接的业务。通过监控业务运营数据，发现业务场景变化，有效快速定位问题。从果上找原因，??业务的发展变化往往是数据仓库运行发生变化的根本原因。需要对业务运行数据进行采集和监控，纳入数据仓库整体运行监控。G行在探索实践中，数据采集和监控告警指标达100余项，其中底层资源采集指标达20余项。除了常规的CPU、内存、IO等资源外，更关注可能影响数据仓库运行的细节项，如磁盘坏块数、负载波动、进程资源消耗、文件系统文件数、内存分页效率、句柄使用率、僵尸、残留进程等详细指标；数据库运行等50余项采集指标，包括库执行效率、实时访问量、访问时长、阻塞队列、库实例级资源消耗、倾斜SQL、低效节点、Xlog同步、数据页读取效率、ETC。;采集业务相关指标10余项，时间点并发业务、单项任务时长、累计时间、完成任务百分比等；20多个其他收集指标。随着业务的发展，运维场景不断丰富，所需的采集指标项也在不断完善。总之，“与时俱进”。运行数据最终图形化呈现，全面排查，快速识别异常。以数据仓库的各种运行数据为基础，根据生产运行场景和日常运维需求，形成针对性的监控模型，通过模型检测运行异常、运行变化等问题。同时，在运营模型的基础上，通过实际结果的反馈，逐步优化监测模型，进而优化各项监测采集指标，形成可行性高的闭环系统。通过场景模型的上线、反馈优化、反馈的不断完善，逐步形成数据仓库的数字化运维平台。随着运维分析模型的建立和完善，除了可以对潜在的运维故障进行早期预测，对突发运维故障进行一定程度的快速定位外，还有一个重要的运维场景：故障回溯。因此，当出现很多故障时，往往无法有足够的时间来分析和定位问题，有些问题隐藏得很深。一旦发生影响生产的事件，一般采用强制手段恢复生产。现场、全面的运行数据采集和留存，可以在一定程度上实现现场留存，为后续的故障分析和定位提供运行数据支持。数据仓库运营数据采集基础建立后，可逐步向上衍生，实现运维功能的自动化。G行数据仓库运维平台建设以自动化、标准化、数字化为原则，基于运维成本、运维质量、运维效率的综合考虑。它包括以下五个功能：业务诊断：通过对业务运营实施跟踪监控，检测业务运营状况；通过历史故障分析模型对实时提交的业务进行分析，对发现的与模型匹配的异常业务访问进行自动处理；在对实时业务进行监控的同时，将运行信息保存在历史中，为后续的故障定位、场景分析、业务回溯做准备。健康监控：实时监控应用状态、基础资源使用情况，模拟业务场景不间断平台监控，实时健康监控，即时响应运行偏差。闭环优化：包括应用业务优化和数据仓库自优化。应用业务优化对收集到的业务运营信息进行整理，自动向相关人员推送低效业务信息和优化建议，督促整改，提升业务体验；数据仓库自优化通过检测访问连接数、并发度和底层资源使用情况动态调整资源分配。容量评估：通过对数仓各集群的计算能力、空间、业务运行时效等多个维度的综合容量评估，可以快速有效地对数仓容量进行日、周、月报表推送的监控和评估。实现有计划的数据仓库容量管理。随着G行各项经营指标数据采集的积累和沉淀，基于业务和运维需求场景，每天使用数十GB的经营数据，根据不同的需求场景建立支撑模型，利用日益完善的数字化和自动化架构，实现快速需求响应。4、数据仓库运维展望我们认为，随着运维技术的不断演进和发展，运维经验的不断积累，工具化和自动化的深入发展，量变将带来质变，数据仓库运维的智能化也将在不久的将来实现。
