当前位置：网站首页>一些企业数据平台建设的思考

一些企业数据平台建设的思考

2022-07-28 13:27:00 【InfoQ】

（本文首发于https://brightliao.com/2021/01/21/some-thoughts-about-data-platform/）

我最近接触到不少传统行业的客户，他们都希望构建自己的数据平台。其目的大都是希望通过借鉴互联网公司积累的成熟的技术经验，构建自己的数据能力，最终实现数据驱动型企业。

数据平台早已不是什么新鲜事物，甚至在当前大家都在谈论数据中台的时候，还显得有点过时。在我看来，其实大家对于数据中台的认识还处于探索的阶段，并没有形成让行业信服的一致的观点。但一提到数据平台，大家对其应该包含的内容还相对比较清楚。所以，本文尝试选择“数据平台”这个可能有点过时但是相对务实一点的词语来组织内容。这里我不想在概念上谈论太多，无论这个东西是什么，它要解决的企业中的数据问题是明确而具体的。

什么是企业数据平台

企业建设数据平台想要解决什么样的数据问题呢？让我们先来看看是数据如何发挥它的价值的。

数据在企业中如何应用

一般企业内部的数据会以两种方式来使用。

一是支持bi分析，即通常我们所说的各种数据报表应用，它也包括数据的上卷下钻分析。二是支持自助式的探索式的数据分析，通常包括统计分析和建模分析。

不管是哪种方式，首先是要有数据。一般的做法是将数据从业务系统搜集到一个专门用于分析的数据存储中。再在这个系统中执行数据计算。

对于报表应用，通常我们需要周期性的将一些数据指标计算出来，并存储为某一张数据库表，供bi系统快速的查询。

对于探索式的数据分析，我们常常需要提供一个可编程的接口，以便数据分析师可以用于数据处理和分析。考虑到数据分析师的技术背景，这里的编程接口通常是

SQL

和

Python

。

数据平台功能

了解了数据应用的流程，我们就可以将数据平台的功能大致梳理出来。

数据接入支持，需要提供一个接口以便业务团队可以快速的把数据接入到数据平台。

数据开发支持，需要提供接口用于进行数据计算，以便可以算出数据指标提供给bi工具。

任务调度支持，需要将上述的计算程序周期性的调度起来，以便可以周期性的计算出数据指标。

探索式数据分析支持，提供
SQL
和
Python
接口给数据分析师使用。

从更方便的组织和管理数据的角度来看，数据平台还需要具备如下能力：

数据安全管理。比如数据权限控制，实现无权限读写的数据无法读写，权限申请流程简单等；还比如数据脱敏控制等。

数据质量管理。比如可以方便的查询数据标准，根据数据标准执行数据检查等。

数据发现支持，便于平台使用者可以快速的找到数据和理解数据。这里就会包括数据目录，元数据管理，数据血缘管理等一系列数据管理功能。

从软件架构的角度来说，为了更好的支持数据理解，以便高效的进行指标开发和数据分析，一般我们会进行一定的数据模型设计。为了支持高效的复杂数据计算，一般数据平台中会沉淀大量的可以复用的基础指标。所以，从改进软件开发的角度来看，数据平台还将具备的功能如下：

数据建模能力支持

分层的数据架构支持

维护数据开发规范、设计建议、最佳实践等指导性的文档

如果用一张图来概括上面的数据平台，就形成了大家常常看到的如下的数据平台架构图。

其中，如果企业对建模能力有特别强的需求，通常我们还会将机器学习模型相关的功能进一步划分出来，形成一个机器学习平台。

数据平台建设思路

了解了数据平台是什么，我们来看看企业数据平台建设思路。

中心化还是非中心化

首先我们从组织形式上面来分析一下如何建设企业数据平台。一般而言，数据平台会是一定程度的中心化和集成式的。

一提到中心化，想必有人会不服，觉得这样的中心化的系统和组织一定不能成功。我曾经就听到有人坚决否定中心化的价值，其举出的反例可能有以项目为单位的小的敏捷团队，去中心化的区块链，去中心化运维团队的devops思想，去中心化测试团队的敏捷实践等等。

中心化确实有其不足，但是我们也要看到它的很多优点，比如：

可以避免各个团队重复建设带来的资源浪费

统一的数据管理可以更好更快的推进企业内部的数据策略的落地，比如数据标准，数据安全等

实现计算和存储资源共享，节省开支

更方便的实现跨业务线数据集成

其实，中心化与非中心化哪种方式更好，与企业的规模，文化，组织结构相关。

比如，一些规模比较大的业务线，人才资源多技术能力也强，通常完全有能力自建一套数据平台。这样的业务线内部通常业务也特别复杂，数据量特别大，且对定制能力有着很高的要求。这时，企业级别的中心化数据平台带来的成本优势就显得不够有吸引力了。反而会由于需要很多的跨团队沟通协作而降低了效率。

但是，如果我们把这样的业务线当做一个稍小的独立自治的组织来看，在其内部通常是划分为更小的业务团队，在这些业务团队间建设一个中心化的数据平台同样会带来价值。

再比如，有一些业务线，虽然也很大，但其内部的组织结构是按照以业务隔离性非常强的项目组为基本单元组织而成的。每个项目组形成一个小的全功能敏捷团队，各自探索式的推动业务发展。这样的情况下，团队间几乎不用数据共享，且对于数据管理要求也不高，他们的第一优先级是快速推动业务发展。于是中心化的数据平台的价值也不那么明显了。他们甚至可能连业务线级别的数据平台都不需要，而是根据团队各自的需要自建一些小的数据平台。

上面这样的情况可以举出的例子很多，比如华为，其内部的消费者业务线就建设了独立的数据平台为大量的内部项目团队提供中心化数据服务，而运营商业务线则由于其面向企业提供服务的特性，项目间业务相似性低隔离性高，更倾向于每个团队自建小的数据平台。

再比如，很多的银行或者零售行业企业，其内部业务通常比较成熟，常见的情况是建设一套统一的中心化的数据平台。

所以，回到最初的数据平台建设思路上，一般而言，数据平台会是一定程度的中心化和集成式的。但究竟是哪种程度的中心化，还要根据具体的企业情况来看。

对于本文最初提到的传统行业的情况，他们大多数并不是以软件服务为核心，而是以其现有的生产或者信息业务为中心（比如汽车、零售、保险业务）。在这些企业内部，软件常常只是辅助作用，因而软件开发团队的能力也不是特别强。从以上的分析来看，对于这些企业，可能建设中心化集成式的数据平台是更为合适的方式。

采用精益的思想来逐步构建数据平台

其次，我们从数据平台建设团队的职责上来分析一下。一般而言，数据平台建设需要以某一高价值数据分析（包括业务指标或者机器学习模型）需求来拉动，在实现业务价值的同时慢慢的完善平台，最终实现企业级的数据平台。

与此相对应的，不少企业一上来就直接想要建设一个功能强大而全面的数据平台，他们很多都成为了失败的案例。这一做法的典型思路就是，先对标一个行业标杆的数据平台，组建一个大型团队开始做开发。开发过程中，他们对于数据平台谁来使用，产生了什么价值关注不够。最终的结果就是，项目投资人花了大笔经费迟迟看不到价值，从而慢慢减少投资导致项目流产。

采用价值拉动的模式其实就是用精益的思想来指导数据平台建设。它以价值实现为目标，每一个平台功能的实现都对应着立即可见的价值实现。长期下来，通过不断的进行技术重构和架构演进，平台也就慢慢形成。

有人可能会说这样建设而来的数据平台大家都不一样，将缺乏一个行业统一标准。然而，企业是以实现经济效益为前提的，为什么数据平台非得是行业的标准实现呢？在我看来，由于数据平台具有非常强的技术相关性，其最终形式本身就会根据企业和团队的不同而不同。试想，对于某一个功能的软件实现，如果交给不同的开发人员去做，最后产生的设计和实现的代码会一样吗？然而，其实我们并不是很关心代码是否一样，只要最后的功能实现了，目的也就达到了。所以，数据平台的最终形式很可能不同企业完全不同。

一个成功的数据平台建设的过程通常会是：