各位小伙伴晚上好,我是联通数字科技有限公司数据智能事业部的王兴杰。
今天,我将和大家聊一聊联通数字科技有限公司是如何基于Apache 构建一体化能力平台的。
今天的分享主要分为三个部分:
关于DataOps的一些思考;
企业在实施任务调度系统时的一些困境和困难;
我们基于Apache DolphinScheduler所做的一些改造。
在谈及任务调度系统时,我们往往会提到DataOps。那什么是DataOps?为什么它与任务调度系统密切相关?企业的数据加工链路中涉及的工具往往不仅仅只有任务调度系统,还包括数据集成、数据治理、数据应用等其他平台工具。
这种情况下,如何解决数据加工链路上的断层,以及如何降低用户的使用成本等等问题需要有一个指导思想,这就是DataOps。
DataOps是基于DevOps提出的,参照了软件研发、发布的流程,对数据的研发、治理、运营体系进行指导,旨在优化数据处理流程,提高数据处理的效率和质量。
在企业实施DataOps的过程中,通常会遇到以下几个主要问题:
复杂的数据接入需求
企业的数据源种类繁多,包含结构化和非结构化数据,并且存在批数据和流数据同时接入的情况。以往单一的开源数据集成工具难以满足企业复杂的数据接入场景和多样的数据源类型。
同时,由于数据源类型和网络等数据加工场景的复杂性,企业很难获取全链路的数据血缘关系。
数据治理介入时机不够完善
企业很难持续高质量的产出满足客户要求的数据。一旦数据出现问题,排查整个数据加工链路的成本很高,如果对数据加工链不熟悉,查找问题节点和修改问题的成本会更大。
长链路的数据加工尤其容易导致问题排查困难,修改问题时还要考虑下游节点的依赖关系,避免盲目修改引发生产事故。当然这种情况的生产事故问题可能不仅由于数据治理,也可能因为需求变更或bug修复导致。
人才需求问题
企业在实施DataOps过程中,通常会遇到技术人员不懂业务,业务人员不懂技术的情况。这主要是企业组织架构问题,尤其在大型企业或数据加工复杂的企业更为明显。
平台维护、数据研发、生产运营的人员通常由不同部门负责,彼此对对方的工作了解不多,数据管理意识薄弱,缺乏统一的数据标准和规范,导致口径不一致,问题处理困难。。
工具集成问题
企业使用的工具通常独立运行,用户操作需要在不同系统间跳转,甚至使用不同账号和配置进行处理。
这种情况不仅增加了操作复杂性,还可能导致数据孤岛和处理效率低下。
在讨论DataOps时,理解数据研发与软件研发的差异非常重要。虽然DataOps借鉴了DevOps的概念,但数据研发和软件研发之间仍存在显著差异。
在需求阶段和设计阶段,数据研发和软件研发的差异并不明显。
软件研发关注的是软件的架构设计和需求的流转,而数据研发则更关注数据的来源、分布以及数据研发的架构等问题。
在研发阶段,数据研发和软件研发的方法和流程相似。两者都需要经过需求分析、设计、编码和测试等步骤。
但数据研发更注重数据的处理和转换 ,而软件研发则更注重功能实现和代码质量。
在测试阶段,数据研发和软件研发的差异较为明显。
软件测试:在需求评审阶段,测试人员已经明确了解点击某个按钮或发起某种请求后应该得到的结果。测试周期通常较短,测试人员和研发人员可以快速沟通并修复bug。
数据测试:数据测试过程更为复杂。在需求提出时,可能对数据结果不够明确,结果的判断需要依赖研发人员或业务人员的经验,或通过其他数据搭配可视化分析工具来辅助结果确认。数据测试周期较长,一些大型复杂的数据加工任务可能会经过一个月甚至更长的时间才能得到测试结果。
软件系统的运维阶段,侧重于保障软件系统的稳定运行,处理故障、优化性能、进行系统升级等,以确保业务的连续性。而对于数据来说,除了运维以外,更应该关注的是数据运营,要持续关注数据安全、数据质量等问题。
DataOps从研发管理到运营管理的所有阶段,都可以在任务调度系统中完成。任务调度系统在整个数据加工链路中扮演核心角色,是解决DataOps困境的关键入口。所以我们结合DataOps与任务调度系统可以更好的解决企业在实施任务调度系统和DataOps平台的困境。
数据研发与软件研发虽然在某些阶段和流程上有相似之处,但在测试和运维阶段的差异尤为明显。
理解这些差异对于有效实施DataOps至关重要。通过采用适当的工具和方法,企业可以更好地应对数据研发中的挑战,提升用户体验,提高数据处理的效率和质量。
而Apache DolphinScheduler作为任务调度系统,可以在DataOps的各个阶段提供支持,帮助企业实现一体化的数据处理和管理。
任务调度系统是DataOps平台工具中的重要组成部分,对于企业的数据加工任务来说也是核心平台工具,企业在实施任务调度系统时往往也会有多方面的要求。
挑战一:稳定性要求
企业对任务调度系统的首要要求是稳定性,要充分确保数据加工任务和业务的连续性,同时系统也需要具备一定的风险抵抗和预警能力,以应对突发状况。
Apache DolphinScheduler采用核心的分布式去中心化架构,并结合服务融合机制,能够充分保证系统的稳定性。即使在极端情况下,部分节点丢失也不会立即导致系统崩溃。通过Master和Worker机制及其队列处理机制,系统可以有效避免服务器崩溃的情况。
挑战二:处理复杂多样的数据加工任务
不同企业的数据加工任务场景会有所差异,最好是能够万全兼容原有数据加工任务和场景。对于一些不常见的情况,也要求二次开发成本尽可能低。
Apache DolphinScheduler目前支持38种数据加工类型节点,能够覆盖大多数企业的数据加工需求。
如果遇到极端或不常见的情况,Apache DolphinScheduler的代码结构规范简单,二次开发成本低,可以轻松增加新的数据类型节点。
挑战三:使用简单
企业在选型任务调度系统时,功能的多样性和操作的简便性同样重要。Apache DolphinScheduler提供了可视化的拖拉拽DAG编辑页面,对用户非常友好,降低了学习成本。
对于技术人员和业务人员来说,传统的脚本式开发工具学习成本高,而DAG编辑页面则更易于接受和使用。
挑战四:系统的可扩展性
任务调度系统需要具备灵活的扩展和缩容能力,以适应企业业务的发展和变更。在扩展过程中,不能对现有任务产生任何影响。
Apache DolphinScheduler通过其分布式架构,可以在不影响现有任务的情况下进行系统扩展和缩容,确保系统的高效运行。
Apache DolphinScheduler的解决方案
稳定性: 通过分布式去中心化架构和服务容错机制,确保系统在极端情况下的稳定运行。
多样性处理: 支持38种数据加工类型节点,满足复杂多样的数据接入需求。
易用性: 提供可视化的DAG编辑页面,降低用户的学习和使用成本。
可扩展性: 灵活的扩展和缩容能力,在不影响现有任务的情况下进行系统调整。
系统集成: 统一调度插件简化系统集成,提高整体工作效率(开源之夏正在研发中)。
企业在实施任务调度系统时,面临着稳定性、数据处理多样性、使用简单性、系统可扩展性和工具集成等方面的挑战。
而Apache DolphinScheduler通过其先进的架构设计和丰富的功能,提供了全面的解决方案,帮助企业高效地实现数据加工和任务调度,确保系统的稳定运行和业务的连续性。
在联通数字科技有限公司,我们基于Apache DolphinScheduler构建了一个大规模的任务调度系统。
以下是我们的当前规模:
单日任务处理量:超过十万。
Worker集群规模:125台机器。
K8s集群:搭配了两套K8s集群用于承接Worker运行的任务。
为了应对庞大的数据量和集群规模,我们进行了以下二次开发和改造。
我们主要使用以下两种数据类型节点:
Shell节点: 主要用于传统服务器运行的任务数据加工类型。结合数据开发平台(后续会详细介绍)和文件管理系统,实现不同数据加工类型任务的运行和封装。
K8s节点: 支持应用镜像的构建、存储,以及K8s集群中的监控和日志查看。由于K8s节点的日志和文件会在pod销毁时丢失,所以我们适配了一套网盘系统,以便下游节点依赖上游节点的数据加工结果(如文件或日志)。
为了增强任务调度系统的功能,我们实现了以下辅助节点类型和功能,并将大部分功能贡献给了社区:
流程参数与条件判断节点:用于动态控制任务流程。
批量子流程节点:用于批量任务处理。
业务系统节点:通过统一调度插件实现对业务系统的集成。
我们还对调度策略进行了改造,主要包括:
任务组控制:用于控制任务的并发度,已贡献到社区。
参数触发:解决下游工作流依赖多个上游工作流的问题,通过参数触发满足功能要求。
为了配合上述改造,我们还开发了一个数据开发平台。
该平台包括以下功能:
模板与代码管理: 通过模板和代码管理系统(git、hdfs),实现对不同数据加工类型任务的统一管理。
镜像管理: 支持应用镜像的构建、存储。
监控与日志管理: 实现对任务运行状态的监控和日志的集中管理。
通过以上的实践和改造,我们在Apache DolphinScheduler的基础上,构建了一个高效、稳定、功能强大的任务调度系统,能够满足大规模数据处理和复杂数据加工的需求。我们也积极将部分功能贡献给社区,促进开源生态的发展。
在我们基于Apache DolphinScheduler的实践中,服务管理是一个针对开发人员的重要功能模块。
服务管理主要包括以下几个方面:
版本管理和在线升级
支持在线版本升级功能,通过页面实现发布包的分发和版本管理。
服务的重启可以通过页面完成,确保系统在进行版本更新时的平滑过渡。
服务的上下线管理
服务上线:服务正常运行,开始接收新任务。
服务下线:服务停止接收新任务,但现有任务继续运行,直到完成。这个功能主要应用于Worker节点。
通过Worker分组和服务下线管理,可以实现服务的滚动升级,确保升级过程中的任务不会受到影响。
多环境管理
我们的开发平台支持数据的开发和测试环境管理。
可以以DAG为单位进行发布,即整个工作流的定义经过测试后可以发布到生产环境。
确保开发、测试和生产环境的隔离,提高数据加工任务的可靠性和稳定性。
在实际应用中,我们通过这些服务管理功能,确保任务调度系统的高可用性和灵活性。
例如:
在线版本升级: 通过在线版本升级功能,开发人员可以在不影响现有任务运行的情况下,对系统进行升级和维护。通过页面实现发布包的分发和服务的重启,极大地提高了运维效率。
服务下线管理: 在一些特殊情况下,需要对某个Worker节点进行维护或升级,通过服务下线功能,可以在不影响现有任务运行的情况下,停止该节点接收新任务,确保系统的平稳过渡。
动态升级和滚动升级: 通过Worker分组和动态升级、滚动升级功能,可以实现系统的平滑升级,避免因升级导致的任务中断或失败。
通过上述功能的实现,我们在确保系统高可用性 的同时,也提高了系统的灵活性和可维护性。
这些功能在实际应用中发挥了重要作用,帮助我们更好地管理和维护任务调度系统。希望这些实践经验对大家有所帮助,也欢迎大家一起交流探讨,共同提升任务调度系统的管理水平。
在维护和管理数据处理流程中,我们通过一些统一的分析指标进行统计分析和告警管理。
这些指标提供了对系统运行状况的可视化展现,帮助用户更好地理解和优化任务调度。
工作流实例运行分布图
我们为每个项目划分工作流实例的运行时间分布。通过颜色区分不同时间段的运行情况,用户可以直观地看到在某个时段内运行的工作流数量和运行时间分布。
例如,对于T+1的批处理任务,用户可以通过分布图决定最佳的运行时间,以确保服务器的负载均衡。
作业执行关系图
显示作业与执行器之间的关系,Master与工作流、Worker与任务之间的关系。
用户可以通过这些关系图分析在不同时间点的任务运行数量,帮助优化任务调度配置。
这些图表有助于用户在决策过程中找到最佳的任务运行时段,从而实现负载均衡和资源的高效利用。
我们的数据开发平台内置了一套独立的任务调度系统,支持开发和测试任务的全流程管理。
该平台提供了以下功能:
在线代码编写与测试
用户可以在平台上完成常见数据处理任务的代码编写和测试,包括HiveSQL
、Sparksql
、Python
等。
平台内置了一个在线代码编译器,方便用户进行数据处理任务的开发和测试。
应用镜像构建
根据不同的语言和版本,我们维护了不同的基础镜像,这些镜像可以用于任务开发和测试。
任务调度系统
除了数据开发平台自带的任务调度系统外,我们还提供了生产环境的任务调度系统,两者完全隔离,确保安全和稳定性。
用户可以在开发平台上进行工作流的开发、测试和定义,然后将其发布到生产环境的任务调度系统中,实现全流程的研发、测试和发布。
我们通过数据开发平台实现了完整的研发和测试流程:
物理隔离
数据开发平台和生产任务调度系统是两套独立部署的系统,物理上完全隔离,确保了环境的安全性和独立性。
完整的工作流管理
用户可以在数据开发平台上完成工作流的研发和测试,然后通过发布功能将工作流同步到生产任务调度系统中,确保工作流在生产环境中的正常运行。
最后会给大家介绍一下我们现在的数据资产管理路线,这是我们今天的重点部分。
当前,我们针对任务调度系统本身的需求已经基本上平稳。最近正在进行整体的改造,即数据加工链路中涉及的平台工具间的集成,这也就是我们提到的DataOps平台工具,一体化数据资产管理平台。
在DataOps的实施中,除了关于人才需求的问题需要企业针对性地做出组织架构调整外,很多在工具层面的问题都可以以任务调度系统为出发点去解决。
现在高版本的Apache DolphinScheduler支持Flink节点,所以围绕数据加工任务,无论是批量数据还是流数据,都可以在任务调度系统内完成。
从数据集成到数据应用,包括中间的数据治理和数据加工之间的依赖关系,都可以在一张图中展示。
我们可以看到在伪DAG图中,包含了从数据采集、数据集成、数据加工和数据治理的整个流程。
当然,数据加工和数据治理可能会有多个环节。可视化数据处理平台是我们内部提供的一个工具,主要用于标签、BI报表和指标等数据应用模块,提供基础的数据处理功能。
这个工具不需要用户具备技术基础,只需通过页面上的可视化操作,拖拽配置即可完成数据加工任务的配置。
对于一些对外交付的小型项目,我们可以简化数据加工过程,直接通过可视化数据处理对接数据采集,为指标报表和BI提供基础数据处理工作。
这个过程可以有效解决数据加工链路的断层问题。以前,如果不在任务调度系统内,其他业务系统可能通过结果通知或轮询数据结果来实现依赖。
而现在,所有数据加工链路的依赖都可以在任务调度系统内通过DAG图直观地看到,避免了数据加工链路的断层问题。
将数据治理节点集成到数据加工任务中,可以将数据治理前置,传统做法是完成数据加工任务后再做数据治理,这样出现问题就需要排查整个数据加工链路。
而将数据治理集成到数据加工任务的过程中,可以有效的保证每个节点或某一段数据加工链路的数据质量问题。
当数据加工任务修改了中间数据加工任务的结果后,我们无法判断哪些下游任务依赖当前数据加工任务的结果。依靠数据血缘分析仅能知道下游依赖的表,但不知道具体任务。
由于任务的依赖关系在任务调度系统中可能出现跨项目或底层数据依赖等情况,所以通过任务调度系统的任务血缘来判断,无法覆盖所有的下游任务。
所以将全链路的数据血缘与任务血缘相结合可以更为全面的覆盖下游任务范围,更好的做到影响分析从而减少生产事故。
本文由 科技 提供发布支持!