从数据库思维到数据湖思维的转变
<p>在数据库和数据湖的工作中，有几个关键的概念性差异。</p>
<p>
在这篇文章中，让我们来确定其中的一些差异，这些差异在第一眼看到时可能并不直观，特别是对于具有强大关系型数据库背景的人来说。</p>
<p>
<img title="从数据库思维到数据湖思维的转变" alt="从数据库思维到数据湖思维的转变" border="0" height="auto" src="https://zhuji.jb51.net/uploads/img/202305/6d644316968adb5ad7314ae4c60ffb3a.jpg" width="auto"></p>
<p>
服务器是一次性的。数据在云中。</p>
<p>
解耦存储和计算。在谈论数据湖时，这是一个典型的问题。</p>
<p>
在传统的数据库系统(以及最初的基于Hadoop的数据湖)中，存储与计算服务器紧密结合。服务器要么有内置的存储，要么直接连接到存储。</p>
<p>
在现代基于云的数据湖架构中，数据存储和计算是独立的。数据被保存在云对象存储(例如：AWS S3、Azure Storage)中，通常是以一种开放的格式，如parquet，而计算服务器是无状态的，它们可以在必要时启动/关闭。</p>
<p>
拥有一个解耦的存储和计算使。</p>
<ul>
<li>
降低计算成本。服务器在必要时运行。当不使用时，它们可以被关闭，从而降低了计算成本。</li>
<li>
可扩展性。你不必为高峰期的使用而购置硬件。服务器/中央处理器/内存的数量可以根据当前的使用情况动态地增加/减少。</li>
<li>
沙盒化。相同的数据可以被多个计算服务器/集群同时读取。这使得你可以让多个团队在不同的集群中并行工作，读取相同的数据，而不影响彼此。</li>
</ul>
<p>
RAW数据才是王道!策划的数据只是衍生的。</p>
<p>
在数据库范式中，来自源系统的数据被转化并加载到数据库表中后，它就不再有用了。在数据湖范式中，RAW数据被保留为真理的源泉，最终永远保留，因为它是真正的资产。</p>
<p>
然而，RAW数据通常不适合商业用户的消费，因此它要经过一个策划过程，以提高其质量，提供结构并方便消费。经过整理的数据最终被储存起来，供数据科学团队、数据仓库、报告系统以及业务用户的一般消费使用。</p>
<p>
<img title="从数据库思维到数据湖思维的转变" alt="从数据库思维到数据湖思维的转变" border="0" height="auto" src="https://zhuji.jb51.net/uploads/img/202305/01105142ba07e32127353fb343b0f527.jpg" width="auto"></p>
<p>
数据湖整理(来源：作者的图片</p>
<p>
典型的数据湖消费者只看到策划过的数据，因此他们对策划过的数据的重视程度远远超过产生这些数据的RAW数据。</p>
<p>
然而，数据湖的真正资产是RAW数据(连同策展管道)，从某种意义上说，策展的数据类似于一个可以随时刷新的物化视图。</p>
<p>
主要收获：</p>
<ul>
<li>
可以在任何时候从RAW中重新创建。</li>
<li>
可以通过改进策展过程来重新创建。</li>
<li>
我们可以有多个策划好的视图，每个视图都用于特定的分析。</li>
</ul>
<p>
今天做出的模式决定不会制约未来的需求</p>
<p>
通常情况下，信息需求会发生变化，一些原先没有从源头/运营系统中收集的信息需要被分析。</p>
<p>
在一个典型的情况下，如果原始的RAW数据没有被存储，历史数据就会永远丢失。</p>
<p>
然而，在数据湖架构中，今天决定不把某个字段加载到策划的模式中，以后可以推翻，因为所有的详细信息都安全地存储在数据湖的RAW区域，历史策划的数据可以用额外的字段重新创建。</p>
<p>
<img title="从数据库思维到数据湖思维的转变" alt="从数据库思维到数据湖思维的转变" border="0" height="auto" src="https://zhuji.jb51.net/uploads/img/202305/709175caa30846ba001b5424e4900391.jpg" width="auto"></p>
<p>
策划的模式演变(图片由作者提供</p>
<p>
主要收获：</p>
<ul>
<li>
如果你现在不需要，就不要花大量的时间去创建一个通用的一刀切的策划模式。</li>
<li>
迭代地创建一个策划的模式，从添加你现在需要的字段开始。</li>
<li>
当需要额外的字段时，将它们添加到策展过程中并重新处理。</li>
</ul>
<p>
<strong>最后的思考</strong></p>
<p>
数据湖不是数据库的替代品，每种工具都有它的优势和致命弱点。</p>
<p>
将数据湖用于OLTP可能是一个坏主意，就像使用数据库来存储数千兆字节的非结构化数据一样。</p>
<p>
我希望这篇文章有助于阐明两个系统之间的一些关键设计差异。</p>
<p>
原文地址：https://www.toutiao.com/i6956627565075284491/</p>
頁:
[1]