数据中台数据中台
申请试用
新闻动态
了解袋鼠云最新动态
新闻动态>数据中台如何设计?主要分为哪几个步骤?>
数据中台如何设计?主要分为哪几个步骤?
2021322|文章来源:-

数据中台如何设计?主要分为哪几个步骤?大家面临的难题域是整体数据信息管理体系,这一管理体系就是指传统式上面有数据仓库、数据集市组成的生态环境,不包含联网交易平台(如关键系统、投资理财销售管理系统)和纯粹的流程管理系统(如业务流程审批流程)。


伴随着技术的发展,这一管理体系提升互联网大数据和AI的设计元素,更为智能化系统,但仍然是以战略和战术方面的数据信息工作能力提供为关键,能够作为业务流程变更的权威性根据和关键性因素,但不直接改变业务流程状态。
首次分解,大家按照是不是具备业务流程特性作为规范,能够先拆出技术平台和“其他部分”。这样从整体架构方面看,后续无论“其他部分”分解为多少个系统,这些系统与技术平台的关系都是一致的,即技术平台提供与业务流程无关的支撑工作能力,这种工作能力包括数据信息的存储、生产加工,甚至能够涵盖可视化方面,前提是这种技术工作能力有进行平台化的必要。
再次分解,大家从“其他部分”拆分出前台和中台。支持这次分拆的理由自然是“小前台、大中台”,也是中台建设热潮的Slogan。前台注重灵活性,中台注重稳定性,两者组成类似“变速齿轮”的关系。
怎么理解灵活与稳定呢?我觉得一条重要的规范就是系统的投产频率。面临需求变更,前台与中台的投产频率至少达到2:1,才能体现出中台的稳定。反之,如果每次需求变更中台都要受到影响,那这一中台就是不成功的。
面临数据信息管理体系,大家通过明确中台边界,产生了前台、中台、技术平台三分天下的格局,如下图所示。
设计构思一个数据中台,总共分几步?
目前大家描述的边界仍然是概念上的,比较宽泛,也就会造成理解上的很多分歧。细化接口能够帮助大家更深刻得描述对中台的期望,从而在组织内达成一致,所以大家第二步就来做这项工作。
技术平台与中台的接口各种各样,但因为是业务流程无关的,不容易有歧义,所以大家重点谈谈前台和中台的接口。传统式上,数据信息管理体系的系统接口主要是以大批量文件形式为主导,前台和中台是不是要延续这种接口呢?我的见解是,应该最大程度的避免使用大批量文件作为接口,更多的使用API服务形式。具体原因有以下几点。
工程实践中,大批量文件的数据信息与元数据常常是分离的,甚至干脆省略掉元数据。具体来说,大批量文件通常是仅包含数据信息的平面文件,在源系统中(可能存在于数据库中)的“数据项标识”、“名称”、“数据类型”、“备注”这些内容,很少在接口中看到。当然,如果做得好些,大家也可以在数据治理系统中登记这一接口,但难题是治理系统中“元数据”的正确性与系统运行是完全无关的,它们从来没被真正验证过,也无法确定是不是伴随着业务流程变更被即时更新,当我们需要根据这些“元数据”做出决策时往往信心不足。
久而久之,治理系统中“元数据”不再被使用,就成了死数据信息。
相对而言,服务的自描述要好很多,大家甚至能够在组织范围内约定更丰富的元数据,将其与服务发布融合在一起。基于架构设计上的服务注册与发现机制,这些服务会受到更强有力的约束,从而保证元数据的质量。
我们在系统建设中常常能够观察到一个现象,系统会自我驱动,业务流程会越来越复杂和发散。究其原因,大概是系统的主要利益相关方更倾向于在系统中拓展功能,能够降低与外部(科技、业务流程等)的协调成本。从局部,尤其是某个特定需求上看,这可能是更快、更好的选择,但从全局而言就是一种伤害。在哲学上方面,这个问题就是局部最优解未必是全局最优解。
追求局部最优解的后果就是建设大量竖井式系统,无法沉淀可复用的工作能力。中台的使命恰恰是要从全局角度,破除或者削弱这种建设模式。
前台尽量不积累数据信息,也就杜绝或者控制了其逻辑向复杂化、发散化演进的可能。我们可以在更高阶的管理方面,以更低的成本洞察到这种演化的趋势,从而采取相应的措施。
服务形式天然满足了控制前台系统积累数据信息的目标。
数据仓库方法论是秉承“以空间换时间”的思路,通过ETL(SQL处理)预加工来降低用户查询报表时的计算负载,从而实现低延时交互。为了统筹提升整体生产加工效率,并不会将单张报表依次生产加工,而是合并报表的生产加工层次,先共性后个性逐层推进,一个批次(一天可能会存在2-3个大批量生产加工批次,通常不会太多)的生产加工结果大致会在同一个时间段完成。
这种形式的弊端是,一旦上游数据信息或基础层生产加工出错,发现错误的时点会大幅延后。本来通过单进程查询就可以发现的错误,现在必须预支大量的大批量计算成本后才能看到。这一过程浪费了大量的计算资源和时间资源(ETL必须在当日完成,因此时间资源也是受限的),甚至导致无法在剩余的时间窗口内完成纠错和任务重跑,造成业务流程的重大影响。
大家应该看到“以空间换时间”的策略是基于若干年前的即时计算能力而做的权衡。今天,分布式技术发展趋势带来了即时计算能力的大幅提升,是时候在ETL处理和即时计算之间寻找更优的平衡点了。
我的建议是将一些计算负载迁移到服务中来,用分布式计算框架代替部分ETL。中台与前台的接口处位于整体ETL的末端,所以这里也就更适合采用服务接口。
此外,还要说说第三种接口方式JDBC,我个人也是不推荐的。一个原因是JDBC暴露了数据源的数据存储结构,强化了前台与中台的耦合,既然我们在架构方面希望两者松耦合,那具体接口上也应该选择匹配的技术。第二个原因是业务流程语义上的差异,RESTFUL服务有一个“有趣(Interesting)”原则,服务要有业务流程语义。直接对一张表的访问显然不够“有趣”,那么JDBC也就不能称为服务了。
数据中台的外部接口主要是API服务。
大家继续探讨数据中台的内部结构,按照我们在第一步设定的边界,“数据仓库”与“数据湖”必然是中台的一部分。两者是不是中台的全部呢?我认为并不是全部。


数据仓库方法论有Inmon和Kimball两个流派,国内数据仓库的实施多数采用Inmon的方法。
具体来说,在数据仓库与数据集市的二元结构中,数据仓库对接上游各类业务系统,按照企业级模型重组数据信息以消除源系统的特异性,这一模型按照若干主题进行组织,是数据仓库理论体系的关键;数据集市在此基础上,根据具体的应用场景进一步生产加工数据信息,实现最终的功能交付。
能够看出两者的指导思想不同,数据仓库是“面向主题”的,数据集市是“面向应用”的。
有些企业以前是竖井式的数据集市,现在把集市中的共性部分下沉,节省了加工成本,认为这就是数据中台。如果笼统得用“工作能力复用”作为规范,似乎数据仓库与数据集市就是中台和前台了。
那么数据中台是在炒概念吗?我认为并不是。
数据中台与数据仓库的差别不是有没有工作能力复用,而是因为数据集市仍然太重不符合前台的灵活性要求。一样是二元结构,因为数据集市不等于前台,所以数据仓库也就不等于中台。
理论上数据集市是满足一个“业务流程单元”的数据分析需求,实践中这一“业务流程单元”往往对应到“业务部门”,因为这样业务流程管控职责明确,能够快速需求边界,和财务管理制度也有直接的关系,项目操作较简便。
但是,今天这种形式遇到了挑战。伴随着数据信息应用的深入,需求越来越具体,同一部门的不同团队的需求也各有侧重,都希望保证各自的灵活性,又不希望自身的稳定性受到其他团队灵活性的影响,“业务流程单元”呈现明显的“碎片化”。
跟伴随着业务流程的“碎片化”,数据集市不断裂变,底层逻辑大量重复。显然,该做架构方面的调整了。这就说到前台,其服务的“业务流程单元”更小,但逻辑相比数据集市要更为轻薄,将原有针对“业务部门”的生产加工要沉淀到数据中台,沉淀的部分也有再次重组的机会。
数据中台既“面向主题”也“面向应用”
数据中台“面向主题”是因为包含了数据仓库,“面向应用”则是因为包含了数据集市下沉部分。这里的新难题是如何重组数据集市下沉到中台的部分,重组形式依赖设计者的经验,其实没有统一方法。我的建议是按“价值链”和“产品线”两个维度分解,两者正交组成若干单元,这些单元称为“业务流程域”。
一样是数据信息沉淀,为什么不使用数据仓库的主题,而要新建“业务流程域”呢?数据仓库的主题是数据信息方面的高度抽象,基本不体现业务流程。今天,数据信息应用的大趋势是强化对“一线操作”数据赋能,必然更为关注业务流程,而价值链正是业务流程的起点;产品则是衔接企业与用户的桥梁,同时也是业务流程操作的关键。
“业务流程域”是对业务流程的抽象,能够说是“面向流程的”,本质还是“面向应用”的。“业务流程域”数据模型不像数据仓库“主题”那样严格的去冗余,有些维度信息会重复出现,比如客户基本信息、机构信息等。
以银行为例,“价值链”上的典型性阶段包括营销、运营、风控等,“产品线”能够分为零售、对公、同业等,两者正交则能够得到“零售营销”、“对公营销”、“零售风控”等业务流程域,当然正交得出的业务流程域也可以适当调整。
数据中台包含一个“面向主题”的数据仓库(及数据湖)和若干个“面向应用”的业务流程域。
目前为止,大家仅在数据结构上探讨了中台的组成,并没有考虑系统的非功能性需求。事实上,在不同应用场景下前台的非功能性需求会有较大的差异,其中最有代表性的是对并发和延时的要求。因为大家已经约定中台与前台的接口是API服务,这些需求会直接传导到中台。接下来,让我们谈谈中台的针对性设计构思。
数据中台如何设计?主要分为哪几个步骤?我给大家的建议是减少“数据信息搬家”和ETL,因为这会导致削弱系统的特性,针对中台的内部设计构思我也坚持一样的见解。数据信息应该通过很短的生产加工路径,产生API服务向前台交付,所以数据仓库和业务流程域都应该具备API服务能力。
数据仓库本来以大批量生产加工为主导,以文件形式输出。

此刻起,和袋鼠云一起让数据产生更大价值
此刻起,和袋鼠云一起让数据产生更大价值