Эта история является/будет настоящим опытом для большинства из нас. Если вы не работаете в компании, которая уже сделала необходимые инвестиции в архитектуру данных раньше.

Я знаю, что вначале возникает много вопросов; сумма инвестиций, кто будет нести ответственность, нужно ли нам что-либо менять в нашей архитектуре БД, сколько времени это займет, мы небольшая компания, как мы масштабируем это преобразование и т. д.

Во-первых, что случилось? Почему вы начали искать по архитектуре БД. В моем случае мы начали создавать продукты на основе ML-Ai и в этом процессе понимаем, что нашего склада недостаточно для запуска моделей ML в продуктах в реальном времени. Возможно, ваш случай отличается, но в какой-то момент большинство компаний сталкивались с проблемой, которая подталкивала их к изменениям («как и ожидалось, больше всего ненавидит изменения») и переходу на более гибкую структуру БД. Кому-то нужно разнообразие данных, кому-то нужны решения для работы с большими данными, кому-то, как и нам, гибкость и т. д. Независимо от того, что произошло на заднем плане, теперь вы ищете решения. Решение временной помощи (быстрое, основанное на проблеме, ежедневное) или более надежное решение (платит больше в долгосрочной перспективе) или больше. Здесь вы можете начать с этих:

1. В чем разница между озером данных и классическим хранилищем данных?

В зависимости от требований типичной организации потребуется как хранилище данных, так и озеро данных, поскольку они служат различным потребностям и вариантам использования.

Хранилище данных — это база данных, оптимизированная для анализа реляционных данных, поступающих из транзакционных систем и ряда бизнес-приложений. Структура данных и схема определяются заранее для оптимизации быстрых запросов SQL, результаты которых обычно используются для оперативной отчетности и анализа. Данные очищаются, обогащаются и преобразуются, чтобы они могли выступать в качестве «единого источника правды», которому пользователи могут доверять.

Озеро данных отличается тем, что в нем хранятся реляционные данные из линейки бизнес-приложений и нереляционные данные из мобильных приложений, устройств IoT и социальных сетей. Структура данных или схема не определяется при захвате данных. Это означает, что вы можете хранить все свои данные без тщательного проектирования или необходимости знать, на какие вопросы вам могут понадобиться ответы в будущем. Различные типы аналитики ваших данных, такие как ;

  • SQL-запросы,
  • аналитика больших данных,
  • полнотекстовый поиск,
  • аналитика в реальном времени,
  • и машинное обучение

можно использовать для раскрытия инсайтов. По мере того, как организации с хранилищами данных видят преимущества озер данных, они развивают свои хранилища, включая озера данных и предоставляя разнообразные возможности запросов, варианты использования в области науки о данных и расширенные возможности для обнаружения новых информационных моделей. Gartner называет эту эволюцию Решением по управлению данными для аналитики или DMSA. В таблице приведено краткое сравнение.

2. Зачем нужны изменения? Влияние MLPO

Как я сказал в начале, в таких случаях, как наш, компании вынуждены разрабатывать продукты на основе машинного обучения. Здесь мы должны подчеркнуть тот факт, что MLOP — относительно новый термин, отличающийся от классического DevOps. В таблице ниже приведены основные различия.

Таким образом, ваше (новое) решение для БД должно быть совместимо с MLOP. Из совместимых я имею в виду БД решения должны поддерживать непрерывные операции в большом объеме с высокой скоростью. Поскольку CI/CD (непрерывная интеграция и непрерывное развертывание) является важной частью MLOP.

3. Должны ли мы использовать открытый исходный код или платить за услугу?

Это зависит от треугольника бюджет-время, и я также должен упомянуть технические возможности вашей команды. Большинство компаний предпочитают запускать решения с открытым исходным кодом до тех пор, пока масштабируемость или время не заставят их перейти на более профессиональные решения. Хотя попытки использовать решения с открытым исходным кодом увеличат технические возможности команды, поскольку они пытаются писать все самостоятельно с нуля, не тратьте слишком много времени на эту техническую адаптацию, потому что в какой-то момент это решение может стать неуправляемым. время проекта или технические возможности, или вы понимаете, что оркестровка всех решений с открытым исходным кодом неуправляема, пока у вас много продуктов. Вот хорошая картина основных поставщиков, каждый из которых предлагает модели разработки, ориентированные на облако, которые позволяют разработчикам создавать и запускать приложения без необходимости управлять серверами, а также у каждого из них есть решения для озер данных.

В зависимости от бюджета и технической компетентности вашей команды вы можете двигаться вперед. Удачи!!!