多图详解数据中台建设框架（建议收藏）
导读：近日，舞动数字·2021数字化转型系列论坛由机械工业出版社华章公司成功举办。在数字化能力与平台构建专场中，《数据中台》的核心作者、数澜咨询及解决方案的负责人铁平老师发表了主题演讲。
铁平老师从技术、服务、数据、运营4个体系回顾了数据中台建设框架1.0，并在此基础上优化给出了数据中台建设框架2.0，同时指出数据中台是企业数字化转型的关键创新引擎。
以下为演讲全文，大数据DT经授权发布。
今天我给大家分享一下企业数据中台的建设框架。我叫沈金，花名是铁平，是目前数澜咨询及解决方案的负责人，是《数据中台》的核心作者之一，也在去年撰写了《数据中台咨询白皮书》。
从我个人的经历来讲，前5年做的事情更多是让数据跑起来，所以更多关注的是数据库，以及数据库相关的一些工作。后七八年更多关注于让数据用起来，所以关注整体的数据架构，包括数据的整体解决方案。是早期阿里集团OneID的一个核心开发者以及运营者。
01 数据中台：企业数字化转型关键创新引擎
关于数据中台，我们有一个观点，就是我们始终认为数据中台是一种让企业数据快速持续用起来的机制，它绝对不是一个技术平台。通过数据中台可以让企业拥有什么呢？
第一，让企业拥有数据价值释放的一个通道能力。
第二，让企业具备开发整个复用、快速试错的一个交付能力。
第三，让企业拥有数据交换、数据资产化，以及资产服务化的技术能力。
所以，数据中台是不是技术平台？其实在去年7月份，Gartner颁布了一个《2020中国ICT成熟度曲线报告》，正式建议企业的管理者把数据中台当作整个数据化转型的关键创新引擎，从而解决数字化的收入，以及实现可持续的交互的业务能力。
第二个观点，Gartner建议企业CIO把数据中台当作一个开发复用和数据资产组合的组织策略。而且数澜非常有幸成为国内首批入选数据中台标杆供应商的一个企业。
所以，Gartner的观点就是数据中台是企业数字化转型的一个关键的创新引擎，大家也可以从这些大的曲线里面看到。
02 数据中台建设框架1.0回顾
然后，我们在2019年详细解释了数据中台建设的框架1.0的版本。今天我们首先回顾一下，把它分解成一二三四五：
一是战略转型的诉求。
有两个保障的条件：
关于组织流程。
关于数据认知。
数据中台的三个建设目标，就是怎么围绕数据的可见、可用和可运营。
以及在大的目标的牵引下面，我们去规划整体的四大体系，就是典型的数据、技术、服务和运营，以及最终落到项目层面，去落实具体的某个需求，或者多个需求。
所以，我首先会把四大体系按照我们的理解给大家回顾一下。
1. 技术体系
技术体系是涵盖了多云异构的计算存储引擎，以及相关的平台工具。对于平台工具它有几个用户角色：
面向数据运维，包括集群运维。
面向数据开发，包括ETL。
面向数据管理，比如数据治理的具体的管理人员，元数据的管理人员，还有数据标准的相关管理人员。
面向应用开发。IT团队的应用开发也是数据中台的一个用户，我们后面在服务体系里边会给大家重点阐述。
面向数据分析。因为我们看到部分的企业里面把一些BI或者一些大屏也当作数据中台的平台工具类。
往下一层就是有关数据如何存储计算查询。我们把它分为四大类：
离线
实时
即席
在线
有关离线和实时其实大家接触的比较多。但对于即席计算，特别是在线计算，或者在线查询，为什么在数据中台里面我们要去考虑规划这方面的内容？这里需要介绍下服务体系。
2. 服务体系
它是补全数据应用的最后一公里问题。它包括一些对于数据服务的分类，包括典型的标签画像类，还是基础数据服务类，还是最终的算法模型相关的。
所以，你会发现围绕数据中台，不光要去承担数据的计算，也还是要去满足数据的查询的能力，我们往往会讲资产服务化。
所以，针对不同的场景，无论是面向售后场景，还是千人千面场景，还是面向一个房地产置业顾问场景，它对于整个数据的响应时间和查询性能的一系列要求，是不一样的。
所以，在整个数据中台规划里面，不但会强调数据相关的存储计算，而且会强调数据的服务化，以及所依赖的一些在线计算和即席计算的能力。
回到服务体系，服务体系里面针对标签画像的基础和规则服务，这边举两个例子。
第一，面向房地产、中介，我拿到一个客户，拿到一个手机号，我想看到置业顾问面向访客的相关信息，这是一个非常典型的画像的诉求。
第二，规则类，我们会发现在客户的数据中台，或者说营销的管理平台里面，我们会经常看到对于人群的精准的圈选的一个诉求。所以，在规则相关的服务里面，这是相对比较常用的。
第三，分析以及相关的搜索。分析典型的产品就是一些自定义的指标体系、平台，然后在查询搜索的能力里面，我们就看到，无论是互联网典型的搜索平台，还是个性化的搜索平台，以及面向企业里面内部管理，面向合同，面向你的知识库，或者怎么做快速的搜索。所以，这两者在整个选型上，一类可能更多是MPP数据库，另外更多是像Elasticsearch这种类型的引擎。
第四，偏算法类。无论你是批量跑，还是实时跑，最终面向整个应用服务的时候，一定会选择一个响应相对比较高的一个查询引擎。比如说，我最终通过落地的方式，用Flink写的一些算法，直接落到具体的Oracle或者MySQL上面，这个用户在直接访问的时候我们就可以快速的响应。
所以，上面的技术体系和服务体系结合我们来说明，数据中台在体系规划上面不光要考虑数据的计算能力，特别是要考虑数据的查询能力。
3. 数据体系
数据体系我们更多的描述的是整个数据资产的一个分层和分域。分层其实市面上有很多理论，包括是分四层，分三层，还是标签层，包括整体数据体系相关的特性。
这里补一个知识点，我们在交流的时候，大家可能会认为企业最终业务用的标签，或者叫指标是不是一定来自于图上的标签层？回答是否定的。标签层的设计，它其实更多是面向通用的一些标签的一个层面，标签层很多时候是一个相对于围绕对象的一个跨领域的组合。
所以，在部分客户里面，我们会看到那些标签层，他们把它称之为对象层，或者叫萃取层。所以，一个观点就是不要认为企业之间能用的数据或者标签是一定来自于标签层，他有可能还是来自于最终的应用层，这是一个点。
第二点，我们经常讲的OneID，或者叫用户识别，到底在整个数据分层里面，或者叫分域里边是在哪个领域？我们更多的建议是在标签层，或者最终的集市层去使用。为什么呢？后面会有一个实例。就是我们认为OneID更多的是一个面向整个数据实体跨领域的一个拉通。
所以，在图里面是什么意思呢？就是我们把全网的用户认为是一个大池子，首先应该缩减成一个小圈子是什么呢？是可识别的用户。这个可识别的用户意思就是我们可唯一的标识一个自然人。所以，典型的，比如说你的FaceID、无线设备码、身份证号、银行卡号，我们都认为是可以统一在标识里的。
第二层，再往下说也就是，我不光要标识，还能触达。什么意思？就是我还得影响你。所以，这个典型的ID是什么呢？就是手机号，或者是部分业务里面能推送信息的一些业务ID，甚至包括你的收货地址。所以，通过全网的用户到后面的标识，到后面的触达，最终这些人我一定能找到相应的数据或者画像来精准的进行营销或者推广。
最早我们对OneID更多的应用场景其实是在销售领域。所以，大家不要片面的去分析说OneID一定是和用户中心，或者是在非营销场景里面。
举个例子，比如铁平可能有两个手机号，一个手机号是我自己的，另外一个手机号是我给我家里邮寄了一个快递。我父亲的手机号就挂在我身上，但是概率不高。
所以，对于OneID的算法模式里面，如果我做得足够精准，其实就是我绑一个手机号，但是一旦识别概率放宽一点，其实认为可能是同一个家庭，或者同一个小区，或者同一个小组的同事，都是有可能的。
但是，如果把这个模型再扩大一点，很多时候就是整个公司在你的模型里面可能是一个人，为什么？因为大家整体的收货地址都是一样的。所以，这个就是我们当初在阿里内部做OneID的一个比较直接能阐明它的用途以及原理的一个图。
4. 运营体系
有了数据体系以后，我们再来看，有了数据，我从左到右，从基础的TDM层到数仓层，到标签层，以及最终的集市我要把它运营起来。就是我们始终觉得整个运营视角会分三大类：
面向数据运维的视角，就是我关心他的运行时长，我关心它的CPU，它的内存。
数据管理角色，就是我到底有多少数据对象，都是从哪里来的，我要怎么用，用得怎么样，这是数据管理的视角。
数据应用的视角，从一个应用来看，或者应用开发来看，我要让我的应用变得更加智能，我更多关注的三有什么数据可用？
为了整个数据体系完整的生命链来看，从左到右我们会分为运维的视角、管理的视角，和最终运营的视角。针对不同的视角下面我们就会关注不同的KPI，不同的KPI条件下我们就会关注不同的使用流程规范，以及相关的一些组织能力的建设，到底现阶段要不要关注整个资产模型，或者相关的某个运营人员数据运营能力的培养。
所以，这是我们基于书本上的一些数据账单，或者说是运营的视角下，我们重新抽象的一个新的更容易让大家理解，通过可控、可持续的保障体系，围绕数据资产来跟大家解释一下我们的运营体系。
当然，在使用当中，比如从数据管理的角色，我要分析从哪里来，到哪里去，无论你是秒级别的数据实时分析能力，还是分钟级别级别的批量数据分析能力。都会考虑一些度量体系的打造，无论是存储的度量，计算的度量，还是服务的度量，都会转成统一的一个计量方式。所以，这是我们对整个运营体系的理解。
你发现我们去分析整体的技术，以及去服务服务体系，以及它核心的建设内容的数据，以及最终把这个体系转起来，整体的运营体系，这是我们在书本上费了很多的篇章，以及项目的实践里我们总结出来的。
所以，一般在项目里面，我们看到很通用的一个架构图是什么呢？就是这四大体系。整体架构的示意图，从下往上，从最初的低层，无论是云、机房，还是各类的计算存储引擎，以及OneID以后数据整体的四层，或者叫三层，以及OneID之间的关系。再往上走就是面向整个数据的API，各类引擎能力，分的类型可能不同企业会不一样。
然后，围绕这些数据的服务内容，以及数据的内容，我应该用什么样的平台工具进行服务。
所以说，从直接面向用户的比如自主分析平台，BI工具，还是一些建模平台，以及整体在我们右边的就是面向整个技术体系里面的服务平台，还是开发平台，还是管控平台，还是数据交换平台，这都是面向不同的IT能力里面不同的角色进行平台工具建设。
然后再往上走，通过数据门户，或者统一的数据服务能力，无论三我内部用户，比如说，我自己的员工，还是我的供应商用户，还是我最终面向终端用户。这是四大体系在我们方案层面面向整体架构描述的时候，我们常常会用这个示意图来跟大家进行一些分享。
03 数据中台建设框架2.0迭代
上一本书我们写了将近两年时间，两年时间里面我们碰到各种各样的项目，一个诉求就是关于数据治理。
数据治理目前包括国家提的一些治理体系，包括国内外无论是DCMM相关的数据管理成熟度模型，还是比较成熟的DAMA体系，这是我们接触到的。然后还有信通院做的数据资产白皮书，这是一个驱动因子。
第二个驱动因子就是客观的我们去做数据，做分析，做应用，放在企业里面，客观的一些数据真是比较差，特别是一些要么就是没数据，要么就是多数据，两边数据对不上，要么就是完全的没法用。所以，这个就是我们认为要把数据治理这个事提上更高的一个维度来考虑。
第二点就是我们在做项目的时候大家都会去考虑，我做数据中台到底给企业业务的价值提供什么？然后我在做的特别大的项目里面，数据中台跟整体的企业信息化规划到底是什么关系？到底通过什么样的数据复杂能力加强了我的应用，我的应用到底是为怎样的业务能力服务的，你得回答出来，这是另外一个驱动因子。
第三个你会发现，其实我们最早的一些交付实施方法，其实很多有借鉴了一些互联网的经验。同时我们对传统企业的交付经验是在不断的摸索和完善的。包括我们去年也深度参与了信通院关于数据工程和分析应用成熟度的制定，包括评估工作。
结合种种互联网的经验，传统的服务经验，信通院的一些相关的碰撞，其实我们总结出来了我们数澜自己的一个整体的交付方法。
从三个方面的驱动因子，我们去完善了一些方法。
变化一：关于数据体系
首先，数据体系。刚才的分享很多我描述的是有关数据如何分层，以及面向数据中台如何进行分域。所以，在这里我们增加了两个新的内容，有关数据分类，以及数据分布。
什么意思呢？就是很多客户在实际落地的时候，包括做管理的时候其实是理不清自己的数据家底，这个数据家底包含两个方面：
我核心的数据对象我不知道。
面向整个业务系统，到底有哪些数据我也不清楚，我该怎么分类，有可能有主数据，有可能有ERP的数据，也有CRM等一系列的数据。
第二，目前业务里面正在用的数据，或者说想要的数据到底哪些是好的，哪些是不好的，我该怎么样做优化，这个其实我也不清楚。所以，我们把数据分类提到了一个更高的维度，这也是工业这块对于数据分析分类的一个诉求。
另外，有关数据分布。很多企业又因为计算存储，或者计算引擎的复杂性，往往在选择的时候会混合一些诉求，往往有不同存储，包括有Oracle、MySQL，甚至GP，不同的计算引擎的诉求。其实从IT管理来讲，我需要一张图看清楚数据整体的流向。
所以，我们做部分的项目里面，无论是规划类项目，还是实施类项目，包括数据流规划，或者数据流实施，或者数据流优化的一系列的项目进行去实施。
另外，企业领导或者管理者特别想搞清楚，我的整个企业数据流向到底是怎么流的，应该分析一下。所以，我们把整个数据分布提上了数据体系里面的一个关键性的内容。
有关数据分布，我接了什么数据，没有接什么数据，整体数据分层怎么划分，哪些是通过数据技术可以做整体驱动的，哪些是数据业务我要反推来优化整个标签层，以及最终的指示层，以及我最终用的时候到底是跨哪些主题域去访问我的数据，然后最终跟整个业务域进行关联关系。
当然，这只是数据分布里面比较High Level的一个层次，往下到级别，或者到实施级别其实有更细的划分，这是给大家做一个示意。
变化二：关于数据业务能力
我要回答到底通过什么样的数据业务能力来刻画数据产品的价值图。以我们以前的原理就是从基座到数据怎么变成资产，然后资产怎么样要服务，最终应用去结合。
所以，在数据中台的一个范畴，我通过大的新的数据应用，以及新的跟业务应用进行结合，让应用变得更加智能，以及我通过应用如何来承接整个价值链里面的一个业务能力。我们后面把它定义为数据中台，其实是帮助企业构筑了整个数据价值的一个释放通道。
一个非常典型的制造业客户围绕他的价值以及支撑的描述，从他整体的市场研发、采购，包括一些物流，包括一些销售到服务，以及未来承接整个价值，我需要IT做什么？我需要财务做什么？我需要人力做什么？以及需要运营做什么？
我们目前做项目的时候一定会首先去刻画它的整体的场景蓝图，我到底通过怎样的数据服务能力去加强这个领域的业务能力。比如说，在整个财务领域的应收应付，还是在整个销售领域商品展示，还是说供应链领域相关的，我要做一个供应商的评估，我们会把这个图刻画出来，这是我们的一个思考和改变。
变化三：关于治理体系
内容其实更多描述的是数据治理，因为我们没有把整个面向数据团队，面向他的人才，面向他的流程，面向他的架构等一系列作为整体的治理内容。所以，这里面我们只是把它涵盖整个数据资产，围绕数据资产的治理放到了这里面。
围绕整个治理体系，基于场景的一些数据生产，还是面向基于规则的一些质量管控，以及最终面向以成本作为考核，作为一个价值运营。所以，你会发现很多传统的数据治理的方法，比如面向元数据、数据标准、数据模型等一系列的，我们其实更多放在了中间，就是规则和质量把控。
为什么我们会强调数据场景的数据生产？一个核心点，除了数据本身交换的技术需求之外，还有一点就是埋点，就是我作为一个数据中台的项目，其实有两个非常难的点：
客观条件下，我如何通过主动的方式去获取一些过程性数据，如行为类或如何识别可以采集更多的数据。
组织级别里面，明明有数据，但是他就不给我，我怎么通过另外的方式，或者组织能力去把这个数据拿到过来。做数据中台或者数据产品的时候有一个基础点，就是作为一个项目发起方，我得有能力去拿到原始数据的资产，如果连数据都拿不到，我的数据中台、数仓，或者BI就没法做了。这是我们认为基于产品的数据资产非常关键的一个点。
第三个点就是我做价值运营，无论做对象的拉通，还是做度量体系，以及相关的数据安全以及数据服务，我都可以这个范畴下面。
所以，在整个治理体系里面，我们还是会围绕三个不同分类项的一个核心的大的流程框架去优化，及具体的一个信息化的支撑，包括数据治理的工具其实就在整个规则的质量管控的下面，我们会统一去考虑。
所以，这是我们经过这么多项目对数据治理体系的一个思考。
变化四：实施交付方法
最后，交付实施方法。所以，通过信通院的深度参与，结合自身的行业实践，包括我们目前对项目的阶段，也原来变为了6个，包括后来项目实施模板，包括项目的类别，以及互相之间的一些共享集市具体某个小的一个细分的业务活动，这是我们对交付方法的一个迭代优化。
04 数据中台建设框架1.0和2.0
基于以上四个不同的优化，其实提出了我们新的数据中台建设框架的2.0的版本，这个版本目前还在部分的迭代。
我们在以上三个大的数据因素的前提下，我们从一二三四五整体的建设框架，演变成在整体还是以数据战略作为整体一个大的牵引，以及数据中台的可见、可用、可运营的一个目标准则，为了承接这三个目标，我们重点打造数据文化，体系框架，以及治理体系，这三类是作为我的一个能力框架进行组建的。
然后，在这三个能力框架的基础上，落到具体的项目需求，然后去规划具体的业务解决方案和IT的解决方案。所以，在整个项目实施里面，就去管理包括资源、架构、实施，包括最终的运维，我们会整体的进行考虑。
所以，有了整体的框架以后，会发现这个框架里面有一些关于数据治理的内容，有关于一些企业架构的开发框架，也有保留了整个互联网，最早数据中台的一些思路和想法。
下面这个示意图非常通用的一个框架就是还在大的数字化转型的一个牵引下，我去夯实整个数字化转型的基盘，然后再去打造业务和数据的一体化示意图。
这个不是业务和IT，更多是业务和数据的一体化模式图，以及面向整个企业完整的拥有的价值的场景，我去把业务领域拉通，以及核心围绕数据技术，整个数据治理，以及为了整个团队的能力框架，我怎么把它去打造出来。
所以，你会发现这个阶段的描述方式就会相对比较全面，我们还是以大的目标作为牵引，重点去看整个团队现阶段，以及未来阶段应该去构造的能力框架，然后着重去看到底选用什么样的数据技术，还是选择什么样的治理技术，这是我们的一个数据中台的建设方法。
把整体的建设的案例和框架往下再细分一点，我们还是会围绕整体的业务蓝图的调研，包括一些数据字典，以及往下落的时候核心的会去抽象场景蓝图，包括整体的数据相关的内容，包括技术体系和服务体系。
以及围绕数据字典，围绕数据体系，以及业务场景蓝图，我在治理体系里面通常的范围，包括元数据、标准质量，以及数据安全，最终的成熟度我应该怎么来做，又细分了很多领域。
我们会把整个体系框架和最终的治理体系的关系在项目落地的时候会梳理清楚。
最终落地的时候就是我们可以看这个治理体系到底是整个数据中台的数据治理，还是面向整个业务应用的数据治理，这个上面我们也可以做一定的阶段性的取舍，以及最后的图示里面，治理体系里面其实可以回过头来服务整体的业务应用开发，这个典型的框架就有很多了，包括数据字典设计，包括性能，以及业务应用的一些开发。
这就是今天我给大家分享了一下数据中台整体的建设框架1.0和2.0的演变，以及我们在这一年多来如何去思考数据中台建设的一个方法，感谢大家！