数据能力的构建过程

云祁

已于 2022-03-10 09:37:05 修改

阅读量323

点赞数

文章标签：数据仓库大数据编程语言 python 机器学习

于 2021-10-10 15:15:46 首次发布

本文链接：https://blog.csdn.net/BeiisBei/article/details/121240320

版权

数据能力的构建过程

|0x00 数据能力是什么

我们经常问自己“什么是数据能力，数据能力如何构建”？我想，没有哪个业务，一开始就是明确知道自己想要什么，都是经过一定时间的摸索之后，才能积累出丰富的经验，这时候数据能力才有了勇武之地。

比如电商行业中，OneData方法形成之后，在其他的电商和类电商业务中，就可以快速铺开应用；而随着越来越多的企业加入到数字化的浪潮，云上中台的概念也就逐步落地。

因此，理解数据能力的构成，懂得每个阶段数据所能够发挥的作用，就是数据同学所需要具备的基本能力，也是我们日常工作时进行规划的前提。

|0x01 数据仓库：数据的历史

从笔者的理解中，数据仓库的最大作用，是承担了沉淀与分析历史数据的功能。

数据仓库是什么？以数据建模理念为基础，以消除数据孤岛为目的，通过一套标准方法和工具集，解决大数据计算中诸如质量、复用、扩展、成本等问题，能够驱动业务发展的体系。可以说，数据仓库能够较好的反映数据的历史变化情况，并通过事实表等方式，加以合理的呈现出来，并提供数据分析的基础展示形式。

数据仓库的第一层境界，是元数据管理，这是数据仓库的沉淀功能。你可以设想一下，表是数据仓库的基本展示形式，当随着业务快速发展时，表的数量不断累积，久而久之，会是一个多么恐怖的数量。对于维护量级在万、十万、百万量级的系统，区分它们的安全级别、使用频率、重复性、数据质量等信息，真的需要一个团队去专门的维护。可以说，元数据有重要的应用价值，对于数据管理，提供诸如计算、存储、成本、质量、安全、模型等方面有重大的利用价值。

元数据的价值主要体现在如下几个方面：一是快速的搜索定位，通过搜索引擎的方式来查找相关数据；二是标准化的图形展示，方便使用者所需要的关键信息；三是积累历史数据信息，避免数据的重复开发；四是直接关联分析工具，可以调用报表插件来快速看到直观的报表信息，提升开发效率。

数据仓库的第二层境界，是数据建模，这是数据仓库的灵魂。业务是随着商业逻辑不断变化的，为了能够更有针对性的进行数据组织和整理业界逐步形成了数据建模的四部曲：业务建模->领域建模->逻辑建模->物理建模。简单讲，就是明确具体业务，抽象实体和关系，结合具体的建模方法，确定所有关键成分和属性，最后建数据表进行数据的存储和计算。目前数据建模的方法论有两大阵营，一个是基于关系型数据库理论设计出来的，比如基于3NF的范式建模。虽然目前也有不少非关系型数据库以及不少半结构化和非结构化数据。但将半结构化/非结构化数据转化为结构化数据，然后再利用关系型数据库处理仍然是一种通用的主流数据处理方案。另一个是基于数据仓库之父Bill Inmon提出的维度建模理论，是从全企业的高度利用实体关系来对企业业务进行描述。

在实际开发场景中，我们更熟知的，是分层理论，也就是经典的ODS - CDM - ADS划分方法，其中CDM又称之为公共层，可以划分为DWD、DWS、DIM三个部分。通常情况下，根据“二八原则”，我们希望20%的表能够覆盖住80%的需求，因此CDM的作用就非常显著，承担了数据整合的主要功能。除此之外，ODS主要承担了过去的ETL功能，负责数据的抽取和转换。而ADS是面向应用层做开发的，可以灵活设计使用。这种方法，清楚的展示了数据的处理流向，是数仓沉淀能力的直观展示。

数据仓库的第三层境界，是主题建设，这是分析能力的前提。我们对数据仓库的划分，基于的是对商业能力的理解，比如电商中的交易、营销；供应链中的库存、物流；流量中的搜索等等。从大的商业逻辑出发，逐步拆分到最细的产品功能、业务实操等过程，以保证整个公司数据的规范和口径统一，最终提供标准化的分析思路和方法，这就是主题建设的作用。

主题建设可以从宏观、微观两个矩阵来进行分析。宏观矩阵描述的是公司业务线和对应的数据状况，比如我们可以将一个业务主题理解为公司的一条业务线，侧重于将数据主题理解为行为数据主题，比如说登陆、点击、下载等行为主题，通过这种方法统计业务的基础数据，或者是北极星指标。微观矩阵则是主题和维度的对应关系，可以是原子的、也可以是抽象的。比如流量统计会区分手机类型、网络类型、地理位置等维度；比如电商统计会区分消费者年龄、购买的路径等维度。

|0x02 数据湖：数据的现状

从笔者的理解中，数据湖的最大作用，是能够提供尽可能多的技术手段集合，以达成越来越复杂的目标。

数据湖的概念提出时间并不算久，可以简单理解为支持企业级应用的、能够适应快速发展技术趋势的一种基础设施，不论是结构化数据or非结构化数据，海量数据or少量数据，都能够支持存储和计算。就像在湖中有多个支流进入一样，结构化数据、非结构化数据、日志数据、实时数据，都流入了同一种数据存储结构之中，并进行不同类型的分析处理，以指导做出更好的决策。

可以说，数据湖的出发点是补全数据仓库实时处理能力、交互式分析能力等新技术缺失的情况。其最重要的特点，就是丰富的计算引擎：批处理、流式、交互式、机器学习，该有的，应有尽有，企业需要什么，就用什么。

数据湖的核心能力包括：

集成能力：支持结构化，半结构化和非结构化类型的数据，提供统一多元的接入方式，并自动生成元数据信息；存储能力：支持异构和多样的存储，供经济高效的存储并允许快速访问数据浏览；治理能力：通过数据的血缘关系，建立完整的上下游脉络关系，支持问题数据的追踪治理；安全能力：每一层数据都能够实现安全管控能力，包括数据的敏感打标与安全监管；发现能力：能够快速搜索和使用目标数据，明确知悉其在数据湖中的位置；分析能力：针对已经接入的数据，提供报表、自助取数、交互式、数据分析、机器学习等分析使用能力；质量治理：针对已经接入的数据，提供字段校验、完整性分析、产出监控等功能，确保数据的质量是可用的。

明确了核心能力，就可以设计对应的体系结构，大体包括：

数据接入层：提供适配的多源异构数据资源接入方式，包括数据源的配置、数据任务的同步、数据的分发与调度、数据的ETL加工等；数据存储层：通常采用HDFS，但针对不同的场景可以提供其他的解决方案；数据计算层：采用多种数据分析引擎，来满足批量、实时等特定计算场景；数据应用层：不仅需要批量报表、即席查询、交互式分析、数据仓库、机器学习等上层应用，还需要提供自助式数据探索能力。

额外提一下，数据仓库非常倾向于事前定义，也就是从事务系统中提取，经过维度或其他方式建模后，固化下来。这么做虽然能够更加清晰的展示基础数据结构，降低数据计算量，提升开发速度，但同时也带来了基础模型改动成本高、数据迁移周期长、数据质量管控难等问题，可以说高度结构化的数据仓库，更适合于月度报告等操作用途。而数据湖倾向于所有数据都保持原始形式，在使用的时候直接用工具来统计分析，对于数据科学家而言，使用起来更加灵活，但同时也非常考验数据引擎的性能，以及科学家对于数据的掌握程度。

|0x03 数据中台：数据的未来

从笔者的理解中，数据中台的作用，是将技术能力的复用性，转化为业务能力的复用性。

“中台”某种意义上是一个正宗的中国概念，早在2015年，马老师访问过北欧的Supercell游戏公司之后，便提出了这个概念。随之而来的，是阿里带动的“大中台、小前台”运动。这个概念听起来还是非常不错的，因为整合技术力量，既能够有效降低研发成本，也能够带来业务上更多的试错机会。但当大家投入进去之后才发现，中台的建设成本如此之大，乃至于一般小公司无法负担起基础的成本。大公司搞了，却又无法应对业务的快速变化，搞得怨声载道。

所以，很多人喊出了“中台无用论”。其实，中台的设计初衷，是提供通用的业务解决方案+通用的技术解决方案，而不是仅仅是通用的技术解决方案。只看技术，忽略了业务，就像两条腿瘸了一条。但业务是最难做的，面向未来的东西，不确定性最大，所以难度挑战最高。

因此，对于数据团队而言，如果说中台提供的是通用的业务解决方案+通用的技术解决方案，那么对应到数据中台，就是提供可复用的数据业务能力+可复用的数据技术能力。举个例子，对于小团队而言，希望通过我们的数据中台分析潜在的商业机会，这时候直接甩过去几张表就不合适。从小团队的视角看，我们希望有一个分析平台，有一些自主分析工具，能够快速了解我们目前能够统计到的数据及其涵义。那么这个时候，数据中台 = 数据仓库 + BI分析工具 + 元数据平台，最好前端能够有个自主搭建报表的工具，通过直接读取数据仓库的数据，来实现快速搭建分析平台的需求。

仅仅是数据仓库，还包含了一系列配套的平台（元数据、数据安全、数据质量、BI分析等），建设的成本比较高，而对于大多数公司而言，这种经济成本是不划算的。

大多数的数据人，做数据中台习惯从自顶向下进行建设。这种做法的优点是能够通盘考虑全局问题，保持数据的一致性，但坏处是变动的成本比较高，难以适应高速变化的业务结构。仔细想想，阿里是先有了电商业务，才有了大中台落地的基础；头条做好了抖音，才有了算法中台的诞生；腾讯IM深耕多年，也是基于IM逻辑做数据中台。其实数据中台更多的要走到业务中，为业务贡献价值，才能真的称之为“中台”。