DMC 的巨大威力，可能远远超过数据中台

[leechen]

讲在前面

近些年来，大数据这个概念异常火爆。越来越多的企业正在重视数据。那么数据能为我们带来什么呢？

这得从大数据的价值说起，我们先来看下面的例子：

大火的美剧《纸牌屋》，通过大数据分析，选取适合网友的视频偏好和明星选择，造成轰动的播放量。大数据在社交媒体和娱乐行业的大数据分析，一部分也在引导观众和粉丝，让其为娱乐产业消费。

这个例子中我们可以看到存在几个逻辑断点叙述中都没有讲到，仔细拆分一下我们发现，要实现上面例子中的目标，我们需要经过以下几个步骤：

1. 数据采集（挖掘）

2. 数据整理（清洗）

3. 数据分析（可视化、算法模型推演……）

4. 决策（分析结果）

但往往现实生活中这个过程是动态的。比如我们根据用户浏览网页的历史数据为用户推送他喜爱的内容，然后用户新的浏览行为又对推送结果做出影响，如此反复，优化出更适合用户口味的内容，没有终点。

所以我们会发现，这些节点在上面的过程中是持续的，系统不断的通过采集 > 清洗（动态过程的清洗节点会变得比较轻量，因为数据结构已经优化过的。）> 分析 > 决策来优化结果。

现在越来越多的互联网应用都采用这套利用数据的思路，只不过每家都有自己独特的算法（数据分析）。

那么答案显而易见，大数据能为我们带来的是科学决策，以及科学决策导致的用户体验提升、效率提升……到收益增加。

DMC

回到我们今天要说的 DMC （ Data Message Center：数据消息平台） 平台架构。我认为这将是未来每一个企业（不仅是软件企业）所应该架设的基础服务平台。相比于数据中台，DMC 才是企业的中枢命脉，那么下面我们展开来讲一下。

随着数字化的进程，信息变得像空气、水一样的必要，获取成本也将变得越来越廉价（经济规则的必然性）。但与水和空气不一样，信息的产物数据，是随着时间向前，逐渐堆积的。不同的数据充斥着我们的生活，它们是大量的、错综的、看似无序的，这就是大数据。我们要怎样从大数据中提炼有利于我们的部分变得至关重要，最常见的做法是企业 BI，是从数据源接入（有些 BI 工具还带有采集功能）到分析决策的一整套流程。

在此基础上数据中台强调数据统一管理，将数据池、数据湖……进行整合，要求数据创建时的结构化，对不结构化的进行自动结构化，方便分析工具数据源接入以及打通数据在各产品间流通的可控和通畅。

而 DMC 是更进一步的、更具革命性的企业数字化基础平台。他将企业数字化分为数据中心和消息中心，统一在 DMC 平台进行发放和管理。

区别于目前所有的数据管控架构，DMC 将不允许使用数据库方言去构建数据库表，因为这对业务扩展和产品的资产性非常不利。但同时 DMC 必须具备结构导入导出能力和自己的方言，以便于配置的传播和备份。DMC 更大的能力在于，他能够统一管控企业的对外消息管道，也就是数据的流通。

一张图我们来看看 DMC 架构的样子：

其主要目的有以下几点：

• 简化应用开发

• 数据统一管控

• 监测信息动态

• 提高安全性和扩展性

就以上几点我们来看看 DMC 怎样实现这些特性的：

简化应用开发

我们都知道，所有应用都分为后台和前端，采用 DMC 在为应用创建数据库时，我们可以通过 DMC 的插件为应用自动生成大量的 CURD 接口，免去了很大程度的应用后端开发，再加上全平台的统一身份认证。

消息平台监控数据的变化。通过应用的订阅，将这些数据的变化信息进行广播，让应用得以实现自动化的流程。

消息平台还能够接入任何外部的消息发送器，并向上层应用提供统一的操作接口，使应用通知变得简单统一。

应用间的相互消息传递也变得非常容易。

如此一来能省去至少一半的应用开发成本。

数据统一管控

这个层面你可以将 DMC 看作一个 ORM 中间件，他有自己的一套方言，并能够将方言转换成任何高性能的数据库方言，并且为用户提供一套可视化的构建界面。

对于初级 DMC 平台，不允许在为应用创建数据库时指定数据库类型，这对于 DMC 将不同应用之间不同的数据类型结构化极其有用，不同应用间数据结构都能在 DMC 上面进行统一的整理，那么相互调用也会变得非常简单。

高级的 DMC 平台，虽然允许用户创建不同类型的数据库，但这个步骤将在 DMC 平台基础上完成，那么表关联关系和字段注释，也将使得数据分析变得容易。

对于以插件方式构建在 DMC 平台上的 BI 系统而言，无论如何数据源都看起来是清晰且单一的。

监测企业所有数据动态

既然企业应用的所有数据和消息都要流经 DMC 平台，那么信息流的管道监控也将变得十分容易。

我们可以在 DMC 平台清晰的看到信息的阻塞情况，必要的时候为指定的管道扩充资源和带宽。

并且这些管道的使用情况都将作为 DMC 平台本身的数据存储在数据库中，同样的我们可以使用 BI 工具对构建在 DMC 平台上的应用进行访问量等分析。

必要的时候我们可以使用插件方式对各管道的收缩，按照算法自动化调整。

提高安全性和扩展性

安全性

上面我们提到了，DMC 能够监控消息管道的资源利用情况，那么对于反常的资源利用也能够容易的判断出来，这对于企业信息安全至关重要。因为上面也提到，所有的信息流通都会被 DMC 所记录，那么一些保密作业的安全审计会变得十分简单。

扩展性

我们上文中也提到，初级 DMC 平台和高级 DMC 平台，这中间至关重要的是一套 DMC 标准规范，如果有了统一的对上标准，我们可以在下面做很多操作，比如 DBA 操作和集群调度来提高数据的操作性能，对于初级 DMC 我们可能用不到这么复杂的技术，简单的数据库常规操作就可以支撑，只需要为他们设计一套标准的数据结构就可以。

DMC 的具体内部架构

一个新的问题，我们以上都在讨论基于 DMC 去开发新的应用，但是外部应用该如何接入 DMC，确实这是 DMC 目前来看最大的难点。对于外部应用而言，DMC 可以做的就与数据中台很雷同了。但也不妨碍我们通过它的插件功能一点点将其移植进 DMC 。

综上来看，DMC 架构的最大难点就是一套统一的标准规范，这能很大程度上降低外部应用的接入难度，也能够更加方便 DMC 的传播和配置复用性。

相对于数据中台等架构理论，我认为 DMC 才是信息化基础设施的不二之选。

实践

为此，我实验性的开发了 Kodev （ taiwutech.com ） 这个 DMC 平台，大家可以通过使用说明，或者注册用户后去了解他的整套思想流程。

[leechen]

一个新的架构思想

[DoctorCat]

听起来是大数据计算平台+数仓么。
窃以为难点在于公司组织层的战略，不同 BU 怎么看待这个玩意。
小公司对数据的态度大多是秉行先活着再治理，所以暂时用不着，大公司里呢很难推进 “我有一顶很好的帽子，不过得把你们的辫子剪掉”

[leechen]

@DoctorCat 可能还是没有讲清楚，DMC 旨在为企业提供所有应用建设的基础服务，也就是数据管理和消息管理，其他的复杂功能或者应用都是以插件形式出现，kodev 目前正在做插件中心，他不是一个 saas 服务，是一种倡导，希望 kodev 希望能够成为一个标准的 DMC 框架，有可能的话它会开源。

[leechen]

@DoctorCat 也就是说，他只存数据和监控数据变动，以及为上层的插件和应用提供接口，至于怎么用数据是应用和插件的事情，这能很好的形成公司的应用生态，减少应用开发难度和周期，集中化管理公司的所有数据。确实对现有的很多东西是颠覆性的改动。

[gemini767]

@chaoxuelei 你没理解 2 楼说的

[leechen]

@gemini767 ~~~~~~~~明白吧，就是大公司商务层面的或者顶层规划的改动难度，以及小公司感觉这东西是大炮打苍蝇~~对吗？我在 4 楼也说明会对现有东西颠覆性改动~~~~~，我整体的意思，这是一种非常普适的架构，并且我把它做成了标准化产品，如果打磨 ok 了，发展生态的话，我会考虑开源。enenen……，怎样兼容老系统也是有办法的

[uxff]

这个项目，做好 ppt，一个估值千万美元的公司马上要诞生了。具体估值，以演讲水平为准。

[leechen]

@uxff ~~~~~~没想过，只是想一点点实现自己的想法而已，但是确实有人联系说要投资 -_-||