数据中台已成下一风口，它会颠覆数据工程师的工作吗？.docxVIP

数据大陆与台湾已成下一风口，它会颠覆数据工程师的工作吗？ 大多数业务软件都可以叫做数据系统。他们基本结构如下图： 大多数业务软件系统都符合如图的结构和公式 y = f(x)： 有一个恳求 x，得到输出 y 软件系统即 f，f 依据 x 输出 y 软件系统的数据库构造部分，有流水表，配置表。 流水表是随着恳求数量增减的 软件依据配置表配置处理恳求。 实际的软件中，还会存在另外一种数据库表：实体表，实体表是软件处理恳求时需要的数据，业务规律可能随着实体表部分规律而有变化。 对于大多数企业级系统而言，多数业务都是可重现的。故若流水表定义为 y 撇（y 的一个可逆变换）, 则必有函数 fy 存在使得 y = fy(y 撇)。我们认为 y 和 y 撇在信息容量上是等价的（或者说在集合上是等价的）。 很明显，流水表包含了全部的业务要素。简约证明如下：假如业务恳求 x，则 x 包含全部业务要素。且业务恳求 x 数量是无限集合 X。软件 f 和配置表皆是有限集。若业务系统有长久化，业务可重现。则业务要素必定只能存储于流水表，且流水表必定包含全部业务要素。 对于任何一个业务系统，我们得到结论或者推论： 推论 1，流水表包含此业务系统的全部业务要素 推论 2，用户界面也包含了全部业务要素 推论 3，业务要素和系统的模块化之间是可以映射的 // 自行证明 推论 4，此流水表业务要素是此类业务领域模型的一个子集 以上四个推论对数据系统的设计工作是有极大挂念的，它们将转变我们传统的设计模式四大要求和业务软件的冲突。 我们晓得我们不行能让业务去学技术，而只能让技术去学业务。但是学习成本格外高，时间消耗格外大，学习边界和效果不好衡量。通过推论 1 和推论 2，使得技术人员对业务的学习和把握变的更有目的和边界。 我们都说系统是演化过来的，而不是设计出来的。这句话一无是处，又极具哄骗性——任何事情都有过程，好的系统有，烂的系统也有，好的系统的过程自然不能否定这句话，可是我没见过哪个烂系统由于这句话变好过的。这句话在现实中有两种场景会消灭： 事前架构设计实在无用且铺张时间，以此节省时间 本人担任的系统太坏被人指摘，来招乾坤大挪移 它的独一无益的是躲避了设计工作——设计对业务开发没什么实质挂念（这是普遍情况）———为业务开发争取了足够的时间，加快业务响应效率。但是在有了可行的设计方法，能够处理设计和业务新系统冲突的情况下。正确的做法既不应当躲避事前设计的，也不应当躲避时候责任。推论 123 是挂念我们事前快速设计系统的方法，推论 4 是挂念全体架构演进的基本依据。 通过以上四个推论（业务的数据要素模型），结合业务流程图，基本上可以在短短几分钟到几个小时内完成需求的设计，并且这种设计是过去和现在情况下的最优解。将使设计工作变的可落地，客观。通过以上四个推论，可以在一天或者几天之内梳理完一个遗留系统的全部业务，给出最优设计方案，当前问题和改进方法。不单单是基于用户 UI 或者遗留系统，对新建系统和需求呢？它同样是有效的，我们只需要多做几个点： 关注的是 PRD（产品文档）到业务要素映射，这是阅读文档的重点。 留意 PRD 有可能是不完备的，不行行的；还可能是有冗余的，要思考辨别。 我们在过去较长时间在大量系统中实践过和推广过这些方法，效果是格外惊人的。对于遗留系统基本上能在几天和一周之内分析清楚并给出改造意见，对于新系统，领域设计和开发速度、后续业务支持力量、响应速度和风险效果都格外好。开发人员也反馈成长很快。?同时要留意的是，这种方法是针对数据系统的特殊结构取巧的一个解法。并不肯定普适于非数据系统。譬如，对于两头件系统，CAD 类系统，或者风控系统等，它依靠于数据系统结构，依靠于流水表，依靠于可重现。 通过这些方法，我们利用数据系统的一些特征，去掉了传统设计方法中过于模糊、不行操作和落地，成本昂扬的部分。让业务系统真的变得可设计，让设计真正变得可落地。 系统划分方法 大多数业务系统都属于数据系统，都可以依据上文中的模型去设计和处理。但是我们必需提示：虽然我们上文一直争辩的是流水系统模型，但是一个流水表，就是一个系统么？流水数据模型某种层面只是挂念我们抓住业务要素的一个方法，并不是划分系统的依据。 系统划分的合理依据是流水表之间的耦合性和内聚性，以及全体业务的简单度。 在笼统层面，全部的流水表都可以笼统为一个表。通过 type 来区分就可以了。但是 type 和 type 之间的关系数量，以及业务系统的代码简单度会急剧上升。也可以一个流水表一个系统，这个系统的简单度会格外低，但由于流水表之间有耦合内聚性，这导致这个系统和其他系统有较强的依靠关系，会导致全体的简单度上升。这方法本质是把对象依靠转变为系统依靠，开发效率会极大降低，协作成本，通讯成本会极大提升。甚至有