数据开发提效有秘诀！离线开发BatchWorks 六大典型场景拆解

Posted 2023-04-12 数栈DTinsight

回顾大数据的发展历程，一句话概括就是海量数据的高效处理。在当今快节奏、不断变化的市场环境下，优秀的开发效率已经成为企业数字化转型的必备条件。

数栈离线开发BatchWorks 是一款专注离线数据ELT开发的产品，采用先进的大数据生态底层技术，具备高性能且功能丰富的大数据处理能力，对大数据离线计算、数据仓库建设提供有效支撑，是企业建设数据中台、数据仓库，加速数字化转型的基础设施。

BatchWorks 经过6年多的打磨已经服务于包括金融、教育、政企、零售等多个行业在内的300+客户，在开发效率提升方面发挥了巨大的价值。本文将从多个项目实施过程中遇到的6个典型场景来介绍一下离线开发BatchWorks 在开发效率提升上的一些解决方案，与大家共同探讨。

场景一：大批量数据快速迁移

问：客户数仓计划从 Oracle 迁移到 Hadoop，初始化需要完成几万张表的数据同步，如何快速进行大批量 hive 表的创建并做数据抽取？

答：BatchWorks 支持连接数据源进行关系型数据库到包括 Hive 在内的多目标数据库之间的整库同步，可一次性完成大批量表的自动创建和同步任务的生成，支持按日期增量和全量两种数据同步方式。考虑到同一时间点启动大量数据同步任务会造成数据库压力过大，还可支持任务并发数的配置。

场景二：SQL 逻辑的复用和批量管理

问：一条业务线上有20+产品，每个产品的数据分析由一个 SQL 任务完成，所有产品的任务逻辑完全一致且需要保持变更同步，而实际业务在快速变化，数据开发每次调整业务逻辑都需要每个 SQL 任务分别手动变更，经常出现调整错漏的情况，如何解决？

答：增加“组件”功能，用户可把在大量任务中通用的业务 SQL 逻辑抽象出来作为组件进行维护，不同的产品只需引用组件并配置输入输出表和字符参数，即可快速完成任务配置。当业务变更时只要调整组件的逻辑就能实现所有引用此组件任务的同步变更。

一个简单例子：业务方需要对不同产品的用户群体做年龄分层，可创建组件做年龄筛选，配置以下输入输出参数：

• 输入参数：数据来源表

• 输出参数：年龄层中的最大最小值（字符串）、数据输出表

实现从产品1中筛选出年龄为20-30的用户数据，在创建任务时选择上述组件配置年龄输入参数和数据来源表，并指定写入的结果表：

场景三：计算结果跨任务复用

问：任务存在上下游依赖时，下游任务可能需要直接使用上游部分任务的计算结果，同时用户不希望建太多临时表，或产生一些额外的重复计算，如何解决？

答：BatchWorks 支持了任务上下游参数传递功能，上游任务的计算结果可进行周期性存储，直接被下游计算引用。

一个简单例子：从业务库完成销售明细表数据采集清洗，按天汇总后将销售金额最高的门店数据输出 sales_1d 任务，从 sales_details 中通过输入参数获取日期数据，然后将当天最高销售数据对应的门店通过输出参数输出传递至下游的同步任务，同步任务筛选此门店数据同步至 oceanbase。

场景四：任务依赖自动解析

问：当任务较多且依赖关系复杂时，依赖关系的配置会占用一定的工作量，尤其在对任务做了修改后，依赖关系可能会有更新不及时/漏更新的情况，发现问题时往往已经到了下游环节，如何解决？

答：BatchWorks 支持了上游任务依赖自动解析推荐/自动依赖功能，选择此功能进行依赖任务配置时，平台将对当前任务进行 SQL 解析，得到来源表和结果表，并寻找来源表的产出任务，用户可从这些推荐任务里选择全部或部分任务添加到上游依赖，也可直接选择自动依赖，当 SQL 调整时自动进行上游依赖的更新。

场景五：任务异常快速排查

问：离线实例的运行流程涉及实例上游依赖检查、到达计划时间检查、资源检查、质量校验等多个环节，运行过程出现异常时仅通过日志难以直观地进行问题溯源，问题处理不及时直接影响下游业务，如何解决？

答：BatchWorks 支持实例诊断功能对实例的运行过程进行分析，将实例调度流程及每个流程当前的状态、节点时间全部展示，用户可直观地看到当前实例的运行阶段和异常原因。

比如在进行上游依赖异常检查时，BatchWorks 将构建以当前实例为末位节点的异常依赖树，寻找直接导致其未运行的根源任务组，快速直达阻塞点。此外针对 SparkSQL，可监控其指标健康状况并给出调参建议，针对 HiveSQL 可观测运行过程中资源使用变化情况，从而可进一步进行任务调优。

场景六：以用户组为单位的用户管理

问：某公司的数据开发团队不定期会有一些人员调整，因业务量大、开发项目比较多，人员调整后开发平台上的维护十分繁琐。例如有新员工入职，需要将其添加到相关的多个开发项目中并赋予不同的角色，任务告警值班时需要添加进对应的告警规则中等等，增加管理员的用户管理成本且容易缺漏，如何解决？

答：BatchWorks 的用户中心支持以用户组为单位的用户管理，每个用户可被添加进一个或多个用户组。项目添加用户、告警圈选用户时均可以用户组的方式进行配置。后续增删用户时仅需在用户中心的用户组内进行操作，即可完成人员->项目/角色等的快速调整。

《数据治理行业实践白皮书》下载地址：https://fs80.cn/380a4b

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=szbky

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术qun」，交流最新开源技术信息，qun号码：30537511，项目地址：https://github.com/DTStack

产品团队管理 - 统一研发环境，提效研发过程

（我本来计划将研发环境和管理流程分开来讲的，最后还是放在一起便于理解。）

软件研发最重要的场景就是在有限的时间和资源下把需求落地为产品/项目，也就是研发和项目管理，毫无疑问，这个阶段的主角是开发人员。

是不是应该多思考下怎么面向开发人员来优化整个研发过程和项目管理流程？

 

本文将介绍如何通过优化开发环境搭建、代码管理来提高研发过程中开发人员效率，并通过持续集成和交付让开发中的问题更早暴露，通过合理的测试反馈工具让开发人员更早定位和解决问题。

 

说到团队的研发和项目管理的实践，就逃不开先要说一下笔者所在公司研发和项目管理中的工具作为背景：

• 即时交流和协作：QQ
• 办公信息平台:诺明
• 代码管理：SVN
• Jar管理：Nexus
• 项目管理：Redmine
• 持续集成：Jenkins、ansible

 

切入正题，本篇分享涵盖的是在研发过程和项目管理流程，以及当中在DevOps上做的一些努力去优化开发人员的体验，就试着从各个环节总结一下：

 

• 研发环境的搭建：包括如何kick off新开发者，如何搭建日常开发环境
• 代码的管理：包括源码管理，Code Review和组织公共库
• 需求在研发中的生命周期管理：包括功能需求清单，功能需求定义和其中的开发任务项分配和状态管理
• 项目进度的管理：包括如何通过Redmine有效的执行敏捷开发
• 研发阶段的产品测试和反馈：包括在产品测试和反馈中的一些经验和工具分享
• 持续集成和持续发布：包括如何针对Web, Android和iOS分别搭建持续集成和发布

 

一、研发环境的搭建

如何让团队新的开发者尽快上手

对新的开发人员，一般都会有开账号，装系统，配环境，跑代码这些过程，我自己发现每次都低估这些工作的耗时，以前就发现有时候不小心就一两天过去了还没跑起来代码，一两周还没搞清楚目前产品的功能，我总结了几点加快这个进度的方法：

1.加快账户开通和权限分配的速度。

笔者公司的帐号包括OA，svn，nexus，redmine，ftp，jenkins，Sonar。这些系统的用户管理和权限无非基本都是通过数据库或者xml进行管理，那么是否可以梳理规则然后通过自动化来实现呢？

• 整理各系统，角色、权限对应的sql表和字段或xml键值对
• 开发同步小程序，建立OA同步至其他系统的相应场景(创建、禁用、密码修改、职位调整等等)
  

2.加快开发IDE环境搭建的速度

同一产品部门或同一工种日常所使用研发IDE环境，基本都是一样的，难道要每一个新入职的同事如果都自行去确认IDE，下载和安装？我们可以统一研发所需使用的IDE组件和版本组装成一键安装包。

• 收集研发IDE工具及版本。如svn，Eclipse、maven、ant、xshell及其他
• 统一组件安装目录。如：D:/develop
• 编写环境插入bat文件
• 编写环境检查，开发指引文件，开发标准规范配置说明
• 通过Winrar创建自解压包，自动安装相应软件，执行bat配置环境变量

(注：环境插入的bat文件，部分windows系统版本无法插入，需手动添加)

 

3.加快能让代码跑起来的速度

有很多可以加速的环节，一个比较重要的就是自动构建代码，就是指开发人员checkout代码后通过简单的构建脚本就能完成代码依赖安装，代码编译，单元测试运行，也就是我们常说的跑起来。以Web为例，可以通过maven的pom完成依赖的安装、代码的构建和版本提交，这也是持续集成的基础。

 

4.对产品功能需求和目前进度的了解

保持尽量清晰的需求定义，新的开发人员可以通过浏览产品的需求文档来了解产品功能。

可以知道以前每个版本都做了什么功能，未来有什么功能正在排期中：

如何方便开发人员进行日常开发调试

目前对于Web开发来说，一般构建的过程中代码都会进行环境文件DLL/SO,CDN地址等替换、CSS Sprite生成等等操作，造成配置切换很不方便，我们采取的解决方法是在web的maven构建流程中分不同的Build Target，自动构建切换至对应环境配置，连接对应数据库，方便Web开发人员调试。

 

二、代码管理

首先最重要的就是代码必须用源码管理工具，我们一直用的SVN。代码的查看和管理都在SVN服务器上，可以查看代码，code review，合并分支，打版本tag之类的。

有两点我觉得需要关注的：

1.怎么让开发人员高效的使用第三方库

项目开发的过程中去抽象公共组件，使用第三方库或开发工具都可以提高开发效率，但需要做好模块和版本管理，有时候碰到一个开发人员引入了一个不合理的依赖，或者学习成本陡峭的组件，每个参与开发人员都要增加学习成本。这个一般都是根据不同的技术栈有相应的一套工具可以使用，在java开发上我们使用的是Nexus来管理， iOS、Android上面也有自己习惯的选择，需要加新的组件或者替换正在使用的通过专家小组评审讨论之后加入，以免发生重复或者后期的分歧。

 

2.如何做新功能开发的代码管理

只要多人开发，而且多功能并行开发都避免不了要考虑如何管理代码。一般有Brunch和Trunk开发两种

传送门：SVN版本管理

三、需求在研发中的生命周期管理

对于开发人员来说，开发工作一般是围绕着具体的功能需求进行的，而 "清晰的需求定义"就是研发的主要输入，由负责的PM来主导需求(User Story)的状态更新，本节以一个功能需求(User Story)为例，先上一个时序图来说明单个功能在研发中的生命周期是什么样的：

从功能需求(User Story)的时间线上可以看出来其分为下面几个状态：

可以划分为需求确认，需求开发，需求测试和上线三个阶段：

PM创建后协作编写需求文档(New) ->     需求确认(Confirmed) ->         开发中(In Progress) ->             待测试(Wait for test) ->                 已完成,可以上线(Finished) ->                     完成,可以关闭(Closed)

 

1. 需求确认

对于需求文档的编写和确认，不同团队方式不一样，我的理解是包括功能需求的前置条件和后置条件，用户流程和规则，完整的产品交互原型，评审确认的设计稿。

2. 需求开发

在需求定义清晰后，开发前需要整个开发团队的参与确认任务的分配。任务分配的原则就是将功能需求对应的任务按树形结构分解，敏捷开发里的学名是"Work Breakdown Structure (WBS)"，保证其中每个任务都是可以开发，并且是可以测试的。

具体到其中一个单独的任务项(Task)，里面会有它所属的功能需求(User Story)，当前的状态，优先级，任务指派的开发者，任务所属的产品线，一个简单的任务描述的，所属的里程碑，预计开发时间和结束时间，任务当前的状态和进度等等。

从上文中"需求在研发中的生命周期"的时序图上可以看出其对应的任务的生命周期是如何管理的，包括前端和后台之间的任务协作是如何完成的，简单来总结的话Task有下面几种状态：

新建 ->     开发中 ->         待代码复查(目前仅junior developer需要被code review) ->             待测试 ->                 反馈 ->                     完成(可以上线) ->                         关闭(上线以后可以关闭)

 

开发人员主要负责的就是开发的同时更新自己任务的状态，状态蛮多，如果开发需要每次登录redmine来改也确实蛮累，在实践的过程中我们可以引入一些优化的方法：

 

• 为Redmine自定义一些SVN hooks来更新状态。通过自定义SVN提交语法，让SVN提交能自动更新在Redmine相应的版本更新上。
  • 参考资料：SVN提交后自动更新Redmine版本库
    
• Server端接口文档自动生成。在需求定义里可以将规则和逻辑写的很清楚，但在前端和服务端协作开发的过程中，如果服务端没有文档可能会经常被前端打断，询问接口具体参数的名称或参数类型，也是比较烦的事情，可以考虑用工具来统一管理和自动生成文档，我们使用的""。
• 开发中的持续集成和交付。这个后面会专门来讲如何操作，具体的意义就是开发人员提交代码之后，在服务器上进行自动构建和发布，这样一方面每次提交都做Sonar检查，有单元测试的做单元测试，降低代码最后集成的时候出现问题的风险，另一方面让PM可以尽早的接触到成品，尽早进行反馈。

3. 需求测试和上线

当单个功能需求下面对应的所有任务都开发完成后，由PM进行测试和反馈，在确认与PRD一致后可以由PM更新为"待测试(Wait for test)"。这里"待测试(Wait for test)"的意义就是该功能需求可以在发布到测试服务器(Test Server)，由业务及测试团队参与测试。当测试没有问题后，如果是Web功能则根据上线计划上线到Production Server；如果是Native App，则按照版本计划，可能需要固定时间发布或者等待几个功能完成后一起发布上架（部分公司可能会有灰度发布的过程）。

由于这里讲的是单个功能需求的研发周期，而测试和上线更多是在整个项目这个 范围 上来讨论，所以针对测试和上线的部分在后面持续集成和发布的部分会来细说。

四、项目进度的管理

顺着上面的思路，当你有单个需求研发的流程后，整个项目的管理就是管理所有的需求，安排优先级和迭代计划，然后对所有需求进行同样的研发流程管理。敏捷开发里把一个迭代周期称为一个Sprint，每个Sprint做一次产品发布，然后回顾Sprint内的问题，规划下一个Sprint的开发任务，如下图：

 

笔者公司的的实践并非Scrum，但比较接近，我们的迭代比较频繁，通常每周至少都往Production上做一次同步。项目的进度管理推荐参考Scrum的实践里的三个Meeting：

• Sprint Planning Meeting：从整个产品的Product Backlogs里一起规划出下一个Sprint要完成的功能，可能对应着很多团队的需求评审会
• Daily Standup Meeting：在一个Sprint里每天和开发人员一起回顾昨天的开发进度，讨论碰到的问题和确认当天的工作计划，其实对应着为开发人员诟病的项目日报
• Sprint Review Meeting：在一个Sprint结束回顾项目进度，问题和下一个Sprint的计划，一般对应着PM要做的项目周报

在这三个Meeting上PM会和开发人员或者产品负责人进行接触，如果这里体验不好就会影响项目的管理。其实我们试点的优化方案也比较简单，就是通过项目管理工具Redmine去实现的功能需求和开发任务的"看板"：

关于redmine的实践后面我单独写一篇文档来介绍。

 

五、研发阶段的产品测试和反馈

产品发布到测试渠道后的反馈

当产品发布到测试渠道就是希望在正式发布前得到业务和测试团队的反馈，对比开发人员的测试反馈，业务和测试团队的反馈会更专业、清晰、充分，这些反馈需要通过相应的工具来进行管理：

• 我们使用的BUG反馈工具是禅道，可以明确缺陷的类型，等级，可记录具体的场景并添加贴图，并有指派和BUG跟进报表等相关功能。需要了解的可以百度"禅道"（我并没有收他们的广告费）。

六、持续集成和持续发布

Native App因本身业务和市场占有的需求，一个重要的痛点就是不停迭代业务、发测试版、进行测试，但对于移动app来讲之前每次打包都需要打断开发人员，等待编译，改文件名加版本号，上传等一系列繁琐的过程，然后还经常因为客户没有装最新版而造成沟通时间的浪费，所以早期我们就开始着手建立持续集成和持续发布体系来避免这些问题。

一个完善的持续集成应该包括代码提交后的构建->部署->测试->发布几个阶段，两张图对比应用持续集成和持续集成之后的研发过程：

然后这张图是我们目前实现的持续集成过程：

自动构建

Jenkins支持定期检测SVN代码更新，会在代码提交成功后能在持续集成服务端(CI Server)触发相应的Server，Web，iOS或android端的自动构建。

持续部署

部署分为客户端部署和服务端部署两种，就是构建以后要把可运行的代码发布到相应的服务器和手机端。

持续测试

分为单元测试和集成测试，理论上来说能在持续集成的过程中执行测试，是对产品质量极大的提升，不过对团队的规模和时间要求比较高，一般还是按自己的实际情况来，非长期维护产品慎用，建议做产出分析。

持续交付

持续集成后的持续发布是我们主要需要解决的痛点，发布的对象分别是给开发和测试人员的Dev版，给测试团队的Test版和给最终线上用户的Production版，发布的渠道又分为Web端和Mobile端，需要分别来考虑：

将发布的dev,test和production分为三个不同的服务器：

• Dev服务器由Jenkins检测来触发，每次代码提交都会触发构建，然后Redmine发邮件给相关负责人，同时集成新版本到Dev上。
• 对于Test服务器就是当有新功能测试完成，准备上线的时候，就先同步到Test服务器上，通知测试团队下载测试。
• 生产的正常的流程就是当测试通过之后，按照确认要上线的功能进行发布。