数据能力的构建过程

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 数据能力的构建过程

数据能力的构建过程


|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逻辑做数据中台。其实数据中台更多的要走到业务中,为业务贡献价值,才能真的称之为“中台”。


|0xFF 总结


任何一种数据能力,都是有其历史局限性的。12年那会有句话是:“会写MR,月薪过万”,今天会使用DataWorks已经是新人的标配了;过去IOS开发飘在天上,如今更多拼的是基础架构能力。


过去的一段时间内,大数据有了非常多的明星系统,比如Hadoop、Spark、Flink、ClickHouse,在经过激烈的厮杀后,有的逐步胜出,实现了规模化应用和商业化开发,而更多的会躺在历史的尘埃中,被后人所怀念。


其实数据能力何尝不是,从数据仓库、数据湖、数据中台,乃至于经营分析、数据分析、数据科学,人们对数据的理解和应用在进一步的提升,那些过去高大上的称呼,正在逐步的像统计学、机器算法的根源去卷,又何尝不是另一种局限性。


近几年,大数据领域少有明星的开源引擎了,而数据科学的概念之后,也只有数字化能看一看了。在这个“后红海”的时代里,我们在争实时开发、我们在探索数据隐私、我们在尝试AI,我们依旧在持续竞争的步伐。


每条线都进入了收敛的阶段,长期看,企业的选择,在“技术狂热期”过去后,更多的会考虑投资的ROI,商业化产品成为了主流,而数据的盛宴,也将逐步走向平淡。不论怎样,我们仍需努力。

相关实践学习
阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
通过该实验体验在阿里云百炼中构建企业专属知识库构建及应用全流程。同时体验使用ADB-PG向量检索引擎提供专属安全存储,保障企业数据隐私安全。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
目录
相关文章
|
14天前
|
机器学习/深度学习 存储 监控
实时特征处理框架:构建与优化实践
在大数据时代,实时特征处理框架在机器学习、数据分析和实时监控等领域扮演着至关重要的角色。这类框架能够快速处理和分析海量数据,为决策提供即时的洞察。本文将探讨实时特征处理框架的构建、优化及其在生产环境中的实践应用。
36 1
|
14天前
|
监控 安全 测试技术
构建高效的精准测试平台:设计与实现指南
在软件开发过程中,精准测试是确保产品质量和性能的关键环节。一个精准的测试平台能够自动化测试流程,提高测试效率,缩短测试周期,并提供准确的测试结果。本文将分享如何设计和实现一个精准测试平台,从需求分析到技术选型,再到具体的实现步骤。
65 1
|
3月前
数据平台问题之在数据影响决策的过程中,如何实现“决策/行动”阶段
数据平台问题之在数据影响决策的过程中,如何实现“决策/行动”阶段
|
3月前
|
存储 消息中间件 监控
构建高效的数据流处理系统:从理论到实践
【8月更文挑战第27天】本文旨在通过深入浅出的方式,带领读者探索构建一个高效、可扩展的数据流处理系统的全过程。我们将从基本概念出发,逐步深入到架构设计、技术选型、实现细节,并最终展示如何将理论应用于实际项目中。文章不仅提供代码示例,还着重讨论了在设计和开发过程中遇到的挑战及解决策略,为希望深入了解或构建数据流处理系统的技术人员提供了一份实用指南。
|
4月前
|
存储 运维 数据库
业务系统架构实践问题之业务模型和存储模型解耦的重要性问题如何解决
业务系统架构实践问题之业务模型和存储模型解耦的重要性问题如何解决
|
6月前
|
监控 测试技术 持续交付
构建高效持续集成系统的策略与实践
【5月更文挑战第28天】 在快速迭代的软件开发过程中,持续集成(CI)系统是确保代码质量和加速交付的关键。本文将探讨构建一个高效、可靠的CI系统的关键策略,并通过实际案例分析如何实现这些策略。我们将讨论自动化测试、容器化部署、监控和日志记录等主题,以及它们如何共同作用以提升开发流程的效率和稳定性。通过实施这些策略,团队可以显著减少集成问题,并缩短从开发到部署的时间。
94 2
|
6月前
|
存储 安全 数据安全/隐私保护
【大模型】如何确保负责任地开发和部署 LLM?
【5月更文挑战第7天】【大模型】如何确保负责任地开发和部署 LLM?
|
6月前
|
监控 负载均衡 测试技术
大模型开发:描述一个你之前工作中的模型部署过程。
完成大型语言模型训练后,经过验证集评估和泛化能力检查,进行模型剪枝与量化以减小规模。接着导出模型,封装成API,准备服务器环境。部署模型,集成后端服务,确保安全,配置负载均衡和扩容策略。设置监控和日志系统,进行A/B测试和灰度发布。最后,持续优化与维护,根据线上反馈调整模型。整个流程需团队协作,保证模型在实际应用中的稳定性和效率。
126 3
|
6月前
|
开发框架 网络安全 数据库
典型应用集成技术
【1月更文挑战第11天】典型应用集成技术。
39 0
|
测试技术
测试如何构建快速反馈的能力
测试如何构建快速反馈的能力
133 0
测试如何构建快速反馈的能力
下一篇
无影云桌面