长城汽车-IDC-数据中台部-刘永飞 高级工程师
我是长城汽车 IDC-数据中台部的刘永飞,给大家分享一下我们自研的一个数据同步工具平台,以及在使用这个工具过程中遇到的问题。今天的分享主要有四个部分:
本章节我将介绍一下我们自研的数据管道平台,包括技术架构、支持多种数据源、支持多种管道、主要界面、引擎设置、数据类型映射、人工告警和推广几个方面。
数据管道是一个基于分布式技术构建的数据传输平台,支持多种数据源海量数据的实时、离线的方式传输。
数据管道可通过简单的页面配置即可完成数据传输,操作过程简单且高效,降低用户使用门槛;内设告警机制,传输任务出现异常可第一时间通过钉钉将信息发送具体责任人。
我们从立项之初,其实是为了解决长城汽车在数据方面的一些问题,主要目标就是连接数据孤岛,加速数据的一元化。大家知道凡是涉及到数据,数据孤岛问题就是一个绕不开的问题,我们就希望能够通过数据管道连接好各个业务线、各个领域、各个系统,真正的打破数据孤岛。
另一个目标就是加速数据一元化了,数据一元化是长城汽车在数智化转型过程中一个关键目标,做数据一元化的第一步就是数据的快速汇集,我们也能够承担好这个快速汇集数据的角色。
给大家介绍一下我们的这个管道平台的技术架构。
整个架构中,最左边是一个数据源的源端,也就是整个数据的起点。最右边就是数据源的目的端,是数据的目的地。通过中间的这个数据管道,可以实现数据的传输,中间最下边就是数据管道资源池。
在数据管道中有一个资源池的概念,我们把它分为公共资源和私有化资源。公共资源是我们平台提供的,公共资源也做到了资源队列隔离,相互之间不会有影响。如果用户对于资源有特殊要求,我们也支持用户提供机器,提供私有化的资源。
在资源之上就是管道引擎层,引擎层中是我们自研的数据传输引擎,细节就不在这里体现了。
最上面的 web 层,我们提供了项目级隔离,任务管理、资源管理、日志查看、告警等能力,更加友好的让用户使用我们平台。
截止到当前的V2.1.4版本,数据管道平台可以支持 23 种数据源,基本上涵盖了主流的关系型数据库常见的大数据组件。
在现有支持的 23 种数据源基础上,细分到离线任务、实时任务的全量同步、增量同步维度后,数据管道平台可支持将近 900 种管道。
以常见的关系型数据库 MySQL 做为数据源为例,一共可以支持 38 个管道。
这是数据管道的 UI 界面,我们自研的初衷就是要简单,通过简单的交互,用户录入源端数据源、目的端数据源,连通性测试通过后,就可以进行任务的创建了。通过简单的页面配置,用户很快就可以创建出一个能够支持大数据量同步的任务。
这是数据源的管理用户界面,你可以根据你想要的类型进行对应的数据源连接参数创建,下面这张图以一个离线任务创建任务为例,来展示新建任务设置的界面。
数据管道平台可以根据任务使用的计算引擎(Spark/Flink)来设置任务运行过程中所需的资源参数。
数据管道平台可以根据任务使用的计算引擎(Spark/Flink)来设置任务运行过程中所需的资源参数。
目标库设置时可以方便的进行源端字段和目标端字段的映射。我们收集了Spark/Flink的数据类型映射字典,用于进行源端数据类型到目标数据类型的转换。
用户在创建任务的时候开启告警设置并选择通知用户后,如果任务执行失败,会在第一时间将告警信息发给通知用户的钉钉账户。
如果用户已经在数据管道平台处于登录状态,则点击”查看错误日志”可以直接跳转到任务实例的提交日志界面,查看日志详情。
在任务创建成功,设置任务”上线”后,点击”手动运行”便可以运行任务了。数据管道平台提供了丰富的日志管理功能,供用户查看任务执行信息。用户可以通过平台生成的日志链接很方便的查看任务向集群提交时的提交日志、任务在集群运行时的运行日志,如果是实时任务,还可以直接跳转到 Flink的web UI 进行任务信息的查看。
目前该产品已经在我们内部的一些部门及子公司进行了使用,创建任务 300+ 个,每日近 2000 个任务实例运行 。
我们的数据管道依赖了 DolphinScheduler(V3.0.0)的能力,用户在数据管道上创建任务、运行任务,会经海豚调度器进行调度,提交工作流后,最终任务将在集群中执行。
对大家可以看到,最左侧就是数据管道平台创建数据源,创建任务,数据管道根据不同的数据源获取模板,更新模板,绑定配置文件,最终在数据管道上点执行任务,就会依赖 DolphinScheduler 的能力去执行工作流,提交任务,并在 Yarn 集群中执行。同时在这个过程中,DolphinScheduler 会收集到提交任务的日志,我们利用这个能力,在我们的平台上可以查看任务的实时日志。
数据管道前台使用了我们自定义的 UI 界面,后台的许多功能使用了DolphinScheduler 的 API 服务,包括项目相关的操作,任务状态相关、数据源相关等,具体如下图所示:
用户在数据管道上创建任务之后会生成一个 Resource Name,还有一些配置文件。配置文件会上传到资源中心,上传成功之后会有一个Resource ID,之后我们会组装数据格式,把它合成任务所需要的参数,然后再组装出来一个任务节点的定义,形成一个任务节点定义列表。任务节点关系就形成任务节点关系列表,任务节点位置就形成任务节点位置列表。任务的执行类型、全局参数等数据组装起来之后,到 DolphinScheduler 创建功能的定义接口,这样创建工作流的流程就做完了。
然后我再讲几个特色的功能给大家分享一下。
用户在数据管道创建任务的时候可以进行参数的设置。这里我们使用了 DolphinScheduler 内置的时间参数进行参数复制,在过滤条件里边使用定义好的参数进行数据过滤。
离线任务比较常见的是补数,这一块,我们通过参数式的功能支持用户在界面上进行参数的自定义,如上图所示。
从数据管道平台运行任务后,我们会调用DolphinScheduler 的运行工作流接口,我们DolphinScheduler 的提交任务日志详情接口拿到提交任务日志数据,用户可以刷新、下载日志。
数据管道平台在创建任务时支持创建多个子任务。每个子任务均可查看实例列表。这里我们调用了 DolphinScheduler 的实例列表接口来展示运行信息,并在该接口的基础上,添加了实例的运行状态、运行开始时间、运行结束时间、实例运行时长等。同时,我们提供了实时任务的停止、运行按钮,可支持实时任务的断点续传功能。
现在我来说一下我们团队小组的成员在使用 DolphinScheduler 时遇到的一些问题。当然遇到的问题很多,我摘出了三个比较有代表性的问题。并给出了我们对应的解决方案。
最初,我们在数据管道平台调用工作流实例列表接口获取实例的信息时,发现接口返回的 state字段值是 SUCCESS,但其实任务是执行失败的。于是就去仔细研究了一下这个 state 字段,发现其实这只是海豚调度器提交任务时获取到的一个状态,并不能真实反映任务的运行状态,于是我们在改接口的基础上又添加了实例的运行状态的逻辑封装。
这个问题是这样,我们在扩容时新增的节点的也加入到了默认的 default 组,由于新扩容的节点和现在的 work 节点属于不同的 Hadoop 集群,这样的话,提交任务到 default 组,会存在这个组的节点不是属于同一个集群而报错。所以需要把这些新增的节点根据hadoop集群而进行分组。
最初我们修改了 install_env.sh 配置文件里面的 works 设置,分发文件,重启集群,但是通过DolphinScheduler web 界面发现 work分组设置没有生效,新节点还是属于 default 组。为什么没生效呢?找了好长的时间,最后发现新节点的 worker-server 的application.yaml 配置里面看到 groups 是 default,于是修改 default 为新的workgroup 名称,再次重启DolphinScheduler 集群,分组就显示正常了。
这个说起来也是因为我们的 DolphinScheduler 上面有两个 Hadoop 集群,配置一个 hdfs,提交到另一个集群的任务可能会存在找不到文件的情况。我们知道对于 standalone 环境,可以选择本地文件目录作为上传文件夹,我们想了两个方案,一个是 NFS 文件共享,另一个是 OSS,我们选择了后者,OSS 通过服务器挂载就像普通磁盘一样使用方便,还有就是 OSS 底层是多副本存储,数据存储上和NFS相比更安全。
说完了我们所遇到的问题,最后总结一下我在使用 DolphinScheduler 过程中的一些心得体会吧!
首先,得益于 DolphinScheduler 强大的能力、丰富的文档、火热的社区等多方面综合因素,我们在技术选项的时候首选了DolphinScheduler。
也得益于这个选择,截止到当前数据管道最新版为止,DolphinScheduler 对数据管道平台提供了强有力的支撑,使我们的开发工作重心可全面投入到数据管道本身产品功能上去,跟工作流调度有关的实现直接调用 DolphinScheduler 的 API 服务即可,我们会在此基础上添加了针对数据管道平台场景的逻辑补充去完善数据管道的产品功能。
最后,在后续的数据管道版本迭代中,我们会根据功能需求,继续深入研究我们尚未体验和使用的 DolphinScheduler 功能,也希望 DolphinScheduler 社区能够一直活跃下去, 让 DolphinScheduler 能够越来越好。