Nothing Special   »   [go: up one dir, main page]

WO2024122709A1 - 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버 - Google Patents

워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버 Download PDF

Info

Publication number
WO2024122709A1
WO2024122709A1 PCT/KR2022/020508 KR2022020508W WO2024122709A1 WO 2024122709 A1 WO2024122709 A1 WO 2024122709A1 KR 2022020508 W KR2022020508 W KR 2022020508W WO 2024122709 A1 WO2024122709 A1 WO 2024122709A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
query
workspace
data processing
processing
Prior art date
Application number
PCT/KR2022/020508
Other languages
English (en)
French (fr)
Inventor
이상수
임정택
윤준영
조설진
Original Assignee
스마트마인드 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 스마트마인드 주식회사 filed Critical 스마트마인드 주식회사
Publication of WO2024122709A1 publication Critical patent/WO2024122709A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the work space hub may be divided into a shared work space hub and a dedicated work space hub depending on whether the data processing engine and the processing resources are shared.
  • Figure 8 is a conceptual diagram showing a resource distribution algorithm according to an embodiment of the present invention.
  • Figure 13 is a conceptual diagram showing a query processing method of a shared workspace hub according to an embodiment of the present invention.
  • Nested query 230 is a mixed query for structured data 210 and unstructured data 220, enabling sequential or complex processing of structured data 210 and unstructured data 220 stored in the database. can do.
  • the data processing system may perform individual processing for each of structured data and unstructured data.
  • the data processing system may be implemented to receive unstructured data processing queries and structured data processing queries, and process the unstructured data processing queries and structured data processing queries.
  • An unstructured data processing query may be a query for processing only unstructured data
  • a structured data processing query may be a query for processing only structured data.
  • Figure 3 is a conceptual diagram showing a data processing system for processing structured data and unstructured data on one platform according to an embodiment of the present invention.
  • a nested query for processing unstructured data and structured data may be input as the input query 300.
  • Search syntax can be used to search for content, meaning, or similarity in unstructured data.
  • search image data, audio data, and video data based on keywords or text based on an unstructured data table created based on the above query syntax.
  • search image data, audio data, and video data based on image data, audio data, and video data.
  • a user can use the "BUILD MODEL" syntax to create a movie recommendation model that recommends movies.
  • the "EVALUATE" syntax can be used to evaluate the classification model that the user created in Learning a Model.
  • FIT MODEL a user can retrain a previously created model using a newly added dataset.
  • the movie recommendation model that the user created in model training based on the "DELETE MODEL" statement may be deleted from the database.
  • AI modeling based on unstructured data and structured data can be performed on a single platform, a data processing system, without a separate batch process.
  • a pre-generated AI model and an AI model created by a user may be located.
  • various AI models such as classification models, regression models, recommendation systems, and voice recognition models can be created.
  • Figure 6 is a conceptual diagram showing a data processing method based on a data processing system according to an embodiment of the present invention.
  • processing of structured data and unstructured data may be performed based on the data processing system's own database.
  • the user can use the user's database and utilize the functions of the extended SQL and extended SQL engine provided by the data processing system based on the API.
  • the processing of structured and unstructured data based on the data processing system's own database can be expressed in the term internal data processing.
  • the processing of structured and unstructured data based on an external database rather than the data processing system's own database can be expressed in the term external data processing.
  • external data In order to use the data processing system according to an embodiment of the present invention from the outside for external data processing, external data must be stored and converted into the data processing system of the present invention using the provided 'API' or 'data transfer method'.
  • the data processing system of the present invention can be utilized using the API. That is, both the internal engine and the PostgreSQL engine can perform data processing by accessing the database according to the embodiment of the present invention rather than an external database.
  • users can perform learning based on separate unstructured data stored in the user's database based on the functions of extended SQL and extended SQL engine through API.
  • a specific user may be a security company and operate a user database that stores CCTV footage.
  • users can perform artificial intelligence learning on CCTV images based on data stored in the user database.
  • Structured data and unstructured data can be inserted from an external database into the database of the data processing system of the present invention based on a query statement for unstructured data for processing structured data and unstructured data defined in the present invention.
  • AI modeling for structured data and unstructured data input to the data processing system according to an embodiment of the present invention can be performed based on the AI engine of the data processing system according to an embodiment of the present invention.
  • the method of processing structured data and unstructured data on a plurality of different databases includes the steps of a data processing system receiving external data from an external database, the data processing system converting the external data, and the data processing system converting the external data. It may include processing the external data.
  • the external data includes structured data and unstructured data
  • the data processing system processes structured data and unstructured data based on nested queries
  • the nested query is the first query for unstructured data and the second query for structured data. It may be a mixed query of 2 queries.
  • a data processing system can process unstructured data based on unstructured data processing queries, and the data processing system can process structured data based on structured data processing queries.
  • a nested query is a query that combines a first query for unstructured data and a second query for structured data
  • an unstructured data processing query is a query for processing only the unstructured data
  • a structured data processing query is a query for processing only structured data. It could be a query for
  • the data processing system creates data tables for structured data and data tables for unstructured data and processes them in one database, and the data processing system supports artificial intelligence engine modeling based on structured data and unstructured data in one database. You can.
  • Figure 7 is a conceptual diagram showing a method of analyzing queries and processing data in a data processing system according to an embodiment of the present invention.
  • a method that analyzes an input query and processes unstructured data and structured data in one data processing system, but utilizes different processing resources when processing the query.
  • a query for processing unstructured data and/or structured data may be input as an input query.
  • the entered query may be a general query for unstructured data or structured data, or a nested query for mixed processing of unstructured data and structured data.
  • the input query may be parsed through the parser 700.
  • Nested queries are divided into general queries and extended queries, and the parser unit 700 can split the general queries and extended queries.
  • a plurality of queries included in the input query may be analyzed and processed through the cloud analyzer 710 and the query tree 720.
  • a nested query is input as an input query, and the nested query may include a first query 715, a second query 725, and a third query 735.
  • the cloud analyzer 710 may determine which computing resources should be used to process the first query 715, second query 725, and third query 735. More specifically, the cloud analyzer 710 can determine whether the query should be executed on the CPU 770 or the GPU 780 through analysis of a plurality of queries included in the nested query.
  • the cloud analyzer 710 determines the expected execution efficiency and expected execution speed of each of a plurality of queries based on the resource distribution algorithm according to an embodiment of the present invention, and determines the expected execution efficiency and expected execution speed of the plurality of queries based on the expected execution efficiency and expected execution speed.
  • Each can be assigned to the CPU 770 or GPU 780.
  • first query 715 and the third query 735 are extended queries
  • the second query 725 is a general query.
  • the first query 715 and the third query 735 can be processed based on the extended SQL engine 760
  • the second query 725 is a general query
  • the PostgreSQL engine (750) is a SQL engine for general query processing. ) can be processed based on.
  • the first query 715 may be processed based on the GPU 780
  • the third query 735 may be processed based on the CPU 770
  • the second query 725 may be processed based on the GPU 780.
  • the processing speed of nested queries is improved and computing resources can be utilized more efficiently.
  • This resource distribution algorithm can be applied and utilized to both the PostgreSQL engine (750), a SQL engine for general queries, and the extended SQL engine (760) for extended queries, and modeling is also performed using GPU, providing fast modeling results. can be derived.
  • Figure 8 is a conceptual diagram showing a resource distribution algorithm according to an embodiment of the present invention.
  • a method for determining whether to use the CPU 860 or the GPU 850 when processing an extended query 800 and a general query 820 is disclosed.
  • the first type expansion query 803 which must be processed based on a model that essentially requires the use of the GPU 850 on the expansion engine, can be processed based on the GPU 850.
  • the second type extended query 806, which can be processed without necessarily using the GPU 850 on the expansion engine, is processed by the CPU 860 or It can be processed based on GPU 850.
  • CPU execution ability can be determined based on query processing speed, resource usage, and query cost when processing queries based on CPU.
  • GPU execution ability can be determined based on query processing speed, resource usage, and query cost when processing queries based on GPU.
  • the query cost to determine CPU execution ability is determined based on data processing volume (row processed) and CPU operation cost
  • the query cost to determine GPU execution ability is determined based on data processing volume (row processed) and GPU operation cost. You can. The faster the query processing speed is, the resource usage is relatively small, and the query cost is relatively small, the higher the execution ability can be judged.
  • General queries can be processed based on CPU or GPU, considering CPU execution ability and GPU execution ability among computing resources.
  • CPU execution ability and GPU execution ability for extended queries and general queries can be determined by considering the overall cost. The smaller the overall cost, the more advantageous the resource may be.
  • the total cost may be the sum of the startup cost and run cost.
  • Startup cost may be a cost incurred before the first tuple is fetched.
  • a tuple is a collection of attribute values related to a given list in a database.
  • the startup cost of an index scan node is the cost of reading an index page to access the first tuple of the target table.
  • the run cost may be the cost of accessing all tuples.
  • CPU run cost and GPU run cost can be determined as shown in the equation below.
  • GPU run cost (gpu_tuple_cost + gpu_operator_cost) x N tuple + seq_page cost x N page
  • CPU run cost (cpu_tuple_cost + cpu_operator_cost) x N tuple + seq_page cost x N page
  • gpu_tuple_cost is the cost of GPU processing table rows during operation.
  • gpu_operator_cost is the cost for the GPU to process table tuples as operators or functions.
  • cpu_tuple_cost is the cost for the CPU to process table rows during operation.
  • cpu_operator_cost is the cost for the CPU to process table tuples as operators or functions.
  • N_tuple is the number of table tuples.
  • seq_page cost is the cost of retrieving a page.
  • N page is the number of index pages.
  • Figure 9 is a conceptual diagram showing a data processing system that processes input multi-query according to an embodiment of the present invention.
  • FIG. 9 discloses a method of scheduling processing of a plurality of queries included in the input multi-query based on a multi-query scheduler when receiving the input multi-query.
  • the input multi-query 900 may be a query including a plurality of queries.
  • the input multi-query 900 may include a first query, a second query, a third query, and a fourth query.
  • the first query may be SELECT
  • the second query may be BUILD
  • the fourth query may be PRINT.
  • the multi-query scheduler 920 may include a multi-query analyzer 940 and a query queue 960.
  • the multi-query analysis unit 920 may analyze a plurality of queries included in the input multi-query 900 and determine the processing order of the plurality of queries.
  • the query queue 960 may schedule a plurality of queries on the queue by considering the processing order of the plurality of queries determined by the multi-query analysis unit 920.
  • Queries scheduled on the queue can be delivered to the parser unit. Thereafter, as in the above-mentioned procedure, the query may be parsed by the parser unit, divided into a general query and an extended query, and interpreted and processed through the cloud analyzer unit and the query tree unit.
  • the cloud analysis unit can determine the engine to process the query and the computing resource (CPU or GPU) to process the query and transfer it to the determined engine (PostgreSQL engine or extension engine) for processing.
  • Figure 10 is a conceptual diagram showing the operation of a multi-query scheduler according to an embodiment of the present invention.
  • the multi-query scheduler 1000 analyzes the dependency score 1020 and computing resource allocation data 1040 for an input query that comes in the form of a multi-query, and calculates the dependency score 1020 and computing resource allocation. Based on the data 1040, the processing order of a plurality of queries included in the input multi-query can be determined.
  • the dependency score 1020 may be determined through cross-correlation between a plurality of queries included in the input multi-query. For example, if the third query is dependent on results processed based on the first query and the second query, the third query may be a query that has dependency on the first query and the second query. When the fourth query is processed independently, the fourth query may be a query that has no dependency on other queries.
  • the dependency score 1020 may be determined for a query that can be performed after processing another query, and may have a relatively high value as the dependency on other queries increases.
  • Computing resource allocation data 1040 may be data about whether the query will be processed based on CPU or GPU processing units, and if the query is processed based on CPU or GPU, computing resources to be allocated.
  • the multi-query scheduler 1000 may determine whether a query will be processed based on which processing unit, CPU or GPU, based on the resource distribution algorithm described above.
  • the multi-query scheduler 1000 can obtain data on allocated computing resources when a query is processed based on CPU or GPU based on the method for determining CPU execution ability and GPU execution ability described above. .
  • CPU execution ability can be determined based on query processing speed, resource usage, and query cost when processing queries based on CPU.
  • GPU execution ability can be determined based on query processing speed, resource usage, and query cost when processing queries based on GPU.
  • the query cost to determine CPU execution ability is determined based on data processing volume (row processed) and CPU operation cost
  • the query cost to determine GPU execution ability is determined based on data processing volume (row processed) and GPU operation cost.
  • dependency score 1020 may be determined to be processed based on different priorities depending on the type of query.
  • Queries for creating tables or models can be defined as priority processing queries, and even within priority processing queries, separate priorities can be given based on scores.
  • COPY, CREATE, and BUILD may be processed preferentially as priority processing queries.
  • processing priority is determined in the order COPY > CREATE > BUILD > PREDICT > SELECT_1 > SELECT_2, and the query queue can reconfigure the queue for performing queries.
  • the multi-query analysis unit may first check the dependency of a plurality of queries included in the input multi-query and then determine the execution order of each of the plurality of queries.
  • the GPU execution capability and CPU execution capability for each of the plurality of queries may be determined secondarily by considering the total cost described above. Based on GPU execution ability and CPU execution ability, it is determined whether each of the plurality of queries included in the query group is assigned to the CPU or GPU, and the execution order can be determined so that the lower the overall cost, the faster the query is executed.
  • the cloud analyzer of the multi-query analysis unit analyzes the correlation of multiple queries included in the input multi-query, and preferentially executes a specific query among the multiple queries based on the correlation (dependency) of the multiple queries. You can decide to do it.
  • the total cost (sum of startup cost and run cost) for each of the plurality of queries may be determined.
  • the major resource may be determined to be CPU or GPU based on the total cost information of each of the plurality of queries. The lower the overall cost, the higher the priority. Multiple query groups can be queued to be processed with higher priority, but CPU and GPU can be selectively used as major resources depending on execution ability.
  • queries located at the front of the input multi-query can be queued to be processed with higher priority.
  • Query 1 has a small overall cost as the first priority, uses GPU as a major resource, and can include the query written at the very beginning in the input multi-query.
  • Query 2 is ranked 3rd and can use GPU as a major resource with small overall cost.
  • Query 3 can use CPU as a major resource with a small overall cost of rank 2.
  • Query 4 is ranked 4th, has a small overall cost, uses CPU as a major resource, and can include queries written last in the input multi-query.
  • query groups may be stacked in the queue to be processed in the following order: query 1, query 3, query 2, and query 4.
  • Figure 11 is a conceptual diagram showing a method of processing an input multi-query according to an embodiment of the present invention.
  • the execution order of the query group can be determined by considering the dependency, total cost, and location of the query. .
  • query 1 (1110) includes a total cost of 3 and PREDICT USING (my_model) as a query statement.
  • Query 2 (1120) includes a total cost of 2 and CREATE TABLE (my_model) as a query statement.
  • Query 3 (1130) has a total cost of 5 and may include BUILD MODEL (my_model) as a query statement.
  • query 2 (1120) with a total cost of 1 may be executed considering the total cost
  • query 1 (11110) with a total cost of 3 may be executed.
  • Figure 12 is a conceptual diagram showing a server that provides processing services for structured data and unstructured data according to an embodiment of the present invention.
  • a server for providing processing services for structured data and unstructured data to user devices based on different architectures is disclosed.
  • the server 1200 may include an instance 1210 and resources.
  • the instance includes workspace hubs 1270 and 1280 and a data processing engine 1220, and resources may include processing resources 1240, storage 1230, and memory (not shown).
  • Work space hubs 1270 and 1280 may include at least one work space 1250.
  • the work space 1250 can be directly connected only to the storage 1230 corresponding to the work space 1250, and the data processing engine 1220 can be connected to all storages 1230.
  • An instance can have a structure directly connected to a resource.
  • the work space hubs 1270 and 1280 may include a shared work space hub 1270 implemented based on a shared architecture and a dedicated work space hub 1280 implemented based on a dedicated architecture. there is.
  • the shared workspace hub 1270 and the dedicated workspace hub 1280 may include a workspace 1250.
  • the work space 1250 may be a space for implementing services based on structured data and unstructured data provided by users. For example, one work space 1250 may be assigned based on one user identifier.
  • the work space 1250 may include a lab and a database.
  • the lab is a space for generating queries for services implemented by users, and the database is a logical storage that stores organized data. In other words, the lab may be a user interface for accessing the work space 1250.
  • the shared workspace hub 1270 may include a plurality of workspaces 1250 of a plurality of users.
  • the shared workspace hub 1270 may share the allocated data processing engine 1220 and the allocated processing resources 1240.
  • Dedicated workspace hub 1280 may include a workspace 1250 for one user.
  • a data processing engine 1220 and a processing resource 1240 for exclusive use by one user may be allocated to the dedicated work space hub 1280.
  • shared work space hub 1270 and the dedicated work space hub 1280 are expressed one by one, but there can be multiple shared work space hubs 1270 and dedicated work space hubs 1280, and this architectural structure is also shown. It may be included in the scope of invention rights.
  • the shared workspace hub 1270 may use the allocated data processing engine 1220 and the allocated processing resources 1240.
  • the shared workspace hub 1270 may include a plurality of workspaces 1250.
  • a plurality of work spaces 1250 may share the allocated data processing engine 1220 and the allocated processing resources 1240.
  • the dedicated work space hub 1280 includes only one work space 1250, and one work space 1250 may exclusively use the allocated data processing engine 1220 and the allocated processing resource 1240.
  • the user can selectively select the shared workspace 1270 or the dedicated workspace 1280 based on the structured data to be processed, the amount of unstructured data, and the services to be implemented based on the structured data and unstructured data to create the workspace 1250. ) can be created.
  • the data processing engine 1220 is the data processing system described above in FIGS. 2 to 11 and can process queries for unstructured data and structured data based on PostgreSQL and extended SQL. That is, the data processing engine 1220 can perform the operations of the data processing system described above in FIGS. 2 to 11.
  • the data processing engine 1220 may create a model for the user through a user request based on the workspace 1250, and the model for the user may be created and stored on the storage 1230.
  • the user may send a query to request an output value based on the model stored in the user's storage 1230 externally through the data processing engine 1220 based on an application programming interface (API) and the user's unique identification information.
  • the data processing engine 1220 may check the user's workspace 1250 based on the user's unique identification information and deliver an output value to the user based on the model stored in the storage 1230.
  • API application programming interface
  • the data processing engine 1220 is implemented to be accessible to all storage 1230 and can access the storage 1230 based on the user's unique identification information upon user request and utilize data stored in the storage 1230.
  • Storage 1230 may be a physical storage for files, models, etc., and one workspace 1250 may be connected to one storage 1230 and may be accessible only when the user's unique identification information is authenticated.
  • Processing resources 1420 may include GPU, CPU, and memory. As described above, CPU and GPU can be selected when processing queries based on a resource distribution algorithm. Additionally, CPU and GPU can be selected based on a multi-query scheduler and optionally used to process multi-queries.
  • the workspace 1250 of the dedicated workspace hub 1280 can exclusively use the allocated resources.
  • a plurality of work spaces 1250 of the shared work space hub 1270 share allocated resources. Accordingly, queries requested by each of the plurality of work spaces 1250 can be processed sequentially.
  • Figure 13 is a conceptual diagram showing a query processing method of a shared workspace hub according to an embodiment of the present invention.
  • query processing for individual workspaces included in the shared workspace hub may be processed based on the resource allocation algorithm described above.
  • queries generated by multiple work spaces can be processed sequentially based on the queue 1300/stack.
  • processing of queries from individual workspaces is performed based on a resource distribution algorithm, and processing of queries from multiple workspaces can be processed sequentially, taking query creation time into consideration.
  • Figure 14 is a conceptual diagram showing a resource distribution method according to an embodiment of the present invention.
  • a method for allocating processing resources is disclosed taking into account the characteristics of a workspace hub (dedicated workspace hub, shared workspace hub).
  • the characteristics of the workspace hub for allocating processing resources may include the volume of queries for structured data (1400), the volume of queries for unstructured data (1410), and the data throughput (1420) required to process the queries. .
  • unstructured queries The more a workspace uses relatively more queries on unstructured data (hereinafter referred to as unstructured queries), the more GPU it uses.
  • structured queries As the workspace uses relatively more queries for structured data (hereinafter referred to as structured queries), and as the number of query requests increases, it uses relatively more CPU.
  • the resources for the workspace hub are adjusted in consideration of the volume of structured queries for structured data used for each workspace hub, the volume of unstructured queries for unstructured data, and the data throughput required to process the queries. Can be allocated adaptively.
  • the workspace (Dedicated) can adaptively adjust the provision limits of CPU, GPU, and memory for the workspace (Dedicated) based on generated structured query data, unstructured query data, and processing resource usage statistical data, which is statistical information on data throughput.
  • Workspace 1 may require a relatively large amount of CPU, and in this case, unused GPU resource allocations can be replaced and converted to CPU resources within the limit.
  • (Dedicated) may require a relatively large number of GPUs, and in this case, unused CPU resource allocations within the limit can be replaced and converted to GPU resources for use.
  • workspace included in a shared workspace hub, processing resources are shared and used.
  • processing resources may be allocated based on processing resource usage statistical data of a plurality of workspaces (shared) included in the shared workspace hub.
  • the fixed method sets the processing resources allocated to one shared workspace hub according to the number of workspaces (shares) included.
  • the workspaces allocated to the shared workspace hub may be determined by considering each of the processing resource usage statistics used in each of the plurality of workspaces. For example, workspaces that use relatively more CPU than GPU and workspaces that use GPU relatively more than CPU can be grouped and assigned to a shared workspace hub to achieve overall balanced processing resources. .
  • the variable method is a method of allocating processing resources allocated to one shared workspace hub by considering processing resources used in multiple shared workspace hubs.
  • the processing resources used in the plurality of shared workspace hubs are determined, and different CPU resources, GPU resources, and memory are allocated to each of the plurality of shared workspace hubs by considering the processing resource usage statistics of each of the plurality of shared workspace hubs. can be assigned.
  • the fixed method and the variable method can be used when a stable supply of processing resources is required considering the usage of total processing resources, and the variable method can be used when a more efficient supply of processing resources is needed. For example, for certain time zones (business hours), processing resources are provided in a fixed manner, and for certain time zones (non-business hours), processing resources are provided in a variable manner to maximize unused processing resources. It can be used efficiently.
  • workspace hubs and workspaces may be allocated on a plurality of servers based on processing resource usage statistics on a server-by-server basis.
  • the embodiments according to the present invention described above can be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium.
  • the computer-readable recording medium may include program instructions, data files, data structures, etc., singly or in combination.
  • Program instructions recorded on the computer-readable recording medium may be specially designed and configured for the present invention, or may be known and usable by those skilled in the computer software field.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks. medium), and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc.
  • Examples of program instructions include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • a hardware device can be converted into one or more software modules to perform processing according to the invention and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Probability & Statistics with Applications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Human Computer Interaction (AREA)

Abstract

본 발명은 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버에 관한 것이다. 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법은 서버가 워크 스페이스 허브 상의 워크 스페이스를 할당하는 단계, 서버가 워크 스페이스에 대응되는 데이터 처리 엔진 및 프로세싱 자원을 할당하는 단계와 서버가 워크 스페이스를 기반으로 한 쿼리를 처리하는 단계를 포함할 수 있다.

Description

워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버
본 발명은 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버에 관한 것이다. 보다 상세하게는 서로 다른 아키텍쳐를 기반으로 구현된 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버에 관한 것이다.
급속한 비대면 환경과 모바일 우선 전략에 따라 해마다 많은 정형 데이터 및 비정형 데이터의 폭발적인 증가와 생성은 모든 분야에서 빅데이터를 활용한 새로운 의사 결정과 서비스를 요구하고 있다.
이와 같이 데이터의 급격한 증가와 소비는 향후 더욱 가속화될 예정이며, 이러한 정형 데이터뿐만 아니라, 비정형 데이터에 포함되어 있는 다양한 패턴들을 수집하고 정제하고 분석하여 미래의 성장동력을 찾는 것이 기업들의 새로운 비즈니스 모델이 되고 있다.
기존 선행 기술로는 국내출원번호10-2014-0036626건이 있다.
본 발명은 상술한 문제점을 모두 해결하는 것을 그 목적으로 한다.
또한, 본 발명은, 확장된 SQL(structured query language) 및 하나의 플랫폼을 기반으로 하나의 언어를 사용하여 정형 데이터와 비정형 데이터를 처리하기 위한 서비스를 제공하되, 서로 다른 특성의 워크스페이스를 기반으로 서로 다른 자원을 할당하여 사용자들에게 정형 데이터와 비정형 데이터를 처리하기 위한 서비스를 제공하기 위한 데이터 처리 아키텍쳐를 제공하는 것을 목적으로 한다.
또한, 본 발명은, 데이터 처리 엔진 및 프로세싱 자원의 공유 여부에 따라 공유 워크 스페이스 허브 및 전용 워크 스페이스 허브로 구분하여 사용자의 필요에 따라 워크 스페이스를 생성하여 적응적으로 모델링 서비스를 활용하게 하는 것을 목적으로 한다.
상기 목적을 달성하기 위한 본 발명의 대표적인 구성은 다음과 같다.
본 발명의 일 실시예에 따르면, 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법은 서버가 워크 스페이스 허브 상의 워크 스페이스를 할당하는 단계, 상기 서버가 상기 워크 스페이스에 대응되는 데이터 처리 엔진 및 프로세싱 자원을 할당하는 단계와 상기 서버가 상기 워크 스페이스를 기반으로 한 쿼리를 처리하는 단계를 포함할 수 있다.
한편, 상기 워크 스페이스는 상기 워크 스페이스에 대응되는 스토리지에만 연결되고, 상기 데이터 처리 엔진은 상기 워크 스페이스를 포함하는 복수의 워크 스페이스에 대응되는 복수의 스토리지와 모두 연결될 수 있다.
또한, 상기 워크 스페이스 허브는 상기 데이터 처리 엔진 및 상기 프로세싱 자원의 공유 여부에 따라 공유 워크 스페이스 허브 및 전용 워크 스페이스 허브로 구분될 수 있다.
본 발명의 다른 실시예에 따르면, 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 서버는 워크 스페이스 허브 상의 워크 스페이스를 할당하고, 상기 워크 스페이스에 대응되는 데이터 처리 엔진 및 프로세싱 자원을 할당하고, 상기 워크 스페이스를 기반으로 한 쿼리를 처리하도록 구현될 수 있다.
한편, 상기 워크 스페이스는 상기 워크 스페이스에 대응되는 스토리지에만 연결되고, 상기 데이터 처리 엔진은 상기 워크 스페이스를 포함하는 복수의 워크 스페이스에 대응되는 복수의 스토리지와 모두 연결될 수 있다.
또한, 상기 워크 스페이스 허브는 상기 데이터 처리 엔진 및 상기 프로세싱 자원의 공유 여부에 따라 공유 워크 스페이스 허브 및 전용 워크 스페이스 허브로 구분될 수 있다.
본 발명에 의하면, 확장된 SQL(structured query language) 및 하나의 플랫폼을 기반으로 하나의 언어를 사용하여 정형 데이터와 비정형 데이터가 처리되되, 멀티-쿼리 스케줄러를 통해 복수의 쿼리가 서로 다른 컴퓨팅 자원을 사용하여 효율적으로 처리될 수 있다.
또한, 본 발명에 의하면, 데이터 처리 엔진 및 프로세싱 자원의 공유 여부에 따라 공유 워크 스페이스 허브 및 전용 워크 스페이스 허브로 구분하여 사용자의 필요에 따라 워크 스페이스를 생성하여 적응적으로 모델링 서비스가 활용될 수 있다.
도 1은 기존 데이터 처리 시스템을 나타낸 개념도이다.
도 2는 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.
도 3은 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.
도 4는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.
도 5는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.
도 6은 본 발명의 실시예에 따른 데이터 처리 시스템을 기반으로 한 데이터 처리 방법을 나타낸 개념도이다.
도 7은 본 발명의 실시예에 따른 데이터 처리 시스템에서 쿼리를 분석하여 데이터를 처리하는 방법을 나타낸 개념도이다.
도 8은 본 발명의 실시예에 따른 자원 분배 알고리즘을 나타낸 개념도이다.
도 9는 본 발명의 실시예에 따른 입력 멀티-쿼리(input multi-query)를 처리하는 데이터 처리 시스템을 나타낸 개념도이다.
도 10은 본 발명의 실시예에 따른 멀티-쿼리 스케줄러의 동작을 나타낸 개념도이다.
도 11은 본 발명의 실시예에 따른 입력 멀티-쿼리를 처리하는 방법을 나타낸 개념도이다.
도 12는 본 발명의 실시예에 따른 정형 데이터 및 비정형 데이터에 대한 처리 서비스를 제공하는 서버를 나타낸 개념도이다.
도 13은 본 발명의 실시예에 따른 공유 워크 스페이스 허브의 쿼리 처리 방법을 나타낸 개념도이다.
도 14는 본 발명의 실시예에 따른 자원 분배 방법을 나타낸 개념도이다.
후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이러한 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 본 명세서에 기재되어 있는 특정 형상, 구조 및 특성은 본 발명의 정신과 범위를 벗어나지 않으면서 일 실시예로부터 다른 실시예로 변경되어 구현될 수 있다. 또한, 각각의 실시예 내의 개별 구성요소의 위치 또는 배치도 본 발명의 정신과 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 행하여 지는 것이 아니며, 본 발명의 범위는 특허청구범위의 청구항들이 청구하는 범위 및 그와 균등한 모든 범위를 포괄하는 것으로 받아들여져야 한다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 구성요소를 나타낸다.
이하에서는, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 여러 바람직한 실시예에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.
도 1은 기존 데이터 처리 시스템을 나타낸 개념도이다.
도 1에서는 기존에 정형 데이터와 비정형 데이터를 처리하는 데이터 처리 시스템이 개시된다.
도 1을 참조하면, 기존 데이터 처리 시스템의 정형 데이터(100) 및 비정형 데이터(120)에 대한 데이터 처리 방식이 개시된다.
정형 데이터(100)는 스키마에 따라 테이블에 저장되고 관계를 통해 테이블 간에 연결이 가능한 데이터이다. 정형 데이터(100)는 보유하고 있는 정보에 대한 적절히 정의된 스키마를 가지고 행과 열로 표시될 수 있다. 각 열은 다른 속성을 나타내는 반면, 각 행에는 단일 인스턴스의 속성과 연결된 데이터가 있다. 행과 열은 쉽게 참조할 수 있는 테이블을 형성할 수 있고, 서로 다른 테이블들은 연결될 수 있고, 여러 테이블이 연속적으로 연결되어 있으면 관계형 데이터베이스(140)가 형성될 수 있다.
비정형 데이터(120)는 정형 데이터(100)와 반대되는 데이터이고, 정해진 규칙이 없어서 값의 의미를 쉽게 파악하기 힘든 데이터로서 음성, 이미지, 영상과 같은 데이터를 포함할 수 있다.
기존 데이터 처리 시스템은 SQL(structured query language)을 기반으로 정형 데이터(100)에 대한 쿼리만이 가능하였고, 비정형 데이터(120)에 대한 처리를 위해서는 특정 스키마가 없는 NoSQL 데이터베이스가 사용되었다.
또한, 기존의 데이터 처리 시스템은 정형 데이터(100)에 대한 실시간 쿼리가 가능하였으나, 비정형 데이터(120)에 대한 실시간 쿼리가 불가능하였다. 기존 데이터베이스 처리 시스템에서 비정형 데이터(120)는 실시간 처리(real time processing) 대신 배치 처리(batch processing)을 통해 처리되었다. 이로 인해, 기존의 데이터 처리 시스템에서 이미지, 영상, 음성에 대한 실시간 검색이 불가하였다. 보다 구체적으로 기존의 데이터 처리 시스템에서 비정형 데이터(120)는 대량의 데이터를 실시간으로 분석하기 어렵다. 따라서, 실시간으로 획득이 가능한 데이터 테이블과 정해진 시간에 계산을 미리 해놓은 배치(Batch) 테이블을 결합하는 람다 아키텍처(150) 기반의 처리가 수행되었고, 정형 데이터(100)와 비정형 데이터(120)가 별도의 DMBS(database management system)를 기반으로 처리되었다.
또한, 기존의 데이터 처리 시스템은 비정형 데이터(120)에 대한 배치 프로세싱을 위해 다양한 파이프라인, 다양한 프레임워크, 다양한 언어를 사용하였다. 따라서, 하나의 가버넌스를 기반으로 한 데이터의 처리가 불가능하였고, 개발 이후 유지 보수가 어려웠다.
또한, 기존의 데이터 처리 시스템에서 비정형 데이터(120)에 대한 학습을 위해서는 데이터베이스 내에서의 인공 지능 학습이 불가하였다. 기존의 데이터 처리 시스템은 정형 데이터(100)에 대한 학습을 데이터베이스에 구현된 AI 엔진을 기반으로 수행하였으나, 비정형 데이터(120)에 대한 학습은 데이터베이스 내에서 SQL 기반으로 처리되지 않았기 때문에 데이터베이스 안에서 비정형 데이터를 기반으로 한 AI 엔진 모델링은 불가능하였다.
또한, 기존의 데이터 처리 시스템은 AI 엔진에 대한 모델링을 수행시 운영계의 모수 테이블에서 샘플링을 통해 샘플 테이블(160)을 생성하여 모델링을 수행하게 되고, 모델링을 수행하는 모델링 플랫폼과 실제 운영을 수행하는 운영 플랫폼이 서로 상이하다. 이러한 경우, 모델링 플랫폼과 운영 플랫폼의 차이로 인해 모델링 결과가 정확하지 않은 문제점이 발생된다.
기존 데이터 처리 시스템에서는 샘플 데이터를 활용하여 AI 모델링 하는데까지 정말 많은 시간이 소요된다.
기존 데이터 처리 시스템에서는 모수 테이블에서 샘플 데이터를 추출해오는 과정이 수행된다. 모수 데이터가 테이블 형태가 아닌 다양한 형태로 존재할 수 있기 때문에 데이터를 변형 및 추출해오는 과정에서 시간이 소요되고, 또 모델링 하기 위해 데이터를 전처리 하는 과정에서도 상당한 시간이 요구된다.
또한, 기존 데이터 처리 시스템의 AI 모델링 과정에서 샘플 데이터는 정형과 비정형 데이터를 모두 포함하고 있고 정형/비정형 AI모델링을 하기 위해 기존 데이터 처리 시스템에서는 람다 아키텍처를 필수로 적용해야 한다. 람다 아키텍처를 통해서 개발을 하게 된다면 다양한 플랫폼과 언어를 사용하게 되는데 플랫폼 간의 특성 차이, 연동 문제 등으로 접목시키는데 시간을 많이 허비하게 된다.
이뿐만 아니라, 모수 테이블에서 데이터를 추출하고 람다 아키텍처 상에서 AI 모델링을 하는 동안 모수 테이블/데이터에 실시간으로 새로운 데이터들이 쌓이게 되는데 그렇게 되면 기존 데이터 처리 시스템에서 만들어진 AI 모델을 적용했을 때 예측 결과(모델의 결과 값)가 정확하지 않다는 문제점이 있다. 그렇다면 다시 한번 모델링을 하기 위해서 1번 프로세스와 2번 프로세스를 거치는 등 많은 시간이 소요된다.
본 발명의 실시예에 따른 데이터 처리 시스템이 사용되는 경우, 모수 데이터가 하나의 형태(테이블)로 관리되고, 샘플 데이터를 추출해 오는 과정도 간단한 쿼리문을 통해 가능하고 람다 아키텍처를 필요로 하지 않기 때문에 정형 데이터 및 비정형 데이터에 대한 AI 모델링 또한 하나의 플랫폼과 하나의 언어를 사용하여 연동 문제없이 쉽게 프로세스 할 수 있다는 장점이 있다.
따라서, 본 발명의 실시예에 따른 데이터 처리 플랫폼은 하나의 플랫폼을 기반으로 하나의 언어를 기초로 정형 데이터(100)와 비정형 데이터(120)를 처리할 수 있다.
또한, 본 발명의 실시예에 따른 데이터 처리 플랫폼은 하나의 플랫폼 상에 운영 플랫폼과 모델링 플랫폼이 위치하여 보다 정확한 모델링이 가능할 뿐만 아니라, 별도의 배치 프로세싱 없이 정형 데이터(100) 및 비정형 데이터(120)를 기반으로 한 AI 모델링 기능을 제공할 수 있다.
이하, 보다 구체적인 본 발명의 실시예에 따른 데이터 처리 플랫폼의 기능이 개시된다.
도 2는 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.
도 2에서는 정형 데이터 및 비정형 데이터를 하나의 플랫폼 상에서 처리하기 위한 데이터 처리 시스템이 개시된다.
도 2를 참조하면, 데이터 처리 시스템은 비정형 데이터(220)와 정형 데이터(210)를 하나의 플랫폼 상에서 처리 가능하다. 본 발명에서는 비정형 데이터(220)를 정형 데이터(210)와 함께 하나의 플랫폼에서 처리하기 위한 데이터 처리 신택스(syntax)가 새롭게 정의되고, 새롭게 정의된 데이터 처리 신택스의 사용이 가능한 확장(extended) SQL(240)이 정의될 수 있다.
정형 데이터(210)에 대한 일반 쿼리는 PostgreSQL과 같은 기존의 SQL을 기반으로 처리되고 비정형 데이터에 대한 쿼리는 본 발명에서 새롭게 정의된 확장 SQL(240)을 기반으로 처리될 수 있다.
확장 SQL(240) 상에서 새롭게 정의된 데이터 처리 신택스를 처리하기 위한 확장 SQL 엔진(250)이 정의될 수 있다. 확장 SQL 엔진(250)은 새롭게 정의된 데이터 처리 신택스를 처리 가능하도록 하기 위한 엔진일 수 있다.
기존의 데이터 처리 시스템과 다르게 확장 SQL 엔진(250)을 기반으로 네스티드 쿼리(nested query)(230)가 가능하다. 네스티드 쿼리(230)는 정형 데이터(210) 및 비정형 데이터(220)에 대한 혼합적인 쿼리로서 데이터베이스에 저장된 정형 데이터(210)와 비정형 데이터(220)에 대한 순차적인 처리 또는 복합적인 처리를 가능하게 할 수 있다.
즉, 기존에 정형 데이터(210)와 비정형 데이터(220)가 별도의 DMBS(database management system)를 기반으로 처리되는 것과 다르게 본 발명에서는 정형 데이터(210)와 비정형 데이터(220)가 하나의 플랫폼 상에서 확장 SQL 엔진(250)을 기반으로 처리되고, 네스티드 쿼리(nested query)(230)를 기반으로 정형 데이터(210)와 비정형 데이터(220)에 대한 데이터 프로세싱이 하나의 데이터 베이스(260) 상에서 동시에 이루어질 수 있다. 이를 기반으로 정형 데이터(210)와 비정형 데이터(220)에 대한 AI 모델링도 데이터 처리 시스템의 AI 엔진(270) 상에서 이루어진다.
AI 엔진은 분류 모델, 회귀 모델, 추천 모델, 음성 인식 모델 등 다양한 AI 엔진이 미리 제공될 수도 있고, 사용자가 직접 생성한 모델, 오픈 소스로 제공되는 AI 엔진 등 제한 없이 사용될 수 있다.
본 발명의 데이터 처리 시스템은 비정형 데이터(220)에 대한 별도의 배치 프로세싱, 별도의 언어, 별도의 플랫폼 없이 하나의 플랫폼 내에서 처리 가능하다. 본 발명의 데이터 처리 시스템은 정형 데이터(210)와 비정형 데이터(220) 모두 SQL 만으로 쿼리 가능하고 정형 데이터(210)와 비정형 데이터(220)에 대한 AI 모델링을 가능하게 하는 통합 플랫폼이다. 따라서 모델링 플랫폼과 운영 플랫폼이 동일하므로 모수가 달라져서 모델링의 정확도가 떨어지는 문제도 줄어들 수 있다.
또한, 본 발명의 데이터 처리 시스템은 RDB(relational database), AI 그리고 빅데이터 플랫폼(big data platform)의 기능을 하나의 플랫폼에서 적용할 수 있으며 AI 기반의 디지털 전환시 발생하는 비효율성을 획기적으로 줄일 수 있고, 빅데이터 처리 및 분산 병렬 처리 기술을 기반으로 하여 기존 대비 2배 이상 빠른 데이터 처리를 가능하게 한다.
즉, 본 발명의 실시예에 따르면, 데이터베이스 상에서 정형 데이터와 비정형 데이터를 처리하는 방법은 데이터 처리 시스템이 네스티드 쿼리를 수신하는 단계와 데이터 처리 시스템이 네스티드 쿼리에 대한 처리를 수행하는 단계를 포함할 수 있다. 네스티드 쿼리는 비정형 데이터에 대한 제1 쿼리 및 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리일 수 있다.
네스티드 쿼리에 대한 처리를 수행하는 단계는, 데이터 처리 시스템이 확장된 SQL(extended structured query language)을 처리하는 확장 SQL 엔진을 기반으로 비정형 데이터에 대한 처리를 수행하는 단계와 데이터 처리 시스템이 Postgre SQL(extended structured query language)을 처리하는 일반 SQL 엔진을 기반으로 정형 데이터에 대한 처리를 수행하는 단계를 포함할 수 있다.
데이터 처리 시스템은 정형 데이터에 대한 데이터 테이블 및 비정형 데이터에 대한 데이터 테이블을 생성하여 하나의 데이터베이스 상에서 처리하고, 데이터 처리 시스템은 정형 데이터 및 비정형 데이터를 기반으로 한 인공 지능 엔진 모델링을 하나의 데이터베이스 상에서 지원할 수 있다.
또한, 본 발명의 실시예에 따르면, 데이터 처리 시스템은 정형 데이터 및 비정형 데이터 각각에 대한 개별적인 처리를 수행할 수도 있다. 데이터 처리 시스템은 비정형 데이터 처리 쿼리 및 정형 데이터 처리 쿼리를 수신하고, 비정형 데이터 처리 쿼리 및 정형 데이터 처리 쿼리를 처리하도록 구현될 수 있다. 비정형 데이터 처리 쿼리는 비정형 데이터만을 처리하기 위한 쿼리이고, 정형 데이터 처리 쿼리는 정형 데이터만을 처리하기 위한 쿼리일 수 있다.
비정형 데이터 처리 쿼리는 확장 SQL 및 확장 SQL 엔진을 기반으로 처리 되고, 정형 데이터 처리 쿼리는 일반 SQL(Postgre SQL) 및 일반 SQL 엔진을 기반으로 처리될 수 있다.
도 3은 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.
도 3에서는 기존에 정의된 일반 쿼리와 비정형 데이터를 위해 확장된 SQL을 기반으로 정의된 확장 쿼리가 네스티드 쿼리를 형성하고, 네스티드 쿼리가 데이터 처리 시스템에서 처리되는 방법이 개시된다.
도 3을 참조하면, 입력 쿼리(300)로서 비정형 데이터 및 정형 데이터에 대한 처리를 위한 네스티드 쿼리가 입력될 수 있다.
예를 들어, 네스티드 쿼리는 제1 쿼리(310), 제2 쿼리(320) 및 제3 쿼리(330)를 포함할 수 있고, 제1 쿼리(310) 및 제3 쿼리(330)는 확장 쿼리(350)이고, 제2 쿼리(320)는 일반 쿼리(360)일 수 있다.
제1 쿼리(310)는 PRINT IMAGE, 제2 쿼리(320)는 SELECT, 제3 쿼리(330)는 SEARCH IMAGE일 수 있다. 제1 쿼리(310), 제2 쿼리(320) 및 제3 쿼리(330)는 네스티드 구조로 입력 쿼리를 형성할 수 있다.
입력 쿼리(300)는 파서를 통해 파싱될 수 있다. 렉서(lexer)를 기반으로 네스티트 쿼리는 일반 쿼리(360)와 확장 쿼리(350)로 구분되고, 파서는 일반 쿼리(360)와 확장 쿼리(350)를 분할할 수 있다.
제1 쿼리(310), 제2 쿼리(320) 및 제3 쿼리(330)는 클라우즈 아날라이즈(clause analyze) 및 쿼리 트리(query tree)를 통해 해석되어 처리될 수 있다. 제3 쿼리(330), 제2 쿼리(320) 및 제1 쿼리(310)의 순서로 처리될 수 있다.
제1 쿼리(310) 및 제3 쿼리(330)는 확장 쿼리(350)로서 확장 SQL 엔진을 기반으로 처리될 수 있고, 제2 쿼리(320)는 일반 쿼리로서 일반 쿼리 처리를 위한 SQL 엔진인 PostgreSQL 엔진을 기반으로 처리될 수 있다.
표준화 SQL 엔진과 PostgreSQL 엔진은 하나의 데이터베이스와 연결되어 쿼리를 처리할 수 있다. 하나의 데이터베이스를 기반으로 정형 데이터 및 비정형 데이터를 기반으로 한 인공 지능 학습이 가능하다.
도 4는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.
도 4에서는 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 동시에 처리하기 위한 확장된 SQL 중 쿼리 기능이 개시된다.
도 4를 참조하면, 비정형 데이터에 대한 쿼리 기능은 아래와 같은 확장된 SQL을 기반으로 수행될 수 있다.
(1) 저장 모델 확인(LIST)(410)
사용자는 "LIST" 구문을 사용하여 비정형 데이터를 프로세싱하기 위한 비정형 데이터 테이블을 위해 미리 생성된 모델(pre-built model)과 사용자가 생성한 사용자 생성 모델을 확인할 수 있다.
예를 들어, LIST MODEL 기능을 통해 사용자에 의해 생성된 사용자 생성 모델에 대한 확인이 가능하고, LIST PREBUILT MODEL 기능을 사용하여 미리 생성된 모델에 대한 확인이 가능하다.
(2) 비정형 데이터 변환(create table)(420)
"create table" 구문을 사용하여 비정형 데이터(이미지, 오디오, 비디오 등)는 수치화 알고리즘을 기초로 사용자형 벡터 형식으로 변환한 비정형 데이터 테이블로 생성될 수 있다.
아래의 표 1은 create table 구문의 예시이다
<표 1>
CREATE TABLE [사용자 지정 데이터 테이블의 이름]
USING [사용할 인공지능 모델]
AS [사용할 데이터 세트]
예를 들어, create table 기능을 사용하여 특정 경로에 존재하는 이미지 파일을 속성 추출 인공지능 모델을 사용하여 비정형 데이터 테이블로서 데이터베이스 상에 생성할 수 있다
(3) 비정형 특성 추가(convert using)(430)
사용자는 "convert using" 구문을 사용하여 이미지, 비디오, 음성 등 비정형 데이터의 정보를 이용해서 수치화 알고리즘을 사용하여 벡터 형식으로 변환하고 이값을 사용할 데이터 세트에 추가할 수 있다.
아래의 표 2는 convert using 구문의 예시이다
<표 2>
CONVERT USING [사용할 인공지능 모델]
OPTIONS(
Table_name=[저장될 테이블명]
)
AS
[사용할 데이터 세트]
예를 들어, convert using 기능을 사용하여 특정 경로에 존재하는 이미지 파일을 추가적인 속성 추출 인공지능 모델을 사용하여 데이터 테이블로서 데이터베이스 상에 생성할 수 있다
(4) 비정형 데이터 검색(search)(440)
Search 구문은 비정형 데이터에서 내용이나 의미 또는 유사도 등을 검색하기 위해 사용될 수 있다.
아래의 표 3은 search 구문의 예시이다.
<표 3>
SEARCH [사용자 지정 데이터 테이블 이름]
USING [사용할 인공지능 모델]
AS [사용할 데이터 세트]
예를 들어, 이미지 수치화 인공 지능 모델을 기반으로 유사 이미지에 대한 검색을 진행하기 위해 search 구문이 활용될 수 있다.
(5) 결과 출력(PRINT)(450)
사용자는 "PRINT" 구문을 사용하여 이미지, 오디오 및 비디오 파일을 출력할 수 있다. 또한, 서브 쿼리를 사용하여 "PRINT" 구문을 통해 나온 결과를 바로 출력할 수 있다.
아래의 표 4는 "PRINT" 구문의 예시이다.
<표 4>
PRINT IMAGE, AUDIO, VIDEO
AS [출력할 데이터 세트]
예를 들어, PRINT 쿼리문을 사용하여 데이터 테이블에 있는 이미지 파일/비디오 파일/오디오파일들을 출력할 수 있다.
위의 쿼리 신택스(syntax)는 본 발명에서 확정된 SQL을 위해 새롭게 정의된 신택스이다.
위와 같은 쿼리 신텍스를 기반으로 만들어진 비정형 데이터 테이블을 기반으로 키워드 또는 텍스트를 기반으로 한 이미지 데이터, 오디오 데이터, 비디오 데이터의 검색이 가능하다. 또한, 이미지 데이터, 오디오 데이터, 비디오 데이터를 기반으로 한 이미지 데이터, 오디오 데이터, 비디오 데이터의 검색도 가능하다.
즉, 본 발명의 실시예에 따른 데이터 처리 시스템에서는 기존의 정형 데이터에 대한 실시간 검색에 추가하여 위와 같은 비정형 데이터에 대한 실시간 검색이 가능하다. 또한, 위와 같은 확장된SQL을 기반으로 비정형 데이터 및 정형 데이터에 대한 쿼리의 조합인 네스티드 쿼리(nested query)도 가능하여 비정형 데이터 및 정형 데이터를 모두 활용한 모델링도 가능하다.
도 5는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.
도 5에서는 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 동시에 처리하기 위한 확장된 SQL 중 ML(machine learning) 기능이 개시된다.
도 5를 참조하면, 비정형 데이터에 대한 ML 기능은 아래와 같은 확장된 SQL을 기반으로 수행될 수 있다.
(1) 모델 학습(BUILD MODEL)(510)
사용자는 "BUILD MODEL" 구문을 사용하여 인공지능모델을 생성할 수 있다.
아래의 표 5는 "BUILD MODEL" 구문의 예시이다.
<표 5>
BUILD MODEL [사용자 지정 모델 이름]
USING [사용할 인공지능모델]
OPTIONS([인공지능모델을 만들 때 필요한 옵션값])
AS [사용할 데이터 세트]
예를 들어, 사용자는 "BUILD MODEL" 구문을 사용하여 영화를 추천하는 영화추천모델을 생성할 수 있다.
(2) 모델 평가(EVALUATE)(520)
사용자는 "EVALUATE" 구문을 사용하여 인공지능모델에 대한 성능 평가를 수행할 수 있다.
아래의 표 6은 "EVALUATE" 구문의 예시이다.
<표 6>
EVALUATE
USING [기존 학습한 모델 이름]
OPTIONS ([모델별 평가시 필요한 옵션값])
AS
[사용할 데이터 세트]
예를 들어, "EVALUATE" 구문을 사용하여 사용자가 모델 학습하기에서 만들었던 분류 모델에 대한 평가가 수행될 수 있다.
(3) 모델 재학습(FIT MODEL)(530)
사용자는 "FIT MODEL" 구문을 사용하여 모델을 재학습시킬 수 있다.
아래의 표 7은 "FIT MODEL" 구문의 예시이다.
<표 7>
FIT MODEL [사용자 지정 모델 이름]
USING [기존 학습한 모델 이름 | 사전 학습된 인공지능모델 이름]
OPTIONS ([인공지능모델을 만들 때 필요한 옵션값])
AS
[사용할 데이터세트]
예를 들어, "FIT MODEL"을 사용하여 사용자가 이전에 만들었던 모델에 새롭게 추가된 데이터세트를 사용하여 모델을 재학습시킬 수 있다.
(4) 모델 업로드(UPLOAD MODEL)(540)
사용자는 "UPLOAD MODEL" 구문을 사용하여 파이썬 환경에서 직접/자체적으로 만든 모델을 확장SQL을 기반으로 작동할 수 있도록 사용자의 모델을 확장 SQL로 업로드할 수 있다.
UPLOAD MODEL [사용자 지정 모델 이름]
OPTIONS([모델 업로드 시 필요한 옵션갑])
FROM [업로드 할 모델의 경로]
(5) 모델 적용하기(PREDICT)(550)
사용자는 "PREDICT" 구문을 사용하여 테스트 데이터 세트에 인공지능 모델을 적용하여 예측, 분류, 추천 등의 작업을 수행할 수 있다.
아래의 표 9는 "PREDICT" 구문의 예시이다.
<표 9>
PREDICT
USING [기존 학습한 모델 이름]
OPTIONS ([모델별 추론시 필요한 옵션값])
AS
[사용할 테스트 데이터 세트]
예를 들어, "PREDICT USING" 구문을 사용하여 기존에 모델 학습하기에서 만들어었던 기존 추천 모델을 사용하여 사용자 ID 31인 사용자가 좋아할만한 영화 목록에 대한 추천이 가능할 수 있다.
(6) 모델 삭제하기(DELETE MODEL)(560)
사용자는 "DELETE MODEL" 구문을 사용하여 생성되거나 업로드된 모델을 삭제할 수 있다.
아래의 표 10은 "DELETE MODEL" 구문의 예시이다.
<표 10>
DELETE MODEL [삭제할 모델 이름]
예를 들어, "DELETE MODEL" 구문을 기반으로 사용자가 모델 학습하기에서 만들었던 영화추천모델이 데이터베이스에서 삭제될 수 있다.
위와 같은 확장된SQL을 기반으로 비정형 데이터 및 정형 데이터를 기반으로 한 AI 모델링이 별도의 배치 프로세스 없이 하나의 플랫폼인 데이터 처리 시스템 상에서 수행될 수 있다.
데이터 처리 시스템 상에서는 미리 생성된 AI 모델 및 사용자에 의해 생성된 AI 모델이 위치할 수 있다. 이러한 AI 모델 생성을 통해 분류 모델, 회귀 모델, 추천 시스템, 음성 인식 모델 등 다양한 AI 모델에 대한 생성이 이루어질 수 있다.
도 6은 본 발명의 실시예에 따른 데이터 처리 시스템을 기반으로 한 데이터 처리 방법을 나타낸 개념도이다.
도 6에서는 전술한 데이터 처리 시스템을 기반으로 한 별도의 데이터베이스 상의 데이터 처리 방법이 개시된다.
도 6를 참조하면, 도 1에서 도 5에서 전술한 바와 같이 데이터 처리 시스템 자체 데이터베이스를 기반으로 한 정형 데이터 및 비정형 데이터의 처리가 수행될 수도 있다. 하지만, 사용자는 사용자의 데이터베이스를 사용하되, 데이터 처리 시스템에서 제공하는 확장 SQL 및 확장 SQL 엔진의 기능을 API를 기반으로 활용할 수 있다.
데이터 처리 시스템의 자체 데이터베이스를 기반으로 한 정형 데이터 및 비정형 데이터의 처리는 내부 데이터 처리라는 용어로 표현될 수 있다. 데이터 처리 시스템의 자체 데이터베이스가 아닌 외부 데이터베이스를 기반으로 한 정형 데이터 및 비정형 데이터의 처리는 외부 데이터 처리라는 용어로 표현될 수 있다.
내부 데이터 처리의 경우 전술한 도 1 내지 도 5에서 개시된 프로세스를 기반으로 처리될 수 있다.
외부 데이터 처리를 위해 외부에서 본 발명의 실시예에 따른 데이터 처리 시스템을 사용하기 위해서는 제공된 'API' 또는 '데이터 이전 방법'을 사용하여 외부 데이터를 본 발명의 데이터 처리 시스템에 저장 및 변환시켜줘야 한다. 저장 및 변환이 완료된 데이터들에 대해서는 API를 사용하여 본 발명의 데이터 처리 시스템을 활용할 수 있다. 즉, 자체 엔진과 PostgreSQL 엔진 모두 외부 데이터베이스가 아닌 본 발명의 실시예에 따른 데이터베이스를 액세스하여 데이터 처리를 수행할 수 있다.
외부 데이터 처리의 경우, 사용자는 사용자의 데이터베이스에 저장된 별도의 비정형 데이터를 기반으로 한 학습을 API를 통해 확장된 SQL 및 확장 SQL 엔진의 기능을 기반으로 수행할 수 있다.
예를 들어, 특정 사용자는 보안 업체로서 CCTV 영상을 저장하는 사용자 데이터베이스를 운영할 수 있다. 사용자는 본 발명의 데이터 처리 시스템의 확장된 SQL을 기반으로 CCTV 영상에 대한 인공지능학습을 사용자 데이터베이스에 저장된 데이터를 기반으로 수행할 수 있다. 외부 데이터베이스에서 본 발명의 데이터 처리 시스템의 데이터베이스로 정형 데이터 및 본 발명에서 정의된 비정형 데이터를 처리하기 위한 비정형 데이터에 대한 쿼리문을 기반으로 정형 데이터와 비정형 데이터가 삽입될 수 있다. 본 발명의 실시예에 따른 데이터 처리 시스템에 입력된 정형 데이터와 비정형 데이터에 대한 AI 모델링이 본 발명의 실시예에 따른 데이터 처리 시스템의 AI 엔진을 기반으로 수행될 수 있다.
즉, 복수의 서로 다른 데이터베이스 상의 정형 데이터와 비정형 데이터를 처리하는 방법은 데이터 처리 시스템이 외부 데이터베이스로부터 외부 데이터를 수신하는 단계, 상기 데이터 처리 시스템이 상기 외부 데이터를 변환하는 단계와 데이터 처리 시스템이 변환된 상기 외부 데이터를 처리하는 단계를 포함할 수 있다.
이때, 외부 데이터는 정형 데이터와 비정형 데이터를 포함하고, 데이터 처리 시스템은 네스티드 쿼리를 기반으로 정형 데이터 및 비정형 데이터를 처리하고, 네스티드 쿼리는 비정형 데이터에 대한 제1 쿼리 및 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리일 수 있다.
데이터 처리 시스템은 비정형 데이터 처리 쿼리를 기반으로 비정형 데이터를 처리하고, 데이터 처리 시스템은 정형 데이터 처리 쿼리를 기반으로 정형 데이터를 처리할 수 있다.
네스티드 쿼리는 비정형 데이터에 대한 제1 쿼리 및 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리이고, 비정형 데이터 처리 쿼리는 상기 비정형 데이터만을 처리하기 위한 쿼리이고, 정형 데이터 처리 쿼리는 정형 데이터만을 처리하기 위한 쿼리일 수 있다.
데이터 처리 시스템은 정형 데이터에 대한 데이터 테이블 및 비정형 데이터에 대한 데이터 테이블을 생성하여 하나의 데이터베이스 상에서 처리하고, 데이터 처리 시스템은 정형 데이터 및 비정형 데이터를 기반으로 한 인공 지능 엔진 모델링을 하나의 데이터베이스 상에서 지원할 수 있다.
도 7은 본 발명의 실시예에 따른 데이터 처리 시스템에서 쿼리를 분석하여 데이터를 처리하는 방법을 나타낸 개념도이다.
도 7에서는 입력된 쿼리를 분석하여 비정형 데이터 및 정형 데이터를 하나의 데이터 처리 시스템에서 처리를 수행하되 쿼리를 처리함에 있어 서로 다른 프로세싱 자원을 활용하는 방법이 개시된다.
도 7을 참조하면, 입력 쿼리로서 비정형 데이터 및/또는 정형 데이터에 대한 처리를 위한 쿼리가 입력될 수 있다. 입력된 쿼리는 비정형 데이터 또는 정형 데이터에 대한 일반 쿼리일 수도 있고, 비정형 데이터 및 정형 데이터에 대한 혼합적인 처리를 위한 네스티드 쿼리일 수도 있다.
입력 쿼리는 파서부(700)를 통해 파싱될 수 있다. 네스티트 쿼리는 일반 쿼리와 확장 쿼리로 구분되고, 파서부(700)는 일반 쿼리와 확장 쿼리를 분할할 수 있다.
입력 쿼리에 포함되는 복수의 쿼리는 클라우즈 아날라이즈부(clause analyze) (710) 및 쿼리 트리부(query tree)(720)를 통해 해석되어 처리될 수 있다.
본 발명에서는 설명의 편의상 입력 쿼리로서 네스티드 쿼리가 입력되고, 네스티드 쿼리는 제1 쿼리(715), 제2 쿼리(725) 및 제3 쿼리(735)를 포함할 수 있다. 클라우즈 아날라이즈부(710)는 제1 쿼리(715), 제2 쿼리(725) 및 제3 쿼리(735)에 대하여 어떠한 컴퓨팅 자원을 사용하여 프로세싱되어야 할지를 결정할 수 있다. 보다 구체적으로 클라우즈 아날라이즈부(710)는 네스티드 쿼리에 포함되는 복수의 쿼리에 대한 분석을 통해 쿼리가 CPU(770)에서 실행되어야 할지 GPU(780)에서 실행되어야 할지를 결정할 수 있다. 클라우즈 아날라이즈부(710)는 본 발명의 실시예에 따른 자원 분배 알고리즘을 기반으로 복수의 쿼리 각각의 실행 예상 능률 및 실행 예상 속도를 판단하고 실행 예상 능률 및 실행 예상 속도를 기반으로 복수의 쿼리 각각을 CPU(770) 또는 GPU(780)에 할당할 수 있다.
제1 쿼리(715) 및 제3 쿼리(735)는 확장 쿼리이고, 제2 쿼리(725)는 일반 쿼리인 경우가 가정될 수 있다. 제1 쿼리(715) 및 제3 쿼리(735)는 확장 SQL 엔진(760)을 기반으로 처리될 수 있고, 제2 쿼리(725)는 일반 쿼리로서 일반 쿼리 처리를 위한 SQL 엔진인 PostgreSQL 엔진(750)을 기반으로 처리될 수 있다.
이때, 자원 분배 알고리즘을 기반으로 제1 쿼리(715)는 GPU(780), 제3 쿼리(735)는 CPU(770), 제2 쿼리(725)는 GPU(780)를 기반으로 처리될 수 있다. 자원 분배 알고리즘을 기반으로 네스티드 쿼리의 처리 속도는 향상되고 컴퓨팅 자원은 보다 효율적으로 활용될 수 있다.
이러한 자원 분배 알고리즘은 일반 쿼리를 위한 SQL 엔진인 PostgreSQL 엔진(750)과 확장 쿼리를 위한 확장 SQL 엔진(760)에 모두 적용되어 활용될 수 있고, 모델링 역시 GPU를 사용하여 진행하기 때문에 빠른 모델링 결과가 도출될 수 있다.
도 8은 본 발명의 실시예에 따른 자원 분배 알고리즘을 나타낸 개념도이다.
도 8에서는 자원 분배 알고리즘을 기반으로 쿼리를 처리시 CPU 또는 GPU를 선택하기 위한 방법이 개시된다.
도 8을 참조하면, 확장 쿼리(800)와 일반 쿼리(820)를 처리시 CPU(860) 또는 GPU(850)를 사용할지 여부를 결정하는 방법이 개시된다.
(1) 확장 쿼리(800)
1) 확장 쿼리(800) 중 확장 엔진 상에서 GPU(850)를 필수적으로 사용해야 하는 모델을 기반으로 처리되어야 하는 제1 타입 확장 쿼리(803)는 GPU(850)를 기반으로 처리될 수 있다.
2) 확장 쿼리(800) 중 확장 엔진 상에서 GPU(850)를 필수적으로 사용하지 않아도 처리 가능한 제2 타입 확장 쿼리(806)는 컴퓨팅 리소스 중 CPU 실행 능력과 GPU 실행 능력을 고려하여 CPU(860) 또는 GPU(850)를 기반으로 처리될 수 있다.
CPU 실행 능력은 CPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. GPU 실행 능력은 GPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. CPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), CPU 연산 비용을 기반으로 결정되고, GPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), GPU 연산 비용을 기반으로 결정될 수 있다. 쿼리 처리 속도가 상대적으로 빠르고 리소스 사용량이 상대적으로 작고, 쿼리 비용이 상대적으로 작을 수록 실행 능력은 높게 판단될 수 있다.
(2) 일반 쿼리
일반 쿼리는 컴퓨팅 리소스 중 CPU 실행 능력과 GPU 실행 능력을 고려하여 CPU 또는 GPU를 기반으로 처리될 수 있다.
보다 구체적으로 확장 쿼리 및 일반 쿼리에 대한 CPU 실행 능력과 GPU 실행 능력은 전체 비용을 고려하여 결정될 수 있다. 전체 비용이 작을수록 더 유리한 자원일 수 있다.
전체 비용(total cost)은 스타트업 코스트(star-up cost)와 런 코스트(run cost)의 합일 수 있다.
스타트업 코스트는 첫번째 튜플(tuple)이 페치(fetch)되기 전에 발생되는 비용일 수 있다. 튜플은 데이터베이스 내의 주어진 목록과 관계있는 속성값의 모음이다.　예를 들어, 인덱스 스캔 노드(index scan node)의 스타트업 코스트는 타겟 테이블의 첫번째 튜플에 액세스하기 위해 인덱스 페이지를 읽기 위한 코스트이다.
런 코스트는 모든 튜플에 액세스하기 위한 비용일 수 있다.
보다 구체적으로 CPU 런 코스트와 GPU 런 코스트는 아래의 수학식과 같이 결정될 수 있다.
<수학식>
GPU run cost = (gpu_tuple_cost + gpu_operator_cost) x Ntuple + seq_page cost x Npage
CPU run cost = (cpu_tuple_cost + cpu_operator_cost) x Ntuple + seq_page cost x Npage
gpu_tuple_cost는 GPU가 연산시 테이블 행들을 프로세스하는 비용이다.
gpu_operator_cost는 GPU가 테이블 튜플을 오퍼레이터나 함수로 프로세스하는 비용이다.
cpu_tuple_cost는 CPU가 연산시 테이블 행들을 프로세스하는 비용이다
cpu_operator_cost는 CPU가 테이블 튜플을 오퍼레이터나 함수로 프로세스하는 비용이다.
N_tuple은 테이블 튜플의 개수이다.
seq_page cost는 페이지를 가지고 오는 비용이다.
Npage는 인덱스 페이지의 개수이다.
도 9는 본 발명의 실시예에 따른 입력 멀티-쿼리(input multi-query)를 처리하는 데이터 처리 시스템을 나타낸 개념도이다.
도 9에서는 입력 멀티-쿼리를 수신시 멀티-쿼리 스케줄러를 기반으로 입력 멀티-쿼리에 포함된 복수의 쿼리에 대한 처리를 스케줄링하는 방법이 개시된다.
도 9를 참조하면, 입력 멀티-쿼리(900)는 복수의 쿼리를 포함하는 쿼리일 수 있다. 예를 들어, 입력 멀티-쿼리(900)는 제1 쿼리, 제2 쿼리, 제3 쿼리 및 제4 쿼리를 포함할 수 있다. 제1 쿼리는 SELECT, 제2 쿼리, 제3 쿼리는 BUILD, 제4 쿼리는 PRINT일 수 있다.
멀티-쿼리 스케줄러(920)는 멀티-쿼리 분석부(multi-query analyzer)(940) 및 쿼리 큐(query queue)(960)를 포함할 수 있다.
멀티-쿼리 분석부(920)는 입력 멀티-쿼리(900)에 포함된 복수의 쿼리를 분석하여 복수의 쿼리의 처리 순서를 결정할 수 있다.
쿼리 큐(960)는 멀티-쿼리 분석부(920)에 의해 결정된 복수의 쿼리의 처리 순서를 고려하여 큐 상에 복수의 쿼리를 스케줄링할 수 있다.
큐 상에 스케줄링된 쿼리는 파서부로 전달될 수 있다. 이후 전술한 절차와 같이 쿼리는 파서부에서 파싱되어 일반 쿼리와 확장 쿼리로 분할되고, 클라우즈 아날라이즈부 및 쿼리 트리부를 통해 해석되어 처리될 수 있다.
클라우즈 아날라이즈부는 쿼리를 처리할 엔진 및 쿼리를 처리할 컴퓨팅 자원(CPU 또는 GPU)를 결정하여 결정된 엔진(PostgreSQL 엔진 또는 확장 엔진)으로 전달하여 처리할 수 있다.
도 10은 본 발명의 실시예에 따른 멀티-쿼리 스케줄러의 동작을 나타낸 개념도이다.
도 10에서는 멀티-쿼리 스케줄러의 복수의 쿼리를 스케줄링하기 위한 방법이 개시된다.
도 10을 참조하면, 멀티-쿼리 스케줄러(1000)는 멀티-쿼리 형태로 들어오는 입력 쿼리에 대한 종속성 스코어(1020) 및 컴퓨팅 자원 할당 데이터(1040)를 분석하고, 종속성 스코어(1020) 및 컴퓨팅 자원 할당 데이터(1040)를 기반으로 입력 멀티-쿼리에 포함되는 복수의 쿼리의 처리 순서를 결정할 수 있다.
종속성 스코어(1020)는 입력 멀티-쿼리에 포함되는 복수의 쿼리 간에 상호 상관 관계를 통해 결정될 수 있다. 예를 들어, 제3 쿼리가 제1 쿼리 및 제2 쿼리를 기반으로 처리된 결과에 종속적인 경우, 제3 쿼리는 제1 쿼리와 제2 쿼리에 대한 종속성을 가지는 쿼리일 수 있다. 제4 쿼리가 독립적으로 처리되는 경우, 제4 쿼리는 다른 쿼리에 대한 종속성을 가지지 않는 쿼리일 수 있다.
종속성 스코어(1020)는 다른 쿼리의 처리 이후에 수행될 수 있는 쿼리에 대하여 판단될 수 있고, 다른 쿼리에 대한 종속성이 높을수록 상대적으로 높은 값을 가질 수 있다.
컴퓨팅 자원 할당 데이터(1040)는 쿼리가 CPU와 GPU 어떠한 프로세싱 유닛을 기반으로 처리될지 및 쿼리가 CPU 또는 GPU를 기반으로 처리될 경우, 할당되는 컴퓨팅 자원에 대한 데이터일 수 있다.
예를 들어, 멀티-쿼리 스케줄러(1000)는 전술한 자원 분배 알고리즘을 기반으로 쿼리가 CPU와 GPU 어떠한 프로세싱 유닛을 기반으로 처리될지를 결정할 수 있다. 또한, 멀티-쿼리 스케줄러(1000)는 전술한 CPU 실행 능력 및 GPU 실행 능력을 판단하는 방법을 기반으로 쿼리가 CPU 또는 GPU를 기반으로 처리될 경우, 할당되는 컴퓨팅 자원에 대한 데이터를 획득할 수 있다.
CPU 실행 능력은 CPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. GPU 실행 능력은 GPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. CPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), CPU 연산 비용을 기반으로 결정되고, GPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), GPU 연산 비용을 기반으로 결정될 수 있다.
또한, 종속성 스코어(1020)는 쿼리의 타입에 따라 서로 다른 우선 순위를 기반으로 처리되도록 결정될 수 있다.
쿼리 중 CREATE, COPY, BUILD 등과 같은 테이블이나 모델을 생성하는 특별한 구문(clause)을 인식하고 이러한 타입의 쿼리가 먼저 실행되도록 스코어가 할당될 수 있다. 테이블이나 모델을 생성하기 위한 쿼리는 우선 처리 쿼리로 정의될 수 있고, 우선 처리 쿼리 내에서도 별도의 우선 순위가 스코어를 기반으로 부여될 수 있다.
예를 들어, 입력 멀티-쿼리에 포함되는 복수의 쿼리가 CREATE, SELECT_1, COPY, SELECT_2, PREDICT, BUILD인 경우, COPY, CREATE, BUILD는 우선 처리 쿼리로서 우선적으로 처리될 수 있다.
예를 들어, 종속성 스코어(1020)를 기반으로 COPY > CREATE > BUILD > PREDICT > SELECT_1 > SELECT_2 순서로 처리 우선 순위가 결정되고, 쿼리 큐는 쿼리를 수행하기 위한 큐(queue)를 재구성할 수 있다.
보다 구체적으로 멀티-쿼리 분석부는 1차적으로 입력 멀티-쿼리에 포함되는 복수의 쿼리의 종속성을 체크한 후 복수의 쿼리 각각의 실행 순서를 결정할 수 있다.
이후, 2차적으로 전술한 전체 비용을 고려하여 복수의 쿼리 각각에 대한 GPU 실행 능력 및 CPU 실행 능력이 결정될 수 있다. GPU 실행 능력 및 CPU 실행 능력을 기반으로 쿼리 그룹에 포함된 복수의 쿼리 각각이 CPU에 할당될지 GPU에 할당될지가 결정되고, 전체 비용이 낮을수록 빠르게 실행되도록 실행 순서가 결정될 수 있다.
보다 구체적으로 멀티-쿼리 분석부의 클라우즈 아날라이저는 입력 멀티 쿼리에 포함되는 복수의 쿼리의 상관 관계를 분석하고, 복수의 쿼리의 상관 관계(종속성)를 기초로 복수의 쿼리 중 특정 쿼리를 우선적으로 실행하도록 결정할 수 있다.
이후, 복수의 쿼리 각각에 대한 전체 비용(스타트업 코스트(star-up cost)와 런 코스트(run cost)의 합)이 결정될 수 있다. 또한, 복수의 쿼리 각각의 전체 비용 정보를 기초로 메이저 자원이 CPU 또는 GPU로 결정될 수 있다. 전체 코스트가 낮을수록 높은 우선 순위로서 처리되도록 큐에 쌓이되, 실행 능력에 따라 메이저 자원으로서 CPU, GPU를 선택적으로 사용되도록 복수의 쿼리 그룹이 큐에 쌓일 수 있다.
마지막으로 복수의 쿼리에 포함되는 쿼리의 위치를 추가적으로 고려하여 입력 멀티 쿼리의 앞단에 위치한 쿼리일수록 높은 우선 순위로서 처리되도록 큐에 쌓일 수 있다.
예를 들어, 쿼리 1 내지 쿼리4가 존재하는 경우가 가정될 수 있다.
쿼리 1은 1순위로 작은 전체 비용을 가지고, GPU를 메이저 자원으로 사용하고, 입력 멀티-쿼리에 가장 앞부분에 작성된 쿼리를 포함할 수 있다.
쿼리 2는 3순위로 작은 전체 비용을 가지고 GPU를 메이저 자원으로 사용할 수 있다.
쿼리 3은 2순위의 작은 전체 비용을 가지고 CPU를 메이저 자원으로 사용할 수 있다.
쿼리 4은 4순위로 작은 전체 비용을 가지고 CPU를 메이저 자원으로 사용하고, 입력 멀티-쿼리에 가장 뒷부분에 작성된 쿼리를 포함할 수 있다. 이러한 경우, 쿼리 1, 쿼리 3, 쿼리 2, 쿼리 4의 순서로 처리되도록 큐에 쿼리 그룹이 쌓일 수 있다.
도 11은 본 발명의 실시예에 따른 입력 멀티-쿼리를 처리하는 방법을 나타낸 개념도이다.
도 11에서는 입력 멀티 쿼리에 포함되는 쿼리 그룹의 실행 순서를 결정하는 알고리즘이 개시된다.
도 11을 참조하면, 멀티-쿼리 분석부의 클라우즈 아날라이저에 의해 복수의 쿼리 그룹의 메이저 자원과 전체 비용이 결정된 이후, 종속성, 전체 비용, 쿼리의 위치를 고려하여 쿼리 그룹의 실행 순서가 결정될 수 있다.
예를 들어, 쿼리1(1110)은 전체 비용 3, 쿼리문으로 PREDICT USING(my_model)을 포함한다. 쿼리2(1120)은 전체 비용 2, 쿼리문으로 CREATE TABLE(my_model)을 포함한다. 쿼리3(1130)은 전체 비용 5, 쿼리문으로 BUILD MODEL(my_model)을 포함할 수 있다.
이러한 경우, 쿼리1(1110)과 쿼리2(1120)에서 사용되는 my_model은 쿼리3(1130)에서 먼저 생성되고 사용 가능하므로 쿼리1(1110)과 쿼리2(1120)은 쿼리3(1130)에 대하여 종속성을 가진다. 따라서, 쿼리3(1130)의 전체 코스트가 높고 위치가 가장 뒤임에도 불구하고 가장 먼저 실행될 수 있다.
쿼리3(1130)의 다음으로 전체 비용을 고려하여 전체 비용 1인 쿼리2(1120)가 실행되고, 마지막으로 전체 비용 3인 쿼리1(1110)이 실행될 수 있다.
만약 쿼리1(1110)과 쿼리2(1120)의 전체 비용이 동일하다면, 쿼리문의 위치를 고려하여, 쿼리 3(1130)의 실행 이후, 쿼리1(1110), 쿼리2(1120)의 순서로 쿼리가 실행될 수 있다.
도 12는 본 발명의 실시예에 따른 정형 데이터 및 비정형 데이터에 대한 처리 서비스를 제공하는 서버를 나타낸 개념도이다.
도 12에서는 서로 다른 아키텍쳐를 기반으로 사용자 장치로 정형 데이터 및 비정형 데이터에 대한 처리 서비스를 제공하기 위한 서버가 개시된다.
도 12를 참조하면, 서버(1200)는 인스턴스(instance)(1210)와 리소스(resource)를 포함할 수 있다. 인스턴스는 워크 스페이스 허브(1270, 1280)와 데이터 처리 엔진(1220)을 포함하고, 리소스는 프로세싱 자원(1240)과 스토리지(1230), 메모리(미도시)를 포함할 수 있다. 워크 스페이스 허브(1270, 1280)는 적어도 하나의 워크 스페이스(1250)를 포함할 수 있다.
워크 스페이스(1250)는 직접적으로 워크 스페이스(1250)에 대응되는 스토리지(1230)에만 연결될 수 있고, 데이터 처리 엔진(1220)은 모든 스토리지(1230)에 연결될 수 있다. 인스턴스는 리소스와 직접적으로 연결된 구조를 가질 수 있다.
이하에서는 보다 구체적으로 서버(1200)를 구성하는 인스턴스 및 리소스에 대해 개시한다.
워크 스페이스 허브(1270, 1280)는 공유 아키텍쳐(shared architecture)를 기반으로 구현되는 공유 워크 스페이스 허브(1270), 전용 아키텍쳐(dedicated architecture)를 기반으로 구현되는 전용 워크 스페이스 허브(1280)를 포함할 수 있다.
공유 워크 스페이스 허브(1270)와 전용 워크 스페이스 허브(1280)는 워크 스페이스(1250)를 포함할 수 있다. 워크 스페이스(1250)는 사용자에 의한 정형 데이터 및 비정형 데이터를 기반으로 한 서비스를 구현하기 위한 공간일 수 있다. 예를 들어, 하나의 워크 스페이스(1250)는 하나의 사용자 식별자를 기반으로 부여될 수 있다. 워크 스페이스(1250)는 랩(lab)과 데이터베이스(database)를 포함할 수 있다. 랩은 사용자에 의해 구현되는 서비스를 위한 쿼리를 생성하는 공간이고, 데이터베이스는 조직화된 데이터를 저장하는 논리적 저장소이다. 다른 표현으로 랩은 워크 스페이스(1250)에 액세스하기 위한 사용자 인터페이스일 수 있다.
공유 워크 스페이스 허브(1270)는 복수의 사용자들의 복수의 워크 스페이스(1250)를 포함할 수 있다. 공유 워크 스페이스 허브(1270)는 할당된 데이터 처리 엔진(1220), 할당된 프로세싱 자원(1240)을 공유할 수 있다. 전용 워크 스페이스 허브(1280)는 하나의 사용자에 대한 워크 스페이스(1250)를 포함할 수 있다. 전용 워크 스페이스 허브(1280)에는 하나의 사용자가 전용으로 사용할 데이터 처리 엔진(1220) 및 프로세싱 자원(1240)이 할당될 수 있다.
설명의 편의상 공유 워크 스페이스 허브(1270)와 전용 워크 스페이스 허브(1280)는 하나씩만 표현되었으나, 공유 워크 스페이스 허브(1270)와 전용 워크 스페이스 허브(1280)는 복수개 존재할 수 있고, 이러한 아키텍쳐 구조도 본 발명의 권리 범위에 포함될 수 있다.
보다 구체적으로 공유 워크 스페이스 허브(1270)는 할당된 데이터 처리 엔진(1220)과 할당된 프로세싱 자원(1240)을 사용할 수 있다. 공유 워크 스페이스 허브(1270)는 복수의 워크 스페이스(1250)를 포함할 수 있다. 복수의 워크 스페이스(1250)는 할당된 데이터 처리 엔진(1220)과 할당된 프로세싱 자원(1240)을 공유할 수 있다.
전용 워크 스페이스 허브(1280)는 하나의 워크 스페이스(1250)만을 포함하고, 하나의 워크 스페이스(1250)는 할당된 데이터 처리 엔진(1220)과 할당된 프로세싱 자원(1240)을 전용으로 사용할 수 있다.
따라서, 사용자는 처리할 정형 데이터, 비정형 데이터의 양, 정형 데이터 및 비정형 데이터를 기반으로 구현될 서비스를 기반으로 공유 워크 스페이스(1270) 또는 전용 워크 스페이스(1280)를 선택적으로 선택하여 워크 스페이스(1250)를 생성할 수 있다.
데이터 처리 엔진(1220)은 도 2 내지 도 11에서 전술한 데이터 처리 시스템으로서 비정형 데이터와 정형 데이터에 대한 쿼리를 PostgreSQL와 확장 SQL를 기반으로 처리할 수 있다. 즉, 데이터 처리 엔진(1220)은 도 2 내지 도 11에서 전술한 데이터 처리 시스템의 동작을 수행할 수 있다.
데이터 처리 엔진(1220)은 워크 스페이스(1250)를 기반으로 한 사용자 요청을 통해 사용자를 위한 모델을 생성할 수 있고, 사용자를 위한 모델은 생성되어 스토리지(1230) 상에 저장될 수 있다.
사용자는 API(application programming interface) 및 사용자 고유 식별 정보를 기반으로 외부에서 데이터 처리 엔진(1220)을 통해 사용자의 스토리지(1230)에 저장된 모델을 기반으로 한 출력값을 요청하기 위한 쿼리를 전달할 수 있다. 데이터 처리 엔진(1220)은 사용자 고유 식별 정보를 기반으로 사용자의 워크 스페이스(1250)를 확인하고, 스토리지(1230)에 저장된 모델을 기반으로 출력값을 사용자에게 전달할 수 있다.
데이터 처리 엔진(1220)은 모든 스토리지(1230)에 액세스 가능하게 구현되고 사용자의 요청에 따라 사용자 고유 식별 정보를 기반으로 스토리지(1230)에 접근하여 스토리지(1230)에 저장된 데이터를 활용할 수 있다.
스토리지(1230)는 파일, 모델 등에 대한 물리적인 저장소일 수 있고, 하나의 워크 스페이스(1250)는 하나의 스토리지(1230)에 연결되어 사용자 고유 식별 정보를 인증받은 경우에만 액세스 가능할 수 있다.
프로세싱 자원(1420)은 GPU, CPU, 메모리를 포함할 수 있다. 전술한 바와 같이 CPU와 GPU는 자원 분배 알고리즘을 기반으로 쿼리를 처리시 선택될 수 있다. 또한, CPU와 GPU는 멀티-쿼리 스케줄러를 기반으로 선택되어 멀티-쿼리를 처리하기 위해 선택적으로 사용될 수 있다.
전용 워크 스페이스 허브(1280)의 워크 스페이스(1250)는 할당된 자원을 독점적으로 사용할 수 있다. 공유 워크 스페이스 허브(1270)의 복수의 워크 스페이스(1250)는 할당된 자원을 공유한다. 따라서, 복수의 워크 스페이스(1250) 각각에 의해 요청된 쿼리는 순차적으로 처리될 수 있다.
도 13은 본 발명의 실시예에 따른 공유 워크 스페이스 허브의 쿼리 처리 방법을 나타낸 개념도이다.
도 13에서는 공유 워크 스페이스 허브에 포함되는 복수의 워크 스페이스 각각에 의한 쿼리를 처리하기 위한 방법이 개시된다.
도 13을 참조하면, 공유 워크 스페이스 허브에 포함되는 개별 워크 스페이스에 대한 쿼리 처리는 전술한 자원 배분 알고리즘을 기반으로 처리될 수 있다.
하지만, 복수의 워크 스페이스에 의해 생성된 쿼리는 큐(queue)(1300)/스택(stack)을 기반으로 순차적으로 처리될 수 있다. 즉, 개별 워크 스페이스의 쿼리에 대한 처리는 자원 배분 알고리즘을 기반으로 수행되고, 복수의 워크 스페이스의 쿼리에 대한 처리는 시퀀셜(sequential)하게 쿼리 생성 시간을 고려하여 순차적으로 처리될 수 있다.
도 14는 본 발명의 실시예에 따른 자원 분배 방법을 나타낸 개념도이다.
도 14에서는 워크 스페이스의 특성을 고려하여 프로세싱 자원을 할당하기 위한 방법이 개시된다.
도 14를 참조하면, 워크 스페이스 허브(전용 워크 스페이스 허브, 공유 워크 스페이스 허브)의 특성을 고려하여 프로세싱 자원(CPU, GPU, 메모리)을 할당하기 위한 방법이 개시된다.
프로세싱 자원을 할당하기 위한 워크 스페이스 허브의 특성은 정형 데이터에 대한 쿼리의 볼륨(1400), 비정형 데이터에 대한 쿼리의 볼륨(1410), 쿼리의 처리를 위해 필요한 데이터 처리량(1420)을 포함할 수 있다.
워크 스페이스가 비정형 데이터에 대한 쿼리(이하, 비정형 쿼리)를 상대적으로 많이 사용할수록 GPU를 상대적으로 많이 사용하게 된다.
워크 스페이스가 정형 데이터에 대한 쿼리(이하, 정형 쿼리)를 상대적으로 많이 사용할수록 또한, 쿼리 요청수가 상대적으로 많을수록 CPU를 상대적으로 많이 사용하게 된다.
워크 스페이스가 쿼리를 처리함에 있어서 많은 데이터양의 처리가 필요할수록 상대적으로 메모리가 많이 할당될 수 있다.
본 발명의 실시예에 따르면, 워크 스페이스 허브 별로 사용되는 정형 데이터에 대한 정형 쿼리의 볼륨, 비정형 데이터에 대한 비정형 쿼리의 볼륨, 쿼리의 처리를 위해 필요한 데이터 처리량을 고려하여 워크 스페이스 허브에 대한 자원이 적응적으로 할당될 수 있다.
본 발명의 실시예에 따르면, 전용 워크 스페이스 허브에 포함되는 워크 스페이스(이하, 워크 스페이스(전용)의 경우, 설정된 한도 내의 프로세싱 자원을 공유하지 않고 사용한다. 본 발명의 실시예에 따르면, 워크 스페이스(전용)은 발생된 정형 쿼리 데이터, 비정형 쿼리 데이터, 데이터 처리량에 대한 통계 정보인 프로세싱 자원 사용 통계 데이터를 기반으로 워크 스페이스(전용)에 대한 CPU, GPU, 메모리의 제공 한도를 적응적으로 조절할 수 있다. 예를 들어, 워크 스페이스1(전용)은 CPU가 상대적으로 많이 필요할 수 있고, 이러한 경우, 제한 한도 내에서 사용하지 않는 GPU 자원 할당량이 치환되어 CPU 자원으로 전환되어 사용될 수 있다. 워크 스페이스2(전용)은 GPU가 상대적으로 많이 필요할 수 있고, 이러한 경우, 제한 한도 내에서 사용하지 않는 CPU 자원 할당량이 치환되어 GPU 자원으로 전환되어 사용될 수 있다.
공유 워크 스페이스 허브에 포함되는 워크 스페이스(이하, 워크 스페이스(공유)의 경우, 프로세싱 자원을 공유하여 사용하게 된다.
따라서, 프로세싱 자원의 공유를 위해 공유 워크 스페이스 허브에 포함되는 복수의 워크 스페이스(공유)의 프로세싱 자원 사용 통계 데이터를 기반으로 프로세싱 자원이 할당될 수 있다. 공유 워크 스페이스 허브에 프로세싱 자원을 할당하는 방식은 고정 방식과 변동 방식이 존재할 수 있다.
고정 방식은 하나의 공유 워크 스페이스 허브에 할당되는 프로세싱 자원을 포함되는 워크 스페이스(공유)의 개수에 따라 설정하는 방식이다.
고정 방식이 사용되는 경우, 공유 워크 스페이스 허브에 포함되는 복수의 워크 스페이스는 복수의 워크 스페이스 각각에서 사용되는 프로세싱 자원 사용 통계 각각을 고려하여 공유 워크 스페이스 허브에 할당되는 워크 스페이스가 결정될 수 있다. 예를 들어, 상대적으로 CPU를 GPU보다 많이 사용하는 워크 스페이스와 상대적으로 GPU를 CPU보다 많이 사용하는 워크 스페이스가 그룹핑되어 전체적으로 균형있는 프로세싱 자원이 이루어지도록 워크 스페이스가 공유 워크 스페이스 허브에 할당될 수 있다.
변동 방식은 하나의 공유 워크 스페이스 허브에 할당되는 프로세싱 자원을 복수의 공유 워크 스페이스 허브에서 사용되는 프로세싱 자원을 고려하여 할당하는 방식이다. 변동 방식에서는 복수의 공유 워크 스페이스 허브에서 사용되는 프로세싱 자원이 결정되고, 복수의 공유 워크 스페이스 허브 각각의 프로세싱 자원 사용 통계를 고려하여 복수의 공유 워크 스페이스 허브 각각으로 서로 다른 CPU 자원, GPU 자원, 메모리가 할당될 수 있다.
고정 방식과 변동 방식은 전체 프로세싱 자원의 사용량을 고려하여 안정적인 프로세싱 자원의 공급이 필요한 경우, 고정 방식이 사용되고, 보다 효율적인 프로세싱 자원의 공급이 필요한 경우, 변동 방식이 사용될 수 있다. 예를 들어, 특정 시간대(업무 시간)의 경우, 고정 방식으로 프로세싱 자원을 제공하고, 예를 들어, 특정 시간대(비업무 시간)의 경우, 변동 방식으로 프로세싱 자원을 제공하여 사용하지 않는 프로세싱 자원이 최대한 효율적으로 활용하도록 할 수 있다.
더 큰 단위로는 서버 단위로 프로세싱 자원 사용 통계를 기반으로 복수의 서버 상에 워크 스페이스 허브 및 워크 스페이스가 할당될 수 있다.
이상 설명된 본 발명에 따른 실시예는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위하여 하나 이상의 소프트웨어 모듈로 변경될 수 있으며, 그 역도 마찬가지이다.
이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항과 한정된 실시예 및 도면에 의하여 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위하여 제공된 것일 뿐, 본 발명이 상기 실시예에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정과 변경을 꾀할 수 있다.
따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

Claims (6)

  1. 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법은,
    서버가 워크 스페이스 허브 상의 워크 스페이스를 할당하는 단계;
    상기 서버가 상기 워크 스페이스에 대응되는 데이터 처리 엔진 및 프로세싱 자원을 할당하는 단계; 및
    상기 서버가 상기 워크 스페이스를 기반으로 한 쿼리를 처리하는 단계를 포함하는 방법.
  2. 제1항에 있어서,
    상기 워크 스페이스는 상기 워크 스페이스에 대응되는 스토리지에만 연결되고,
    상기 데이터 처리 엔진은 상기 워크 스페이스를 포함하는 복수의 워크 스페이스에 대응되는 복수의 스토리지와 모두 연결되는 것을 특징으로 하는 방법.
  3. 제2 항에 있어서,
    상기 워크 스페이스 허브는 상기 데이터 처리 엔진 및 상기 프로세싱 자원의 공유 여부에 따라 공유 워크 스페이스 허브 및 전용 워크 스페이스 허브로 구분되는 것을 특징으로 하는 방법.
  4. 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 서버는,
    워크 스페이스 허브 상의 워크 스페이스를 할당하고,
    상기 워크 스페이스에 대응되는 데이터 처리 엔진 및 프로세싱 자원을 할당하고,
    상기 워크 스페이스를 기반으로 한 쿼리를 처리하도록 구현되는 것을 특징으로 하는 서버.
  5. 제4항에 있어서,
    상기 워크 스페이스는 상기 워크 스페이스에 대응되는 스토리지에만 연결되고,
    상기 데이터 처리 엔진은 상기 워크 스페이스를 포함하는 복수의 워크 스페이스에 대응되는 복수의 스토리지와 모두 연결되는 것을 특징으로 하는 서버.
  6. 제5항에 있어서,
    상기 워크 스페이스 허브는 상기 데이터 처리 엔진 및 상기 프로세싱 자원의 공유 여부에 따라 공유 워크 스페이스 허브 및 전용 워크 스페이스 허브로 구분되는 것을 특징으로 하는 서버.
PCT/KR2022/020508 2022-12-05 2022-12-15 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버 WO2024122709A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220167683A KR102605932B1 (ko) 2022-12-05 2022-12-05 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버
KR10-2022-0167683 2022-12-05

Publications (1)

Publication Number Publication Date
WO2024122709A1 true WO2024122709A1 (ko) 2024-06-13

Family

ID=88968362

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/020508 WO2024122709A1 (ko) 2022-12-05 2022-12-15 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버

Country Status (2)

Country Link
KR (1) KR102605932B1 (ko)
WO (1) WO2024122709A1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150056258A (ko) * 2013-11-15 2015-05-26 (주)가이온 생산성을 향상시킬 수 있는 정형 및 비정형의 빅데이터 엔진 및 처리 방법
KR20160052524A (ko) * 2016-04-29 2016-05-12 주식회사 아이온커뮤니케이션즈 SaaS 애플리케이션 빌드를 지원하는 멀티 워크 스페이스 시스템
KR20180075852A (ko) * 2016-12-27 2018-07-05 전자부품연구원 비정형 빅데이터 처리를 통한 지능형 마케팅 분석 시스템 및 방법
KR101927450B1 (ko) * 2016-12-29 2018-12-10 주식회사 와이즈넛 대용량 비정형 데이터를 처리하는 rest api 서비스 제공 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150056258A (ko) * 2013-11-15 2015-05-26 (주)가이온 생산성을 향상시킬 수 있는 정형 및 비정형의 빅데이터 엔진 및 처리 방법
KR20160052524A (ko) * 2016-04-29 2016-05-12 주식회사 아이온커뮤니케이션즈 SaaS 애플리케이션 빌드를 지원하는 멀티 워크 스페이스 시스템
KR20180075852A (ko) * 2016-12-27 2018-07-05 전자부품연구원 비정형 빅데이터 처리를 통한 지능형 마케팅 분석 시스템 및 방법
KR101927450B1 (ko) * 2016-12-29 2018-12-10 주식회사 와이즈넛 대용량 비정형 데이터를 처리하는 rest api 서비스 제공 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Beginning Azure Synapse Analytics: Transition from Data Warehouse to Data Lakehouse", 16 June 2021, ISBN: 9781484270608, article SHIYAL, B. , pages: 73 - 183, XP009555316 *

Also Published As

Publication number Publication date
KR102605932B1 (ko) 2023-11-30

Similar Documents

Publication Publication Date Title
WO2018159997A1 (ko) 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치
WO2020009297A1 (ko) 도메인 추출기반의 언어 이해 성능 향상장치및 성능 향상방법
WO2019177182A1 (ko) 속성 정보 분석을 통한 멀티미디어 컨텐츠 검색장치 및 검색방법
WO2012074338A2 (ko) 자연어 및 수학식 처리 방법과 그를 위한 장치
WO2021060609A1 (ko) 복수의 엣지와 클라우드를 포함하는 분산 컴퓨팅 시스템 및 이의 적응적 지능 활용을 위한 모델 제공 방법
WO2023080276A1 (ko) 쿼리 기반 데이터베이스 연동 딥러닝 분산 시스템 및 그 방법
WO2018034426A1 (ko) 커널 ｒｄｒ을 이용한 태깅 말뭉치 오류 자동수정방법
WO2020101108A1 (ko) 인공지능 모델 플랫폼 및 인공지능 모델 플랫폼 운영 방법
WO2018174603A1 (ko) 인공 지능 기술 기반의 머신 러닝을 사용하는 특허 도면 이미지에 도면 부호의 설명이 표시되도록 처리하는 방법 및 장치
WO2018117619A1 (en) Display apparatus, content recognizing method thereof, and non-transitory computer readable recording medium
WO2015129989A1 (ko) 콘텐츠 및 음원 추천 장치 및 방법
WO2019088334A1 (ko) 빅 데이터의 실시간 저장 및 검색 시스템
WO2011155736A9 (ko) 모든 자연어 표현의 각각의 의미마다 별도의 용어를 동적으로 생성하는 방법 및 이를 기반으로 하는 사전 관리기,문서작성기, 용어 주석기, 검색 시스템 및 문서정보체계 구축장치
WO2017095195A1 (ko) 시스템 리소스 관리를 위한 방법 및 장치
WO2023172025A1 (ko) 시계열적 정보를 인코딩하는 모델을 사용하여 개체-쌍 사이의 연관성 관련 정보를 예측하는 방법 및 이를 이용하여 생성되는 예측 시스템
WO2017146338A1 (ko) 인덱스정보를 생성하는 데이터베이스의 아카이빙 방법 및 장치, 인덱스정보를 포함하는 아카이빙된 데이터베이스의 검색 방법 및 장치
WO2024122709A1 (ko) 워크 스페이스 기반으로 비정형 데이터 및 정형 데이터에 대한 데이터 처리 서비스를 제공하는 방법 및 이러한 방법을 수행하는 서버
WO2021112647A1 (en) Method, apparatus and electronic device for determining word representation vector
WO2024071505A1 (ko) 멀티-쿼리 스케줄러를 기반으로 멀티-쿼리를 처리하는 방법 및 이러한 방법을 제공하는 데이터 처리 시스템
WO2011068315A4 (ko) 최대 개념강도 인지기법을 이용한 최적의 데이터베이스 선택장치 및 그 방법
WO2018043843A1 (ko) 낮은 데이터 중복으로 빠른 쿼리 처리를 지원하는 관계형 데이터베이스 저장 시스템, 저장 방법 및 관계형 데이터베이스 저장 방법에 기초한 쿼리를 처리하는 방법
WO2024071504A1 (ko) 서로 다른 프로세서 자원을 할당하여 정형 데이터와 비정형 데이터를 처리하는 방법 및 이러한 방법을 제공하는 데이터 처리 시스템
WO2021230469A1 (ko) 아이템 추천 방법
WO2017094967A1 (ko) 자연 언어 처리 스키마 및 그 지식 데이터베이스 구축 방법 및 시스템
WO2023055047A1 (en) Prediction model training method, information prediction method and corresponding device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22967967

Country of ref document: EP

Kind code of ref document: A1