大数据业内有两个趋势,已经悄悄滋生出来。
第一个趋势,是在任何一个公司,甚至是垂直领域的公司,数据量正在剧烈增长,而且数据类型越来越复杂。
我们已经没有办法通过单一、关系型数据库来存储这些数据了。将BI工具配置一下,指向数据存储,马上开始数据业务分析的日子,一去不返了。
事实上,传统的ETL工具栈,也在努力适应企业内现代化的数据格局,只是架构越来越复杂,效率越来越低。如下图所示:
从数据到洞察(灯泡所示),各个环节都需要精密的控制和配合
很多大型公司,已经认识到这种局面,启动了数据治理,希望可以一举扭转这种被动。我们把这个趋势称之为:现代化数据场景与传统数据工具链的不匹配。
然而,事情还没有结束。即使只是这一个挑战,处理起来就已经是按下葫芦浮起瓢了。若是将这个趋势,与另一个趋势相结合的话,只能用“雪上加霜”来形容了!我们来看下大数据的第二个趋势。
这个趋势就是,使用数据的用户,成分越来越多样,比如业务分析师、业务人员、产品经理、营销分析师、算法工程师等等。
这些身份中,很多人并不是数据专家,数据只是他们日常工作的辅助。问题在于,这些人,在日常生活中,都有令人惊叹的数据体验:
在生活中,这部分用户,对这种“数据的即时满足感”印象深刻。当他们回到公司,发现新创建一个可视化报表,从寻找数据源、数据采集、到清洗、到最终完成工作,需要两周、甚至一个月的时候,这种沮丧之情,是可以想象的。
这种与日常数字生活中,用户体验的巨大反差,也给公司解决大数据问题带来了很大的压力:
很快,你会发现,你面临了一个不可能解决的问题!
回头再看下这些技术栈,会发现,多年来,它几乎没有什么改变。
我们看看这些数据。它们存储在不同的地方,倒是使用了越来越多的现代数据技术,如S3,Hadoop,MongoDB,Elasticsearch等等,当然还有关系数据库。
我们看看数据的使用方式。下面是人们在数据分析中常用的工具。如果公司已经到一定规模,那么你还可能同时存在多个工具链(数据链路)来处理数据:
注意:我有意的不把ETL工程师和数仓工程师加进来,因为他们对数据的价值没有主张,是赋能业务线的。
可以看到,不同角色和背景的员工,倾向于使用不同的工具来处理和分析数据。
我们再看看团队间如何协同的。数据使用方非常依赖IT。
上面三个方面构成的工作模式,我们称之为传统的数据架构, 那么他在现代化的企业中,有什么问题呢?
数据链路的维护是灾难
首先通过ETL工具,把数据转移到一个特定区域里,通常是Hadoop集群、云存储、S3等数据湖中。当然,这个工作是需要很多人、很多数据处理脚本来完成的。
如果上游的数据源发生变化,比如,业务同学在Mysql数据表中添加了字段,下游数据该怎么做呢?是维持不变,还是自动的添加上这些新的字段呢?这都是需要考虑的问题。
因此,只是维护该数据链路的正常运行,就已经是一个非常具有挑战的工作了。
大数据已经是人力密集型行业了
数据副本是灾难
大家都知道,直接在数据湖上进行分析,通常情况下都很慢。
一般都是通过ETL,把部分数据(可能是过去30天或某些聚合级别数据)放入数据仓库中,如基于云的Redshift,也可能是Teradata,Vertica,Oracle,SQL Server等非云环境。
这些都是专用系统,昂贵不说,能否提供BI用户想要的性能,还需要画个疑问号。
为了解决上面的问题,一般会引入一个额外的数据产品层-多维数据集(CUBE)。通常的做法是,在数据仓库中预先聚合数据:
最后才发现,你为大数据支付了巨大的费用:
既有架构上,无法构建大数据的自助服务
基于上面的事实,在目前既有的数据架构上,是无法构建起自助服务的:
上述这种非常繁琐、过度依赖的工作模式,已经维持了至少10年,基本上没有改变过。如果想让公司变成数据驱动,那么这套传统数据架构,已经不得不调整了。
我们呼吁:把数据使用的权利真正赋予数据公民,使那些通过BI工具、机器学习的员工,可以自给自足的完成工作。当然,这种自助的工作方式,需要在公司的管理和安全控制下。
传统与现代数据架构
有了上面的分析,我们就可以看看什么样的数据架构,是用户需要的。
首先,它必须支持任何数据源,但又允许以统一的方式访问。解决传统ETL带来的问题的有效办法,就是省去ETL。
大多数公司,都拥有许多不同的数据源,比如mysql、Elasticsearch。同时,必须适用于任何主流的分析工具,如Tableau、MicroStrategy、Excel和Python等等。
如果没有数据仓库和cube,世界将变得更加美好。当然,不可能在一天之内摆脱所有这些,但必须有一个更好的方法,没有人真的喜欢管理这些。
其次,我们深信,甚至崇拜,自助服务和协作。这是现代数据体系必备的能力:
再次,性能是所有这一切的关键。如果你做的东西不够快,就没有人愿意在它上面浪费时间。
如果你曾经在大数据基础上,使用过各种BI,并且需要十分钟才能看到查询结果,那就说明,这套架构是有问题的。
即使对于最大的数据集,甚至是数PB和数十亿条记录,我们也必须能够提供一到两秒的交互式体验。
最后,我们认为它必须是开源的。任何类型的数据基础架构,或分析技术都需要是开源的。任何公司不希望被绑死。同时,这也是构建健康的生态系统所需要的。
基于上面的分析,我们已经认清了,什么样的数据架构,才是数据消费者所需要的。那么如何构建这个数据体系呢?
数据消费者,需要的不仅仅是服务的自助化,本质上,更是数据的自助化,即自服务的数据。
我们在数据工作栈中,引入一个数据抽象层,来解决数据自助服务的问题。这个抽象层架起数据本身与工具之间的桥梁。
需要使用数据的人,通过这个抽象层,可以获得它所需要的任何基础能力。比如:
这个数据抽象层,即自服务的数据架构,从物理层上来看,它需要提供如下的能力:
查询的加速,对于自服务的数据架构来说,是至关重要的。可以想象一下,即使面对PB级别的数据,业务人员还是想以交互的方式得到查询结果。也就是说,响应速度不能超过几秒钟。
如何实现一个自服务的数据架构呢?
现代化自服务的数据架构
从架构上来说,它需要包含如下的组件:
相比于传统的数据服务优化,我更强调数据的优化,通过对数据服务和数据双向的优化,来提供协作和自助服务能力。
再强调一次,目前大部分的做法,是把注意力放在工具的优化上。短期来看,可能有效果,但是它不解决根本问题。我们需要从数据的角度,重新审视大数据当前面临的问题,在优化工具的同时,对数据本身进行架构的优化,才有可能解决当前企业快速发展和数据驱动中,面临的问题。
“数据分析”、“数据分析师”这些词很有误导性,它让人认为,分析的目标是数据本身。叫“业务分析”可能好点,它至少会让人把焦点放到业务本身,数据是它的支撑。
注:Dremio是上述数据架构的一个参考实现。文中部分图片来自Dremio。