Pegdwendé Sawadogo
email: pegdwende.sawadogo@univ-lyon2.fr

Jérôme Darmont
email: jerome.darmont@univ-lyon2.fr

On Data Lake Architectures and Metadata Management

Keywords: Data lakes, Data lake architectures, Metadata management, Metadata modeling

Over the past two decades, we have witnessed an exponential increase of data production in the world. So-called big data generally come from transactional systems, and even more so from the Internet of Things and social media. They are mainly characterized by volume, velocity, variety and veracity issues. Big data-related issues strongly challenge traditional data management and analysis systems. The concept of data lake was introduced to address them. A data lake is a large, raw data repository that stores and manages all company data bearing any format. However, the data lake concept remains ambiguous or fuzzy for many researchers and practitioners, who often confuse it with the Hadoop technology. Thus, we provide in this paper a comprehensive state of the art of the different approaches to data lake design. We particularly focus on data lake architectures and metadata management, which are key issues in successful data lakes. We also discuss the pros and cons of data lakes and their design alternatives.

Introduction

The 21 st century is marked by an exponential growth of the amount of data produced in the world. This is notably induced by the fast development of the Internet of Things (IoT) and social media. Yet, while big data represent a tremendous opportunity for various organizations, they come in such volume, speed, heterogeneous sources and structures that they exceed the capabilities of traditional management systems for their collection, storage and processing in a reasonable time [START_REF] Miloslavskaya | Big Data, Fast Data and Data Lake Concepts[END_REF]. A time-tested solution for big data management and processing is data warehousing. A data warehouse is indeed an integrated and historical storage system that is specifically designed to analyze data. However, while data warehouses are still relevant and very powerful for structured data, semi-structured and unstructured data induce great challenges for data warehouses. Yet, the majority of big data is unstructured [START_REF] Miloslavskaya | Big Data, Fast Data and Data Lake Concepts[END_REF]. Thus, the concept of data lake was introduced to address big data issues, especially those induced by data variety.

A data lake is a very large data storage, management and analysis system that handles any data format. It is currently quite popular and trendy both in the industry and academia. Yet, the concept of data lake is not straightforward for everybody. A survey conducted in 2016 indeed revealed that 35% of the respondents considered data lakes as a simple marketing label for a preexisting technology, i.e., Apache Hadoop [START_REF] Grosser | Hadoop and Data Lakes: Use Cases, Benefits and Limitations[END_REF]. Knowledge about the concept of the data lake has since evolved, but some misconceptions still exist, presumably because most of data lakes design approaches are abstract sketches from the industry that provide few theoretical or implementation details [START_REF] Quix | Data Lake[END_REF]. Therefore, a survey can be useful to give researchers and practitioners a better comprehension of the data lake concept and its design alternatives.

To the best of our knowledge, the only literature reviews about data lakes are all quite brief and/or focused on a specific topic, e.g., data lake concepts and definitions [START_REF] Couto | A Mapping Study about Data Lakes: An Improved Definition and Possible Architectures[END_REF]33], the technologies used for implementing data lakes [START_REF] Mathis | Data Lakes[END_REF] or data lakes inherent issues [START_REF] Giebler | Leveraging the Data Lake -Current State and Challenges[END_REF][START_REF] Quix | Data Lake[END_REF]. Admittedly, the report proposed in [START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF] is quite extensive, but it adopts a purely industrial view. Thus, we adopt in this paper a wider scope to propose a more comprehensive state of the art of the different approaches to design and exploit a data lake. We particularly focus on data lake architectures and metadata management, which lie at the base of any data lake project and are the most commonly cited issues in the literature (Figure 1). More precisely, we first review data lake definitions and complement the best existing one. Then, we investigate the architectures and technologies used for the implementation of data lakes, and propose a new typology of data lake architectures. Our second main focus is metadata management, which is a primordial issue to avoid turning a data lake into an inoperable, so-called data swamp. We notably classify data lake metadata and introduce the features that are necessary to achieve a full metadata system. We also discuss the pros and cons of data lakes.

Data Lake

Design and implementation

Architectures Metadata Management

Zone Architectures Functional x Maturity Architectures

Eventually, note that we do not review other important topics, such as data ingestion, data governance and security in data lakes, because they are currently little addressed in the literature, but could still presumably be the subject of another full survey.

The remainder of this paper is organized as follows. In Section 2, we define the data lake concept. In Section 3, we review data lake architectures and technologies to help users choose the right approach and tools. In Section 4, we extensively review and discuss metadata management. Eventually, we recapitulate the pros and cons of data lakes in Section 5 and conclude the paper in Section 6 with a mind map of the key concepts we introduce, as well as current open research issues.

2 Data Lake Definitions

Definitions from the Literature

The concept of data lake was introduced by Dixon as a solution to perceived shortcomings of datamarts, which are business-specific subdivisions of data warehouses that allow only subsets of questions to be answered [START_REF] Dixon | Pentaho, Hadoop, and Data Lakes[END_REF]. In the literature, data lakes are also refered to as data reservoirs [START_REF] Chessell | Governing and Managing Big Data for Analytics and Decision Makers[END_REF] and data hubs [START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF][START_REF] Laskowski | Data lake governance: A big data do or die[END_REF], although the terms data lake are the most frequent. Dixon envisions a data lake as a large storage system for raw, heterogeneous data, fed by multiple data sources, and that allows users to explore, extract and analyze the data.

Subsequently, part of the literature considered data lakes as an equivalent to the Hadoop technology [START_REF] Fang | Managing Data Lakes in Big Data Era: What's a data lake and why has it became popular in data management ecosystem[END_REF][START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF][START_REF] O'leary | Embedding AI and Crowdsourcing in the Big Data Lake[END_REF]. According to this point of view, the concept of data lake refers to a methodology for using free or low-cost technologies, typically Hadoop, for storing, processing and exploring raw data within a company [START_REF] Fang | Managing Data Lakes in Big Data Era: What's a data lake and why has it became popular in data management ecosystem[END_REF]. The systematic association of data lakes to low cost technologies is becoming minority in the literature, as the data lake concept is now also associated with proprietary cloud solutions such as Azure or IBM [33,[START_REF] Sirosh | The Intelligent Data Lake[END_REF] and various data management systems such as NoSQL solutions and multistores. However, it can still be viewed as a data-driven design pattern for data management [START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF].

More consensually, a data lake may be viewed as a central repository where data of all formats are stored without a strict schema, for future analyses [START_REF] Couto | A Mapping Study about Data Lakes: An Improved Definition and Possible Architectures[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF][START_REF] Mathis | Data Lakes[END_REF]. This definition is based on two key characteristics of data lakes: data variety and the schema-on-read approach, also known as late binding [START_REF] Fang | Managing Data Lakes in Big Data Era: What's a data lake and why has it became popular in data management ecosystem[END_REF], which implies that schema and data requirements are not fixed until data querying [START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF][START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF][START_REF] Stein | The enterprise data lake: Better integration and deeper analytics[END_REF]. This is the opposite to the schema-on-write approach used in data warehouses.

However, the variety/schema-on-read definition may be considered fuzzy because it gives little detail about the characteristics of a data lake. Thus, Madera and Laurent introduce a more complete definition where a data lake is a logi-cal view of all data sources and datasets in their raw format, accessible by data scientists or statisticians for knowledge extraction [33].

More interestingly, this definition is complemented by a set of features that a data lake should include:

1. data quality is provided by a set of metadata; 2. the lake is controlled by data governance policy tools; 3. usage of the lake is limited to statisticians and data scientists; 4. the lake integrates data of all types and formats; 5. the data lake has a logical and physical organization.

Discussion and New Definition

Madera and Laurent's definition of data lakes is presumably the most precise, as it defines the requirements that a data lake must meet (Section 2.1). However, some points in this definition are debatable. The authors indeed restrain the use of the lake to data specialists and, as a consequence, exclude business experts for security reasons. Yet, in our opinion, it is entirely possible to allow controlled access to this type of users through a navigation or analysis software layer.

Moreover, we do not share the vision of the data lake as a logical view over data sources, since some data sources may be external to an organization, and therefore to the data lake. Since Dixon explicitly states that lake data come from data sources [START_REF] Dixon | Pentaho, Hadoop, and Data Lakes[END_REF], including data sources into the lake may therefore be considered contrary to the spirit of data lakes.

Finally, although quite complete, Madera and Laurent's definition omits an essential property of data lakes: scalability [START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF][START_REF] Miloslavskaya | Big Data, Fast Data and Data Lake Concepts[END_REF]. Since a data lake is intended for big data storage and processing, it is indeed essential to address this issue. Thence, we amend Madera and Laurent's definition to bring it in line with our vision and introduce scalability [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF].

Definition 1 A data lake is a scalable storage and analysis system for data of any type, retained in their native format and used mainly by data specialists (statisticians, data scientists or analysts) for knowledge extraction. Its characteristics include:

1. a metadata catalog that enforces data quality; 2. data governance policies and tools; 3. accessibility to various kinds of users; 4. integration of any type of data; 5. a logical and physical organization; 6. scalability in terms of storage and processing.

Data Lake Architectures and Technologies

Existing reviews on data lake architectures commonly distinguish pond and zone architectures [START_REF] Giebler | Leveraging the Data Lake -Current State and Challenges[END_REF][START_REF] Ravat | Data Lakes: Trends and Perspectives[END_REF]. However, this categorization may sometimes be fuzzy. Thus, we introduce in Section 3.1 a new manner to classify data lakes architectures that we call Functional × Maturity. In addition, we present in Section 3.2 a list of possible technologies to implement a data lake. Eventually, we investigate in Section 3.3 how a data lake system can be associated with a data warehouse in an enterprise data architecture.

3.1 Data Lake Architectures

Zone Architectures

Pond architecture Inmon designs a data lake as a set of data ponds [START_REF] Inmon | Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump[END_REF]. A data pond can be viewed as a subdivision of a data lake dealing with data of a specific type. According to Dixon's specifications, each data pond is associated with a specialized storage system, some specific data processing and conditioning (i.e., data transformation/preparation) and a relevant analysis service. More precisely, Inmon identifies five data ponds (Figure 2). 1. The raw data pond deals with newly ingested, raw data. It is actually a transit zone, since data are then conditioned and transferred into another data pond, i.e., either the analog, application or textual data pond. The raw data pond, unlike the other ponds, is not associated with any metadata system. 2. Data stored in the analog data pond are characterized by a very high frequency of measurements, i.e., they come in with high velocity. Typically, semistructured data from the IoT are processed in the analog data pond. 3. Data ingested in the application data pond come from software applications, and are thus generally structured data from relational Database Management Systems (DBMSs). Such data are integrated, transformed and prepared for analysis; and Inmon actually considers that the application data pond is a data warehouse. 4. The textual data pond manages unstructured, textual data. It features a textual disambiguation process to ease textual data analysis.

Storage

5. The purpose of the archival data pond is to save the data that are not actively used, but might still be needed in the future. Archived data may originate from the analog, application and textual data ponds.

Zone architectures So-called zone architectures assign data to a zone according to their degree of refinement [START_REF] Giebler | Leveraging the Data Lake -Current State and Challenges[END_REF]. For instance, Zaloni's data lake [START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF] adopts a six-zone architecture (Figure 3). 1. The transient loading zone deals with data under ingestion. Here, basic data quality checks are performed. 2. The raw data zone handles data in near raw format coming from the transient zone. 3. The trusted zone is where data are transferred once standardized and cleansed. 4. From the trusted area, data move into the discovery sandbox where they can be accessed by data scientists through data wrangling or data discovery operations. 5. On top of the discovery sandbox, the consumption zone allows business users to run "what if" scenarios through dashboard tools. 6. The governance zone finally allows to manage, monitor and govern metadata, data quality, a data catalog and security.

However, this is but one of several variants of zone architectures. Such architectures indeed generally differ in the number and characteristics of zones [START_REF] Giebler | Leveraging the Data Lake -Current State and Challenges[END_REF], e.g., some architectures include a transient zone [START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF][START_REF] Tharrington | The Dzone Guide to Big Data, Data Science & Advanced Analytics[END_REF][START_REF] Zikopoulos | Big Data Bayond the Hype[END_REF]] while others do not [START_REF] Hai | Constance: An Intelligent Data Lake System[END_REF][START_REF] Ravat | Data Lakes: Trends and Perspectives[END_REF].

A particular zone architecture often mentioned in the data lake literature is the lambda architecture [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF][START_REF] Mathis | Data Lakes[END_REF]. It indeed stands out since it includes two data processing zones: a batch processing zone for bulk data and a real-time processing zone for fast data from the IoT [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF]. These two zones help handling fast data as well as bulk data in an adapted and specialized way.

Discussion

In both pond and zone architectures, data are pre-processed. Thus, analyses are quick and easy. However, this come at the cost of data loss in the pond architectures, since raw data are deleted when transferred to other ponds.

The drawbacks of the many zone architectures depend on each variant. For example, in Zaloni's architecture [START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF], data flow across six areas, which may lead to multiple copies of the data and, therefore, difficulties in controlling data lineage. In the Lamda architecture [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF], speed and batch processing components follow different paradigms. Thus, data scientists must handle two distinct logics for cross analyses [START_REF] Mathis | Data Lakes[END_REF], which makes data analysis harder, overall.

Moreover, the distinction of data lake architectures into pond and zone approaches is not so crisp in our opinion. The pond architecture may indeed be considered as a variant of zone architecture, since data location depends on the refinement level of data, as in zone architectures. In addition, some zone architectures include a global storage zone where raw and cleansed data are stored altogether [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF][START_REF] Quix | Data Lake[END_REF], which contradicts the definition of zone architectures, i.e., components depend on the degree of data refinement.

Functional × Maturity Architectures

To overcome the contradictions of the pond/zone categorization, we propose an alternative way to group data lake architectures regarding the type of criteria used to define components. As a result, we distinguish functional architectures, data maturity-based architectures and hybrid architectures (Figure 4).

Maturity-based Architectures Hybrid Architectures

Zikopoulos et al. (2015)

Laplante and Sharma ( 2016) [START_REF] Tharrington | The Dzone Guide to Big Data, Data Science & Advanced Analytics[END_REF] ... Functional architectures follow some basic functions to define a lake's components. Data lake basic functions typically include [START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF]:

Functional Architectures

1. a data ingestion function to connect with data sources; 2. a data storage function to persist raw as well as refined data; 3. a data processing function; 4. a data access function to allow raw and refined data querying.

Quix and Hai, as well as Mehmood et al., base their data lake architectures on these functions [START_REF] Mehmood | Implementing big data lake for heterogeneous data sources[END_REF][START_REF] Quix | Data Lake[END_REF]. Similarly, John and Misra's lambda architecture [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF] may be considered as a functional architecture, since its components represent data lake functions such as storage, processing and serving.

Data maturity-based architectures are data lake architectures where components are defined regarding data refinement level. In other words, it is constituted of most zone architectures. A good representative is Zaloni's data lake architecture [START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF], where common basic zones are a transient zone, a raw data zone, a trusted data zone and a refined data zone [START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF][START_REF] Tharrington | The Dzone Guide to Big Data, Data Science & Advanced Analytics[END_REF][START_REF] Zikopoulos | Big Data Bayond the Hype[END_REF].

Hybrid architectures are data lake architectures where the identified components depend on both data lake functions and data refinement. Inmon's pond architecture is actually a hybrid architecture [START_REF] Inmon | Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump[END_REF]. On one hand, it is a data maturity-based architecture, since raw data are managed in a special component, i.e., the raw data pond, while refined data are managed in other ponds, i.e., the textual, analog and application data ponds. But on the other hand, the pond architecture is also functional because Inmon's specifications consider some storage and process components distributed across data ponds (Figure 2). Ravat and Zhao also propose such an hybrid data lake architecture (Figure 5 [START_REF] Ravat | Data Lakes: Trends and Perspectives[END_REF]).

Raw data storage

Raw data ingestion

Governance zone

Raw data zone

Intermediate data storage

Data processing

Processing zone

Available data storage Data querying

Access zone

Fig. 5 Ravat and Zhao's hybrid architecture [START_REF] Ravat | Data Lakes: Trends and Perspectives[END_REF] Discussion Functional architectures have the advantage of clearly highlighting the functions to implement for a given data lake, which helps match easily with the required technologies. By contrast, data maturity-based architectures are useful to plan and organize the data lifecycle. Both approaches are thus limited, since they only focus on a unique point of view, while it is important in our opinion to take both functionality and data maturity into account when designing a data lake.

In consequence, we advocate for hybrid approaches. However, existing hybrid architecture can still be improved. For instance, in Inmon's data pond approach, raw data are deleted once they are refined. This process may induce some data loss, which is contrary to the spirit of data lakes. In Ravat and Zhao's proposal, data access seems only possible for refined data. Such limitations hint that a more complete hybrid data lake architecture is still needed nowadays.

Technologies for Data Lakes

Most data lake implementations are based on the Apache Hadoop ecosystem [START_REF] Couto | A Mapping Study about Data Lakes: An Improved Definition and Possible Architectures[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF]. Hadoop has indeed the advantage of providing both storage with the Hadoop Distributed File System (HDFS) and data processing tools via MapReduce or Spark. However, Hadoop is not the only suitable technology to implement a data lake. In this section, we go beyond Hadoop to review usable tools to implement data lake basic functions.

Data Ingestion

Ingestion technologies help physically transfer data from data sources into a data lake. A first category of tools includes software that iteratively collects data through pre-designed and industrialized jobs. Most such tools are proposed by the Apache Foundation, and can also serve to aggregate, convert and clean data before ingestion. They include Flink and Samza (distributed stream processing frameworks), Flume (a Hadoop log transfer service), Kafka (a framework providing real time data pipelines and stream processing applications) and Sqoop (a framework for data integration from SQL and NoSQL DBMSs into Hadoop) [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF][START_REF] Mathis | Data Lakes[END_REF][START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF].

A second category of data ingestion technologies is made of common data transfer tools and protocols (wget, rsync, FTP, HTTP, etc.), which are used by the data lake manager within data ingestion scripts. They have the key advantage to be readily available and widely understood [START_REF] Terrizzano | Data Wrangling: The Challenging Journey from the Wild to the Lake[END_REF]. In a similar way, some Application Programming Interfaces (APIs) are available for data retrieval and transfer from the Web into a data lake. For instance, CKAN and Socrata provide APIs to access a catalogue of open data and associated metadata [START_REF] Terrizzano | Data Wrangling: The Challenging Journey from the Wild to the Lake[END_REF].

Data Storage

We distinguish two main approaches to store data in data lakes. The first way consists in using classic databases for storage. Some data lakes indeed use relational DBMSs such as MySQL, PostgreSQL or Oracle to store structured data [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF]. However, relational DBMSs are ill-adapted to semi-structured, and even more so to unstructured data. Thus, NoSQL (Not only SQL) DBMSs are usually used instead [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF][START_REF] Giebler | Leveraging the Data Lake -Current State and Challenges[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF]. Moreover, assuming that data variety is the norm in data lakes, a multi-paradigm storage system is particularly relevant [START_REF] Nogueira | Modeling Data Lake Metadata with a Data Vault[END_REF]. Such so-called multistore systems manage multiple DBMSs, each matching a specific storage need.

The second main way to store data and the most used is HDFS storage (in about 75% of data lakes [START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF]). HDFS is a distributed storage system that offers a very high scalability and handles all types of data [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF]. Thus, it is well suited for schema-free and bulk storage that are needed for unstructured data. Another advantage of this technology is the distribution of data that allows high faulttolerance. However, HDFS alone is not sufficient to handle all data formats, especially structured data. Thus, it should ideally be combined with relational and/or NoSQL DBMSs.

Data Processing

In data lakes, data processing is very often performed with MapReduce [START_REF] Couto | A Mapping Study about Data Lakes: An Improved Definition and Possible Architectures[END_REF][START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF][START_REF] Mathis | Data Lakes[END_REF][START_REF] Stein | The enterprise data lake: Better integration and deeper analytics[END_REF][START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF], a parallel data processing paradigm provided by Apache Hadoop. MapReduce is well-suited to very large data, but is less efficient for fast data because it works on disk [START_REF] Tiao | Object Storage for Big Data: What Is It? And Why Is It Better?[END_REF]. Thus, alternative processing frameworks are used, from which the most famous is Apache Spark. Spark works like MapReduce, but adopts a full in-memory approach instead of using the file system for storing intermediate results. Thence, Spark is particularly suitable for real-time processing. Similarly, Apache Flink and Apache Storm are also suitable for real-time data processing [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF][START_REF] Mathis | Data Lakes[END_REF][START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF][START_REF] Tiao | Object Storage for Big Data: What Is It? And Why Is It Better?[END_REF]. Nevertheless, these two approaches can be simultaneously implemented in a data lake, with MapReduce being dedicated to voluminous data and stream-processing engines to velocious data [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF][START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF].

Data Access

In data lakes, data may be accessed through classical query languages such as SQL for relational DBMSs, JSONiq for MongoDB, XQuery for XML DBMSs or SPARQL for RDF resources [START_REF] Farid | CLAMS: Bringing Quality to Data Lakes[END_REF][START_REF] Fauduet | A data-first preservation strategy: Data management in spar[END_REF][START_REF] Hai | Constance: An Intelligent Data Lake System[END_REF][START_REF] Laskowski | Data lake governance: A big data do or die[END_REF][START_REF] Pathirana | Modeling Industrial and Cultural Heritage Data[END_REF]. However, this does not allow simultaneously querying across heterogeneous databases, while data lakes do store heterogeneous data, and thus typically require heterogeneous storage systems.

One solution to this issue is to adopt the query techniques from multistores (Section 3.2.2) [START_REF] Nogueira | Modeling Data Lake Metadata with a Data Vault[END_REF]. For example, Spark SQL and SQL++ may be used to query both relational DBMSs and semi-structured data in JSON format. In addition, the Scalable Query Rewriting Engine (SQRE) handles graph databases [START_REF] Hai | Query Rewriting for Heterogeneous Data Lakes[END_REF]. Finally, CloudMdsQL also helps simultaneously query multiple relational and NoSQL DBMSs [START_REF] Leclercq | A Tensor Based Data Model for Polystore: An Application to Social Networks Data[END_REF]. Quite similarly, Apache Phoenix can be used to automatically convert SQL queries into a NoSQL query language, for example. Apache Drill allows joining data from multiple storage systems [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF]. Data stored in HDFS can also be accessed using Apache Pig [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF].

Eventually, business users, who require interactive and user-friendly tools for data reporting and visualization tasks, widely use dashboard services such as Microsoft Power BI and Tableau over data lakes [START_REF] Couto | A Mapping Study about Data Lakes: An Improved Definition and Possible Architectures[END_REF][START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF].

Combining Data Lakes and Data Warehouses

There are in the literature two main approaches to combine a data lake and a data warehouse in a global data management system. The first approach pertains to using a data lake as the data source of a data warehouse (Section 3.3.1). The second considers data warehouses as components of data lakes (Section 3.3.2).

Data Lake Sourcing a Data Warehouse

This approach aims to take advantage of the specific characteristics of both data lakes and data warehouses. Since data lakes allow an easier and cheaper storage of large amount of raw data, they can be considered as staging areas or Operational Data Stores (ODSs) [START_REF] Fang | Managing Data Lakes in Big Data Era: What's a data lake and why has it became popular in data management ecosystem[END_REF][START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF], i.e., intermediary data stores ahead of data warehouses that gather operational data from several sources before the ETL process takes place.

With a data lake sourcing a data warehouse, possibly with semi-structured data, industrialized OLAP analyses are possible over the lake's data, while ondemand, ad-hoc analyses are still possible directly from the data lake (Figure 6).

Data Warehouse within a Data Lake

As detailed in Section 3.1.1, Inmon proposes an architecture based on a subdivision of data lakes into so-called data ponds [START_REF] Inmon | Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump[END_REF]. For Inmon, structured data ponds sourced from operational applications are, plain and simple, data warehouses. Thus, this approach acts on a conception of data lakes as extensions of data warehouses.

Discussion

When a data lake sources a data warehouse (Section 3.3.1), there is a clear functional separation, as data warehouses and data lakes are specialized in industrialized and on-demand analyses, respectively. However, this comes with a data siloing issue.

By contrast, the data siloing syndrome can be reduced in Inmon's approach (Section 3.3.2), as all data are managed and processed in a unique global platform. Hence, diverse data can easily be combined through cross-reference analyses, which would be impossible if data were managed separately. In addition, building a data warehouse inside a global data lake may improve data lifecycle control. That is, it should be easier to track, and thus to reproduce processes applied to the data that are ingested in the data warehouse, via the data lake's tracking system.

Metadata Management in Data Lakes

Data ingested in data lakes bear no explicit schema [START_REF] Miloslavskaya | Big Data, Fast Data and Data Lake Concepts[END_REF], which can easily turn a data lake into a data swamp in the absence of an efficient metadata system [START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF]. Thence, metadata management plays an essential role in data lakes [START_REF] Laskowski | Data lake governance: A big data do or die[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF]. In this section, we detail the metadata management techniques used in data lakes. First, we identify the metadata that are relevant to data lakes. Then, we review how metadata can be organized. We also investigate metadata extraction tools and techniques. Finally, we provide an inventory of desirable features in metadata systems.

Metadata Categories

We identify in the literature two main typologies of metadata dedicated to data lakes. The first one distinguishes functional metadata, while the second classifies metadata with respect to structural metadata types.

Functional Metadata

Oram introduces a metadata classification in three categories, with respect to the way they are gathered [START_REF] Oram | Managing the Data Lake[END_REF]. 1. Business metadata are defined as the set of descriptions that make the data more understandable and define business rules. More concretely, these are typically data field names and integrity constraints. Such metadata are usually defined by business users at the data ingestion stage. 2. Operational metadata are information automatically generated during data processing. They include descriptions of the source and target data, e.g., data location, file size, number of records, etc., as well as process information. 3. Technical metadata express how data are represented, including data format (e.g., raw text, JPEG image, JSON document, etc.), structure or schema. The data structure consists in characteristics such as names, types, lengths, etc. They are commonly obtained from a DBMS for structured data, or via custom techniques during the data maturation stage. Diamantini et al. enhance this typology with a generic metadata model [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF] and show that business, operational and technical metadata sometimes intersect. For instance, data fields relate both to business and technical metadata, since they are defined in data schemas by business users. Similarly, data formats may be considered as both technical and operational metadata, and so on (Figure 7).

Structural Metadata

In this classification, Sawadogo et al. categorize metadata with respect to the "objects" they relate to [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF]. The notion of object may be viewed as a generalization of the dataset concept [START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF], i.e., an object may be a relational or spreadsheet table in a structured data context, or a simple document (e.g., XML document, image file, video file, textual document, etc.) in a semi-structured or unstructured data context. Thence, we use the term "object" in the remainder of this paper.

Intra-object metadata belong to a set of characteristics associated with single objects in the lake. They are subdivided into four main subcategories.

1. Properties provide an object's general description. They are generally retrieved from the filesystem as key-value pairs, e.g., file name and size, location, date of last modification, etc. 2. Previsualization and summary metadata aim to provide an overview of the content or structure of an object. For instance, metadata can be extracted data schemas for structured and semi-structured data, or wordclouds for textual data. 3. Version and representation metadata are made of altered data. When a new data object o is generated from existing object o in the data lake, o may be considered as metadata for o. Version metadata are obtained through data updates, while representation metadata come from data refining operations.

For instance, a refining operation may consist of vectorizing a textual document into a bag-of-words for further automatic processing. 4. Semantic metadata involve annotations that describe the meaning of data in an object. They include such information as title, description, categorization, descriptive tags, etc. They often allow data linking. Semantic metadata can be either generated using semantic resources such as ontologies, or manually added by business users [START_REF] Hai | Constance: An Intelligent Data Lake System[END_REF][START_REF] Quix | Metadata Extraction and Management in Data Lakes With GEMMS[END_REF].

Inter-object metadata represent links between two or more objects. They are subdivided into three categories.

1. Object groupings organize objects into collections. Any object may be associated with several collections. Such links can be automatically deduced from some intra-object metadata such as tags, data format, language, owner, etc. 2. Similarity links express the strength of likeness between objects. They are obtained via common or custom similarity measures. For instance, [START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF] define the affinity and joinability measures to express the similarity between semistructured objects. 3. Parenthood links aim to save data lineage, i.e., when a new object is created from the combination of several others, these metadata record the process. Parenthood links are thus automatically generated during data joins.

Global metadata are data structures that provide a context layer to make data processing and analysis easier. Global metadata are not directly associated with any specific object, but potentially concern the entire lake. There are three subcategories of global metadata.

1. Semantic resources are knowledge bases such as ontologies, taxonomies, thesauri, etc., which notably help enhance analyses. For instance, an ontology can be used to automatically extend a term-based query with equivalent terms. Semantic resources are generally obtained from the Internet or manually built. 2. Indexes (including inverted indexes) enhance term-based or pattern-based data retrieval. They are automatically built and enriched by an indexing system. 3. Logs track user interactions with the data lake, which can be simple, e.g., user connection or disconnection, or more complex, e.g., a job running.

Discussion

Oram's metadata classification is the most cited, especially in the industrial literature [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF][START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF][START_REF] Ravat | Metadata management for data lakes[END_REF][START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF], presumably because it is inspired from metadata categories from data warehouses [START_REF] Ravat | Data Lakes: Trends and Perspectives[END_REF]. Thus, its adoption seems easier and more natural for practitioners who are already working with it. Yet, we favor the second metadata classification, because it includes most of the features defined by Oram's. Business metadata are indeed comparable to semantic metadata. Operational metadata may be considered as logs and technical metadata are equivalent to previsualization metadata. Hence, the structural metadata categorization can be considered as an extension, as well as a generalization, of the functional metadata classification.

Moreover, Oram's classification is quite fuzzy when applied in the context of data lakes. Diamantini et al. indeed show that functional metadata intersect (Section 4.1.1) [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF]. Therefore, practitioners who do not know this typology may be confused when using it to identify and organize metadata in a data lake.

Table 1 summarizes commonalities and differences between the two metadata categorizations presented above. The comparison addresses the type of information both inventories provide.

Metadata Modeling

There are in the literature two main approaches to represent a data lake's metadata system. The first, most common approach, adopts a graph view, while the second exploits data vault modeling.

Graph Models

Most models that manage data lake metadata systems are based on a graph approach. We identify three main subcategories of graph-based metadata models with respect to the main features they target.

Data provenance-centered graph models mostly manage metadata tracing, i.e., the information about activities, data objects and users who interact with a specific object [START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF]. In other words, they track the pedigree of data objects [20]. Provenance representations are usually built using a directed acyclic graph (DAG) where nodes represent entities such as users, roles or objects [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF][START_REF] Hellerstein | Ground: A Data Context Service[END_REF]. Edges are used to express and describe interactions between entities, e.g., through a simple timestamp, activity type (read, create, modify) [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF], system status (CPU, RAM, bandwith) [START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF] or even the script used [START_REF] Hellerstein | Ground: A Data Context Service[END_REF]. For instance Figure 8-a shows a basic provenance model with nodes representing data objects and edges symbolizing operations. Data provenance tracking helps ensure the traceability and repeatability of processes in data lakes. Thus, provenance metadata can be used to understand, explain and repair inconsistencies in the data [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF]. They may also serve to protect sensitive data, by detecting intrusions [START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF].

Similarity-centered graph models describe the metadata system as an undirected graph where nodes are data objects and edges express a similarity between objects. Such a similarity can be specified either through a weighted or unweighted edge. Weighted edges show the similarity strength, when a formal similarity measure is used, e.g., affinity and joinability [START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF] (Figure 8-b). In contrast, unweighted edges serve to simply detect whether two objects are connected [START_REF] Farrugia | Towards Social Network Analytics for Understanding and Managing Enterprise Data Lakes[END_REF]. Such a graph design allows network analyses over a data lake [START_REF] Farrugia | Towards Social Network Analytics for Understanding and Managing Enterprise Data Lakes[END_REF], e.g., discovering communities or calculating the centrality of nodes, and thus their importance in the lake. Another use of data similarity may be to automatically recommend to lake users some data related to the data they currently observe [START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF].

Composition-centered graph models help decompose each data object into several inherent elements. The lake is viewed as a DAG where nodes represent objects or attributes, e.g., columns, tags, etc., and edges from any node A to any node B express the constraint B ⊆ A [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF]20,[START_REF] Nargesian | Optimizing Organizations for Navigating Data Lakes[END_REF]. This organization helps users navigate through the data [START_REF] Nargesian | Optimizing Organizations for Navigating Data Lakes[END_REF]. It can also be used as a basis to detect connections between objects. For instance, [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF] used a simple string measure to detect links between heterogeneous objects by comparing their respective tags.

Data Vault

A data lake aims at ingesting new data possibly bearing various structures. Thus, its metadata system needs to be flexible to easily tackle new data schemas. Nogueira et al. propose the use of a data vault to address this issue [START_REF] Nogueira | Modeling Data Lake Metadata with a Data Vault[END_REF]. Data vaults are indeed alternative logical models to data warehouse star schemas that, unlike star schemas, allow easy schema evolution [START_REF] Linstedt | Super Charge your Data Warehouse: Invaluable Data Modeling Rules to Implement Your Data Vault[END_REF]. Data vault modeling involves three types of entities [START_REF] Hultgren | Data Vault modeling guide: Introductory Guide to Data Vault Modeling[END_REF]. A hub represents a business concept, e.g., customer, vendor, sale or product in a business decision system. 2. A link represents a relationship between two or more hubs.

3. Satellites contain descriptive information associated with a hub or a link.

Each satellite is attached to a unique hub or link. In contrast, links or hubs may be associated with any number of satellites.

In Nogueira et al.'s proposal, metadata common to all objects, e.g., title, category, date and location, are stored in hubs; while metadata specific to some objects only, e.g., language for textual documents or publisher for books, are stored in satellites (Figure 9). Moreover, any new type of object would have its specific metadata stored in a new satellite.

Discussion

Data vault modeling is seldom associated with data lakes in the literature, presumably because it is primarily associated with data warehouses. Yet, this approach ensures metadata schema evolutivity, which is required to build an efficient data lake. Another advantage of data vault modeling is that, unlike graph models, it can be intuitively implemented in a relational DBMS. However, several adaptations are still needed for this model to deal with data linkage as in graph models. Graph models, though requiring more specific storage systems such as RDF or graph DBMSs, are still advantageous because they allow to automatically enrich the lake with information that facilitate and enhance future analyses. Nevertheless, the three subcategories of graph models need to be all integrated together for this purpose. This remains an open issue because at most two of these graph approaches are simultaneously implemented in metadata systems from the literature [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF]20]. The MEDAL metadata model does include all three subcategories of graph models [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF], but is not implemented yet.

Metadata Generation

Most of the data ingestion tools from Section 3.2.1 can also serve to extract metadata. For instance, Suriarachchi and Plale use Apache Flume to retrieve data provenance in a data lake [START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF]. Similarly, properties and semantic metadata can be obtained through specialized protocols such as the Comprehensive Knowledge Archive Network (CKAN), an open data storage management system [START_REF] Terrizzano | Data Wrangling: The Challenging Journey from the Wild to the Lake[END_REF].

HUB_DATE

SAT_TITLE

Title

Last but not least, Apache Atlas [START_REF]The Apache Software Foundation: Apache Atlas -Data Governance and Metadata framework for Hadoop[END_REF], a widely used metadata framework [START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF], features advanced metadata generation methods through so-called hooks, which are native or custom scripts that rely on logs to generate metadata. Hooks notably help Atlas automatically extract lineage metadata and propagate tags on all derivations of tagged data.

Features of Data Lake Metadata Systems

A data lake made inoperable by lack of proper metadata management is called a data swamp [START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF], data dump [START_REF] Inmon | Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump[END_REF][START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF] or one-way data lake [START_REF] Inmon | Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump[END_REF], with data swamp being the most common terms. In such a flawed data lake, data are ingested, but can never be extracted. Thus, a data swamp is unable to ensure any analysis. Yet, to the best of our knowledge, there is no objective way to measure or compare the efficiency of data lake metadata systems. Therefore, we first introduce in this section a list of expected features for a metadata system. Then, we present a comparison of eighteen data lake metadata systems with respect to these features.

Feature Identification

Sawadogo et al. identify six features that a data lake metadata system should ideally implement to be considered comprehensive [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF].

1. Semantic Enrichment (SE) is also known as semantic annotation [START_REF] Hai | Constance: An Intelligent Data Lake System[END_REF] or semantic profiling [2]. It involves adding information such as title, tags, description and more to make the data comprehensible [START_REF] Terrizzano | Data Wrangling: The Challenging Journey from the Wild to the Lake[END_REF]. This is commonly done using knowledge bases such as ontologies [2]. Semantic annotation plays a vital role in data lakes, since it makes the data meaningful by providing informative summaries [2]. In addition, semantic metadata could be the basis of link generation between data [START_REF] Quix | Metadata Extraction and Management in Data Lakes With GEMMS[END_REF]. For instance, data objects with the same tags could be considered linked. 2. Data Indexing (DI) is commonly used in the information retrieval and database domains to quickly find a data object. Data indexing is done by building and enriching some data structure that enables efficient data retrieval from the lake. Indexing can serve for both simple keyword-based retrieval and more complex querying using patterns. All data, whether structured, semistructured or unstructured, benefit from indexing [START_REF] Singh | Visual Bayesian Fusion to Navigate a Data Lake[END_REF]. 3. Link Generation (LG) consists in identifying and integrating links between lake data. This can be done either by ingesting pre-existing links from data sources or by detecting new links. Link generation allows additional analyses.

For instance, similarity links can serve to recommend to lake users data close to the data they currently use [START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF]. In the same line, data links can be used to automatically detect clusters of strongly linked data [START_REF] Farrugia | Towards Social Network Analytics for Understanding and Managing Enterprise Data Lakes[END_REF]. 4. Data Polymorphism (DP) is the simultaneous management of several data representations in the lake. A data representation of, e.g., a textual document, may be a tag cloud or a vector of term frequencies. Semi-structured and unstructured data need to be at least partially transformed to be automatically processed [START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF]. Thus, data polymorphism is relevant as it allows to store and reuse transformed data. This makes analyses easier and faster by avoiding the repetition of certain processes [START_REF] Stefanowski | Exploring Complex and Big Data[END_REF].

5. Data Versioning (DV) expresses a metadata system's ability to manage update operations, while retaining the previous data states. It is very relevant to data lakes, since it ensures process reproducibility and the detection and correction of inconsistencies [START_REF] Bhattacherjee | RStore: A Distributed Multi-Version Document Store[END_REF]. Moreover, data versioning allows branching and concurrent data evolution [START_REF] Hellerstein | Ground: A Data Context Service[END_REF]. 6. Usage Tracking (UT) consists in managing information about user interactions with the lake. Such interactions are commonly creation, read and update operations. This allows to transparently follow the evolution of data objects.

In addition, usage tracking can serve for data security, either by explaining data inconsistencies or through intrusion detection. Usage tracking and data versioning are related, since update interactions often induce new data versions. However, they are distinct features as they can be implemented independently [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF][START_REF] Suriarachchi | Crossing Analytics Systems: A Case for Integrated Provenance in Data Lakes[END_REF].

Metadata System Comparison

We present in Table 2 a comparison of eighteen state-of-the-art metadata systems and models with respect to the features they implement [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF]. We distinguish metadata models from implementations. Models are indeed quite theoretical and describe the conceptual organization of metadata. In contrast, implementations follow a more operational approach, but are usually little detailed, mainly focusing on a description of the resulting system instead of the applied methodology. This comparison also considers metadata systems that are not explicitly associated with the concept of data lake by their authors, but whose characteristics allow to be considered as such, e.g., the Ground metadata model [START_REF] Hellerstein | Ground: A Data Context Service[END_REF].

The comparison shows that the most comprehensive metadata system with respect to the features we propose is MEDAL, with all features covered. However, it is not implemented yet. The next best systems are GOODS and CoreKG, with five out of six features implemented. However, they are black box metadata systems, with few details on metadata conceptual organization. Thus, the Ground metadata model may be preferred, since it is much more detailed and almost as complete (four out of six features).

Eventually, two of the six features defined in Section 4.4.1 may be considered advanced. Data polymorphism and data versioning are indeed mainly found in the most complete systems such as GOODS, CoreKG and Ground. Their absence from most of metadata systems can thus be attributed to implementation complexity.

Pros and Cons of Data Lakes

In this section, we account for the benefits of using a data lake instead of more traditional data management systems, but also identify the pitfalls that may correspond to these expected benefits.

An important motivating feature in data lakes is cheap storage. Data lakes are ten to one hundred times less expensive to deploy than traditional decisionoriented databases. This can be attributed to the usage of open-source technologies such as HDFS [START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF][START_REF] Stein | The enterprise data lake: Better integration and deeper analytics[END_REF]. Another reason is that the cloud storage often used to build data lakes reduces the cost of storage technologies. That is, the data lake owner pays only for actually used resources. However, the use of HDFS may still fuel System Type SE DI LG DP DV UT SPAR [START_REF] Fauduet | A data-first preservation strategy: Data management in spar[END_REF] [1] [55] Constance [START_REF] Hai | Constance: An Intelligent Data Lake System[END_REF] GEMMS [START_REF] Quix | Metadata Extraction and Management in Data Lakes With GEMMS[END_REF] ♦ CLAMS [START_REF] Farid | CLAMS: Bringing Quality to Data Lakes[END_REF] [54] ♦ [50] [START_REF] Farrugia | Towards Social Network Analytics for Understanding and Managing Enterprise Data Lakes[END_REF] GOODS [20] CoreDB [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF] Ground [START_REF] Hellerstein | Ground: A Data Context Service[END_REF] ♦ KAYAK [START_REF] Maccioni | KAYAK: A Framework for Just-in-Time Data Preparation in a Data Lake[END_REF] CoreKG [START_REF] Beheshti | CoreKG: A Knowledge Lake Service[END_REF] [9] ♦ [36] CODAL [START_REF] Sawadogo | Metadata Management for Textual Documents in Data Lakes[END_REF] MEDAL [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF] ♦ : Implementations ♦ : Metadata models : Model or implementation akin to a data lake Table 2 Comparison of data lake metadata systems [START_REF] Sawadogo | Metadata Systems for Data Lakes: Models and Features[END_REF] misconceptions, with the concept of data lake remaining ambiguous for many potential users. It is indeed often considered either as a synonym or a marketing label closely related to the HDFS technology [START_REF] Alrehamy | Personal Data Lake With Data Gravity Pull[END_REF][START_REF] Grosser | Hadoop and Data Lakes: Use Cases, Benefits and Limitations[END_REF].

Another feature that lies at the core of the data lake concept is data fidelity. Unlike in traditional decision-oriented databases, original data are indeed preserved in a data lake to avoid any data loss that could occur from data preprocessing and transformation operations [START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF][START_REF] Stein | The enterprise data lake: Better integration and deeper analytics[END_REF]. Yet, data fidelity induces a high risk of data inconsistency in data lakes, due to data integration from multiple, disparate sources without any transformation [START_REF] O'leary | Embedding AI and Crowdsourcing in the Big Data Lake[END_REF].

One of the main benefits of data lakes is that they allow exploiting and analyzing unstructured data [START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF][START_REF] Laskowski | Data lake governance: A big data do or die[END_REF][START_REF] Stein | The enterprise data lake: Better integration and deeper analytics[END_REF]. This is a significant advantage when dealing with big data, which are predominantly unstructured [START_REF] Miloslavskaya | Big Data, Fast Data and Data Lake Concepts[END_REF]. Moreover, due to the schema-on-read approach, data lakes can comply with any data type and format [START_REF] Cha | International Network Performance and Security Testing Based on Distributed Abyss Storage Cluster and Draft of Data Lake Framework[END_REF][START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF][START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF]33]. Thence, data lakes enable a wider range of analyses than traditional decision-oriented databases, i.e., data warehouses and datamarts, and thus show better flexibility and agility. However, although the concept of data lake dates back from 2010, it has only been put in practice in the mid-2010's. Thus, implementations vary, are still maturing and there is a lack of methodological and technical standards, which sustains confusions about data lakes. Finally, due to the absence of an explicit schema, data access services and APIs are essential to enable knowledge extraction in a data lake. In other words, a data access service is a must to successfully build a data lake [START_REF] Alrehamy | Personal Data Lake With Data Gravity Pull[END_REF][START_REF] Inmon | Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump[END_REF], while such a service is not always present.

Next, an acclaimed advantage of data lakes over data warehouses is real-time data ingestion. Data are indeed ingested in data lakes without any transformation, which avoids any time lag between data extraction from sources and their ingestion in the data lake [START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF][START_REF] Laskowski | Data lake governance: A big data do or die[END_REF]. But as a consequence, a data lake requires an efficient metadata system for ensuring data access. However, the problem lies in the "how", i.e., the use of inappropriate methods or technologies to build the metadata system can easily turn the data lake into an inoperable data swamp [START_REF] Alrehamy | Personal Data Lake With Data Gravity Pull[END_REF].

More technically, data lakes and related analyses are typically implemented using distributed technologies, e.g., HDFS, MapReduce, Apache Spark, Elasticsearch, etc. Such technologies usually provide a high scalability [START_REF] Fang | Managing Data Lakes in Big Data Era: What's a data lake and why has it became popular in data management ecosystem[END_REF][START_REF] Miloslavskaya | Big Data, Fast Data and Data Lake Concepts[END_REF]. Furthermore, most technologies used in data lakes have replication mechanisms, e.g., Elasticsearch, HDFS, etc. Such technologies allow a high resilience to both hardware and software failure and enforce fault tolerance [START_REF] John | Data Lake for Enterprises: Lambda Architecture for building enterprise data systems[END_REF].

Eventually, data lakes are often viewed as sandboxes where analysts can "play", i.e., access and prepare data so as to perform various, specific, on-the-fly analyses [START_REF] Russom | Data Lakes Purposes, Practices, Patterns, and Platforms[END_REF][START_REF] Stein | The enterprise data lake: Better integration and deeper analytics[END_REF]. However, such a scenario requires expertise. Data lake users are indeed typically data scientists [START_REF] Khine | Data Lake: A New Ideology in Big Data Era[END_REF]33], which contrasts with traditional decision systems, where business users are able to operate the system. Thus, a data lake induces a greater need for specific, and therefore more expensive, profiles. Data scientists must indeed master a wide knowledge and panoply of technologies.

Moreover, with the integration in data lakes of structured, semi-structured and unstructured, expert data scientists can discover links and correlations between heterogeneous data [START_REF] Ganore | Introduction To The Concept Of Data Lake And Its Benefits[END_REF]. Data lakes also allow to easily integrate data "as is" from external sources, e.g., the Web or social media. Such external data can then be associated with proprietary data to generate new knowledge through cross-analyses [START_REF] Laskowski | Data lake governance: A big data do or die[END_REF]. However, several statistical and Artificial Intelligence (AI) approaches are not originally designed for parallel operations, nor for streaming data, e.g., K-means or K-Nearest Neighbors. Therefore, it is necessary to readjust classical statistical and AI approaches to match the distributed environments often used in data lakes [START_REF] O'leary | Embedding AI and Crowdsourcing in the Big Data Lake[END_REF], which sometimes proves difficult.

Conclusion

In this survey paper, we establish a comprehensive state of the art of the different approaches to design, and conceptually build a data lake. First, we state the definitions of the data lake concept and complement the best existing one. Second, we investigate alternative architectures and technologies for data lakes, and propose a new typology of data lake architectures. Third, we review and discuss the metadata management techniques used in data lakes. We notably classify metadata and introduce the features that are necessary to achieve a full metadata system. Fourth, we discuss the pros and cons of data lakes. Fifth, we summarize by a mind map the key concepts introduced in this paper (Figure 10).

Eventually, in echo to the topics we chose not to address in this paper (Section 1), we would like to open the discussion on important current research issues in the field of data lakes.

Data integration and transformation have long been recurring issues. Though delayed, they are still present in data lakes and made even more challenging by big data volume, variety, velocity and lack of veracity. Moreover, when transforming such data, User-Defined Functions (UDFs) must very often be used (MapReduce tasks, typically). In ETL and ELT processes, UDFs are much more difficult to optimize than classical queries, an issue that is not addressed yet by the literature [START_REF] Stefanowski | Exploring Complex and Big Data[END_REF]. data storage solutions currently going beyond HDFS in data lakes, data interrogation through metadata is still a challenge. Multistores and polystores indeed provide unified solutions for structured and semi-structured data, but do not address unstructured data, which are currently queried separately through index stores. Moreover, when considering data gravity [33], virtual data integration becomes a relevant solution. Yet, mediation approaches are likely to require new, big data-tailored query optimization and caching approaches [START_REF] Quix | Data Lake[END_REF][START_REF] Stefanowski | Exploring Complex and Big Data[END_REF].

Unstructured datasets, although unanimously acknowledged as ubiquitous and sources of crucial information, are very little specifically addressed in data lake-related literature. Index storage and text mining are usually mentioned, but there is no deep thinking about global querying or analysis solutions. Moreover, exploiting other types of unstructured data but text, e.g., images, sounds and videos, is not even envisaged as of today.

Again, although all actors in the data lake domain stress the importance of data governance to avoid a data lake turning into a data swamp, data quality, security, life cycle management and metadata lineage are viewed as risks rather than issues to address a priori in data lakes [33]. Data governance principles are indeed currently seldom turned into actual solutions.

Finally, data security is currently addressed from a technical point of view in data lakes, i.e., through access and privilege control, network isolation, e.g., with Docker tools [START_REF] Cha | International Network Performance and Security Testing Based on Distributed Abyss Storage Cluster and Draft of Data Lake Framework[END_REF], data encryption and secure search engines [START_REF] Maroto | Data Lake Security -Four Key Areas to Consider When Securing Your Data Lake[END_REF]. However, beyond these issues and those already addressed by data governance (integrity, consistency, availability) and/or related to the European General Data Protection Regulation (GDPR), by storing and cross-analyzing large volumes of various data, data lakes allow mashups that potentially induce serious breaches of data privacy [START_REF] Joss | The Rise of the GDPR Data Lake[END_REF]. Such issues are still researched as of today.

Fig. 1

 1 Fig. 1 Issues addressed in this paper

Fig. 2

 2 Fig. 2 Data flow in a pond architecture

Fig. 3

 3 Fig.3Zaloni's zone architecture[START_REF] Laplante | Architecting Data Lakes Data Management Architectures for Advanced Business Use Cases[END_REF]

Fig. 4

 4 Fig. 4 Architecture typology proposal

Fig. 6

 6 Fig. 6 Data lake and data warehouse architecture

Fig. 7

 7 Fig.7Functional metadata model[START_REF] Diamantini | A New Metadata Model to Uniformly Handle Heterogeneous Data Lake Sources[END_REF]

Fig. 8

 8 Fig. 8 Sample graph-based metadata models

Fig. 10

 10 Fig. 10 Key concepts investigated in this survey

Table 1

 1 Comparison of Oram's and Sawadogo et al's metadata categories

	Type of information	Functional metadata Structural metadata
	Basic characteristics of data
	(size, format, etc.)
	Data semantics
	(tags, descriptions, etc.)
	Data history
	Data linkage
	User interactions

Acknowledgement

The research accounted for in this paper was funded by the Université Lumière Lyon 2 and the Auvergne-Rhône-Alpes Region through the COREL and AURA-PMI projects, respectively. The authors also sincerely thank the anonymous reviewers of this paper for their constructive comments and suggestions.

A second kind of technologies is more specific to metadata generation. For instance, Apache Tika helps detect the MIME type and language of objects [START_REF] Quix | Metadata Extraction and Management in Data Lakes With GEMMS[END_REF]. Other tools such as Open Calais and IBM's Alchemy API can also enrich data through inherent entity identification, relationship inference and event detection [START_REF] Farid | CLAMS: Bringing Quality to Data Lakes[END_REF].

Ad-hoc algorithms can also generate metadata. For example, Singh et al. show that Bayesian models allow detecting links between data attributes [START_REF] Singh | Visual Bayesian Fusion to Navigate a Data Lake[END_REF]. Similarly, several authors propose algorithms to discover schemas or constraints in semistructured data [START_REF] Beheshti | CoreDB: a Data Lake Service[END_REF][START_REF] Klettke | Uncovering the Evolution History of Data Lakes[END_REF][START_REF] Quix | Metadata Extraction and Management in Data Lakes With GEMMS[END_REF].


Mohamed Touaibia
email: mohamed.touaibia@umoncton.ca

Anne-Sylvie Fabiano-Tixier
email: anne-sylvie.fabiano@univ-avignon.fr

Farid Chemat
email: farid.chemat@univ-avignon.fr

Chloropinane and Chloromenthene as Novel Solvents for Solubilisation of Natural Substances

Keywords: biobased solvents, extraction, chloropinane, chloromenthene, pinene, limonene, menthene

Chloropinane and chloromenthene, synthesized from pinene and limonene, respectively, were compared with their non-halogenated analogs and n-hexane for their ability to solubilize natural products of interest such as β-carotenoids, vanillin, and rosmarinic acid. Chloropinane was six times more efficient than hexane for β-carotene solubilization. Chloromenthene was 15 times better than hexane. Vanillin was 20 times more soluble in chloropinane than in hexane. Chloropinane and chloromenthene were 3.5 and 2 times more efficient than hexane for rosmarinic acid solubilization. Obtained from pinene and limonene, two very abundant natural products, and even from their waste byproducts, chloropinane and chloromenthene can be an alternative to solvents from nonrenewable resources.

Introduction

Solvents are essential for chemical synthesis, for the extractions of bioactive compounds, and for all separations and purifications of mixtures of compounds. However, most if not the majority of solvents are hydrocarbons derived from fossil resources and are considered hazardous and toxic [START_REF] Tobiszewski | A solvent selection guide based on chemometrics and multicriteria decision analysis[END_REF][START_REF] Prat | A survey of solvent selection guides[END_REF]. In a previous study, we showed the potential of pinane as an alternative solvent for the extraction of natural products. Cis-rich pinane (cis/trans: 7/3) solvent was prepared for the first time by a solvent-free catalytic hydrogenation of α/β-pinene or turpentine oil [START_REF] Varón | Solvent from forestry biomass. Pinane a stable terpene derived from pine tree byproducts to substitute n-hexane for the extraction of bioactive compounds[END_REF][START_REF] Selka | A Comparative Study of Solvent-Free and Highly Efficient Pinene Hydrogenation over Pd on Carbon, Alumina, and Silica Supports[END_REF][START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF]. Solubilization simulations with Conductor like Screening Model Realistic Solvation (COSMO-RS) software [START_REF] Klamt | Prediction of the mutual solubilities of hydrocarbons and water with COSMO-RS[END_REF] of some natural products have revealed that pinane compares very well with n-hexane and may be an alternative to this fossil-based solvent. When compared experimentally with n-hexane, cis-pinane solubilized 42, 2, and 3 times more of b-carotene, vanillin, and rosmarinic acid, respectively [START_REF] Varón | Solvent from forestry biomass. Pinane a stable terpene derived from pine tree byproducts to substitute n-hexane for the extraction of bioactive compounds[END_REF][START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF]. Obtained through limonene's partial and total hydrogenation under various catalytic conditions, menthene, and menthane were also compared to n-hexane [START_REF] Moutombi | Partial and Total Solvent-Free Limonene's Hydrogenation: Metals, Supports, Pressure, and Water Effects[END_REF]. While COSMO-RS software predicted a comparable solubilization of these β-carotene, vanillin, and rosmarinic acid for the menthene, menthane, and menthene/menthane mixture, experimental assays revealed that menthene solubilizes β-carotene, vanillin, and rosmarinic acid three to five times better than n-hexane [START_REF] Moutombi | Partial and Total Solvent-Free Limonene's Hydrogenation: Metals, Supports, Pressure, and Water Effects[END_REF].

As part of our continuing interest in biobased solvents as potential sustainable and green solvents, we were interested to the halogenated analogs of pinane and menthene for comparison with their non-halogenated analogs and n-hexane. Halogenated solvents may have the advantage of extracting more products due to the greater affinity of the molecules for these solvents. In this study, chloropinane and chloromenthene were synthesized to be compared with pinane, menthene, and n-hexane for the extraction of bioactive compounds. To the best of our knowledge, chloropinane and chloromenthene have never been investigated as solvents for the extraction of natural products.

Results and Discussion

Synthesis

Chloropinane (2) and chloromenthene (4) were synthesized as depicted in Scheme 1 as reported by Beckmann et al. and De Mattos et al. with slight modifications [START_REF] Beckmann | Synthesis and structure of some cis-and trans-myrtanylstannanes[END_REF][START_REF] De Mattos | A Convenient and Simplified Preparation of Both Enantiomers of?-Terpinyl Chloride[END_REF]. Chloropinane (2) was obtained from β-pinene which was transformed into myrtenol to subsequently be halogenated (Scheme 1). Chloromenthene (4) was obtained by halogenation of limonene (Scheme 1). Cis rich-pinane and menthene were synthesized through a solvent free hydrogenation over Pd/C and Ru/C as reported in our previous contributions [START_REF] Varón | Solvent from forestry biomass. Pinane a stable terpene derived from pine tree byproducts to substitute n-hexane for the extraction of bioactive compounds[END_REF][START_REF] Selka | A Comparative Study of Solvent-Free and Highly Efficient Pinene Hydrogenation over Pd on Carbon, Alumina, and Silica Supports[END_REF][START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF][START_REF] Moutombi | Partial and Total Solvent-Free Limonene's Hydrogenation: Metals, Supports, Pressure, and Water Effects[END_REF].

Prediction of Solubilization with COSMO-RS

The COSMO-RS simulation was conducted to evaluate the potential of pinane, chloropinane (2), cis-pinane (3), chlorolimonene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF], menthane [START_REF] Klamt | Prediction of the mutual solubilities of hydrocarbons and water with COSMO-RS[END_REF], and n-hexane for the solubilization of β-carotenoids, vanillin, and rosmarinic acid. COSMO-RS integrates a quantum chemistry approach that allows the calculation of various properties as the relative solubility of a compound in several solvents. The analysis of the σ-profile and σ-potential of the components in the mixture (compounds and solvents) gives important information about the molecules that can be used to predict possible interactions in the fluid phase. Table 1 shows the COSMO-RS results. Predictions indicate that chloropinane (2) solubilizes 60% fewer catenoids than cispinane (3), its non-halogenated analogue. However, chloromenthene (5) solubilizes the same proportion as menthene (6) (Table 1). For the solubilization of carotenoids, the predictions point to hexane as the best solvent followed by cis-pinane (3).

For vanillin, chloropinane (2) is predicted to solubilize two times more vanillin than its non-halogenated analogue while chloromenthene (5) solubilizes 3 times more vanillin than menthene (6) (Table 1).

Chloropinane (2) and chloromenthene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF] were predicted to outperform hexane 3 to 5 times, respectively, for vanillin solubilization (Table 1).

For rosmarinic acid, chloropinane (2) was predicted to be a better solvent than its non-halogenated analogue. This trend appears to be reversed with chloromenthene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF] since it was predicted to be a poorer solvent than menthene (6) (Table 1). Among the five solvents compared, menthene (6) would be the best solvent for the solubilization of rosmarinic acid (Table 1).

Solubility of β-Carotene, Vanillin, Rosmarinic Acid

The solubility of each compound in these different solvents at room temperature was realized by bead milling. Table 2 shows the solubility of carotenoids, vanillin, and rosmarinic acid in the five compared solvents. The results are expressed in solubility in g/L. The results are in agreement with the COSMO-RS prediction. The extraction of carotenoids depends on the solvent used, its polarity, and their solubility in the extraction solvents. Further, the solubility of carotenoids is related to physical and chemical properties, molecular structure and the nature of material particles, and operating conditions such as temperature, pressure, and density of solvents, which must be considered [START_REF] Arvayo-Enríquez | Carotenoids extraction and quantification: A review[END_REF]. Considering the solubility of carotenoids, we evaluated the solubility of β-carotene with the five investigated solvents.

The highest carotenoids solubility was observed in the cis-pinane (3) as predicted by COSMO-RS (Table 1). Chloropinane (2) was six times less efficient than its non-halogenated analogue. However, it was six times more efficient than hexane for β-carotene solubilization (Table 2). Unlike chloropinane (2), chloromenthene (5) was 5 times better than its nonhalogenated analogue and 15 times better than hexane (Table 2).

Vanillin was significantly better solubilized in chloropinane (2) than all other solvents including hexane (Table 2). Vanillin was over 9 times more soluble in chloropinane (2) than in cis-pinane (3) and 20 times more soluble in chloropinane (2) than in hexane (Table 2).

Chloromenthene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF] was the least efficient of all solvents including hexane for the solubilization of vanillin. Compared to menthene (6), chloromenthene (5) was 14 times less efficient for the solubilization of vanillin (Table 2).

For the solubilization of rosmarinic acid, chloropinane (2) and menthene (6) were the best solvents. These two solvents were 3.5 and 3.8 more efficient than hexane (Table 2). Chloropinane (2) was 10 times more efficient than cis-pinane, which confirms the affinity of certain molecules for halogenated solvents. On the other hand, chloromenthene (5) was half as good as its non-hydrogenated analogue (Table 2).

Energy Efficiency

Energy efficiency is a crucial point in a green chemical process (Green Chemistry Principle #6 [START_REF] Anastas | Green Chemistry: Principles and Practice[END_REF]). The extraction must also follow this same principle to be considered green. Beyond the solubility of products in solvents, the energy required for the evaporation of these solvents must be part of the equation. The enthalpy of vaporization of 1 kg of the solvent (E vap ) for the investigated solvent was calculated using specific heat, latent heat of vaporization, and the boiling point [START_REF] Sicaire | Alternative Bio-Based Solvents for Extraction of Fat and Oils: Solubility Prediction, Global Yield, Extraction Kinetics, Chemical Composition and Cost of Manufacturing[END_REF].

As shown in Table 3, chloropinane (2) and chloromenthene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF] required almost 30% less energy to be vaporized compared to n-hexane which is a good energy gain.

Materials and Methods

Chemistry

All chemicals used were purchased from Aldrich (CA) (Manufactor, St. Louis, MI, USA) and used without further purification. FTIR spectra were recorded on a Cary 630 spectrometer (Agilent, Santa Clara, CA, USA). NMR spectra were recorded on Bruker ® Avance III 400 MHz spectrometer (Bruker, Billerica, MA, USA) using TMS as an internal standard. High-resolution mass measurements were performed on Bruker ® Daltonics' micrOTOF (Bruker, Billerica, MA, USA) instrument in positive or negative electrospray. ( 1 H-NMR, FTIR, 13 C-NMR, and HRMS spectra: see Supplementary Materials).

Synthesis of Chloropinane (2)

To a solution of sodium borohydride (4.2 g, 0.11 mol) in THF (150 mL), β-pinene (30 g, 0.22 mol) was added at 0 • C. A solution of dimethyl sulfate (13.8 g, 0.11 mol) in THF (50 mL) was added dropwise to the reaction mixture over a period of 10 min at 0 • C and the reaction mixture was stirred for 12 h at r.t. Water (100 mL), 3 M NaOH (100 mL), and 30% H 2 O 2 (100 mL) were added to the mixture cooled at 0 • C. The solution was stirred for 3 h followed by the addition of Et 2 O (150 mL). The aqueous phase was extracted with Et 2 O (3 × 50 mL). The combined organic phases were washed with water (3 × 100 mL) and brine (3 × 100 mL), dried over MgSO 4 , and concentrated under vacuum. To the obtained crud myrtenol dissolved in carbon tetrachloride (300 mL),triphenylphosphine (115 g, 0.44 mol) were added and the solution was refluxed for 24 h. Hexane (200 mL) was added to the reaction mixture, which was then cooled in an ice bath. The triphenylphosphine oxide which precipitated was filtered off under vacuum. The filtrate was then stored in the fridge for 24 h to precipitate the remaining triphenylphosphine oxide followed by a last filtration and solvent removal under vacuum. Fractional distillation afforded the desired chloropinane ( 2

Synthesis of Chloromenthene (5)

To a stirred solution of (R)-(+)-limonene (5 g, 36.7 mmol) in CH 2 Cl 2 (50 mL), Si0 2 (5 g) was added. The suspension was then stirred at room temperature for 15 min. A solution of SOCl 2 (2.17 g, 18.4 mmol, 0.5 eq) in CH 2 Cl 2 (5 mL) was added dropwise to the reaction mixture over a period of 10 min at 0 • C. The mixture was then stirred for 12 h at room temperature. The SiO 2 was filtered and washed with CH 2 C1 2 (3 × 10 mL). To avoid any emulsion, the filtrate was evaporated and dissolved in EtOAC (100 mL) and then filtered. The EtOAc solution was washed with saturated aqueous solution of NaHCO 3 (3

Prediction of Solubility

Solubility parameters of pinane, chloropinane, menthene, chlorolimonene, and nhexane to dissolve beta-carotene, vanillin, and rosmarinic acid were investigated using COSMO-RS software. The chemical structures of the solvents and solutes were transformed by JChemPaint version 3.3 (GitHub Pages, San Francisco, CA, USA) to their simplified molecular input line entry syntax (SMILES) notations, which were subsequently used to calculate the solubility parameters of solvents and compounds.

The Conductor-like Screening Model for Real Solvents (COSMO-RS) uses a statistical thermodynamic approach based on the result of quantum chemical calculations for an understanding of the dissolving mechanism. COSMO-RS combines quantum chemical considerations and statistical thermodynamics to determine and predict the thermodynamic properties without experimental data. The COSMO-RS developed by Klamt is known as a powerful method for molecular description and solvent screening based on a quantum-chemical approach [START_REF] Klamt | Prediction of the mutual solubilities of hydrocarbons and water with COSMO-RS[END_REF].

COSMO-RS is a two-step procedure including microscopic and macroscopic steps. In the first step, the COSMO model is applied to simulate a virtual conductor environment for the molecule of interest. The molecule is embedded into a virtual conductor. In such an environment, the molecule induced polarization charge density is on its surface. Thus, during the quantum calculation self-consistency algorithm the solute molecule is converged to its energetically optimal state in the conductor with respect to its electron density and geometry. The standard quantum chemical methods, triple zeta valence polarized basis set (TZVP), were used in this study.

The second step used the statistical thermodynamic calculation. This polarization charge density was used for the quantification of the interaction energy of the pair-wise interacting surface segments with regard the most important molecular interaction modes, i.e., electrostatics and hydrogen bonding. The 3D distribution of the polarization charges on the surface of each molecule was converted into a surface composition function (σprofile). Such a σ-profile provided detailed information about the molecular polarity distribution. The thermodynamics of the molecular interactions that were based on the obtained σ-profile were then used to calculate the chemical potential of the surface segment (σ-potential) using the COSMOthermX program (version C30 release 13.01). The σ-potential described the likeliness of the compound being able to interact with the solvents with polarity and hydrogen bonds. The part of the negative charge of the molecule was located on the right side (acceptor hydrogen bonds) with positive σ values, while the part of the positive charged was located on the left side (donor hydrogen bonds) with negative σ values. Generally, the region σ ± 0.01 e/A2 was considered to be non-polar or weakly polar. The σ-profile and the σ-potential were used for interpreting the affinity of the solvent for surface polarity, to understand the interaction between the compound and solvent in mixed state and to estimate the thermodynamic properties of the system. In addition, the COSMOthermX also allows the determination of the relative solubility between the solid compound and the liquid solvent in terms of the logarithm of the solubility converted to solubility in g/L.

Test of Solubility

Solubilization by bead milling was performed using Precellys 24 (Bertin Technology, Ozyme, Montigny-le-Bretonneux, France) operating in a 2 mL tube with 1 g of ceramic beads. An amount of 100 mg of compounds was mixed with 1 mL of the investigated solvent and submitted in a drive tube operating at 6500 rpm during intervals of 2 × 20 s. After extraction, the beads were filtered before solid/liquid separation by centrifugation. The samples were stored at -20 • C until analysis. All experiments were carried out in triplicate.

The total content of each compound was measured spectrophotometrically (Biochrom Libra S22 UV/Vis Spectrophotometer, Cambridge, United Kingdom) in a 1 cm optical pathlength quartz cell at the maximum wavelength of each compound in each extract using DMSO as a blank. The Beer-Lambert law was used to determine the carotenoid, vanillin, and rosmarinic acid concentration in each extract using a calibration curve prepared using β-carotene, vanillin, and rosmarinic acid standard. The straight calibration curve of absorbance versus compound concentration (mgL -1 ) was reliant on the Beer-Lambert law. Finally, the quantity of compound dissolve in each solvent was calculated and expressed as g/L.

Conclusions

In the present communication, chloropinane (2) and chloromenthene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF], which can be obtained from pinene and limonene, two products derived from plant biomass and more especially byproducts, were investigated as potential biobased-solvents for the extraction of β-carotenoids, vanillin, and rosmarinic acid.

Compared to their non-halogenated analogs and n-hexane, chloropinane (2) and chloromenthene [START_REF] Moutombi | Highly selective solvent-free hydrogenation of pinenes to added-value cis-pinane[END_REF] have shown a good ability to serve as non-fossil origin solvents. Prediction tests as well as experimental solubility tests of β-carotenoids, vanillin, and rosmarinic acid have shown that these halogenated products have the potential to replace n-hexane for the extraction of such natural products.

The synthesis method of the two chloro-derivatives could be optimized and improved with less carbon footprint to ideally be as green as possible. This first investigation of these solvents does not clearly prove their green and sustainable character. Safety studies regarding their bioaccumulation potential and their ecotoxicological profile will be necessary.

Scheme 1 .

 1 Scheme 1. (i) (1) NaBH 4 , Me 2 SO 4 , THF, 24 h, rt. (2) NaOH, H 2 O 2 , 12 h, rt. (3) PPh 3 , CCl 4 . 24 h, reflux; (ii) SOCl 2 , SiO 2 , CH 2 Cl 2 , 12 h, rt; (iii) Pd/C, 2.75 MPa, rt; (iv) Pd/Al 2 O 3 , H 2 O, 2.75 MPa, rt.

  × 50 mL), water (3 × 50 mL), and brine (2 × 25 mL), then dried over MgS0 4 and concentrated under vacuum. Fractional distillation afforded the desired chloromenthene (5) (4-(2-chloropropan-2-yl)-1-methylcyclohexene) as pale-yellow viscous liquid. Yield: 3.3 g (52%), B.p. = 47-48

Table 1 .

 1 Solubility prediction of β-carotenoids, vanillin, and rosmarinic acid.

	Solvent	β-Carotene (g/L)	Vanillin (g/L)	Rosmarinic Acid (g/L)
	Chloropinane (2)	0.53687	0.008651508	5.08677 × 10 -9
	Cis-pinane (3)	0.892240611	0.003535516	2.8593 × 10 -10
	Chloromenthene (5)	0.53687	0.012689957	2.11912 × 10 -8
	Menthene (6)	0.53687	0.00429	6.9545 × 10 -7
	n-Hexane	0.916261686	0.002447161	5.14395 × 10 -11

Table 2 .

 2 Solubility of β-caroten, vanillin, and rosmarinic acid.

	Solvent	β-Caroten (g/L)	Vanillin (g/L)	Rosmarinic Acid (g/L)
	Chloropinane (2)	6.3 ± 0.14	23.85 ± 0.62	1.89 ± 0.07
	Cis-pinane (3)	42.7 ± 2.5	2.5 ± 0.03	0.185 ± 0.003
	Chloromenthene (5)	15.68 ± 0.26	0.43 ± 0.02	1.09 ± 0.04
	Menthene (6)	3.55 ± 0.10	6.07 ± 0.25	2.11 ± 0.18
	n-Hexane	0.99 ± 0.06	1.19 ± 0.09	0.54 ± 0.01

Table 3 .

 3 Energy efficiency.

	Energy Efficiency a	Chloropinane (2)	Pinane (3)	Chloromenthene (5)	Menthene (6)	Hexane
	∂Hvap. (kJ/mol) at boiling point	42.9	37.7	43.2	39.5	28.9
	E of vaporization (E vap ) (kJ/kg)	248	273	250	286	343
	E vap compared to hexane (%)	-28	-20	-27	-17	-

a Predictive values obtained from: https://ilab.acdlabs.com/ilab2/, accessed on (March 2021).

  • C/1.5 mmHg. IR: v 2972, 2929, 2836, 1455, 1440, 1386, 1369, 1224, 1118, 801, 786 cm -1 . 1 H-NMR (400 MHz, CDCl 3 , 25 • C); δ (ppm): 5.39 (s, 1H), 2.11-2.69 (m, 1H), 2.06-2.01 (m, 3H), 1.99-1.90 (m, 1H), 1.79-178 (m, 1H), 1.67 (s, 3H), 1.61 (s, 3H), 1.56 (s, 3H), 1.46-1.38 (m, 1H). 13 C-NMR (101 MHz, CDCl 3 , 25 • C); δ (ppm): 133.94, 120.12, 74.62, 46.47, 30.91, 30.71, 29.74, 27.44, 24.81, 23.24. MS (m/z) 172, 174, 136, 121, 107, 93, 67.

Molbank 2021, 2021, M1205. https://doi.org/10.3390/M1205 https://www.mdpi.com/journal/molbank

Funding: This research received funding from the Natural Sciences and Engineering Research Council of Canada (NSERC).

Institutional Review Board Statement: Not applicable.

Informed Consent Statement: Not applicable.

Data Availability Statement: Data are contained within the article or supplementary material.

Acknowledgments: M.T. thanks J.A. Doiron for his help during the distillation of the two synthesized products and F.J. Ndongou Moutombi for her help with the MS analyses.

Conflicts of Interest:

The authors declare no conflict of interest.