EA036384B1 - Способ и система комплексного управления большими данными - Google Patents
Способ и система комплексного управления большими данными Download PDFInfo
- Publication number
- EA036384B1 EA036384B1 EA201892256A EA201892256A EA036384B1 EA 036384 B1 EA036384 B1 EA 036384B1 EA 201892256 A EA201892256 A EA 201892256A EA 201892256 A EA201892256 A EA 201892256A EA 036384 B1 EA036384 B1 EA 036384B1
- Authority
- EA
- Eurasian Patent Office
- Prior art keywords
- data
- subsystem
- loading
- processing
- tfs
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 238000012545 processing Methods 0.000 claims abstract description 61
- 238000003860 storage Methods 0.000 claims abstract description 25
- 238000013500 data storage Methods 0.000 claims abstract description 22
- 238000012546 transfer Methods 0.000 claims abstract description 14
- 238000007726 management method Methods 0.000 claims abstract description 7
- 238000006243 chemical reaction Methods 0.000 claims abstract description 4
- 238000012384 transportation and delivery Methods 0.000 claims description 14
- 230000008569 process Effects 0.000 claims description 11
- 230000032258 transport Effects 0.000 claims description 10
- 230000008859 change Effects 0.000 claims description 5
- 238000000638 solvent extraction Methods 0.000 claims description 5
- 230000009466 transformation Effects 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 4
- 230000009471 action Effects 0.000 claims description 3
- 230000006870 function Effects 0.000 claims description 3
- 238000000844 transformation Methods 0.000 claims description 3
- 238000005192 partition Methods 0.000 description 4
- 230000015572 biosynthetic process Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 240000001436 Antirrhinum majus Species 0.000 description 1
- 241001025261 Neoraja caerulea Species 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000005266 casting Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 210000001525 retina Anatomy 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
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/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Изобретение относится к управлению большими объемами данных, в частности к системе и способу для их обработки и унифицированного хранения. Достигаемый технический результат совпадает с решаемой технической проблемой и заключается в повышении эффективности хранения больших объемов данных за счет применения распределенной архитектуры хранения с обеспечением обработки входных данных с целью их унификации. Изобретение осуществляется с помощью системы комплексного управления большими данными (Big Data), содержащая подсистему транспортировки и проверки входных данных (далее TFS), подсистему загрузки внешних данных (далее xStream), функционирующую на основании стандарта описания данных, в которой TFS осуществляет прием, проверку и передачу в xStream данных, поступающих от источников данных, причем TFS принимает данные в архивированном виде и осуществляет передачу данных по транспортному протоколу; xStream содержит подсистему загрузки файлов, подсистему обработки и архивирования данных, подсистему доступа к данным (далее hCatalog), модуль управления загрузкой данных и модуль управления доступом, причем в xStream подсистема загрузки файлов осуществляет опрос TFS для передачи данных, поступивших от источников, в подсистему обработки и архивирования данных, причем источники данных предварительно регистрируются в подсистеме загрузки данных; подсистема загрузки данных выполняет первичное копирование файлов, поступающих от TFS, в подсистему обработки и архивирования; подсистема обработки и архивирования содержит области хранения данных, которые осуществляют структурированное хранение первичных данных, промежуточных данных и публикуемых данных; в область хранения первичных данных передаются файлы из подсистемы загрузки данных, которые соответствуют установленным параметрам архивирования и хранятся в первоначально заархивированном виде; подсистема обработки и архивирования выполнена с возможностью передачи в область промежуточных данных разархивированных первичных данных, преобразованных в формат parquet для дальнейших преобразований; в область публикуемых данных передаются подготовленные, преобразованные, унифицированные данные, приведенные к стандарту xStream, и из унифицированных данных области публикуемых данных формируется структурированный каталог для доступа к упомянутым данным посредством hCatalog.
Description
Область техники
Изобретение относится к управлению большими объемами данных, в частности к системе и способу для их обработки и унифицированного хранения.
Уровень техники
Из уровня техники известны различные решения по организации систем хранения данных на основе распределенных файловых систем (HDFS/Hadoop File System), которые, в частности, применяются для работы с большими данными. Под термином большие данные (Big Data) понимается огромный объем данных, поступающих в систему хранения. Данные, как правило, поступают из множества источников информации в неструктурированном виде. Big Data включает в себя также технологии их обработки и использования, методы поиска необходимой информации в больших массивах.
Основная проблема больших данных связана с большим количеством информации, которую необходимо обрабатывать и, соответственно, хранить доверенным образом с минимизацией рисков потери данных. В связи с этим возникает необходимость резервного копирования данных, которая подразумевает организацию объемных структур хранения данных. Однако с увеличением объема информации растут сложности с ее резервированием.
HDFS, или распределенная файловая система Hadoop - это основная система хранения данных, используемая приложениями Hadoop. HDFS многократно копирует блоки данных и распределяет эти копии по вычислительным узлам кластера, тем самым обеспечивая высокую надежность и скорость вычислений.
Из уровня техники известна архитектура хранилища данных для предоставления совместного доступа к данным, хранимым в нем (US 20130262615, 03.10.2013). Хранилище данных может быть реализовано с помощью HDFS и представлять фильтр для поступающей информации для ее первичной обработки при непосредственном сохранении для последующего использования. Система хранения функционирует с помощью формирования копий, поступающих данных из разнородных источников для последующей связки их с помощью метаданных для целей доступа к ним.
В заявке CN 106407309 (Wei et al., 15.02.2017) описывается механизм кластерного хранилища для получения информации из множества различных источников данных и обеспечения процесса аутентификации между базой данных и источниками данных.
Известное решение обладает существенными недостатками, которые заключаются в отсутствии обработки поступающих данных с целью их преобразования в унифицированный вид, что не позволяет оперативно обновлять информацию от источников, и снижает эффективность работы хранилища данных. Также, отсутствие процесса унификации данных приводит к низкой отказоустойчивости системы хранения в случае поступления данных в неправильном или неподдерживаемом формате (ошибки транспортного формата, ошибки архивирования, ошибки копирования, ошибки структуры данных, ошибки типов данных).
Раскрытие изобретения
Решаемой технической проблемой с помощью заявленного способа и системы является устранение недостатков, присущих известным аналогам, а также создание нового принципа эффективного хранения больших объемов данных.
Достигаемый технический результат совпадает с решаемой технической проблемой и заключается в повышении эффективности хранения больших объемов данных за счет применения распределенной архитектуры хранения с обеспечением обработки входных данных с целью их унификации.
Дополнительным техническим эффектом является повышение отказоустойчивости системы хранения данных за счет архитектуры системы управления хранением больших данных и обеспечения унификации хранимых данных.
Изобретение осуществляется с помощью системы комплексного управления большими данными (Big Data), содержащая подсистему транспортировки и проверки входных данных (далее TFS), подсистему загрузки внешних данных (далее xStream), функционирующую на основании стандарта описания данных, в которой
TFS осуществляет прием, проверку и передачу в xStream данных, поступающих от источников данных, причем TFS принимает данные в архивированном виде и осуществляет передачу данных по транспортному протоколу;
xStream содержит подсистему загрузки файлов, подсистему обработки и архивирования данных, подсистему доступа к данным (далее hCatalog), модуль управления загрузкой данных и модуль управления доступом, причем в xStream подсистема загрузки файлов осуществляет опрос TFS для передачи данных, поступивших от источников, в подсистему обработки и архивирования данных, причем источники данных предварительно регистрируются в подсистеме загрузки данных;
подсистема загрузки данных выполняет первичное копирование файлов, поступающих от TFS, в подсистему обработки и архивирования;
подсистема обработки и архивирования содержит области хранения данных, которые осуществляют структурированное хранение первичных данных, промежуточных данных и публикуемых данных;
в область хранения первичных данных передаются файлы из подсистемы загрузки данных, которые
- 1 036384 соответствуют установленным параметрам архивирования и хранятся в первоначально заархивированном виде;
подсистема обработки и архивирования выполнена с возможностью передачи в область промежуточных данных разархивированных первичных данных, преобразованных в формат parquet для дальнейших преобразований;
в область публикуемых данных передаются подготовленные, преобразованные, унифицированные данные, приведенные к стандарту xStream, в которых имена таблиц и полей приведены к стандарту xStream, типы данных приведены к стандарту xStream, таблицы дополнены обязательными техническими полями, описывающими поставку данных - датами начала и конца периода актуальности поставки данных, номерами потоков, выполнивших загрузку и преобразование;
и из унифицированных данных области публикуемых данных формируется структурированный каталог для доступа к упомянутым данным посредством hCatalog.
В одном из частных вариантов реализации системы TFS осуществляет проверку целостности получаемых архивных данных.
В другом частном варианте реализации системы для зарегистрированных источников в модуле управления загрузкой хранится ID упомянутых источников.
В другом частном варианте реализации системы модуль управления загрузкой осуществляет управление потоком данных множества источников по соответствующим сохраненным ID.
В другом частном варианте реализации системы для каждого источника данных в модуле управления загрузкой содержатся параметры загрузки данных.
В другом частном варианте реализации системы подсистема загрузки данных осуществляет загрузку файлов в подсистему обработки и архивирования на основании маски загрузки файлов.
В другом частном варианте реализации системы маска загрузки файлов формируется на основании, по меньшей мере, имени загруженного архивного файла.
В другом частном варианте реализации системы в подсистеме обработки и архивирования в каждой из областей хранения данных формируется каталог для хранения данных соответствующего источника.
В другом частном варианте реализации системы модуль управления загрузкой проверяет наличие информации по всем источникам в TFS.
В другом частном варианте реализации системы выполняется полная или инкрементальная загрузка данных из TFS.
В другом частном варианте реализации системы инкрементальная загрузка выполняется модулем загрузки данных при обнаружении в TFS новых данных отличающихся от поставленных ранее по дате поставки архива файлов.
В другом частном варианте реализации системы подсистема обработки и архивирования осуществляет обработку parquet файлов для их приведения в соответствие типам Hive-SQL.
В другом частном варианте реализации системы для файлов при их обработке подсистемой обработки и архивирования выполняется проверка на наличие аналогичных данных, сохраненных ранее.
В другом частном варианте реализации системы при наличии более ранних данных в область публикуемых данных передается актуальная версия данных с перемещением предыдущей версии в каталог хранения истории с партиционированием по дате загрузки.
В другом частном варианте реализации системы hCatalog предоставляет отображение структуры данных области публикации данных.
В другом частном варианте реализации системы структура данных разбивается по базам данных, соответствующих источникам предоставления данных.
В другом частном варианте реализации системы подсистема обработки и архивирования данных дополнительно обеспечивает автоматизированную функцию оката загрузки данных на любую дату в прошлом.
Заявленное решение осуществляется также с помощью способа управления большими данными (Big Data) с помощью подсистемы транспортировки и проверки входных данных (далее TFS) и подсистемы загрузки внешних данных (далее xStream), причем xStream состоит из подсистемы загрузки файлов, подсистемы обработки и архивирования, подсистемы доступа к данным, модуля управления загрузкой данных и модуля управления доступом, причем способ включает этапы, на которых с помощью модуля управления загрузкой xStream выполняют взаимодействие с TFS для получения данных от упомянутых источников, причем источники данных предварительно регистрируются в модуле управления загрузкой данных;
получают данные из упомянутых источников с помощью TFS, которая принимает данные в архивированном виде и осуществляет накопление и проверку данных, в случае успешной проверки упомянутых данных осуществляют их передачу в подсистему загрузки данных по транспортному протоколу;
осуществляют с помощью подсистемы обработки и архивирования данных обработку получаемых данных, которая включает накопление файлов, проверку файлов, распаковку архивных файлов, прошедших проверку и преобразование распакованных файлов в формат parquet;
осуществляют структуризацию преобразованных файлов с помощью их размещения в каталогах,
- 2 036384 каждый из которых связан с источниками данных, зарегистрированными в упомянутом модуле управления загрузкой данных;
осуществляют контроль и удаление дублирующих данных, контроль и удаление данных с нарушенной структурой, преобразование типов данных в Hive-SQL, контроль и обновление каталога актуальных данных, контроль и обновление каталога истории изменения данных, контроль и управление глубиной архива данных;
осуществляют доступ пользователей к данным, размещенным в подсистеме доступа к данным с помощью модуля управления доступом.
В одном из частных примеров реализации способа модуль управления доступом определяет набор функционала на основании уровня доступа пользователя.
В другом частном примере реализации способа подсистема обработки и архивирования данных осуществляет обработку файлов формата parquet для их соответствия типу Hive-SQL.
В другом частном примере реализации способа регистрация источников данных осуществляется с помощью записи ID источника в модуле управления загрузкой.
В другом частном примере реализации способа модуль управления загрузкой осуществляет управление потоком данных множества источников по соответствующим сохраненным ID.
В другом частном примере реализации способа управление потоком данных включает проверку наличия информации от источника данных в TFS, обработку сообщений от TFS, выполнение действий на основании обработки сообщений.
В другом частном примере реализации способа выполняется полная или инкрементальная загрузка данных из подсистемы первичной обработки входных данных.
В другом частном примере реализации способа инкрементальная загрузка выполняется при обнаружении модулем загрузки наличия новых данных.
В другом частном примере реализации способа для каждого источника данных в модуле управления загрузкой содержатся параметры загрузки данных.
В другом частном примере реализации способа загрузки файлов в подсистему обработки и архивирования осуществляется на основании маски загрузки файлов.
В другом частном примере реализации способа маски загрузки файлов формируется на основании, по меньшей мере, имени загруженного архивного файла.
Описание чертежей
Признаки и преимущества технического решения станут очевидными из приводимого ниже подробного описания и прилагаемых чертежей, на которых фиг. 1 иллюстрирует заявленную систему комплексного управления большими данными;
фиг. 2 - пример идентификатора источника;
фиг. 3 - общий вид вычислительного устройства пользователя;
фиг. 4 - общую схему сетевого взаимодействия.
Осуществление изобретения
На фиг. 1 представлена общая схема реализации заявленной системы (100) управления большими данными. Основным функциональным элементом заявленной системы (100) является подсистема (170) загрузки внешних данных - xStream, которая взаимодействует (или является частью) с облачной платформой (ОП) (180) хранения и управления данными. XStream представляет собой фреймворк для обеспечения централизованной инфраструктуры получения, обработки и хранения внешних данных в ОП на Hadoop для дальнейшего распространения всем заинтересованным лицам с целью использования в бизнес-процессах и в исследованиях на предмет извлечения ценности. Источники данных (110) могут представлять различные ресурсы и каналы предоставления информации, например социальные сети, системы бухгалтерского учета, CRM-системы, реестры госорганов (ЕГРЮЛ, РОССТАТ, ФСФР и др.) и т.п. Информация, поступающая из источников данных (110), первоначально обрабатывается подсистемой транспортировки и проверки входных данных (далее TFS/Transport File System) (120). TFS (120) осуществляет прием, проверку и передачу по транспортному протоколу в xStream (170) данных, поступающих от источников данных (110). В качестве протокола передачи информации от TFS (120) в xStream (170) может применяться протокол сетевого доступа к файловым системам (NFS - Network File System).
Данные поступают на вход TFS (120) в архивированном виде.
Подсистема xStream (170) в свою очередь состоит из подсистемы загрузки файлов (130), подсистемы обработки и архивирования данных (140), подсистемы доступа к данным (150) и технологического ядра (160).
Данные, поступившие на вход TFS (120), передаются в подсистему загрузки файлов (130), которая выполняет транспортировку архивов с данными с помощью модуль интеграции (131) c TFS (120) в первичный слой хранения данных - подсистему (140).
Для каждого из источников данных (110) предполагается два типа загрузки.
Первичная загрузка - является инициализирующей загрузкой, которая выполняется один раз и захватывает все архивы доступные в TFS (120), названия файлов которых удовлетворяют спецификациям на поставку данных от поставщиков.
- 3 036384
Регулярная загрузка - выполняется инкрементально, при которой захватываются только архивы, которые не были загружены ранее.
Захват архивов происходит из каталогов ТФС. При доступе к TFS (120) осуществляется аутентификация с помощью технической учетной записи и приватного ключа. Копирование данных из TFS (120) в первичный слой хранения xStream (170) осуществляется с помощью инициирования модулем управления загрузкой (161) запросов данных из TFS (120). В TFS (120) указываются маршруты загрузки данных и управляющих сообщений между модулем (161) и TFS (120). Модуль (161) может инициировать загрузку одного или нескольких поток данных одновременно, при этом потоки будут обрабатываться параллельно.
Каждый источник данных (110) регистрируется в модуле (161). Для каждого источника создается и хранится его идентификатор (ID). В процессе регистрации источника данных (110) выполняется следующий порядок действий;
присвоение номера источнику данных (110);
определение схем внутри источника (110) и присвоения им номера. Схема является необязательным элементом и применяется для логической группировки таблиц;
присвоение номера всем таблицам внутри источника (110) в пределах схемы (при условии ее использования).
Источник (110), схемы, таблицы соответствуют в модуле (161) сущностям с уникальными идентификаторами. Идентификатор представляет собой целое число формата, представленного на фиг. 2.
Номер источника - это внутренний суррогатный идентификатор источника (110) в xStream (170), который генерируется на этапе подключения источника (110) к xStream (170).
Область данных указывает на область хранения получаемой информации в xStream (170):
- область публикуемых данных (143);
- область сырых данных (141);
- область промежуточных данных (142);
- базовая сущность, идентифицирующая данные источника. Схема представляет собой идентификатор схемы в источнике или подсистемы. Генерируется на этапе подключения источника (110) к xStream (170). Номер таблицы представляет номер таблицы в схеме, также генерируется на этапе подключения источника (110) к xStream (170).
Подсистема обработки и архивирования данных (140) представляет собой хранилище данных, получаемых от внешних источников (110), и является логической областью в HDFS. Доступ к хранимым данным осуществляется через подсистему доступа (150) hCatalog, которая также предназначена для публикации метаинформации о данных. Подсистема обработки и архивирования данных (140) содержит области хранения данных, которые осуществляют структурированное хранение первичных (сырых) данных (141), промежуточных данных (142) и публикуемых данных (143). В область хранения первичных данных (141) передаются архивы информации, получаемые от TFS (120) из источников данных (110), зарегистрированных в модуле (161). Получаемые данные проверяются на целостность в TFS (120). В случае нарушения целостности архивов, получаемых от источников данных (110), такая информация не передается в подсистему xStream (170). При успешном копировании информации из TFS (120) в область первичных данных (141), xStream (170) уведомляет о проведении успешной операции.
При загрузке данных в область хранения промежуточных данных (142) первоначально выполняется разархивация архивов данных из области первичных данных (141). Передача файлов из подсистемы (130) в подсистему хранения (140) может осуществляться с помощью маски загрузки файлов, которая может формироваться на основании, например, имени (названия) загруженного архивного файла. В системе (100) сохраняется информация обо всех успешно загруженных архивах из источников данных (110).
Модуль ETL (Extract, Transform, Load) (132) выполняет передачу данных в необходимые области (142)-(143) подсистемы хранения и архивации (140), а также осуществляет подготовку и преобразование разархивированных данных в формат parquet при их поступлении в подсистему (130). Parquet представляет собой бинарный, колоночно-ориентированный формат хранения данных (см., например, Производительность Apache Parquet. //https://habr.com/post/282552/).
При преобразовании данные источников (110) приводятся к типам Hive-SQL. Пример приведения данных к типу Hive-AQL представлен в табл. 1. В случае если наименование файла, например формата *json, не соответствует маске, то данные архивов, содержащих такие файлы, не будут преобразованы в parquet. Данная методика обеспечивает устойчивый процесс обращения к данным через Hive с помощью обычных SQL-запросов, что приводит к повышению надежности доступа к информации.
- 4 036384
Таблица 1. Матрица конвертации типов данных
| Типы данных, тех. поля | Типы данных Hive-SQL |
| D(10) | STRING |
| F | BOOLEAN |
| N(l) | BIGINT |
| N(5,2) | DECIMAL(22,2) |
| N(6) | BIGINT |
| N(8) | BIGINT |
| N(9) | BIGINT |
| N(13) | BIGINT |
| N(15) | BIGINT |
| N(18,2) | DECIMAL(22,2) |
| N(19) | DECIMAL (22,0) |
| N(22,2) | DECIMAL (22,2) |
| N(22) | DECIMAL (22,0) |
| N(1000) | DECIMAL (38,0) |
| T(l) | STRING |
| T(3) | STRING |
| T(4) | STRING |
| T(5) | STRING |
| T(6) | STRING |
| T(7) | STRING |
| T(8) | STRING |
| T(9) | STRING |
| T(10) | STRING |
| T(ll) | STRING |
| T(12) | STRING |
| T(13) | STRING |
| T(15) | STRING |
В область публикуемых данных (143) передаются подготовленные, преобразованные, унифицированные данные, которые приводятся к стандарту подсистемы xStream (170). При подготовке унифицированных данных имена таблиц и полей приведены к стандарту xStream, типы данных приведены к стандарту xStream, таблицы дополнены обязательными техническими полями, описывающими поставку данных - датами начала и конца периода актуальности поставки данных, номерами потоков, выполнивших загрузку и преобразование.
Выполнение вышеуказанных процедур по обработке данных в подсистеме (140) позволяет организовать и обновлять актуальный срез данных (например, исторический срез) для каждого источника (110) в первичном слое xStream (170), при этом также обеспечивается поддержание требуемой временной глубины архива данных. Загрузка данных в область публикации (143) осуществляется в несколько этапов. На первом этапе выполняется получение новых архивов. Для получения нового списка архивов сканируется область хранения сырых данных (141) по имени соответствующего источника (110) (например, для источника abc - каталог в области (141) /data/core/external/abc/src) по шаблону имени архивов. Из полученного списка исключаются архивы, которые уже были загруженные в область публикации (143) источника, которые были успешно обработаны подсистемой хранения и архивирования (140). Также, из полученного списка исключаются архивы, которые были обработаны с ошибкой. Архивы источника (110) из оставшегося списка переносятся в область сырых данных (141). Далее осуществляется распаковка полученных архивов. Для распаковки, выбираются только те архивы из области (141), наименование которых соответствует шаблону. Из полученного списка исключаются архивы источника (110), которые ранее были загружены в область публикации (143) данного источника. Из полученного списка исключаются архивы, которые были обработаны с ошибкой. Архивы из оставшегося списка распаковываются в область промежуточных данных (142) в соответствующий подкаталог, например, src/<loading_id>/unpack/<имя_архива>.
Каждый архив распаковывается в отдельный подкаталог в области промежуточных данных (142), соответствующий названию архива. В случае успешной распаковки архива его имя регистрируется в файле src/<loading_id>/unpack/.success, который представляет собой журнал успешной загрузки, при возникновении ошибки при распаковке архива, его имя зарегистрируется в файле src/<loading_id>/unpack/.fail, который является, соответственно, журналом неуспешной загрузки. Обработка других архивов при получении данных при этом не прерывается. После сохранения данных из архивов в области промежуточных данных (142) выполняется их преобразование в формат parquet. Переводу в формат parquet подлежат только те файлы данных из архивов, которые были зарегистрированы в подсис
- 5 036384 теме (140) как успешно распакованные. При этом файлы из разных архивов обрабатываются отдельно. Каждый файл из архива соответствует только одной сущности, например таблице источника, в случае если данные были загружены из табличного вида (определяется по маске имени файла), файлы одного архива, соответствующие одной таблице, обрабатываются вместе. Таблицы дополняются служебными атрибутами (см. табл. 2), которые позволяют поддерживать актуальный снимок (слепок) и формировать историю изменения файлов, полученных от источника данных (110).
Таблица 2. Пример служебных атрибутов
| Атрибут | Тип | Описание |
| ctlloading | Int | Идентификатор загрузки модуля (161), в рамках которого запись была вставлена или обновлена |
| ctl_pa_loadi ng | Int | Значение атрибута ctl_loading из Реплики перед переносом записи в Историю. Значение null означает, что записи с таким состоянием в Реплике не было. ctl_pa_loading < ctl loading |
| ctlaction | String | Индикатор последней операции над записью в источнике: I - запись была вставлена U - обновлена |
| ctlvalidFro m | String | Временная метка вставки/обновления. Время подтверждения (commit-a) транзакции, в рамках которой запись попала в snp. |
| ctlvalidTo | String | Временная метка переноса записи из snp в history. Поле ctl validTo может быть больше или равно ctl validFrom. Равенство возможно, если от источника |
| данные пришли за предыдущий период (задним числом), в таком случае запись сразу попадает в history. | ||
| archivenam e | String | Наименование архива поставщика, в котором находится файл, содержащий данные этой таблицы (Например: abc_fb_pagesgeneralinfo_<date>_<time>_ nnn.tar.gz). |
| file_name | String | Наименование файла, который находился в архиве поставщика, содержащий данные этой таблицы (Например: abc_fb_pagesgeneralinfo_20171031 19115 8_001.json). |
Вышеуказанные атрибуты передаются как параметры задания и обеспечиваются функционалом модуля управления загрузкой (161). В результате обработки создается соответствующая структура каталогов. В случае успешного преобразования всех файлов из архивов в формат parquet имя архива регистрируется в журнале, что необходимо для управления процессом доступа к информации и обеспечения автоматического отката системы на более раннюю точку. При возникновении ошибки при обработке хотя бы одного файла архива последующая обработка архива прекращается и имя архива помечается как ошибочное.
Обработанные и унифицированные данные из области публикуемых данных (143) передаются в подсистему доступа к данным (150) для обеспечения получения данных для работы конечными пользователями.
В подсистеме доступа к данным (150) формируется два раздела - актуальный срез данных (151), со
- 6 036384 держащий отпечаток текущих данных, и раздел истории данных (152), содержащий информацию об изменениях данных.
Каждая сущность, содержащая данные источника (110), обрабатывается отдельно, при этом обрабатываются данные, соответствующие сущности, из всех архивов, которые были зарегистрированы как успешно обработанные. Предусмотрены два способа обработки данных - выбор способа зависит от наличия историчности в данных по упомянутой сущности.
В случае отсутствия выделения историчности (наличие новых данных) выполняется следующее. Для всех новых данных по таблице архива, хранящегося в области промежуточных данных (142), обеспечивается установка атрибута с текущим значением времени старта потока передачи данных. Данные сохраняются с партиционированием в области публикуемых данных (143) stg/<loadingId>/ра/snp/<имя_ таблицы>, в результате чего создается только одна партиция (раздел).
В случае наличия выделения историчности (наличие новых данных) для всех новых данных по таблице из области промежуточных данных (142) устанавливается атрибут со временем старта потока загрузки данных модулем (161). Полученные данные объединяются с данными таблицы из области публикуемых данных (143) и из полученного объединения выделяются новые данные, которые помещаются в области (151) и (152).
Данные для отображения в области (151) сохраняются с партиционированием по полю ctl_loading в каталоге промежуточных данных (142) stg/<loadшgШ>/ра/snp/<имя_таблицы> Ctl_loading - это поток (техническая сущность), который активируется модулем управления загрузкой (161). Под каждый источник (110) создается и регистрируется отдельный поток.
Для данных в области (152) истории изменения данных обеспечивается заполнение полей ctl _pa_loading (из поля ctl_loading), ctl_loading (текущим значением <loadingId>) и ctl_validTo (временем старта потока загрузки данных). Данные для отображения в области (152) сохраняются с партиционированием по полю ctl_loading в каталоге промежуточных данных (142) stg/<loadingId>/pa/hist/<имя_таблицы>. В результате для области (152) создается только одна партиция (раздел) stg/<loadingId>/pa/hist/<uмя_таблuцы>/ctl_loading=<loadingId>
По окончании данного действия в каталог области хранения промежуточных данных (142) stg/<loadingId>/pa/ копируется файл stg/status/.fail. По окончанию операции область хранения промежуточных данных (142) очищается. Данные журнала операции, производимой в области (142), должны быть добавлены в общий журнал области публикуемых данных (143).
Далее выполняется объединение файлов из области (142) stg/status/.success и области (141) src/<loading_id>/parquet/.success в файл stg/<loadingId>/pa/.success. Этап считается успешным, если все данные при этом были успешно обработаны, иначе поток завершится с ошибкой.
В рамках реализации заявленного решения предусмотрены два способа публикации данных, полученные из источника (110), выбор способа зависит от наличия историчности изменений в данных в данном источнике (110).
Если для источника (110) отсутствуют сведения об изменениях, то каталог stg/<loadingId>/ра/snp/<имя_таблицы>/ctl_loading=<loadingId> из области хранения промежуточных данных (142) перемещается в каталог области публикуемых данных (143) ра/snp/<имя_таблицы> как новый раздел, который впоследствии регистрируется для отображения в hCatalog (150) в области (151).
В случае наличия выделения историчности (наличие новых данных) для источника данных (110) выполняется следующее. Каталог с данными для источника (110) ра/snp/<имя_таблицы> из области (143) перемещается в stg/<loadingId>/reserve/pa/snp области промежуточных данных (142). Каталог stg/<loadingId>/ра/snp/<имя_таблицы> из области промежуточных данных (142) перемещается в каталог области публикуемых данных (142) как ра/snp/<имя_таблицы> Новый раздел в области (143) ра/snp/<имя_таблицы>/ctl_loading=<loadingId> регистрируется в hCatalog (150) для предоставления доступа к информации. Каталог в области (142) stg/<loadingId>/ра/hist/<имя_таблицы>/ctl_loading=<loadingId>, созданный ранее, перемещается в каталог в области (143) pa/hist/<имя_таблицы> как новый раздел, который также регистрируется в подсистеме (150). По окончании данного процесса в каталог области промежуточных данных (142) stg/status/ копируются файлы stg/<loadingId>/pa/.success и stg/<loadingId>/pa/.fail, которые отображают статус выполнения операций загрузки данных. Данный этап считается успешным, если во время его исполнения не возникало исключений и ошибок загрузки данных. Подсистема обработки и архивирования данных (140) очищает/архивирует область публикуемых данных (143) по параметру идентификатора потока загрузки информации (ctlloading и ctl_pa_loading), который устанавливается модулем управления загрузкой (161). Глубина истории подлежащей очистке/архивированию задается параметром, например, 5 лет.
Для подключения нового источника данных (110) или изменения параметров существующего подсистема xStream (170) имеет конфигурационные файлы, а также профили, указываемые при запуске подсистемы XStream (170), содержащие набор параметров. Конфигурационные файлы предполагают настройку следующих параметров:
адрес папки источника;
тип входных файлов;
- 7 036384 имена архивов и файлов в архиве;
тип преобразований;
необходимость ведения истории;
ролевая модель;
скрипты создания базы данных и таблиц для источника и др.
Файлы от отправителя - источника данных (110) - как правило публикуются в общую папку отправителя в TFS (120), поэтому для этого необходимо осуществлять формирование уникального имени файла. Файлы поставляются упакованные в архивах. Допустимые типы расширения могут быть различными, например tar.gz, zip и т.п. Имя файла архива может формироваться, например, по следующей маске: <saller>_<source>_<table>_<inc>_<ver>_<date>_<time>_<nnn>.<extension>, где saller - конечный поставщик данных (или прокси-поставщик);
source - источник данных (110);
table - название типа данных или сущности. В случае если в поставке одним архивом приходит схема, состоящая из нескольких взаимосвязанных сущностей, которые необходимо поставлять одновременно, например таблиц, то в этой секции ставится - kit, а в самих файлах внутри архива уже указываются непосредственные имена сущностей;
inc - содержит full, если архив относится к поставке/перепоставке полного архива данных, incr - если архив относится к поставке инкремента;
ver - версия поставки. В случае изменения состава данных или формата поставки необходимо инкрементировать версию вверх. Может состоять из литеры v и 3 цифр, начиная с v001, например v001, v002 и т.д.;
date - дата формирования файла в формате ГГГГММДД;
time - время формирования файла в формате ЧЧММСС;
nnn - номер по порядку, начинающийся с 001, если несколько файлов поставки в рамках совпадений остальных частей названия файла архива. Всегда состоит из 3 цифр, начиная с 001, например, 001, 002 и т.д. Если в поставке только 1 файл, то в этой секции указано - 001; extension - расширение архива. Пример имени архива: abc_def_org1_incr_v002_20171106_112400_001.tar.gz. He допускается наличие архива в архиве. Имя файла в архиве формируется также, как имя файла архива, за исключением расширения файла и секции <table> для набора.
Имя архива: abc_def_kit_incr_v002_20171106_112400_001.tar.gz, файлы в архиве: abc_def_kit1_incr_v002_20171106_112400_001.xml, abc_def_orgl_incr_v002_20171106112400_001.xml и т.д. Допустимые типы и расширения файлов, например, csv, tsv, txt, json, avro, xml и др. В имени передаваемого файла допускается использование не более 128 символов (включая расширение).
Модель данных внешнего источника (110) соответствует структуре поставляемых данных и определяется на этапе анализа и подготовки источника (110) к загрузке в xStream (170). Целевым средством для доступа к данным служит Apache Hive. Доступ пользователей к опубликованным данным, содержащимся в области (150) осуществляется на основании контроля уровня доступа каждого из пользователей. Для каждого пользователя при взаимодействии с xStream (170) проверяется разрешенный функционал по осуществлению операций с данными, в частности, такими операциями могут быть: просмотр, редактирование, получение аналитического среза, комбинированный просмотр и т.п. Пользователь с ролями Администратор и Аудитор имеют доступ к логам xStream (170) через централизованную систему управления логами, доступную в облачной платформе (180).
На фиг. 3 представлен общий вид вычислительного устройства (200), используя которое в составе кластера реализуется заявленный способ и система. В общем случае, вычислительное устройство (200) содержит объединенные общей шиной один или несколько процессоров (201), средства памяти, такие как ОЗУ (202) и ПЗУ (203), интерфейсы ввода/вывода (204), средства ввода/вывода (205), и средство для сетевого взаимодействия (206).
Процессор (201) (или несколько процессоров, многоядерный процессор) могут выбираться из ассортимента устройств, широко применяемых в текущее время, например, компаний Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™ и т.п.
ОЗУ (202) представляет собой оперативную память и предназначено для хранения исполняемых процессором (201) машиночитаемых инструкций, для выполнения необходимых операций по логической обработке данных. ОЗУ (202), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.).
ПЗУ (203) представляет собой одно или более устройств постоянного хранения данных, например жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш-память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, BlueRay Disc, MD) и др.
Для организации работы компонентов устройства (200) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (204). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: PCI, AGP, PS/2, IrDa, FireWire, LPT, cOm, SATA, IDE, Lightning, USB (2.0, 3.0,
- 8 036384
3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232 и т.п. Для обеспечения взаимодействия пользователя с вычислительным устройством (200) применяются различные средства (205) В/В информации, например клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.
Средство сетевого взаимодействия (206) обеспечивает передачу данных устройством (200) посредством внутренней или внешней вычислительной сети, например Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (206) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.
Дополнительно могут применяться также средства спутниковой навигации, например GPS, ГЛОНАСС, BeiDou, Galileo.
На фиг. 4 представлен пример сетевого окружения при осуществлении работы заявленной системы (100). Организация работы с данными при использовании FIDFS заключается в формировании соответствующих уровней абстракции в кластерных или виртуальных средах. Каждый стек системы включает множество вычислительных устройств, например компьютеров и/или серверов, которые обмениваются данными с облачной платформой (180), содержащей xStream (170), посредством коммутаторов. Такая архитектура позволяет оперативно наращивать необходимые вычислительные мощности при значительном росте объема хранимых и обрабатываемых данных. Представленные материалы заявки раскрывают предпочтительные примеры реализации технического решения и не должны трактоваться как ограничивающие иные, частные примеры его воплощения, не выходящие за пределы испрашиваемой правовой охраны, которые являются очевидными для специалистов соответствующей области техники.
Claims (28)
- ФОРМУЛА ИЗОБРЕТЕНИЯ1. Система комплексного управления большими данными (Big Data), содержащая подсистему транспортировки и проверки входных данных (далее TFS), подсистему загрузки внешних данных (далее xStream), функционирующую на основании стандарта описания данных, в которойTFS осуществляет прием, проверку и передачу в xStream данных, поступающих от источников данных, причем TFS принимает данные в архивированном виде и осуществляет передачу данных по транспортному протоколу;xStream содержит подсистему загрузки файлов, подсистему обработки и архивирования данных, подсистему доступа к данным (далее hCatalog), модуль управления загрузкой данных и модуль управления доступом, причем в xStream подсистема загрузки файлов осуществляет опрос TFS для передачи данных, поступивших от источников, в подсистему обработки и архивирования данных, причем источники данных предварительно регистрируются в модуле управления загрузкой;подсистема загрузки данных выполняет первичное копирование файлов, поступающих от TFS, в подсистему обработки и архивирования;подсистема обработки и архивирования содержит области хранения данных, которые осуществляют структурированное хранение первичных данных, промежуточных данных и публикуемых данных;в область хранения первичных данных передаются файлы из подсистемы загрузки данных, которые соответствуют установленным параметрам архивирования и хранятся в первоначально заархивированном виде;подсистема обработки и архивирования выполнена с возможностью передачи в область промежуточных данных разархивированных первичных данных, преобразованных в формат parquet для дальнейших преобразований;в область публикуемых данных передаются подготовленные, преобразованные, унифицированные данные, приведенные к стандарту xStream, в которых имена таблиц и полей приведены к стандарту xStream, типы данных приведены к стандарту xStream, таблицы дополнены обязательными техническими полями, описывающими поставку данных - датами начала и конца периода актуальности поставки данных, номерами потоков, выполнивших загрузку и преобразование;и из унифицированных данных области публикуемых данных формируется структурированный каталог для доступа к упомянутым данным посредством hCatalog.
- 2. Система по п.1, характеризующаяся тем, что TFS осуществляет проверку целостности получаемых архивных данных.
- 3. Система по п.1, характеризующаяся тем, что для зарегистрированных источников в модуле управления загрузкой хранится ID упомянутых источников.
- 4. Система по п.3, характеризующаяся тем, что модуль управления загрузкой осуществляет управление потоком данных множества источников по соответствующим сохраненным ID.- 9 036384
- 5. Система по п.4, характеризующаяся тем, что для каждого источника данных в модуле управления загрузкой содержатся параметры загрузки данных.
- 6. Система по п.1, характеризующаяся тем, что подсистема загрузки данных осуществляет загрузку файлов в подсистему обработки и архивирования на основании маски загрузки файлов.
- 7. Система по п.6, характеризующаяся тем, что маска загрузки файлов формируется на основании, по меньшей мере, имени загруженного архивного файла.
- 8. Система по п.1, характеризующаяся тем, что в подсистеме обработки и архивирования в каждой из областей хранения данных формируется каталог для хранения данных соответствующего источника.
- 9. Система по п.7, характеризующаяся тем, что модуль управления загрузкой проверяет наличие информации по всем источникам в TFS.
- 10. Система по п.9, характеризующаяся тем, что выполняется полная или инкрементальная загрузка данных из TFS.
- 11. Система по п.10, характеризующаяся тем, что инкрементальная загрузка выполняется модулем загрузки данных при обнаружении в TFS новых данных, отличающихся от поставленных ранее по дате поставки архива файлов.
- 12. Система по п.1, характеризующаяся тем, что подсистема обработки и архивирования осуществляет обработку parquet файлов для их приведения в соответствие типам Hive-SQL.
- 13. Система по п.1, характеризующаяся тем, что для файлов при их обработке подсистемой обработки и архивирования выполняется проверка на наличие аналогичных данных, сохраненных ранее.
- 14. Система по п.13, характеризующаяся тем, что при наличии более ранних данных в область публикуемых данных передается актуальная версия данных с перемещением предыдущей версии в каталог хранения истории с партиционированием по дате загрузки.
- 15. Система по п.1, характеризующаяся тем, что hCatalog предоставляет отображение структуры данных области публикации данных.
- 16. Система по п.15, характеризующаяся тем, что структура данных разбивается по базам данных, соответствующих источникам предоставления данных.
- 17. Система по п.1, характеризующаяся тем, что подсистема обработки и архивирования данных дополнительно обеспечивает автоматизированную функцию оката загрузки данных на любую дату в прошлом.
- 18. Способ управления большими данными (Big Data) с помощью подсистемы транспортировки и проверки входных данных (далее TFS) и подсистемы загрузки внешних данных (далее xStream), причем xStream состоит из подсистемы загрузки файлов, подсистемы обработки и архивирования, подсистемы доступа к данным, модуля управления загрузкой данных и модуля управления доступом, причем способ включает этапы, на которых с помощью модуля управления загрузкой xStream выполняют взаимодействие с TFS для получения данных от упомянутых источников, причем источники данных предварительно регистрируются в модуле управления загрузкой данных;получают данные из упомянутых источников с помощью TFS, которая принимает данные в архивированном виде и осуществляет накопление и проверку данных, в случае успешной проверки упомянутых данных осуществляют их передачу в подсистему загрузки данных по транспортному протоколу;осуществляют с помощью подсистемы обработки и архивирования данных обработку получаемых данных, которая включает накопление файлов, проверку файлов, распаковку архивных файлов, прошедших проверку и преобразование распакованных файлов в формат parquet;осуществляют структуризацию преобразованных файлов с помощью их размещения в каталогах, каждый из которых связан с источниками данных, зарегистрированными в упомянутом модуле управления загрузкой данных;осуществляют контроль и удаление дублирующих данных, контроль и удаление данных с нарушенной структурой, преобразование типов данных в Hive-SQL, контроль обновление каталога актуальных данных, контроль и обновление каталога истории изменения данных, контроль и управление глубиной архива данных;осуществляют доступ пользователей к данным, размещенным в подсистеме доступа к данным с помощью модуля управления доступом.
- 19. Способ по п.18, характеризующийся тем, что модуль управления доступом определяет набор функционала на основании уровня доступа пользователя.
- 20. Способ по п.18, характеризующийся тем, что подсистема обработки и архивирования данных осуществляет обработку файлов формата parquet для их соответствия типу Hive-SQL.
- 21. Способ по п.18, характеризующийся тем, что регистрация источников данных осуществляется с помощью записи ID источника в модуле управления загрузкой.
- 22. Способ по п.18, характеризующийся тем, что модуль управления загрузкой осуществляет управление потоком данных множества источников по соответствующим сохраненным ID.
- 23. Способ по п.22, характеризующийся тем, что управление потоком данных включает проверку наличия информации от источника данных в TFS, обработку сообщений от TFS, выполнение действий на- 10 036384 основании обработки сообщений.
- 24. Способ по п.22, характеризующийся тем, что выполняется полная или инкрементальная загрузка данных из подсистемы первичной обработки входных данных.
- 25. Способ по п.23, характеризующийся тем, что инкрементальная загрузка выполняется при обнаружении модулем загрузки наличия новых данных.
- 26. Способ по п.18, характеризующийся тем, что для каждого источника данных в модуле управления загрузкой содержатся параметры загрузки данных.
- 27. Способ по п.18, характеризующийся тем, что загрузка файлов в подсистему обработки и архивирования осуществляется на основании маски загрузки файлов.
- 28. Способ по п.27, характеризующийся тем, что маска загрузки файлов формируется на основании, по меньшей мере, имени загруженного архивного файла.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2018137863A RU2690777C1 (ru) | 2018-10-26 | 2018-10-26 | Способ и система комплексного управления большими данными |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| EA201892256A1 EA201892256A1 (ru) | 2020-05-29 |
| EA036384B1 true EA036384B1 (ru) | 2020-11-03 |
Family
ID=67037918
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EA201892256A EA036384B1 (ru) | 2018-10-26 | 2018-11-02 | Способ и система комплексного управления большими данными |
Country Status (3)
| Country | Link |
|---|---|
| EA (1) | EA036384B1 (ru) |
| RU (1) | RU2690777C1 (ru) |
| WO (1) | WO2020085938A1 (ru) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US12008421B1 (en) | 2023-03-07 | 2024-06-11 | Ricoh Company, Ltd. | Print data conversion mechanism |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070226535A1 (en) * | 2005-12-19 | 2007-09-27 | Parag Gokhale | Systems and methods of unified reconstruction in storage systems |
| US20130024424A1 (en) * | 2009-06-30 | 2013-01-24 | Commvault Systems, Inc. | Data object store and server for a cloud storage environment, including data deduplication and data management across multiple cloud storage sites |
| RU141446U1 (ru) * | 2013-08-22 | 2014-06-10 | Санкт-Петербург, от имени которго выступает Комитет по информации и связи | Информационно-поисковое устройство представления данных об объектах |
| US20160210064A1 (en) * | 2015-01-21 | 2016-07-21 | Commvault Systems, Inc. | Database protection using block-level mapping |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7007034B1 (en) * | 2000-01-21 | 2006-02-28 | International Business Machines Corporation | File structure for storing content objects in a data repository |
| SG176438A1 (en) * | 2006-11-06 | 2011-12-29 | Dell Marketing Usa L P | A system and method for managing data across multiple environments |
| US7693877B1 (en) * | 2007-03-23 | 2010-04-06 | Network Appliance, Inc. | Automated information lifecycle management system for network data storage |
-
2018
- 2018-10-26 RU RU2018137863A patent/RU2690777C1/ru active
- 2018-10-26 WO PCT/RU2018/000706 patent/WO2020085938A1/ru active Application Filing
- 2018-11-02 EA EA201892256A patent/EA036384B1/ru unknown
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070226535A1 (en) * | 2005-12-19 | 2007-09-27 | Parag Gokhale | Systems and methods of unified reconstruction in storage systems |
| US20130024424A1 (en) * | 2009-06-30 | 2013-01-24 | Commvault Systems, Inc. | Data object store and server for a cloud storage environment, including data deduplication and data management across multiple cloud storage sites |
| US20130238572A1 (en) * | 2009-06-30 | 2013-09-12 | Commvault Systems, Inc. | Performing data storage operations with a cloud environment, including containerized deduplication, data pruning, and data transfer |
| RU141446U1 (ru) * | 2013-08-22 | 2014-06-10 | Санкт-Петербург, от имени которго выступает Комитет по информации и связи | Информационно-поисковое устройство представления данных об объектах |
| US20160210064A1 (en) * | 2015-01-21 | 2016-07-21 | Commvault Systems, Inc. | Database protection using block-level mapping |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020085938A1 (ru) | 2020-04-30 |
| RU2690777C1 (ru) | 2019-06-05 |
| EA201892256A1 (ru) | 2020-05-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11816126B2 (en) | Large scale unstructured database systems | |
| US11604804B2 (en) | Data replication system | |
| CN107122355B (zh) | 数据迁移系统和方法 | |
| US11687550B2 (en) | Live data conversion and migration for distributed data object systems | |
| CN107122360B (zh) | 数据迁移系统和方法 | |
| US9600500B1 (en) | Single phase transaction commits for distributed database transactions | |
| US10853242B2 (en) | Deduplication and garbage collection across logical databases | |
| US8832020B2 (en) | Method and system for safely transporting legacy data to an object semantic form data grid | |
| US20160259811A1 (en) | Method and system for metadata synchronization | |
| CN107122361B (zh) | 数据迁移系统和方法 | |
| US11403269B2 (en) | Versioning validation for data transfer between heterogeneous data stores | |
| US10877810B2 (en) | Object storage system with metadata operation priority processing | |
| CN114756577A (zh) | 多源异构数据的处理方法、计算机设备及存储介质 | |
| EP4189914B1 (en) | Using multiple blockchains for applying transactions to a set of persistent data objects in persistent storage systems | |
| Qiao et al. | Gobblin: Unifying data ingestion for Hadoop | |
| US11748495B2 (en) | Systems and methods for data usage monitoring in multi-tenancy enabled HADOOP clusters | |
| US11567957B2 (en) | Incremental addition of data to partitions in database tables | |
| US20220382637A1 (en) | Snapshotting hardware security modules and disk metadata stores | |
| US20170344592A1 (en) | Database integration system | |
| RU2690777C1 (ru) | Способ и система комплексного управления большими данными | |
| CN116501700B (zh) | 一种app格式化文件离线存储方法、装置、设备及存储介质 | |
| US11755613B2 (en) | Streamlined data engineering | |
| WO2021004042A1 (zh) | 药物研发软件仓库及其软件包管理系统 | |
| TWI571754B (zh) | 用來進行檔案同步控制之方法與裝置 | |
| Boytsov et al. | The problem of creating multi-tenant database clusters |