关于大数据:数栈产品分享干货解读数据中台产品模块化设计思路

45次阅读

共计 2318 个字符,预计需要花费 6 分钟才能阅读完成。

一、前言

在做企业服务类 (ToB) 的产品时,咱们常常会遇到如下场景:

每个客户拿着他们的需要清单,来征询咱们的产品是否可满足他们的诉求。如图所示:

每个客户的需要有重叠的内容,也有不一样的内容,而这些需要,在某一畛域均具备较强的通用性。

如何满足这些客户需要的同时又能使各个需要积淀为规范性能,而不仅仅是为了交付我的项目?这成为 ToB 类产品经理思考最多的问题。

为撑持客户诉求,根本的做法是形象各个需要,落地为规范性能,将各个性能拼装成一个产品。然而一段时间后大家就会发现性能越堆越多、产品越做越宏大,然而用户体验却越来越差,产品开发保护越来越艰难。
如何既能满足客户诉求,又能解决产品存在的这些问题?模块化设计是一个方向。前面咱们开展介绍下,数栈在模块化设计方面的一些教训供参考。

大题目

二、模块化设计介绍

(一)目标

从商务销售的角度说,产品模块可自由组合报价,贴合不同客户的需要,进步产品销售的成单率。从产品研发的角度说,缩小反复造轮子的景象,进步研发效率和产品扩展性。

(二)落地教训
模块化设计在数栈平台的落地施行,从大到小次要分为上面三种形式:

子产品化
公共模块
组件 / 插件化开发

1、子产品化
1)需要背景:
每个客户,甚至同一个客户在不同阶段,对数据中台的了解都不尽相同。

比方客户 A 是个中等规模企业,心愿能有款产品帮忙他建设离线数仓,满足根本的数据开发诉求,那数栈的离线开发模块就能够满足他们的诉求。比方客户 B 是个大型的团体企业,心愿能从数据开发、数据服务、数据治理等多个方面搭建起团体数据中台,那就得输入一整套数栈去满足该客户。

2)设计思路:

产品上——依据业务逻辑,各个模块独立解耦,定位降级为子产品,负责解决不同的业务场景诉求。
商务上——销售时可独自报价输入,也可组合报价输入。

3)落地成绩:
数栈作为一款数据中台产品,其中蕴含了:离线开发、实时开发、算法开发、数据服务、数据资产、数据品质、智能标签等子产品,每个子产品可解决不同的业务场景诉求,并反对独立、组合部署。

2、公共模块
1)需要背景:
数栈的各个模块独立化成子产品后,尽管能够解决不同的业务场景诉求,然而在数据中台这个框架内,依然会存在一些雷同的根底性能诉求,比方用户体系、数据源治理、工作运维等。如果每个子产品外部独立实现,会存在两个问题:

减少了用户的应用老本。比方雷同的用户、雷同的数据源须要在各个子产品内屡次保护,而且还容易造成了解歧义。
减少了产品的研发老本。雷同的性能须要反复实现,反复造轮子,节约研发资源和运维老本。

2)设计思路:
剥离各个子产品中的通用性能作为公共模块,对立进行保护治理,而后为各个子产品提供服务。
公共模块的设计须要充沛调研各个子产品的诉求。对于通用诉求,形象出规范性能;对于拓展诉求,提供配置化性能;对于共性诉求,由子产品自行实现。

3)落地成绩:

3、组件 / 插件化开发
1)需要背景:
如果说前两局部的模块化设计是对产品经理能力的考验,那这部分内容更多是对开发人员的要求。

上面介绍咱们在日常工作中遇到过三个问题场景:
a、产品设计时,须要新增一个输入框,要求是:属于必填项、内容格局限度中英文、长度限度 255 字符。

需要很简略,然而每次评审时,产品经理都得给研发阐明如果为空时怎么提醒、内容不合乎格局要求时怎么提醒、长度超过限度时怎么解决,沟通老本极大,而这仅仅是整个原型设计中 1% 都不到的内容。

b、产品设计时,须要复用另一个模块中的表单,表单中保护的各个表单项、表单项关联逻辑均雷同。
性能完全一致,然而研发调研后发现,原有的表单解决逻辑和业务解决逻辑强耦合,导致表单代码无奈复用,须要从新独立开发。

c、在产品迭代过程中发现存在一类需要,更新绝对频繁,需要逻辑具备肯定共性,而且更新不会波及已有性能的改变。
这类需要对于开发,和公共模块之于产品相似,能够形象为一种公共技术能力对外提供服务。比方我司常常会遇到的需要有:新增反对一种数据源、引擎新增一种工作类型等。

2)解决方案:

前端积淀规范组件库。对于一些罕用的设计,通过组件复用来缩小开发和产品的工作量;目前咱们已积淀 30+ 前端组件,并在继续迭代中。
代码的低耦合设计。这部分要求比拟虚,而且没有十分明确的边界,依赖开发教训和对业务的了解,须要继续成长。
插件化设计。辨别应用层代码和底层代码,底层代码进行插件化封装,可为下层不同的利用提供反对,在反对疾速迭代的同时又不会影响已有性能,这样应用层开发能够投入更多地精力去反对业务。目前已落地:数据源插件、数据同步插件、Engine 插件、血统解析插件。

三、总结思考

模块化设计是一种解决方案,并不是最终目标,因而,在产品设计时不能为了模块化而模块化。尤其是产品初期,此时产品性能并不丰盛,而且为了疾速迭代抢占市场,并不适宜投入较多的精力去做这个事件。然而一旦产品进入稳固发展期,产品经理和研发同学都应该开始思考模块化设计在日常工作中的利用了。

模块化设计并不是产品换个名称、独立做个页面就是模块化了,业务层面如何划分、模块之间如何配合、插件剥离的边界在哪,代码逻辑怎么解耦等等,这些都是须要思考的中央。

数栈是云原生—站式数据中台 PaaS,咱们在 github 和 gitee 上有一个乏味的开源我的项目:FlinkX,FlinkX 是一个基于 Flink 的批流对立的数据同步工具,既能够采集动态的数据,也能够采集实时变动的数据,是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个 star!star!star!

github 开源我的项目:https://github.com/DTStack/fl…

gitee 开源我的项目:https://gitee.com/dtstack_dev…

正文完
 0