腾讯、快看漫画专家万字详解数据中台！抓住技术落地重难点

eyung

-引言-

DataFun 访谈了几位数据中台的专家，讨论当前的重点、难点和趋势，从而让读者可以更好的抓住技术落地中的重点，提升自我。
我们在文章中减少了常识的部分，着重表达 DataFun 独家访谈专家后得到的观点。
本文分别介绍了专家在数据中台整体、技术体系、数据体系、服务体系、运营体系、成熟度等方面的观点，其中数据中台整体层面涉及技术成熟度、落地方法论、开源生态等方面。

DataFun社区｜出品

数据智能专家访谈 第03期｜来源

<hr>

-观点汇总-

1. 技术成熟度

• 成熟期：离线和实时的数据加工链路，代表性的技术框架就是Spark生态、Flink生态。
  
• 热点期：LakeHouse，主要技术路径包括Iceberg、Hudi、Delta Lake等；以及OLAP方向，从Kylin、Druid、ClickHouse到Doris等，一直都是市场上的一个热点。
  
• 长大期：数据安全和数据治理。行业在这两方面都还处在一个相对偏规则的简单阶段。
  
• 前瞻期：数据可观测性。它的价值在于随着数据堆栈越来越复杂，数据的准确性越来越重要。在技术上，数据可观测性也开始结合机器学习的能力。
  

2. 技术落地方法论

• 快速发展期的公司，对于中台工具链的要求会更高；对于业务或者数据增长已经趋向饱和的公司，这个时候更专注在数据治理层面。
  
• 大公司和中小公司在技术落地原则上有很大的差异。大公司在数据中台方面更偏向自建，并通常在之后落地到自身的云服务平台；中小企业要么自建，要么使用云厂商的产品，云厂商能够解决平台化或者通用化的问题，自建则更适合业务更垂直的部门。至于数据中台的全链路技术方案上，建议越底层的技术，交给越专业的人做。
  

3. 开源生态
在过去的几十年，一直都是国外公司或者组织在主导开源社区。近10年国内的很多公司或者个人都在积极参与开源体系，并涌现了很多优秀的开源项目。但在商业领域，国内外市场成熟度依旧有差距。

4. 技术体系

• 生产实践中最受关注和重视的，还是数据集成和数据开发建模。在数据集成方向，正在拓展延伸到ETL/Reverse-ETL领域。在数据开发方向上，调度是其中最为核心的能力，dbt等产品的出现是一个非常明显的突破。
  
• 离线开发的痛点：数据链路长，没有成熟的、集成度高的统一开发环境；数据质量、离线任务时间基线管理复杂。
  
• 实时开发的痛点：成熟的建模方案，Flink、Kafka的优化；前沿：流批一体，目前的高效解决方案是数据湖。
  

5. 数据体系
ClickHouse、DorisDB、StarRocks、Druid、HBase、Kudu和数据湖都是很常用的实时数据存储系统。ClickHouse适合单表数据的查询，不适合upsert；DorisDB/StarRocks解决了ClickHouse不适合多表关联的问题，也支持upsert；Druid适合面向聚合操作查询的场景。

6. 服务体系
数据服务体系往往都是定制化自建开发的，数据中台能提供通用的数据服务，但无法为单个业务进行深度定制化支持。

7. 运营体系
数据运营在数据中台中引起的重视度不够；数据安全法在互联网公司落地的指导方案，还比较欠缺，目前落地的也并不广泛。

8. 数据中台成熟度评估
对于数据中台的成熟度评估，并未形成统一的评估标准。

▼

01

技术成熟度

1. 成熟期

薛赵明

计算领域的成熟产品是离线和实时的数据加工链路，代表性的技术框架就是Spark生态、Flink生态，两者也都在从自身强势的领域侵蚀对方的市场。
由于过往的数据生态体系都是基于HDFS的大文件存储，适合的场景是一次写、多次读。这对于一些upsert场景不是很合适。
解决这个痛点通常从两个角度入手，其一是替换底层的存储引擎，例如Hudi、HBase、TiDB等组件来覆盖upsert的需求。但如此最大的问题是脱离原生的大数据体系，有较高的数据搬迁和维护成本。
延伸出来的另一个思路就是Iceberg、Hudi、Delta Lake等产品。它们在大文件存储之上，重新构建一层table format，屏蔽底层的读写细节，在table format这层提供upsert、隐藏分区、模式演进、事务等等方面的能力。加上一些统计信息的采集和定义来加速查询和计算。

2. 热点期

薛赵明

基于table format的技术路线依然存在很多问题，例如小文件碎片、upsert性能等。可以说LakeHouse是当前各家公司都在重点投入的领域，LakeHouse落地目前的主要技术路径就是Iceberg、Hudi、Delta Lake等。
另一个比较成熟也是比较热的领域是OLAP方向，从Kylin、Druid、ClickHouse到Doris，这个方向一直都是市场上的一个热点，也是数据中台体系必不可少的一部分。
整体趋势上是从MOLAP到ROLAP、HOLAP演进，最早成熟的Kylin也是一直在自我革命和更新，不断增强在ROLAP方向的能力。
如果说ClickHouse的出现是解决了单表下大宽表的查询性能的话，那么Doris的出现是技术上的更近一步，在保障一定单宽表的查询性能基础上，大大增强了多表聚合查询的能力，此外在系统伸缩、运维都做了较大力度的加强。
总体来说，OLAP方向既是成熟期也是热点期。

3. 长大期

薛赵明

数据安全和数据治理处于长大期。人们重视这个领域，是因为随着在广大企业积累了海量的数据后，继续在数据驱动的理念下实现突破存在难度。
因为较为容易的数据驱动决策、数据驱动产品体验、数据驱动流程改进等三个方向都有较为成熟的实践和落地，难的是通过数据驱动新场景挖掘。那么在未知场景下，数据的成本就成为一个面临的严峻现实问题。
此外，日益趋严的数据安全保护态势，也驱动我们必须在安全领域做更多的工作。所以业界在这块也一直在突破长大，例如OneTrust、BigID、Immuta、Privacera等公司，在数据隐私保护和计算都有在布局。
但是行业在安全和治理上都还处在一个相对偏规则的简单阶段，或者说行业内公司在安全保护和数据治理的成熟度上来说，都依然处在初级阶段。
可能部分公司有工具和方法，但是缺乏平台和组织配套，或者说没有形成一个自我循环的体系。
整体上来说，路依然很长。

4. 前瞻期

薛赵明

数据可观测性（Data Observability）处于前瞻期，当前也有一些公司在实施和进行能力建设，例如Monte Carlo Data、Big eye等。
数据可观测性其实可以归属在数据治理体系下，它的价值在于随着数据堆栈越来越复杂，数据的准确性越来越重要。
因此，需要我们在数据监控上丰富更强大的能力，像Carlo Data在监控的基础上还增加了排错、 分析并追踪上游原因、显示对下游的影响及通知相关人员等功能，同时这些自动故障发现和故障定位必须是自动化的，自动化意味着效率和具备自循环演进的能力。
在技术上，数据可观测性也开始结合机器学习的能力，是AI+BigData的一个典型实践。Monte Carlo Data也创造性地推出“数据停机”概念。
大部分的理念其实并没有新颖的突破，但出现了一些新的思考路径，例如“数据停机”、 Reverse-ETL等，大部分都是普适性的技术。要让技术得到应用和普及覆盖，关键在于中台建设上如何抉择。

--

02

技术落地方法论

薛赵明

大数据在行业赋能和企业运营、效能提升依然承担了非常核心的角色和定位，未来也依然是企业运行过程中的重要参与者。
大数据技术领域当前也百花齐放，在链路层的数据集成、存储、计算、调度、数据服务、可视化等不同领域的技术可选择，在垂直域的IAAS、PAAS、SAAS如何联动、如何落子也是共性的难题。例如，在云原生时代下，大数据该如何适应和结合？
那么在面对如此多的技术生态中，如何搭建一个适合自身企业的数据中台架构，也是一个非常有挑战的事情。
数据中台其实一个很庞大的体系，在这个庞大的体系中，通常来说，技术人员基本60%以上的时间是聚焦在数据开发上。
当然，这个比例也取决于当前公司所在的阶段。例如，快速发展期的公司，对于中台工具链的要求会更高，因为它优先要解决的是数据怎么保质、保量（及时性、完整性）地接入（数据集成），同时基础设施能够支撑海量数据增长过程中的存储、计算体系的稳定性。
对于业务或者数据增长已经趋向饱和的公司，这个时候更专注在数据治理层面。那么，治理体系的功能覆盖度和执行落地率就非常关键，更细化的指标还包括时效、质量、可用性、安全、成本等维度。回到我们最核心的中台数据开发能力上，则涉及DAG作业的成功率、失败率、下发延迟率、完成准时率等。
大公司和中小公司在技术落地原则上也有很大的差异。大公司在数据中台方面更偏向自建，主要是由自身内部业务的复杂性和内部原生系统的联动打通决定。
当然大公司在完成内部实践和落地后，也通常会落地到自身的云服务平台，例如腾讯的Wedata产品，也是将腾讯内部多年的大数据万亿规模的使用经验在云上产品化落地，很多友商也是如此。
中小企业决定自建还是用云厂商，需要考量自身企业的增长数据和规模，而且要看当前数据在业务上价值变现的紧迫度。例如一家专业做推荐、强依赖数据的公司，必然需要加强投入，在人员规模不是很充足的情况下，云厂商是一个非常好的选择。
云厂商能够解决平台化或者通用化的问题，对于业务更垂直的部门往往不太匹配，从而就需要加强在这块的团队建设。
至于数据中台的全链路技术方案上，建议越底层的技术，交给越专业的人做。因为门槛和技术难度会高很多，专业的人才可以是自己招聘的团队，也可以是云厂商，取决于当前的业务自身状况，特别是存储、计算、加速等等。
举个例子，计算方向概念多、技术繁杂，特别是在计算的OLAP领域上，如何建设技术？
原则是在易用性、性能、性价比三个维度上做trade off。可关注的公司有Firebolt、Dremio、Materialize、 Firebolt等。他们分别在不同的视角切入市场空间，满足市场需求，解决市场问题。
特别是Firebolt目前已经是相对成熟的数仓解决方案，针对ClickHouse做了大量定制的优化、存算分离的架构、矢量化处理、JIT编译、基于成本的优化、索引等领域的工作，促使了这家公司在性能和性价比上非常具有优势。

--

03

开源生态

薛赵明

在过去的几十年，一直都是国外公司或者组织在主导开源社区。这个主导体现在标准体系、开源框架的主导权两个方面，国人一直缺少话语权。
可喜的是，近10年国内的很多公司或者个人都在积极参与开源体系，包含项目开发的参与及主导，也在一些开源组织上建立自己的话语体系，涌现了很多优秀的开源项目，例如Apache Inlong、Apache Skywalking、Apache Double、Apache DolphinScheduler等等。
当然在商业领域，国外的一些商业软件对于国内的广大从业者来说，是相对陌生的，如安全领域的oneTrust、Collibra、Alation等，计算领域的Starburst、Dremio、Firebolt等，数据集成方向的Fivetran、dbt、Astronomer等。
导致如此局面的原因是国内外市场的成熟度不同。在国外，云基础设施以及ToB的付费市场更成熟。不过也可以看到，国内的很多商业化公司也逐渐国外得到了认可，并赢得一些公司的信任，例如TiDB就是一个比较典型的产品。

--

04

技术体系

1. 数据集成

薛赵明

生产实践中最受关注和重视的，还是数据集成和数据开发建模，可以说这两个领域占据了大数据生产中60～70%的工作占比。
这两个领域现在依然保持着活跃的生命力，但也在呈现一些不同的趋势和特点，整体上都在不停拓展自身的功能边界。
在这两个领域的社区中，也不断地出现新的开源框架和技术。例如，在数据集成领域有Apache Inlong、Apache SeaTunnel、Apache Gobblin等，商业化的starup公司有Airbyte、Fivetran、Stitch、Matillion、Singer等；
数据集成和数据开发建模，成熟但是依然生机蓬勃，也一直都在突破自身的能力边界，未来还是有较大的发展空间。
在数据集成方向，除了一些必须要覆盖的源终端的支持之外，也在拓展延伸到ETL/Reverse-ETL领域，特别是在数仓架构中的ODS层（贴源层）数据到DWD层数据的加工。传统的方式是在调度系统做加工处理，目前市面上越来越多的技术在数据集成环节进行简单的数据转换，比如过滤、压缩、采样、条件判断、控制流等能力，例如Data Fusion、Airbyte、Fivetran都是较为典型的产品。
这里特别要提到的是Reverse-ETL。当前大数据不再局限于在离线场景下发挥价值，过往虽然也有一些在线业务和离线数据的联动，实时性也是一直在突破能力边界和时间边界。但是，更广泛的数据价值挖掘和在线业务的结合成了更为紧迫和更具有突破价值的点。自动洞察生成BI，朝着使用门槛降低、服务于业务人员的方向发展，不断提升数据利用效率。典型的公司有Census、Hightouch，更多适应的场景包括了营销、销售、客服、数据分析等。

2. 数据建模

薛赵明

在数据开发方向上，调度是其中最为核心的能力，开源社区有Apache Airflow、Apache dolphinscheduler、Luigi、cdap等。在商业化的公有云领域，各家在这块也都是投入重兵。无论是国外的AWS、谷歌、微软，还是国内的Wedata、Dataworks、DataArts等。
调度和数据建模上，dbt等产品的出现是一个非常明显的突破。该产品主要是在数据转换能力提供了非常灵活的构建方式，大大降低了数据转换的技术门槛的同时。dbt的出现，导致在调度和建模上出现了从ETL到ELT的转变。
转变的原因是，传统的每条ETL管道都是一个复杂的、定制的解决方案，敏捷性低，维护成本高，而数据建模从一次性操作变得越来越即时和高频，转换的步骤被移到最后就成为了必然。

3. 离线开发

屈世超

离线开发，是企业大数据应用最常用的开发形态之一，也具有最多的开发形态，离线开发的技术栈也是最广泛应用的技术。
数据采集-数据库同步部分，常见的数据库有MySQL、MongoDB、Redis、GreenPlum、Redshift等，常用的工具有DataX、BitSell等，能够对数据库数据进行实时、批量、增量、定时、全量采集。有不少企业基于开源，或者完全自建数据库采集同步工具系统。
消息队列常用工具有：Kafka、RocketMQ、RabbitMQ。
离线开发-作业调度的常用工具有：Airflow、Azkaban。
代码校验常用的平台有：Git、SVN、阿里云效等。
多环境级联，目前在企业中并不非常成熟，也还没有通用的方案。当下都以企业自建多级联环境为主，一般搭建多个大数据集群环境，分别承担测试环境、开发环境、线上环境的定位。阿里和腾讯的大数据中台离线开发环境Dataworks在功能上具备多环境级联的功能，能区分测试和开发环境分别开发。
离线开发，需要具备数仓元数据管理、数据血缘功能，还需要具备数据质量监控能力，有一些开源的数据质量监控软件：Apache Griffin，但在企业内容使用的并不广泛，主要是因为其功能不够灵活便捷，难以和较多的离线开源框架、存储系统较好打通应用。
权限管理部分，一般基于Sentry或者Ranger实现。
▍行业现状、痛点、前沿

• 痛点一：数据链路长，没有成熟的、集成度高的统一开发环境
  

从数据采集到数仓建模，再到离线ETL开发、数据治理、数据质量监控、OLAP分析和可视化。不同企业在数据链路的不同环节，面对不同的数据现状，往往要采用适配的技术框架，造成每个企业的大数据技术栈都存在特定选型。
因为离线开发链路太长，技术栈的选型差异很大，所以难以开发出集成度高的统一开发环境。所以，目前各个企业自建的离线开发，一般都根据开源框架做搭积木式的应用建设。
目前阿里的DataWorks、火山引擎的DataLeap提供了一个云原生的集成式的离线开发环境，但需要基于他们提供的大数据平台服务实现。需要采购他们的数据平台服务，然后将数据和任务全部迁移到他们的数据平台中。云原生的数据平台，对企业开发者不够开放和透明，所以迁移云原生还存在一些风险。

• 痛点二：数据质量、离线任务时间基线管理复杂
  

数据质量管理的标准，往往定义为：准确性、完整性、一致性、及时性等。但由于不同企业行业数据差异过大，往往需要各企业根据自身的领域模型、数仓模型对数据质量做出定义，形成企业内部专用的数据质量标准。
目前没有行业认可度较高的通用数据质量和时间基线管理框架。Apache Griffin较难和一些企业所用的离线开发技术栈深度结合使用。
根据调研了解，发现各业务往往需要根据企业自身的技术栈、数据质量特点，定制开发数据质量、时间基线监控系统。

4. 实时开发

屈世超

实时开发，也是企业中经常用到的开发形式。主要针对需要实时了解数据，并根据实时数据反馈做出策略调整的场景。实时开发主要是支持业务中需要实时调整策略的场景。
Flink/SparkStreaming/Storm是实时计算最常用的三种计算引擎，目前Flink的使用率最高。Kafka是最常用的数据队列工具，Clickhouse、Druid、DorisDB/StarRocks是最常用的实时数据存储和查询引擎，Impala、Presto是比较常用的实时数据查询引擎。
实时数仓流程与建模是重要的规范。和离线数仓建模规范的思路一致，但分层会有一些差异，一般也包括ODS、DWD、DWS/APP等分层，分层目的也是为了更好地对数据进行冗余存储提升复用性，提升开发效率。
▍行业现状、痛点、前沿
数据湖作为比较新的技术方向，在实时计算体系的应用还在快速发展中。因其对实时数据的upsert支持较好，所以能够支持数据的实时更新，是流批一体的高效解决方案。Delta、IceBerg、Hudi是最成熟的3个开源数据湖产品。在国内，Hudi和Iceberg的使用都比较广，比Delta Lake的使用度高一点。
实时数仓模型建设，目前没有特别成熟的建模方案。主要是因为实时场景的需求会比离线少很多，所以对实时数仓做复杂建模的必要性和复用性并不高，所以重视度并不如离线建模高。
Flink + Kafka的实时任务开发工具和框架，使用非常广泛，但面临一个问题：Flink任务的监控/失败重启、Kafka消息延迟监控都没有很便捷易用的工具，很多公司二次开发自建了实时任务管理和监控平台。
流批一体开发理念已经兴起了6、7年，Spark Streaming、Flink、Apache Beam都期望解决流批一体的应用。Spark Streaming和Flink主要还是解决实时计算的场景问题，对大量离线数据的处理能力不足，在离线场景的应用中并不多，离线场景主要还是以Spark core、Spark SQL、Hive SQL为主；Apache Beam期望定义一个流批一体的开发框架，定义了各种操作接口来处理实时和批量数据，但目前也并没有和Flink、Spark有非常深入的接口适配，所以难以通过Beam对Spark、Flink实现深度集成式的开发。

--

05

数据体系

屈世超

根据数据的使用用途，可以将数据粗分为四类：离线数据、实时数据、OLAP查询分析应用数据、数据服务应用数据，使用用途不同，那么存储引擎和存储格式也会有不同。
离线数据的存储和管理，主要以离线数仓为主。离线数仓的建设需要依赖模型规范，一般业界都参考了阿里的OneData数仓建模规范和流程。一般数仓会从纵向上做分层，从底层到上层分别是：贴源层ODS、明细数据层DWD、数据聚合层DWS、数据集市层DM/APP。分层的目的是对数据提炼出不同层级的聚合做冗余存储，减少重复计算。
实时数据体系的存储有很多的选择。ClickHouse、DorisDB、StarRocks、Druid、HBase、Kudu和数据湖都是很常用的实时数据存储系统。实时数据是为了解决部分业务场景基于实时数据做的实时策略调整，为了在业务中查询、展示和应用，通常会根据不同的实时场景和数据查询特点而选择不同的数据存储和查询引擎：

• ClickHouse适合单表数据的查询，不适合upsert，所以适合那些数据量约几十亿量级又无需多表关联分析的场景。
  
• DorisDB/StarRocks解决了ClickHouse不适合多表关联的问题，也支持upsert，集群形式支持动态扩容，适合的场景比ClickHouse更广泛，但生态支持没有ClickHosue完善。
  
• Druid适合面向聚合操作查询的场景，数据具有时间属性，独特功能支持按照时间序列做聚合。
  

不少公司使用使用ClickHouse、DorisDB、StarRocks作为实时数仓的存储引擎，基于Kafka存储原始实时数据，然后通过Flink进行聚合计算，将计算结果存储到ClickHouse、DorisDB、StarRocks中。
数据应用服务体系，一般支持实时KV查询和OLAP查询分析：

• 实时KV查询服务，是基于数据对外提供查询服务，支持按照特定key查询对应的数据内容。比如支持查询单个用户的画像内容；
  
• OLAP查询分析，通过特定查询引擎基于SQL查询特定表的特定内容，反馈对应结果；
  
• Ad-hoc（即席查询），支持按照查询的指标生成对应SQL，查询特定的数仓库表行列，经过聚合计算，返回对应的结果。
  

数据在各个行业中的不同场景应用不同，需要使用的数据内容、格式、查询应用方式也不同。标签数据是多种业务场景会依赖的一种数据内容。
▍行业现状、痛点、前沿
数据湖是一个新的应用趋势，能够支持实时计算，同时又能兼容离线计算的架构。已经有不少公司在尝试类似于Hudi + Hive + Presto/Impala的架构同时支持实时和离线的使用场景。但由于生态还不是很成熟，在应用中会遇到不少Hudi稳定性、性能问题，以及和Hive、Presto集成使用的兼容性问题。

--

06

服务体系

屈世超

数据服务的本质是支撑业务需求，所以数据服务的内容和形式，取决于如何以最优的形式支持好业务需求。精准营销、精细化运营、智能风控、个性化推荐，都是对数据服务需求较多的业务。
一般来说，数据服务的形式分为以下种：BI报表/仪表盘、OLAP自定义查询/Ad-hoc（即席查询）、特定数据产品、数据服务化。
BI报表/仪表盘是数据服务业务的最基础也是最常见的形式。不少公司自建BI报表平台，也可以采购行业中比较成熟的第三方报表平台，比如：帆软、观远、QuickBI等。
OLAP自定义查询/Ad-hoc（即席查询）为业务同事提供了更加灵活的自助查询数据能力。一般基于HUE、Zeppelin能够实现自助查询离线/实时数仓的数据，底层的查询引擎可以是Impala、Presto、clickhouse、DorisDB、Hive、Flink等，也有的企业基于Impala、ClickHouse、Presto等查询引擎做了二次封装，支持用户书写SQL或者通过可视化界面选择查询和筛选条件生成SQL，来发起查询。Ad-hoc，支持使用者选择特定的筛选条件，自动生成所需要的报表，开源Zeppelin就具备类似功能，一些第三方BI平台也具备这样的能力（比如观远BI）。当然也有企业自建Ad-hoc查询。
数据产品的目的是服务业务，用最佳产品形态和功能支持业务诉求。常见的数据产品有：AB实验平台、画像平台、DMP平台、广告投放平台、渠道投放数据监控平台、个性化推荐平台等。有不少第三方的数据平台，包含了多种通用的数据产品能力，比如友盟、神策，都包含了数据可视化、行为分析、渠道投放等多种通用产品能力。
数据服务化，是封装对外提供数据服务的接口，将数据以服务接口的形式提供给依赖的业务。数据服务包括实时KV数据查询服务、数据产品的功能性API服务两种，两种服务都可以基于SpringBoot框架开发实现，底层数据的存储和查询使用MySQL、MongoDB、HBase、Redis等。
▍行业现状、痛点、前沿
数据服务体系包含的数据类型、形式繁杂，一般都会针对某类业务搭建一些专用的数据服务系统。所以，不同公司的数据服务系统往往都是定制化自建开发的。
数据中台能提供通用的数据服务，但无法为单个业务进行深度定制化支持。如果业务对数据的应用有很多定制需求，一般都会选择在业务内自建定制化的数据服务。这一点在企业内较难取舍和迁移。
不同业务应用数据服务的场景不同，查询的数据内容和查询特点也不同，导致底层数据存储和查询引擎也需要根据其特点做出不同选择，导致底层存储和查询引擎的使用较难统一。

--

07

运营体系

屈世超

数据运营的目的是为了保证数据的可用性、易用性和安全性。
数据的可用性包括数据准确性、完整性、一致性、及时性。这是数据本身的特性，只有保证了这4个特性，数据才具备了应用的基础，才能推广给业务使用。
易用性是指业务方使用数据的便捷程度。只有便捷应用的数据，才便于让业务方掌握使用方法，较快上手使用起来。易用性运营，主要指数据口径定义清晰、数据模型结构合理清晰、易于检索和查询。
安全性是数据的安全管理，避免数据丢失、损坏、篡改、泄露等安全事故。
数据资产治理：
可用性包括主数据、数据质量管理（准确性、完整性、一致性、及时性）；易用性包括：元数据管理、数据地图、数据指标体系：

• 主数据管理，是对企业通用的部分核心数据统一管理和维护，保证数据口径的一致性；
  
• 数据质量管理，一般通过时间基线管理、数据准确性/完整性检测来实现；
  
• 元数据管理，是将数仓的数据元信息进行管理，标准化库表名称和内容，以及每个表字段的含义和取值含义，便于查询和理解使用；
  
• 数据地图，是将所有数仓库表的位置进行索引和展示，便于理解表之间的血缘关系；
  
• 数据指标体系，是数据在业务应用中发挥统计价值的集中体现，通过数据指标体系，可以直观看出数据模型为业务解决哪些统计类型的需求；
  

数据应用产品运营。是对所有面向业务的数据应用层产品进行数据信息维护、产品应用的运营，目的是让业务使用者快速掌握工具的使用方法、底层数据的用法，解决业务问题。
数据安全管理：

• 一般会对数据进行分级管理，不同级别的数据采用不同级别的权限管理机制；
  
• 建立权限审批机制，对不同分级的数据进行权限管理；
  
• 建立数据权限申请的流程规范，保留数据审计记录；
  
• 可以通过采用一些三方的OA审批管理软件，或者自建专门的数据权限管理系统实现。
  

一般来说，数据运营由数据产品角色来承担。数据产品要根据实际业务需求来设计不同的产品承接方案，负责产品的底层数据依赖、数据安全方面的权限管理，又要推动底层数据模型的建设、准确性保证。
▍行业现状、痛点、前沿
数据运营在数据中台中引起的重视度不够，这方面行业的经验积累也偏少，但却是业务便捷使用数据的重要助力。
《数据安全法》于2021年发布，是各企业需要遵守的数据安全治理法律条文，但对数据安全法在互联网公司落地的指导方案，还比较欠缺，目前落地的也并不广泛。

--

08

数据中台成熟度评估

屈世超

数据中台建立的目的是为多个业务提供通用的数据服务、数据查询能力，支撑业务对数据的依赖。所以评估数据中台成熟度的指标主要有：数据服务能力在业务中应用的广度和深度。广度评估标准是：应用的业务线数量，以及业务内使用数据服务的种类；深度的评估标准是数据服务对业务需求的支持深度。
1. 评估标准一：业务应用广度
广度包括两种：
一是使用数据中台服务的业务数量和比例。当企业内使用数据中台服务的业务越来越多，那证明数据中台的成熟度越来越高，越能针对业务诉求建设通用的数据服务，数据和服务能力的积累也越来越好；
二是在每个业务内使用数据中台服务种类的数量。数据服务的形式分为以下种：BI报表/仪表盘、特定数据产品、OLAP自定义查询/Ad-hoc（即席查询）、数据服务化。一般来说，这几种数据应用形式对数据中台的要求从低到高排列：

• BI报表/仪表盘是使用要求最低的数据服务形式，这种形式没有将底层数据暴露给业务方。
  
• 特定数据产品需要针对各个业务的需求提炼成通用需求，并开发特定数据产品系统支持这类通用需求。这种形式也没有将底层数据暴露给业务方，但需要对数据产品做出规划和设计，以满足业务需求。
  
• OLAP自定义查询/Ad-hoc（即席查询）需要业务方掌握一定的SQL能力，同时数据中台也需要对数据有较好的治理体系，以便于业务使用者便捷的检索和查询数据。
  
• 数据服务化，为业务的系统提供服务接口和数据服务功能API接口，以供业务系统打通数据在业务系统内的灵活应用。
  

2. 评估标准二：业务应用深度
深度包括：数据在业务内的应用深度。从报表的使用辅助业务决策，到通过实时数据引擎驱动业务做实时策略优化，再到建立智能分析引擎驱动业务，做出业务运营策略的调整。
▍行业现状、痛点、前沿
对于数据中台的成熟度评估，并未形成统一的评估标准。

- End -

访谈人：屈世超/薛赵明

与谈人：刘晓坤 DataFun

撰文：刘晓坤 DataFun

<hr>▌专家介绍
屈世超
快看漫画数据中台部门数据研发负责人，大连理工大学计算机专业硕士毕业，依次在小米、EverString、快看漫画工作，专注于分布式服务、大数据中台建设，目前负责快看漫画数据中台，有6年数据产品相关经验积累。
薛赵明
腾讯TEG-数据平台部数据中台体系负责人，10年+大数据工作经历，当前在腾讯主要负责偏数据中台的基础设施建设，涉及数据接入，消息队列，数据治理、数据调度、数据安全等领域。

▌数据智能专家访谈
“数据智能专家访谈”是 DataFun 新推出的内容系列，本系列旨在访谈不同公司的核心技术人员，得到专家在不同领域的洞察，包括但不限于行业重点、热点、难点，增加读者对行业技术的了解。

▌大话数智
大话数智，是DataFun策划的智库类公众号，包括但不限于知识地图、深度访谈、直播、课程等学习资料，旨在为广大数据智能从业者、数据智能团队提供一个日常学习长大的平台，促进先进的数据智能技术的传播与广泛落地。

原文地址：https://m.toutiao.com/i7182525551063466548/