当前的湖泊就像一个假命题
#编程 #database #bigdata #lakehouse

从多合一的机器，超连接，云计算到HTAP，我们不断尝试将多个应用程序方案结合在一起，并尝试通过一项技术解决此类问题，以实现简单有效的目标使用。如今，Lakehouse非常热，正是如此的技术。它的目标是将数据湖与数据仓库集成在一起，以同时发挥其各自的价值。

数据湖和数据仓库一直密切相关，但它们之间存在显着差异。数据湖更加关注保留原始信息，其主要目标是存储原始数据。但是，原始数据中有很多垃圾数据。存储原始数据是否意味着所有垃圾数据都将存储在数据湖中？是的，数据湖就像一个存储所有数据的垃圾数据码，无论它们是否有用。因此，数据湖面对的第一个问题是存储大量（垃圾）数据。

受益于现代存储技术的大量发展，存储大量数据的成本大大降低了。例如，使用分布式文件系统可以完全满足数据湖的存储需求。但是，仅数据存储能力是不够的，还需要计算能力才能使该值发挥作用。 Data Lake存储了各种类型的数据，并且每个数据的处理方式都不同，并且结构化数据处理的重要性最高。无论是历史数据还是新生成的业务数据，数据处理主要集中在结构化数据上。在许多情况下，半结构化数据和非结构化数据的计算最终将转换为结构化数据计算。但是，不幸的是，由于数据湖的存储模式本身（文件系统）没有计算能力，因此不可能直接在数据湖上处理数据。要处理数据，您必须使用其他技术（例如数据仓库）。数据湖面临的主要问题是能够存储，但无法计算。

对于数据仓库，情况恰恰相反。数据仓库基于SQL系统，并且通常具有计算结构化数据的强大能力。但是，只有在将原始数据清洗，转换和深入组织之后，直到它们达到数据库的约束才能加载到数据仓库中。在此过程中，将丢失大量原始信息，即使数据粒度也将变得粗糙，导致无法获得粒度较低的数据值。此外，数据仓库是高度注重主题的，仅服务一个或几个主题。由于受试者之外的数据不是数据仓库的目标，因此它将使可用数据的范围相对狭窄，从而使其无法像数据湖一样探索完整和未知数据的价值，更不用说存储大量的原始数据，例如数据湖。与数据湖相比，数据仓库具有计算能力，但无法存储

。

从数据流的角度来看，数据仓库的数据可以根据数据湖进行组织，因此自然的想法是将数据湖与数据仓库整合在一起，以实现的目标能够存储和计算，即所谓的湖泊。

那么，当前的实施情况是什么？

当前方法过于简单且粗糙，也就是说，在数据湖上打开数据访问权限，以允许数据仓库实时访问数据（所谓的实时是相对于原始ETL的需要定期将数据从数据湖转移到数据仓库的过程。但是，实践中仍然存在一定的延迟）。从物理上讲，数据仍然存储在两个地方，并且数据交互是通过高速网络执行的。由于具有一定的实时处理数据湖的数据，因此实施结果（主要在建筑级别）被称为Lakehouse。

是吗？那是真正意义上的湖泊吗？

好吧，我不得不说 - 只要那个（声称是莱克豪斯的人）不会感到尴尬，那就是（谁知道莱克豪斯应该是什么）感到尴尬。

那么，数据仓库如何读取数据湖的数据？一种常见的做法是在数据仓库中创建一个外部表/模式，以映射RDB的表，模式或Hive的Metastore。此过程与传统RDB通过外部表访问外部数据的方法相同。尽管保留了元数据信息，但缺点是显而易见的。具体而言，它需要数据湖在相应的关系模型下以表和图量的形式映射，并且还需要在计算数据之前组织数据湖。此外，可用数据源的类型减小（例如，我们无法基于NOSQL，TEXT和WEBS服务直接执行映射）。此外，即使还有其他数据源（例如RDB）可以在数据湖中计算，数据仓库通常需要在计算时将数据移至本地位置（例如分组和聚集），从而导致高数据传输成本，性能下降和许多问题。

除了实时数据交互之外，目前的湖泊还保留了定期组织数据的原始渠道。这样，数据湖的有组织数据可以存储到数据仓库中，以进行本地计算。当然，这与Lakehouse无关，因为它是在整合之前以相同的方式进行的。

无论如何，数据湖和数据仓库都发生了很小的变化（仅提高了数据传输频率，但必须满足许多条件），无论数据是通过传统的ETL还是外部实时映射从湖中传输到仓库。从物理上讲，数据仍然存储在两个地方。数据湖仍然是原始的数据湖，仓库仍然是原始数据仓库，基本上不是整合的！因此，不仅数据多样性和效率问题根本无法解决（缺乏（缺乏）灵活性），但还需要首先组织数据湖的垃圾数据，然后在计算之前将它们加载到仓库（实时性能差）。如果您想通过以这种方式实施的湖泊在数据湖上建立实时有效的数据处理能力，恐怕这是个玩笑。

为什么？

如果我们有点思考，我们会发现问题在数据仓库中。数据库系统太封闭了，缺乏开放性，它需要在计算之前将数据加载到数据库（包括外部数据映射）中。此外，由于数据库限制，必须深入组织数据以符合规范，然后再加载到数据库中，而Data Lake的原始数据本身具有许多垃圾数据。尽管组织这些数据是合理的，但很难响应数据湖的实时计算需求。如果数据库足够开放，并且具有直接计算数据湖无组织数据的能力，甚至可以根据各种不同类型的数据源执行混合计算的能力，并提供高性能机制以确保同时计算效率，然后很容易实施真正的湖泊。但是，可惜数据库无法实现此目标。

幸运的是，Esproc Spl做。

SPL-开放的计算引擎 - 有助于实施真正的湖泊

开源SPL是一个结构化数据计算引擎，可为数据湖提供开放的计算能力，该计算能力可以直接计算数据湖的原始数据，也没有约束，甚至没有数据库来存储数据。此外，SPL具有不同数据源的混合计算能力。无论数据湖是建立在统一文件系统上的，还是基于不同的数据源（RDB，NOSQL，LocalFile，WebService），可以在SPL中完成直接混合的计算，并且可以快速产生数据湖的价值。此外，SPL提供了高性能的文件存储（数据仓库的存储功能）。当计算在SPL中进行时，可以无需组织数据，同时将原始数据加载到SPL的存储中可以获得更高的性能。应特别注意数据在组织系统中存储在SPL存储中后仍然存储在文件系统中，从理论上讲，它们可以与数据湖一起存储在同一位置。这样，可以实施真正的湖泊。

Image description

在整个架构中，SPL可以基于数据湖直接执行统一的存储和计算，并且还可以连接到数据湖中的不同数据源，甚至可以直接读取外部生产数据源。借助这些能力，可以实现数据湖的实时计算，在某些情况下需要高数据及时性（在将数据存储到数据湖中之前，需要使用数据），SPL可以连接到现实 - 时间数据源，因此数据及时性更高。

仍然可以保留将数据从数据湖移至数据仓库的原始方法。将原始数据与SPL的高性能存储保持更高的计算性能。同时，使用文件系统存储数据使数据可以分布在SPL服务器（存储）上，或者，我们仍然可以使用Data Lake的统一文件来存储数据，即原始数据的工作仓库完全被SPL接管。结果，湖屋是在一个系统中实施的。

让我们看一下Spl的这些能力。

开放和全方位计算能力

多样的源混合计算能力

SPL支持各种数据源，包括RDB，NOSQL，JSON/XML，CSV，WebService等，并且具有在不同源之间执行混合计算的能力。这可以直接使用存储在数据湖中的任何类型的原始数据，并在不转换数据的情况下播放数据的值，并且省略了加载到数据库中的动作。因此，确保了灵活有效地使用数据，并涵盖了更广泛的业务需求。

Image description

通过此功能，数据湖将能够在应用程序建立后立即为应用程序提供数据服务，而不是必须完成长时间的数据准备，加载和建模周期。此外，基于SPL的数据湖更加灵活，可以根据业务需求提供实时响应。

支持文件计算

尤其是，SPL对文件的良好支持为其提供了强大的计算能力。将湖泊数据存储在文件系统中还可以获得计算能力，甚至大于数据库功能。除文本文件外，SPL还可以处理JSON等层次格式的数据，因此可以直接使用NOSQL和RESTFUL的数据而无需转换。真的很方便。

    A   
1   =json(file("/data/EO.json").read()) 
2   =A1.conj(Orders)    
3   =A2.select(Amount>1000 && Amount<=3000 && like@c(Client,"*s*")) Conditional filtering
4   =A2.groups(year(OrderDate);sum(Amount)) Grouping and aggregating
5   =A1.new(Name,Gender,Dept,Orders.OrderID,Orders.Client,Orders.Client,Orders.SellerId,Orders.Amount,Orders.OrderDate) Join

全能计算能力

SPL提供了全方位的计算能力。离散的数据集模型（而不是关系代数），它以SQL的完整计算能力集为基础。此外，具有敏捷语法和程序编程能力，SPL中的数据处理比SQL更简单，更方便。

Image description
SPL的丰富计算库

这使数据湖完全具有数据仓库的计算能力，实现将数据湖与数据仓库集成的第一步。。

直接访问源数据

SPL的开放计算能力延伸到数据湖之外。通常，如果目标数据不从源到湖中同步，但现在需要，我们别无选择，只能等待同步完成。现在，使用SPL，我们可以直接访问数据源以执行计算，或在湖中数据源和现有数据之间执行混合计算。从逻辑上讲，数据源可以作为数据湖的一部分进行处理，以便可以实现更高的灵活性。

数据组织之后的高性能计算

除了自己的全能和强大的计算能力外，SPL还提供基于文件的高性能存储。将原始数据和将其存储在SPL存储中可以实现更高的性能。更重要的是，文件系统具有一系列优势，例如灵活使用和易于与众不同的过程。具有数据存储能力等于实现将数据湖与数据仓库集成的第二步，并形成了新的开放和灵活的数据仓库。

当前，SPL提供了两种高性能文件存储格式：bin文件和复合表。 bin文件采用压缩技术（由于空间占用较少而引起的更快读数），存储数据类型（由于不需要解析数据类型而导致的读数更快），并支持双重增量细分机制可以附加数据。由于使用分割策略可以易于实现并行计算，因此可以确保计算性能。 复合表支持柱状存储，此存储模式在仅涉及少量列（字段）的方案中具有很大的优势。此外，复合表实现了Minmaxindex并支持双重增量分割机制，因此，它不仅享有柱状存储的优势，而且还可以使执行并行计算更容易提高性能。

此外，很容易在SPL中实现并行计算，并充分发挥多个CPU的优势。许多SPL功能，例如文件检索，过滤和排序，支持并行处理。对于他们来说，仅通过添加@Moption来自动实现多线程处理，这很简单。他们明确支持并行编写平行程序以增强计算性能。

特别是，SPL支持各种高性能算法SQL无法实现。例如，结果将常见的TOPN操作视为SPL中的聚合操作，因此，可以将高复杂性排序操作转换为低复杂性聚集操作，同时扩展了应用程序的范围。
。

    A   
1   =file(“data.ctx”).create().cursor() 
2   =A1.groups(;top(10,amount)) Get orders whose amount rank in top 10
3   =A1.groups(area;top(10,amount)) Get orders whose amount rank in top 10 in each area

在这些语句中，没有任何与分类相关的关键字，也不会触发完整的分类操作。从整体和分组子集中获得顶级N的陈述基本上是相同的，并且两者都可以实现更高的性能。 SPL拥有更多这样的高性能算法。

根据这些机制，SPL可以实现超过传统数据仓库的性能，以数量级来衡量的超越程度，并且在数据湖中的湖泊全部实施不是用文字而是有效的机制来完成的。

此外，SPL可以对转换的数据和原始数据执行混合的计算，以使各种数据的价值充分发挥作用，而不是预先准备数据。这样，数据湖的灵活性不仅完全扩展了，而且还具有实时数据仓库的功能。这实现了将数据湖与数据仓库集成的第三步，该仓库都考虑了灵活性和高性能。

通过上述三个步骤，建立数据湖的途径得到了改善（原始路径需要在计算之前加载和转换数据），并且可以同时进行数据准备和计算，并且可以同时进行计算数据湖是逐步建造的。此外，在构建数据湖的过程中，数据仓库已经完善，使数据湖具有强大的计算能力，并实现了真正的湖泊。这是实施真正的湖泊的正确方法。

SPL源代码：https://github.com/SPLWare/esProc
来源：https://blog.scudata.com/the-current-lakehouse-is-like-a-false-proposition/