数据中台实战(02)-什么企业适合建设数据中台?

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: 数据中台实战(02)-什么企业适合建设数据中台?

从历史脉络中,看到数据中台凸显价值,数据中台是大数据下一站。所有企业都适合建设数据中台吗?什么样应该建数据中台?


2018年我们在建数据中台前面临的窘境,通过了解我们建数据中台的背景,你也可以对照着看一下自己所在的企业是否存在这样的问题,从而针对“是否需要构建一个数据中台”这个问题形成自己看法。


1 前言

2018年线上流量枯竭,业绩增长乏力,企业成本高筑, 利润飞速下滑。 原先粗放的企业管理模式和经营模式(如采购商品时,凭经验做出采购哪个商品的决策)已没法继续支撑企业高速增长,越来越多企业开始数字化转型,强调数据是企业增长新动力,它应深入企业经营各环。


数据需求爆发式增长,促进数据产品发展,在每个业务过程中,都有大量数据产品辅助运营完成日常工作。如电商中,用户运营、商品运营、市场运营……每天有大量运营基于这些产品完成经营决策。


比如在供应链决策协同系统中,我们有一个智能补货的功能,会根据商品的库存、历史销售数据以及商品的舆情,智能计算商品的最佳采购计划,推送给运营审核,然后完成采购下单。


2 大量数据产品的问题

2.1 指标口径不一

两个数据产品一个包含税,一个不包含税,它们相同的一个指标名称都是销售额,结果却不一样。运营面对这些指标的时候,不知道指标的业务口径,很难使用这些数据。

根因

可能:业务口径、计算逻辑、数据来源不一致。

业务口径不一致,要明确区分两个指标不能使用相同的标识,含税、不含税两个指标, 不能同时叫销售额。


业务口径描述往往是一段话,但对很多指标,涉及计算逻辑复杂,一段话描述不清,此时,两个相同业务口径的指标,恰分别由两个数据开发去实现,就可能造成计算逻辑不一。如有个指标叫排关单(排关单:把关单的排除;关单:关闭订单)的当天交易额这个指标:


  • A认为关单定义是未发货前关闭的订单
  • B认为关单是当天关闭的订单

大家对业务口径理解不一致,实现的计算结果也不一致。

最后,可能两个指标的数据来源不一:

  • 一个来自实时数据
  • 一个来自离线的数据,即使加工逻辑一样,最终结果也可能不相同。

要实现一致,务必确保对同一指标,只有一个业务口径,只加工一次,数据来源必须相同。

2.2 数据重复建设,需求响应时间长

随需求增长,运营和分析师不断抱怨需求的交付时间拉长,面对快速变化的业务,需求响应时间已经无法满足业务对数据的敏捷研发要求。

根因

在于烟囱式开发导致大量重复逻辑代码研发,一份原始数据,两个任务都对原始数据进行清洗。如只有:

  • 一个任务清洗,产出一张明细表
  • 另外一个任务直接引用这张表

就能节省一个研发的清洗逻辑的开发。

所以,要解决数据需求响应慢,就必须解决数据复用的问题,要确保相同数据只加工一次,实现数据的共享。


2.3 取数效率低

面对数十万张表,我的运营和分析师找数据、准确地理解数据非常困难,想找到一个想要的数据,确认这个数据和自己的需求匹配,他们往往需要花费三天以上的时间,对新人来说,这个时间会更长。

除了查找数据效率低,从系统中取数分析对于非技术出身的分析师和运营来说也是一个难题,这就导致大部分的取数工作还是依赖数据开发来完成。数据开发大部分的时间都被临时取数的需求占据,根本无法专注在数仓模型的构建和集市层数据的建设,最终形成了一个恶性循环,一方面是数据不完善,另一方面是数据开发忙于各种临时取数需求。


根因
  • 找不到数据
    须构建全局的企业数据资产目录,实现数据地图,快速找到数据。
  • 取不到数据
    而非技术人员不适合用写SQL取数据,所以要解决取不到数据的问题,就要为他们提供可视化的查询平台,通过勾选一些参数,才更容易使用。

2.4 数据质量差

数据经常因为BUG导致致计算结果错误,最终导致错误的商业决策。


大促期间,某类商品搜索转化率增长,于是我们给这个商品分配更大流量,可转化率增长的原因是数据计算错误,所以这部分流量也就浪费了,如果分配给其他的商品的话,可以多赚200W的营收。


根因

数据问题难被发现。我们常等使用数据的人投诉,才知数据异常。而数据加工链路长,在我们的业务中,一个指标上游的所有链路加起来有100多个节点都很正常。等到运营投诉再知道数据有问题,太迟!因为要逐个排查到底哪个任务有问题,再重跑这个任务及所有下游链路上的每个任务,要半天到一天,最终导致故障恢复效率低,时间长。

所以,要解决数据质量差,就要及时发现然后快速恢复数据问题。

2.5 数据成本线性增长

数据成本随着需求的增长而线性增长,2017年的时候,我们一个业务的大数据资源在4000Core,但是2018就已经到达9000Core水平,如果折算成钱的话,已经多了500多万的机器成本。

根因

与需求响应慢背后的数据重复建设有关,因为重复开发任务,上线肯定花双倍资源。如节省一个任务资源消耗,满足两个数据需求,就可控制不必要资源消耗。所以,成本问题背后也是数据重复建设问题。


数据中台是企业构建的标准的、安全的、统一的、共享的数据组织,通过数据服务化的方式支撑前端数据应用。


数据中台消除冗余数据,构建企业级数据资产,提高数据共享能力,所以很快,我们开启数据中台建设。

3 数据中台如何解决问题

指标是数据加工结果,要确保数据需求高质量交付,首要管好指标:

  • 原先指标的管理分散,没有全局统一的管理,数据中台中,须有一个团队统一负责指标口径管控
  • 要实现指标体系化的管理,提高指标管理的效率。在指标系统中,我们会明确每个指标的业务口径,数据来源和计算逻辑,同时按类似数仓主题域的方式进行管理
  • 最后,要确保所有的数据产品、报表都引用指标系统的口径定义。当运营把鼠标Hover到某个指标上时,就可以浮现出该指标的口径定义。

通过对全局指标的梳理,我们实现了100%数据产品的指标口径统一,消除了数据产品中,指标口径二义性问题,同时还提供方便分析师、运营查询的指标管理系统。


数据中台咋实现所有数据只加工一次?对数仓数据,要求相同粒度的度量或指标只加工一次,构建全局一致的公共维表。


实现上述目标,需两个工具产品:

  • 数仓设计中心,在模型设计阶段,强制相同聚合粒度的模型,度量不能重复
  • 数据地图,方便数据开发能快速理解一张表的准确含义

这就解决数据重复加工导致研发效率瓶颈的问题,把需求的平均交付时间从一周减到2~3天,大幅提高数据产能,得到分析师和运营的认可。

**数据中台通过服务化方式,提高数据应用接入和管理效率。**原先数仓提供给应用的访问方式是直接提供表,应用开发自己把数据导出到一个查询引擎,然后访问查询引擎。数据中台中,数仓的数据是通过API接口提供给数据应用,数据应用不关心底层不同查询引擎访问方式的差异。


**对非技术人员,数据中台提供可视化取数平台,**你只需选取指标、通过获取指标系统中每个指标的可分析维度,然后勾选,添加筛选过滤条件,点击查询,就能获取数据。


同时,数据中台构建企业数据地图,方便检索有哪些数据,它们在哪些表,又关联哪些指标和维度。通过自助取数平台和数据地图,非技术人员开始自助完成取数,相比通过提需求给技术人员,取数效率提高300%。


EasyFetch 网易自助取数界面:

**数据中台由于数据只能加工一次,强调数据复用性,对数据质量提出更高要求。**而我们实现全链路的数据质量稽核监控,对一个指标的产出上游链路中涉及的每个表,都实现了数据一致性、完整性、正确性和及时性的监控,确保第一时间发现、恢复、通知数据问题。


原先,当技术人员问我们“今天数据有没问题?” ,我们难答,现在可自信回答,数据对不对,哪些数据不对,啥时能恢复。这能力对最终达成99.8% 数据SLA很重要。


成本问题

构建数据中台时,研发了一个数据成本治理系统,从应用维度、表维度、任务的维度、文件的维度进行全面治理。


从应用维度,如一个报表30天内没访问,这报表产出价值就低,然后结合这报表产出的所有上游表及上游表的产出任务,可计算加工这张表的成本,有价值和成本,就能计算ROI,根据ROI可实现将低价值报表下线的功能。通过综合治理,最终在一个业务中节省超20%成本,约900W。


通过数据中台,最终成功解决面临的问题,大幅提高数据研发效率、质量,降低数据成本。


4 啥企业适合数据中台?

数据中台构建需大投入:

  • 数据中台建设离不开系统支撑,研发系统要投入大量人力,而这些系统是否能够匹配中台建设的需求,还需要持续打磨
  • 面对大量数据需求,要花费额外人力做数据模型重构

所以数据中台建设,要结合企业现状,按需选择。选择数据中台时,应考虑:

  • 企业是否有大量的数据应用场景: 数据中台本身不能直接产生业务价值,数据中台本质是支撑快速孵化数据应用。所以当你的企业有较多数据应用场景时(3个以上就可考虑),像电商有各种各样数据应用场景
  • 经过快速的信息化建设,企业存在较多业务数据的孤岛,需整合各业务系统的数据,进行关联分析。此时,需构建数据中台。如电商初期,仓储、供应链、市场运营都是独立数据仓库,当时数据分析时,往往跨很多数据系统,为消除这些数据孤岛
  • 当团队面临效率、质量和成本苦恼,面对大量开发,却不知如何提高效能,数据经常出问题而无策,老板还要求你控制数据成本当企业经营困难,需通过数据实现精益运营,提高企业运营效率。同时结合可视化BI数据产品,实现数据从应用到中台的完整构建,在我的接触中,这种类型往往出现在传统企业中。
  • 数据中台投入大,收益偏长线,更适合业务稳定大公司,不适合初创型小公司

5 总结

企业数据在日常使用过程中面临的一些难题,分析发现,数据中台对症下药。

  • 效率、质量和成本是决定数据能否支撑好业务的关键,构建数据中台的目标就是要实现高效率、高质量、低成本。
  • 数据只加工一次是建设数据中台的核心,本质上是要实现公共计算逻辑的下沉和复用。
  • 如果你的企业拥有3个以上的数据应用场景,数据产品还在不断研发和更新,你必须要认真考虑建设数据中台。

建设数据中台别盲目跟风,不一定适合你,很多不符合上述特征,却建设数据中台的公司,初期投入大量人力成本建设数据中台,因为业务变化快,缺少深入数据应用场景,结果虎头蛇尾,价值无法落地。所以,仔细想那5要素。

相关实践学习
阿里云百炼xAnalyticDB PostgreSQL构建AIGC应用
通过该实验体验在阿里云百炼中构建企业专属知识库构建及应用全流程。同时体验使用ADB-PG向量检索引擎提供专属安全存储,保障企业数据隐私安全。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
目录
相关文章
|
2月前
|
存储 人工智能 搜索推荐
解锁AI新境界:LangChain+RAG实战秘籍,让你的企业决策更智能,引领商业未来新潮流!
【10月更文挑战第4天】本文通过详细的实战演练,指导读者如何在LangChain框架中集成检索增强生成(RAG)技术,以提升大型语言模型的准确性与可靠性。RAG通过整合外部知识源,已在生成式AI领域展现出巨大潜力。文中提供了从数据加载到创建检索器的完整步骤,并探讨了RAG在企业问答系统、决策支持及客户服务中的应用。通过构建知识库、选择合适的嵌入模型及持续优化系统,企业可以充分利用现有数据,实现高效的商业落地。
109 6
|
2月前
|
机器学习/深度学习 人工智能 开发框架
解锁AI新纪元:LangChain保姆级RAG实战,助你抢占大模型发展趋势红利,共赴智能未来之旅!
【10月更文挑战第4天】本文详细介绍检索增强生成(RAG)技术的发展趋势及其在大型语言模型(LLM)中的应用优势,如知识丰富性、上下文理解和可解释性。通过LangChain框架进行实战演练,演示从知识库加载、文档分割、向量化到构建检索器的全过程,并提供示例代码。掌握RAG技术有助于企业在问答系统、文本生成等领域把握大模型的红利期,应对检索效率和模型融合等挑战。
212 14
|
2月前
|
存储 人工智能 搜索推荐
揭秘LangChain+RAG如何重塑行业未来?保姆级实战演练,解锁大模型在各领域应用场景的神秘面纱!
【10月更文挑战第4天】随着AI技术的发展,大型语言模型在各行各业的应用愈发广泛,检索增强生成(RAG)技术成为推动企业智能化转型的关键。本文通过实战演练,展示了如何在LangChain框架内实施RAG技术,涵盖金融(智能风控与投资决策)、医疗(辅助诊断与病历分析)及教育(个性化学习推荐与智能答疑)三大领域。通过具体示例和部署方案,如整合金融数据、医疗信息以及学生学习资料,并利用RAG技术生成精准报告、诊断建议及个性化学习计划,为企业提供了切实可行的智能化解决方案。
88 5
|
3月前
|
机器学习/深度学习 消息中间件 搜索推荐
【数据飞轮】驱动业务增长的高效引擎 —从数据仓库到数据中台的技术进化与实战
在数据驱动时代,企业逐渐从数据仓库过渡到数据中台,并进一步发展为数据飞轮。本文详细介绍了这一演进路径,涵盖数据仓库的基础存储与查询、数据中台的集成与实时决策,以及数据飞轮的自动化增长机制。通过代码示例展示如何在实际业务中运用数据技术,实现数据的最大价值,推动业务持续优化与增长。
126 4
|
3月前
|
机器学习/深度学习 搜索推荐 算法
从数据中台到数据飞轮:企业升级的必然之路
在探讨是否需从数据中台升级至数据飞轮前,我们应先理解两者之间的关系。数据中台作为数据集成、清洗及治理的强大平台,是数据飞轮的基础;而要实现数据飞轮,则需进一步增强数据自动化处理与智能化利用能力。借助机器学习与人工智能技术,“转动”数据并创建反馈机制,使数据在循环中不断优化,如改进产品推荐系统,进而形成数据飞轮。此外,为了适应市场变化,企业还需提高数据基础设施的敏捷性和灵活性,这可通过采用微服务架构和云计算技术来达成,从而确保数据系统的快速扩展与调整,支持数据飞轮高效运转。综上所述,数据中台虽为基础,但全面升级至数据飞轮则需在数据自动化处理、反馈机制及系统敏捷性方面进行全面提升。
110 14
|
5月前
|
自然语言处理 API 开发工具
初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程
【7月更文挑战第6天】初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程
初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程
|
4月前
|
数据采集 存储 自然语言处理
LangChain实战:构建自定义问答助手
【8月更文第4天】随着自然语言处理(NLP)技术的发展,构建能够理解和回答复杂问题的问答助手变得越来越容易。LangChain 是一个强大的框架,它为开发人员提供了一套工具和模式,用于构建和部署基于语言模型的应用程序。本文将引导您通过 LangChain 构建一个自定义的问答助手,该助手可以理解并回答关于特定领域的复杂问题。
120 1
|
7月前
|
人工智能 自然语言处理 开发者
Langchain 与 Elasticsearch:创新数据检索的融合实战
Langchain 与 Elasticsearch:创新数据检索的融合实战
215 10
|
7月前
|
存储 人工智能 数据库
【AI大模型应用开发】以LangChain为例:从短期记忆实战,到如何让AI应用保持长期记忆的探索
【AI大模型应用开发】以LangChain为例:从短期记忆实战,到如何让AI应用保持长期记忆的探索
750 0
|
7月前
|
人工智能 API
【AI大模型应用开发】【LangChain系列】实战案例6:利用大模型进行文本总结的方法探索,文本Token超限怎么办?
【AI大模型应用开发】【LangChain系列】实战案例6:利用大模型进行文本总结的方法探索,文本Token超限怎么办?
606 0
下一篇
DataWorks