Термин «фабрика данных» используется во всей технологической отрасли, однако его определение и реализация могут различаться. Я видел это у разных поставщиков: осенью прошлого года British Telecom (BT) рассказала о своей фабрике данных на мероприятии для аналитиков; тем временем в сфере хранения данных NetApp переориентирует свой бренд на интеллектуальную инфраструктуру, хотя ранее использовала этот термин. Поставщик платформы приложений Appian имеет продукт фабрики данных, а поставщик баз данных MongoDB также говорит о фабриках данных и подобных идеях.
По своей сути фабрика данных представляет собой унифицированную архитектуру, которая абстрагирует и интегрирует разрозненные источники данных для создания единого уровня данных. Принцип состоит в том, чтобы создать единый синхронизированный слой между разрозненными источниками данных и рабочими нагрузками, которым требуется доступ к данным — вашими приложениями, рабочими нагрузками и, во все большей степени, вашими алгоритмами искусственного интеллекта или механизмами обучения.
Есть много причин хотеть такого наложения. Фабрика данных действует как общий уровень интеграции, подключаясь к различным источникам данных или добавляя расширенные возможности для облегчения доступа к приложениям, рабочим нагрузкам и моделям, например, обеспечивая доступ к этим источникам при сохранении их синхронизации.
Все идет нормально. Проблема, однако, заключается в том, что у нас существует разрыв между принципом фабрики данных и его фактической реализацией. Люди используют этот термин для обозначения разных вещей. Возвращаясь к нашим четырем примерам:
- BT определяет фабрику данных как оверлей на уровне сети, предназначенный для оптимизации передачи данных на большие расстояния.
- Интерпретация NetApp (даже с использованием термина «интеллектуальная инфраструктура данных») подчеркивает эффективность хранения и централизованное управление.
- Appian позиционирует свой продукт Data Fabric как инструмент для объединения данных на уровне приложений, что позволяет быстрее разрабатывать и настраивать инструменты, ориентированные на пользователя.
- MongoDB (и другие поставщики решений для структурированных данных) рассматривают принципы структуры данных в контексте инфраструктуры управления данными.
Как нам преодолеть все это? Один из ответов — признать, что мы можем подойти к этому вопросу с разных точек зрения. Вы можете говорить о фабрике данных концептуально, признавая необходимость объединения источников данных, но не переусердствуя. Вам не нужна универсальная «супер-ткань», которая покрывает абсолютно все. Вместо этого сосредоточьтесь на конкретных данных, которыми вам нужно управлять.
Если мы перемотаем пару десятилетий назад, мы увидим сходство с принципами сервис-ориентированной архитектуры, которая стремилась отделить предоставление услуг от систем баз данных. Тогда мы обсуждали разницу между сервисами, процессами и данными. То же самое применимо и сейчас: вы можете запросить услугу или запросить данные как услугу, сосредоточив внимание на том, что необходимо для вашей рабочей нагрузки. Создание, чтение, обновление и удаление остаются самыми простыми службами обработки данных!
Мне также напоминают об истоках сетевого ускорения, которое использовало кэширование для ускорения передачи данных за счет локального хранения версий данных, а не многократного доступа к источнику. Akamai построила свой бизнес на эффективной передаче неструктурированного контента, такого как музыка и фильмы, на большие расстояния.
Это не означает, что фабрики данных заново изобретают велосипед. В технологическом отношении мы находимся в другом (облачном) мире; Кроме того, они привносят новые аспекты, не в последнюю очередь связанные с управлением метаданными, отслеживанием происхождения, функциями обеспечения соответствия и безопасности. Это особенно важно для рабочих нагрузок ИИ, где управление данными, качество и происхождение напрямую влияют на производительность и надежность модели.
Если вы планируете развернуть структуру данных, лучше всего подумать о том, для чего вам нужны данные. Это не только поможет вам сориентироваться в том, какая структура данных может быть наиболее подходящей, но и поможет избежать ловушки, когда вы пытаетесь управлять всеми данными в мире. Вместо этого вы можете расставить приоритеты для наиболее ценного подмножества данных и решить, какой уровень структуры данных лучше всего подходит для ваших нужд:
- Сетевой уровень: для интеграции данных в мультиоблачных, локальных и периферийных средах.
- Уровень инфраструктуры: Если ваши данные централизованы у одного поставщика систем хранения, сосредоточьтесь на уровне хранения для обслуживания согласованных пулов данных.
- Уровень приложения: собрать воедино разрозненные наборы данных для конкретных приложений или платформ.
Например, в случае с BT они нашли внутреннюю ценность в использовании своей структуры данных для консолидации данных из нескольких источников. Это уменьшает дублирование и помогает оптимизировать операции, делая управление данными более эффективным. Это, несомненно, полезный инструмент для объединения разрозненности и улучшения рационализации приложений.
В конце концов, фабрика данных не является монолитным, универсальным решением. Это стратегический концептуальный уровень, подкрепленный продуктами и функциями, который вы можете применять там, где наиболее целесообразно повысить гибкость и улучшить доставку данных. Структура развертывания — это не упражнение по принципу «установил и забыл»: оно требует постоянных усилий по определению масштаба, развертыванию и обслуживанию — не только самого программного обеспечения, но также настройки и интеграции источников данных.
Хотя фабрика данных концептуально может существовать в нескольких местах, важно не дублировать усилия по доставке без необходимости. Итак, независимо от того, собираете ли вы данные по сети, в инфраструктуре или на уровне приложений, принципы остаются теми же: используйте их там, где они наиболее подходят для ваших нужд, и дайте им возможность развиваться вместе с данными, которые они обслуживают.
Пост Демистификация фабрик данных – устранение разрыва между источниками данных и рабочими нагрузками впервые появился на Гигаом.
2025-01-15 10:38:00
1771289585
#Демистификация #фабрик #данных #устранение #разрыва #между #источниками #данных #рабочими #нагрузками
По теме
