TALEND WEBINAR : March 27th, 2018 | Step-by-Step to Enterprise Data Integration

Talend 成功之道

Talend 成功之道

  • Dale Anderson
    Dale Anderson is a Customer Success Architect at Talend. Over a 30 year career, Mr. Anderson has gained extensive experience in a range of disciplines including systems architecture, software development, quality assurance, and product management and honed his skills in database design, modeling, and implementation, as well as data warehousing and business intelligence. A keen advocate for an appropriate temperance of the software workflow process, he has applied his innovations to the often overlooked lifecycle of a database. The Database Development Lifecycle Mr. Anderson has developed incorporates data modeling best practices to address the complexities involved in modeling adaptations, multi-environment fulfilments, fresh installations, schema upgrades, and data migrations for any database implementation.
  • January 08, 2018

 

熟悉我先前 Talend 博客 读者或许已经注意到,我常常论及通过设计模式和最佳实践来构建更好的解决方案。我的博文也往往篇幅较长,在此向愿意拨冗浏览的读者致以谢意。本文将重点关注适用于 Talend 解决方案的方法论。希望最后大家达成这样的通识:任何成功的 Talend 项目都应当运用恰当的方法,否则项目必然难逃败局。

圆凳需要三条腿才能站稳,对吧?我认为可将软件开发项目比作这样的圆凳,同样需要三条凳腿,分别定义如下:

  • 用例 - 解决方案明确定义的业务数据/工作流要求
  • 技术 - 我们创建、部署和运行解决方案的工具
  • 方法 - 业界公认的行事方式

软件项目通常只关注用例和技术堆栈,往往会忽略方法。在我看来这是一种错误的认知,也是事倍功半乃至无功而返的根源。在规划成功的 Talend 项目时,应以将最佳实践纳入作业设计模式 (JDP&BP) 以及 数据模型设计 (DMD&BP) 作为基本目标。在众所周知的圆凳方法论当中,这些原则恰如相应的凳腿。我在 JDP 和 BP 博文中探讨了一些基本的规则,其中一致性或许是最为重要的普适性规则。原因很简单:即使您是做事的方式有问题,或者说得更委婉些,方式不够恰当,那么后续若还沿用相同的方式,纠正起来便会更容易。我对此深以为然,因而认为成功的方法应当包含一致性。

成功的三大支柱

我们下面进一步详述。以凳腿来类比成功支柱,每个支柱各司其职,共同服务于更大的目标。软件并不神奇,应当理解自启用到停用的演变过程和生命周期,这是成功实施的基础。严谨的开发者很少忽略这一点,但往往屈服于业务压力,而大多数情况下,所运用的方法受到影响最大。由于将其弃之不顾,隐藏的长期成本会急剧上升。最严重时可能导致项目全盘失败,即便是最好的情况,也可能造成项目质量不如人意,缺乏竞争优势和/或延长交付周期。

因而我们需对此认真以待。以下是要考虑的启动概要:

可根据需要进行修改;具体情况各不相同,但要求大多类似。我们接下来继续探讨。

何谓成功之道?

成功的方法无非是得到真正采纳并付诸实践,仅此而已。当软件项目团队应用某种方法论时,便也知晓如何统筹规划以实现预期结果。如果缺少适当定义及采行的方法论,多少有些像西部电影或“打哪儿指哪儿”的场景那样随性,窃以为对于软件项目将毫无助益。方法论作为第三条凳腿必不可少。

谈到方法论,人们可能会洋洋洒洒涉及众多话题。不过本质而言,讨论首先应侧重于规划软件项目的设计、开发、发布、部署和维护。 这一环节通常称为 “软件开发生命周期 ” 简称 SDLC,多数情况下是在设置、管理、协调和测评所需资源、重要里程碑和实际可交付成果方面要迈出的第一步。很多读者已经了解两种最常见的 SDLC 方法:

  • 瀑布式 - 严格规定的步骤(阶段),可划定整个软件结果范围
  • 敏捷式 - 灵活的迭代方法(冲刺),可优化早期结果
  • JEP+ - 一种混合型最佳方法,包含所有重要内容

如果没有 SDLC 方法,我认为相比因误导、错误配置、结果出错导致未达到原定目的而产生的成本,原先所设想的省去这项工作(是方法也是工作)而带来的节约只能说是得不偿失。软件失误代价几何?无需具体到数字,必然十分巨大。因此首先要选择一种适合的 SDLC,并将方法落到实处。道理显而易见。敏捷开发似乎已成为整个软件行业通行的标准,不妨以此为起点。两种方法论基本任务相似,只是具体方式有所不同。本文不会深入研究这些问题,仅就两个不可或缺的方面进行说明。

瀑布式 SDLC

瀑布式 SDLC 方法源于制造业和建筑业,规定顺序、非迭代流程,像瀑布一样向下游流动。从想法或概念出发,收集、分析和明确指定所有需求,再到设计的构思、图解和广泛审查,随后进行代码开发(有时似乎永无休止),接着是测试/调试、投产和代码库后续维护。

这种方法的真正优点是每个人都知道项目结束时会取得什么结果(据说)。缺点是可能需要很长时间才能看到或用到结果。如有任何上游步骤未能领会初始概念的真实意图,则可能造成代价高昂的问题。流程越往上回溯,一步踏错所引发的纠正成本就可能更高。好吧,得到的文档至少通常比较漂亮。

敏捷式 SDLC

敏捷式 SDLC 的原则是专注于缩短开发任务以及快速将功能交付给用户。这种自适应方法催生高度迭代的流程,可对进化事件序列作出反应并且机动灵活:持续改进并增加功能,随时间推移逐步提供价值。

敏捷式较之瀑布式的明显优势在于支持跨职能团队参与整个端到端流程,有助于强化沟通,并能在开发过程中随时作出调整。劣势可能在于特征蠕变确实棘手,虽说应当采用最佳实践来避免这种情况。

再有就是纸面上并不好看。

请别误会,敏捷开发在大多数情况下无疑是正确的方法。但止步于此还不够,因为这种方法并未涵盖更广泛 SDLC 最佳实践的所有方面。以数据乃至大数据为例。就我们自己来说,目前正构建以某种形式推送数据的软件。如果您关注过我先前的博文,会知道我所言何事,是的,DDLC,也即数据库开发生命周期。有兴趣可阅读对应这两个部分的系列文章(点击上方链接),了解有关数据模型设计和最佳实践的更多内容。

介绍 JEP+- Just Enough Process

从事软件业多年来,我经手过不少项目,有得亦有失,深刻认识到 SDLC/DDLC 流程至关重要且必不可少,因为有赖于这些流程来评定项目质量,进而作出更好的业务决策以支持项目/产品发布。另一项经验之谈是,流程过于繁冗则可能让人束手束脚,会妨碍创造性可交付成果的产生,导致成果价值缩水、成本增加。

我和 Drew Anderson,我们兄弟二人在过去 20 年左右的时间中致力于打造混合 SDLC 流程,我们称之为 JEP+ (Just-Enough-Process-Plus),顾名思义,也就是在采用适当流程的基础上再“加”一点点,确保恰到好处、不多不少。本质上是基于敏捷开发/Scrum 的方法,我们对能力成熟度模型、瀑布式和 ISO 9000 方法进行了有益的融合。JEP+ 可作为 DDLC 的根基。

通常在向客户介绍我们的方法时,他们几乎总会问到一个问题,就是他们凭什么相信这一点。最终凭借竞争优势,我们的方法在众多咨询项目中获得采用。Drew 的工作还在持续。很多人建议我们出书,比如敏捷方法学家 Scott Ambler 先生也这样提议。我们会将此事排进日程。

Talend 的作业设计模式

但凡成功的方法,无不涉及众多要素或流程。对于 Talend 开发人员,我们应当讨论的一个关键元素是作业设计模式。我会在 JDP 和 BP 系列详述一些提示。假设我们已有明确定义的用例,并且已确定技术参考架构,在真正深入编写代码之前,应当考虑可靠的设计模式。设计模式为 Talend 开发人员提供构建成功作业的既定方法。我们来看一些有用的设计模式:

 

LIFT-N-SHIFT

提取并直接加载数据,从源数据到目标存储进行 1:1 映射;除非需要数据类型转换,否则很少包含转换;常见于在系统间快速移动数据;通常并非长期解决方案,但能够完成任务

DUMP-LOAD

提取任何指定的源数据,写入中间存储(通常是平面文件:CSV/XML/JSON),然后加载到目标数据存储;转换可能发生在任一步骤中;通常是 2 项独立、分离的作业;常见于填充数据仓库或数据湖

SYNCHRONIZE

从源或目标无缝和/或连续提取新数据和已更改数据,将数据(根据需要插入、更新或删除)发回目标或源数据存储;转换通常不会发生在这种交换中;常见于 CDC 流程和/ MDM 系统,其中所有数据存储随时需要所有当前信息;此外也用作信息集市单向群体分析

CHUNKING

通常基于参数化的开始/停止值处理指定区块中的大型数据集,然后可以同时(并行)多次执行作业而不影响下游流程;通常适用于提取的转储/加载模式,需要进行大量转换以减缓整个执行流程;常见于来自不同系统的迁移

MICRO-SERVICES

将数据处理分离为较小的独立服务,可在数据集上操作,不受调用或被调用作业的影响;微服务可以完成各项所需事务,但应当简明,且除了参数化传入和/或传递参数外,均依赖于外部影响;常见于数据系统集成和电子商务应用;也可设计为微批处理流程,以支持分块模式的并行化

MULTI-MERGE

对于需通过多来源查找将多项其他元素添加到其流中的数据集,需要特别考虑;内存和逐行查找模型必须仔细选择及平衡;通常用于与微服务协调;常见于电子商务购物车和机器学习应用

STREAM 4 PERFORMANCE

大数据平台提供支持大容量 (volume)、多样化 (variety) 和高速度 (velocity) 的快速批量数据摄取流程,而当 V-V-V 为海量数据流内存时则可显著提高性能;常见于使用 Spark 解析 Hadoop 中的大数据文件

 NEAR-REAL-TIME STREAMS

物联网、传感器数据要求即时或近实时地实际获取其利益,可利用数据流绕过中间处理;常见于收集连续数据源(如视频系统、报警或其他传感器数据),对其所产生的转换进行监测至关重要;通常借助大数据系统、Kafka 主题和 Spark Streaming 实现

 

以上列表并非详尽无遗,只是希望能让您思考相应的可能性。

结语

Talend 是一种多用途技术,加上完善的方法论,可以提供经济有效、流程高效和高生产率的业务数据解决方案。SDLC 流程和作业设计模式是成功方法论的重要组成部分。在下一篇博文中,我打算再通过一些可能有用的其他细分来扩充这些内容。

我们下次再会。

Most Downloaded Resources

Browse our most popular resources - You can never just have one.

Join The Conversation

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *