聊一聊数据建模和数据转换
最近经常有一些朋友跟我探讨未来几年关于数据方面的一些趋势,以及为什么美国最近现代数据技术栈中为什么会有那么多独角兽级别的公司出来。为什么dbt这个公司突然间这么值钱(估值超过42亿美金)? 接下来谈一下我对新的这个趋势下数据建模和数据转换的一些想法和思考。
数据建模和数据转换是什么?
我们首先来简单阐述一下什么是数据建模和数据转换。咱们人实际上自从进化到人开始,就开始用数据来支撑咱们的决策了。大家通常在做决策之前会有一个基于历史的经验数据的一个模型,来判断这个决策可能产生的结果,从而指导人的行动。只不过很多这些历史的经验数据或者依赖于人在人脑中存储的各种数据,或者依赖于在纸上记录下来的数据。这些数据会在人脑中根据决策的目标进行数据的提取、转换和建模,然后被人用来做判断。
自从人类世界有了计算机,数字化逐渐在改造人类社会纪录和使用数据的方式。尤其是互联网发明以后,人与人,人与世界的交互越来越依托于互联网这个载体来完成,于是各种相关的数据都被互联网记录下来。而这些记录下来的数据,则进一步被人类使用去改善自己的生活。在这个前提下,数据建模和数据转换的工作则需要在计算机这个载体上去实现。具体来讲,就是人使用计算机上的软件工具,根据自己想要达到的目标,去找到需要的数据,进行数据处理、转换、清洗、增强,然后生成自己想要的数据模型,进而去做分析、挖掘、可视化图表、预测等等相关的工作。
ETL->ELT
我们现在回到企业使用数据做决策的场景,在提到数据建模和数据转换相关的概念时,经常被提及的两个概念就是ETL和ELT。这两个概念实际上反映了在数据化不同的时期企业在使用数据的方法和流程。E,T,L这三个字母实际上代表了数据处理的不同阶段。 E - Extract,数据抽取。实际上是把数据从原始产生数据的地方提取过来 T - Transform,数据转换。这实际上就是我们所说的数据建模和转换过程,把原始数据根据自己的目标模型的需要,转换为模型所需要的数据 L - Load,数据装载。把根据模型转换好的数据装载到目标存储(一般是数据仓库),然后再去被使用
在互联网尤其是移动互联网普及之前,企业用数据的典型的方式是ETL。为什么会采用ETL的方式,其原因有如下几点: 数据的产生一般都是企业的业务系统,存储一般都是企业业务系统的数据库。 数据使用的目标对象一般是企业的决策层,也就是E Level的人,核心是给决策层提供做决策的各种维度的数据报表。 一般是通过数据仓库项目的方式来达到数据使用的目标,因此是一个项目流程驱动的。
在这种情况下,企业一般会首先进行立项,确定项目实施的目标。然后根据目标去选择产品和项目实施方。产品和实施方确定后,项目实施方会有数据架构师、数据工程师、业务分析师入场。这个时候一般会进行如下的工作 业务访谈 - 业务分析师和数据架构师会对客户相关的干系人进行业务访谈,从而了解整个数据项目的目标 数据调研 - 数据架构师和数据工程师会对客户的业务系统进行数据调研,了解有哪些数据,收集数据字典,从而了解数据现状 数据建模 - 数据架构师会根据业务情况,以及数据情况进行数据仓库建模,可能会根据具体情况分不同层次进行建模。 数据开发 - 数据工程师根据数据模型的要求,从数据源提取数据,进行数据清洗、转换,然后将数据装载到目标的数据仓库中。然后再根据要求进行相关的报表开发,最终生成客户可以使用的数据报表。
我们可以看到,这种传统企业使用数据的成本相对是比较高的,而且灵活性不足。但是在过去的那个场景下,已经解决了大部分企业使用数据的需求。传统BI以及敏捷BI都是在这种场景下服务客户的,区别就是项目实施的周期和难度不同。
但是随着互联网公司的发展,数据的使用方式在从ETL向ELT这种方式在转变。其核心原因是互联网公司一开始就是构建在互联网这个基础上的,利用数据提高运营效率是互联网公司的核心竞争力。而互联网公司由于很多一开始没有成熟的业务系统,数据来源更杂,很多都是网站或者移动端用户行为的日志,使用数据则更偏向于日常运营过程中随时优化自己的运营效率,包括自己客户的转化、留存等等,以及内部资源的优化。因此传统的项目制使用数据的方式根本不适合互联网公司。
于是互联网公司使用数据的方式就变成了先把不同数据来源的数据都一股脑的先放到一个廉价的存储,要么是自建的HDFS存储,要么是公有云的对象存储。也就是先做数据集成工作,把E和L的工作前置到第一阶段。这时候数据存放的地方我们一般可以称之为数据湖,然后因为互联网公司的组织架构一般也会比较扁平,各种小团队根据自己的目标,再从这些湖里边捞自己想要的数据,边探索,边清洗,边转换。数据处理之后有时候就是一次性的报告或者问题发现,直接就触发对应的行动计划。有时候会转变为日常被调度的报表,或者线上执行的机器学习模型。而这些报表和机器学习模型,也会日常被监控,随时进行调整和优化。
在这种场景下,T的工作从过去ETL中的项目制的一个阶段完成就结束的工作变成了日常工作,数据建模和转换工作就越来越频繁和重要。就拿我们常说的数据科学工作说吧,大家统一的认知是80%的工作可能都是花费在数据准备上,也就是数据清洗、转换和基本模型构建上,后面模型的训练花费的时间倒是相对没那么多了。
互联网公司是具备规模效应的公司,因此一般会投入相当的人力来进行数据相关的工作,国内的大厂一般会配备有数据分析师、数据产品经理、数据科学家、数据工程师、软件工程师等等不同角色来保证自己能够快速、高效地利用数据。
但是回到非互联网公司,随着竞争的日益激烈,传统的固定报表需求已经不能满足传统行业类型客户对数据的需求。而且世界越来越进入一个变化是常态的世界,所谓VUKA世界。如何能够更低成本、快速地采集和利用数据就变成了传统企业面临的难题。从发展来讲,所有企业对数据的需求都越来越接近互联网类型的企业,从传统的ETL在向ELT转换,但是在ELT这种场景下,如何能够满足企业数据使用的需求就成了一个很大的问题。
企业应用数据之难
前面提到所有企业都希望自己能够更加的数据驱动,能够在日常运营中就更方便的使用数据,但是这里传统行业客户却面临很多使用数据的难题。 数据收集难 - 通过过去几年的市场的教育,所有企业都是知道把自己更多相关的数据收集起来,方便未来使用非常对重要。但是数据的收集还面临不同的困难。当然这个困难在海外的现代数据技术栈中在逐渐被解决,有Fivetran, Airbyte包括垂直做客户数据的segment在解决。但是国内的数据收集还面临很多困难,这里有技术的因素,更多还是业务系统数据API化的思想在国内还没有形成习惯。企业要从不同的系统收集数据的门槛比较高,国内企业甚至不得不用RPA来从一些系统去采集业务相关的数据。 数据建模和转换门槛高 - 正常来讲,最了解数据使用的业务场景的人员是运营人员、商业分析师或者懂业务的数据分析师,但是真正在处理数据的往往是懂SQL,懂编程的工程师。互联网企业是知识和技术密集型企业,通过高素质的数据人员(必须懂SQL,python)或者更豪华配置(给业务人员配置分析师、工程师)来解决数据使用的问题。但是传统的企业往往没有足够的资金来进行这些配置。而且传统企业也不具备足够多规模效益来通过规模收益来抵消这部分成本,这就意味着传统的企业虽然能解决数据收集的问题,但是在数据使用上还是很难放大数据使用的效率。在海外,有些新兴企业通过招聘和培养懂SQL和编程的数据分析师来解决问题,配合相关的工程化管理工具(dbt)来解决问题,但是大部分企业使用数据还是很艰难。 数据越来越脏乱差 - 在传统时代,数据一般来自于业务系统的数据库,数据的质量相对比较好,处理难度低,人通过一些规则就能处理。但是随着各种不同的数据的纳入,很多数据已经不是传统意义上的格式化数据,数据规模也在增大,如何在一定规模的脏乱差的数据上提取有价值的数据出来,进而再建模和使用就变得日趋困难。很多工作就算有工程师支撑,也很难高效地提取数据,比如医疗系统中的病例数据,业务系统用户的反馈文本等等数据。 使用数据的成本高 - 既有的很多数据处理工具很多都是传统软件时代的工具,适合项目制的解决方案,成本动辄几十万,甚至百万。而传统行业的企业本身就是成本决定了企业的生死,高成本的投入如果带不来收益,将会把企业带入到非常困难的境地。
解决问题的思路
虽然现在面临诸多的困难,但是公有云的普及以及云原生的发展,还是给我们解决问题带来了一些可能。比如在公有云上,云端的数据仓库、数据湖可以按照容量和计算来计费,使得用户使用数据仓库的成本显著的降低。而从不同数据源进行数据的产品也日趋成熟,并且可以按照行级变化进行计费。在数据建模和转换领域,dbt对于懂SQL的人来讲,可以方便地隔离下层数据仓库的差异性,去进行基于SQL的建模和转换,并且支持协同。但是对于大部分的企业来讲,数据建模和转换应该有更简单、易用廉价的工具帮助他们解决数据使用的难题,这个工具最好具备如下的特点: 使用门槛低 - 对于普通的运营人员、商业分析师、数据分析师应该能马上上手就能使用。 使用成本低 - 个人和小企业可以按照人计费,个人最好不要超过100美金/月(海外),100人民币/月(国内), 小团队和企业每个月不要超过1000美元。 能够支持知识沉淀 - 数据工作实际上是将业务知识用数据建模来表达的过程,这种知识应该能够沉淀下来。 支持分享 - 数据处理的结果应该可以分享查看,方便知识的分享。 大规模数据的支持 - 能够支持G级别乃至T级别数据的即时处理,并且能够随时查看数据中的问题。 智能化 - 对于复杂的数据,最好能够能够让机器帮助人进行处理,从而显著提高处理数据的效率
从现实基础看,目前互联网技术和公有云技术的发展,以及人工智能技术逐渐在与场景结合使实现这种工具的基础条件已经具备。正如dbt的CEO所说的,我们现在正处在数据技术的寒武纪二期,也就是在数据工具大爆发的第二个阶段,相信有更多的快速、易用、成本低廉的数据工具会产生。这也正是我们在努力做的事情。