星城技术厚积二十余年,秉承专业、创新的精神,诚心为您服务!

行业资讯

十年之后,再看数据湖

来源:中国软件网 作者:陈杨

假如有这样一种解决方案,能帮助企业实现不同数据从获取、存储,到处理再到分析这样全生命周期的管理,同时支持批量历史数据和实时流数据的处理。

 

想必,这对于急于向数字化,甚至是智能化转型,并渴望从数据中挖掘价值的企业而言,无疑是一项最具吸引力的“魔法”。

 

今天,因为数据湖的出现,这一解决方案再也不是假如,这一“魔法”也真正可以被企业使用。

 

 

 

 

新鲜又不新鲜的数据湖

 

1956年夏季,以麦卡赛、明斯基、罗切斯特和申农等为首的一批年轻科学家首次提出“人工智能”这一术语,到近两年以人工智能为主导的第四次工业革命的到来,五十多年的时间里,人工智能经历了几番起起落落又再起。

 

无独有偶,数据湖也如此。尽管数据湖这一解决方案近两年火热异常,但这一说法并非最近才提出。

 

早在十年前的2010年,Pentaho的创始人兼CTO詹姆斯·狄克逊(James Dixon)便在纽约Hadoop World大会上提出了这一概念。不过当时,Pentaho刚刚发布了如今被大数据界广泛使用的开源框架Hadoop的第一个版本。

 

随后几年,数据湖一直处于不温不火状态,更多的是在一些开源项目上得以应用。直到2016年前后,数据湖才从一个初级概念,发展到第二阶段。近两年随着大数据、云计算的愈发成熟,以及物联网、异构计算等技术的兴起,数据湖才真正从技术逐步走向企业实际应用。

 

那么,究竟数据湖是什么呢?最早,James Dixon对数据湖的解释是:把以前在磁带上存储的东西倒入到数据湖,便可以开始探索该数据,重要的是能只把需要的数据“倒”入到Hadoop。如果想结合来自数据湖的信息和客户关系管理系统(CRM)里面的信息,便可以在需要时将二者数据结合。

维基百科对数据湖的解释是:数据湖是一种在系统或存储库中以自然格式存储数据的方法,其可对企业中的所有数据进行统一存储,从原始数据转换为用于报告、可视化、分析和机器学习等各种任务的转换数据。

其中,从关系数据库的结构化数据、到CSV、XML、JSON日志为代表的半结构化数据,再到电子邮件,文档,PDF等非结构化数据和以图像、音频、视频为代表的二进制数据,数据湖均可支持。

到今天,被普遍认可的数据湖的概念是:数据湖是一个可集中存储、处理、分析多个来源、多种类型数据的平台,其本质上是一套先进的企业数据架构。

在架构组成上,数据湖主要可分为数据接入层、数据存储层、数据处理计算层及数据应用层四个层面。

 

 

 其中,数据接入层提供各种类型元数据的接入;数据存储层提供多种接口,支持多种类型数据异构存储;数据处理计算层提供数据的清洗、治理、权限管理以及安全等;数据应用层则可用于BI报表、机器学习、交互式大数据SQL分析等。

数据湖的引力何在

其实不难看出,数据湖“天生”带着吸引力。因为数据湖具备的这些特性,恰恰是当下企业所需要的,具体来看:

便于收集数据。由于数据湖支持结构化、半结构化、非结构化等各种类型数据,这使得企业借助数据湖收集数据时不用担心数据的写入限制。尤其是未来几年,5G、IoT的发展将产生更多的流数据需要实时处理。

打破数据孤岛。早期,企业内部IT系统逐步完善,这使得每个应用都产生并存储着大量数据,且各个应用间数据互不相通,这便是企业常说的烟囱式IT架构,这样的建设模式也使得企业产生数据孤岛问题。而数据湖由于可以汇集不同应用间的数据,自然不用担心数据孤岛问题。

实现数据的挖掘与分析。如今人工智能盛行,但阻碍人工智能落地的一点便是数据的数量与质量,如果企业内部各系统间的数据不能复用的话,训练难度自然增大。

数据湖由于存储了各类型最原始的数据,且可共享不同部门、不同应用间的数据,这使得企业无需增加太多难度便可对这些数据进行训练,或者借助BI工具进行数据分析,挖掘数据价值。

 

灵活性和敏捷性。由于采用分布式架构部署,这使得数据湖具有很方便的扩展能力,而不像传统集中存储式那样,在对系统进行扩展时“牵一发而动全身”。同时在添加新单元或者单项目时,无需对整个数据湖进行大规模改变,仅需几天或几周时间便可实现,这也正契合当下提倡的敏捷开发理念。

一直以来,企业在数据的管理、应用上存在着诸多难题。汤姆斯·约翰、潘卡·米斯拉在《企业数据湖》一书中这样描述到:长期以来,企业一直试图找到一个统一的模型来表示企业中的所有实体,但这个任务具有极大的挑战性。

例如:一个实体在企业中可能有多种表示形式,因此可能不存在某个完备的模型来统一表示实体;不同的企业应用程序可能会基于特定的商业目标来处理实体,这使得处理实体时企业某些流程会被使用或受影响;不同应用程序可能对每个实体的访问模式、存储结构不同。这些问题的困扰,也阻碍了企业业务处理、服务定义及术语命名等事务的标准化。

而数据湖,由于尽可能从实体所有者相关的系统中捕获全量数据来表示实体。这使得企业隐式实现了一个较好的统一数据模型,同时这一模型也不会对业务、程序产生实质性影响。这使得企业在数据处理、管理以及洞察上获得极大帮助。

数据湖、数据仓库、Hadoop与数据中台

如同为了方便数据的读取而发明了数据库一样,企业为了更进一步借助数据进行分析报告和商业决策,于是在数据库基础上提出了数据仓库这一解决方案。数据仓库这一解决方案也的确在某种程度上帮助企业解决了不少困难。

也因此,在数据湖这一概念提出之初,甚至在当下也有人认为数据湖就是数据仓库,不过是“新瓶装旧酒”罢了。

事实上,真正了解数据湖和数据仓库后会发现,二者是截然不同的东西。从数据接入上看。不同于数据湖的支持各种类型数据接入,数据仓库中的数据多来自事务系统、运营数据库等关系型数据,其支持的数据仅为结构化的关系数据。

从数据存储上看。数据湖尽可能保存了数据原始状态,而数据仓库中的数据进行了清洗加工,是可信任、结构良好的数据。

从数据处理上看。数据仓库中的数据经过了事先定义,即所谓的Schema-On-Write,写时模式。而数据湖中的数据均为原始数据,是在使用时定义,即Schema-On-Read,读时模式。数据湖这样在使用时才做模型定义的灵活性,也使得企业可用其进行多种的应用分析。

从使用对象上看。数据仓库的使用对象面向业务分析师、企业决策者,主要用于报告批处理、BI等。而数据湖的使用对象在数据仓库的基础上,还可面向开发者和科学家,使用场景也从批处理、BI扩展到机器学习、数据分析。

 

从架构本身来看。1990年首次提出,数据仓库的技术已经使用了30年,尽管其已相当成熟,但在架构的扩展以及安全性上,数据仓库并不具备优势。而晚“出生”的数据湖,其分布式架构天生便于扩展,且更加安全,再加上目前常用的大数据框架多开源,这使得数据湖在构建成本上也占得优势。

除了与数据仓库进行对比外,数据湖也经常与Hadoop一块出现,并被认为数据湖就是Hadoop集群。

的确,凭借着开源、低价、支持各种类型海量数据以及快速传输等优势,Hadoop早已成为企业部署数据湖理想的选择。但仅仅依靠Hadoop是构建不了数据湖的。

其中最大的问题便是Hadoop虽然实现了数据存储以及分布式计算,但并未实现海量数据的管理、分配,而数据的管理在数据湖中的作用又极为重要。

所以,Hadoop只是实现数据湖解决方案的一种技术,企业部署数据湖不一定需要Hadoop,如果有更好的技术出现,Hadoop在数据湖的作用也将被取代。

当然,还有一个数据中台。但数据中台,跟数据湖则差的更远了。可以先简单理解中台,数据中台是相对于数据前台和数据后台的概念,数据前台表现的是对数据的应用,通常与用户交互,如app、网站等。数据后台则负责数据开发、支持。

所以,数据中台的出现是为了解决数据后台开发无法跟上前台业务需求变化、业务系统数据孤岛、数据繁杂、数据隔离等系列难题,在前台和后台之间搭建的桥梁,以实现前台效率的提升,后台灵活性的增加。

在本质上,数据中台并不像数据仓库、数据湖一样是一个具体的软件产品或者解决方案,而是一个企业级的逻辑概念,是一系列数据组件的集合。其通过聚合和治理跨域数据,将数据抽象封装成服务,因此为业务提供服务的主要方式是数据API。