|
许多人跟我一样，对于数据湖充满好奇，大概还读了不少数据湖文章，但无论别人怎么说，你还是会觉得难以把握数据湖的本质。 有些人会望文生义说，数据湖嘛，就是什么东西都可以往里面扔，特殊是对非结构数据的处理比力方便。
是如许吗？
有案例才有辨别，有的人找了数据湖的作者AWS来说明数据湖是什么东西，比如下图：
不懂数据的人大概会觉得数据湖很厉害，而懂数据的人大概会觉得仅是一堆数据堆栈技术的堆砌包装而已，你看上面那张框架图，哪个专业词汇数据人士会不懂？凭什么数据湖被炒作成了一个新概念？
有比力才有辨别，因此许多文章对数据湖与数据堆栈做了比力，下面是网上传播的一些说法：
这种比力似乎能找到点区别，岂非结构化与非结构化就成了数据堆栈和数据湖的一个重要区别？BI和呆板学习成为了重要区别？
究竟上，这种比力有较大逻辑毛病：即是从结果出发来看差异，然后又用这个差异来说明区别，颠倒了因果，因此受到了不少专业人士的鄙视。比如AWS的数据湖能够处理非结构化数据，而数据堆栈无法处理非结构化数据，就认为这是数据湖与数据堆栈的本质区别之一。
本文来跟大家聊聊我所明白的数据湖的本质，对于一种新事物不了解本质，你就很难驾驭它，下面这张图道尽了一切。
下面我用一篇文章来详细说明数据湖与数据堆栈的区别，更多的是给出why，知其以是然是明白事物的一个原则。
数据堆栈和数据湖的处理流程可以用下图来表现，此中用红圈标出了5个对标的流程节点。
可以看到，数据湖并不比数据堆栈在处理流程上多出了什么内容，更多的在于结构性的变化，下面就从数据存储、模型设计、加工工具、开发职员和消耗职员五个方面来进行比力。
（1）数据存储
数据堆栈采集、处理过程中存储下来的数据一般是以结构化的形式存在的，即使原始数据是非结构化的，但这些非结构化数据也只是在源头暂存一下，它通过结构化数据的形式进入数据堆栈，成了数据堆栈的根本存储格式，这个跟数据堆栈的模型（维度或关系建模）都是建立在关系型数据底子上的特点有关。
究竟上，是传统的数据建模负担让数据堆栈只处理结构化数据，其实谁都没规定过数据堆栈只处理和存储结构化数据。
数据湖应有尽有，轻装上阵，结构化与非结构化数据都成为了数据湖本身的一部门，这体现了数据湖中“湖”这个概念。因为没有数据堆栈建模的限定，当然什么东西都可以往里面扔，但这为其变成数据沼泽埋下了伏笔。
看了这段大概无法让人佩服，不要急，接着往下看。
（2）模型设计
数据堆栈中全部的Schema(比如表结构)都是预先设计并天生好的，数据堆栈建设最重要的工作就是建模，其通过封装好的、稳定的模型对外提供有限的、标准化的数据服务，模型能否设计的高内聚、松耦合成了评估数据堆栈好坏的一个标准，就好比数据中台非常夸大数据服务的复用性一样。
你会发现，数据堆栈很像数据领域的筹划经济，全部的产品（模型）都是预老师成好的，模型可以变更，但相当缓慢。
数据湖的模型不是预老师成的，而是随着每个应用的必要即时设计天生的，其更像是市场经济的产物，牺牲了复用性却带来了机动性，这也是为什么数据湖的应用更多夸大探索分析的缘故原由。
（3）加工工具
数据堆栈的采集、处理工具一般是比力封闭的，许多采取代码的方式暴力实现，大多只向集中的专业开发职员开放，重要的目标是实现数据的统一采集和建模，它不为消耗者（应用方）服务，也没这个必要。
数据湖的采集和处理工具是完全开放的，因为第（2）点提到过：数据湖的模型是由应用即席设计天生的，意味着应用必须具备针对数据湖数据的直接ETL本领和加工本领才华完成定制化模型的建设，否则就没有落地的可能，更无机动性可言。
工具能否开放、体验是否充足好是数据湖能够成功的一个条件，显然传统数据堆栈的一些采集和开发工具是不行的，它们每每不可能向平凡大众开放。
（4）开发职员
数据堆栈集中开发职员处理数据涵盖了数据采集、存储、加工等各个阶段，其不仅要管理数据流，也要打造工具流。
由于数据流最终要为应用服务，因此其特殊关注数据模型的质量，而工具流只要具备根本的功能、满足性能要求就可以了，反正是数据堆栈团队职员本身用，导致的结果是害苦了运营职员。
数据湖完全不一样，集中开发职员在数据流阶段只负责把原始数据扔到数据湖，更多的精神花在对工具流的改造上，因为这些工具是直接面向最终利用者的，如果不好用，数据湖就不能用了。
（5）应用职员
数据堆栈对于应用职员袒露的全部东西就是建好的数据模型，应用方的全部脚色只能在数据堆栈限定好的数据模型范围内倒腾，这在一定水平上限定了应用方的创新本领。比如原始数据有个字段很有代价，但数据堆栈集中开发职员却把它过滤了。
这种标题在数据堆栈中很常见，许多取数职员只会取宽表，对于源端数据完全不清楚，所谓成也数据堆栈，败也数据堆栈。
数据湖的应用方则可以利用数据湖提供的工具流接触到最生鲜的原始数据，涵盖了从数据采集、抽取、存储、加工的各个阶段，其可以基于对业务的明白，压榨出原始数据的最大代价。
可以看到，数据堆栈和数据湖，代表着两种数据处理模式和服务模式，是数据技术领域的一次轮回。
早在ORACLE的DBLINK期间，我们就有了第一代的数据湖，因为那个时间ORACLE一统天下，ORALCE的DBLINK让直接探索原始数据有了可能。
随着数据量的增长和数据范例的不断丰富，我们不得不搞出一种新的“数据库”来集成各种数据。
但那个时间搞出的为什么是数据堆栈而不是数据湖呢？
重要还是应用驱动力的标题。
因为那个时间大家关注的是报表，而报表最焦点的要求就是准确性和一致性，标准化、规范化的维度和关系建模正好适应了这一点，集中化的数据堆栈支持模式就是一种变相的筹划经济。
随着大数据期间到来和数字化的发展，许多企业发现，原始数据的非结构化比例越来越高，前端应用响应的要求越来越高，海量数据挖掘的要求越来越对，报表取数已经满足不了数据驱动业务的要求了。
一方面企业必要深挖各种数据，从展示数据为主（报表）渐渐向挖掘数据（探索预测）变化，另一方面企业也必要从按部就班的支持模式向快速机动的方向变化，要求数据堆栈能够开放更多的机动性给应用方，这个时间数据堆栈就有点撑不住了。
数据湖就是在这种背景下诞生的。
其实早在数据湖出来之前，许多企业就在做雷同数据湖的工作了，比如我们5年前重构hadoop大数据平台的时间，就已经要求源端能将各种格式的数据直接扔过来，然后用差别的引擎处理，非结构化的就本身做一个定制化的ETL工具，只是没有统一进行整合而已。
ETL之以是不开放，重要是驱动力不敷，其实我们没有那么多范例的数据要定制化抽取，大概后续会必要吧。
而可视化开发平台利用比力广泛，只是因为市场觉得IT做的太慢了，必要一个可视化平台来直接操纵。
许多企业不搞可视化开发平台也是容易明白的，报表就能活得很好，干嘛业务职员要本身开发和挖掘。现在数据湖叫的欢的，大多是互联网公司，比如亚马逊，这是很正常的。
数据湖和数据堆栈，不能说谁更好谁更差，大家都有可取之处，阿里最近一篇文章提到的数湖一体是很好的概念，可以实现双方的优势互补，我这里画一张图，方便你的明白：
何谓湖仓一体？
（1）湖和仓的数据/元数据无缝打通，互相补充，数据堆栈的模型反哺到数据湖（成为原始数据一部门），湖的结构化应用知识沉淀到数据堆栈
（2）湖和仓有统一的开发体验，存储在差别体系的数据，可以通过一个统一的开发/管理平台操纵
（3）数据湖与数据堆栈的数据，体系可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化
至于明白的对不对，你怎么看？
在数据管理和分析的不断演进中，选择合适的工具宁静台显得尤为重要。数据湖和数据堆栈作为差别的数据处理模式，在满足企业多样化数据需求方面各有所长。然而，随着数据量的急剧增长和数据范例的多样化，传统的数据堆栈模型渐渐显袒露其局限性，尤其是在处理非结构化数据和支持实时分析方面的本领有所不足。
FineDataLink作为先辈的ETL工具，不仅提供了强大的数据采集、洗濯和整合功能，还支持跨平台数据集成和自动化处理，使得企业能够更高效地管理和利用数据湖中的各类数据。通过FineDataLink，用户不仅能够简化数据湖的构建和管理流程，还能够更机动地应对不断变化的业务需求，实现数据的快速探索和智能分析，为业务决策提供更有力的支持。
无论是寻求数据的深度挖掘还是实现数据驱动的业务创新，FineDataLink都为企业提供了一个可靠的数据管理办理方案。了解更多关于FineDataLink如何助力企业数据湖建设的信息，请访问FineDataLink数据集成平台，探索数据管理的新视角，开启数据驱动业务的新篇章。
了解更多数据堆栈与数据集成关干货内容请关注>>>FineDataLink官网
免费试用、获取更多信息，点击了解更多>>>体验FDL功能
往期推荐：
SQL Server和Oracle数据库的实时同步_sqlserveroracle数据库实时同步-CSDN博客
数据融合平台的概述、特点及技术方案-CSDN博客
什么是API？如何进行API对接？-CSDN博客
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
