Управляемое чтение: острова корпоративных данных, совместное управление данными и производительность служб данных сталкиваются с проблемами, а услуги управления основными данными с высокой доступностью все больше ценятся предприятиями.Начиная с качества и совместного использования базовой модели бизнес-данных программы Mini, границы модели бизнес-данных и обеспечивает процесс эволюции высокодоступных служб управления данными для предприятий.Я надеюсь помочь вам получить больше помощи на пути к применению мастер-данных.
Полный текст 5262 слова, расчетное время чтения 16 минут.
Концепция основных данных
1.1 Введение в концепцию основных данных
Основные данные (сокращенно MD) обычно относятся к данным, совместно используемым между системами (например, содержимое данных с общими сценариями, такими как клиенты, учетные записи и организации), поэтому их основная ценность заключается в решении проблемы совместного использования и согласованности данных.
В соответствии со сложностью реализации управления мастер-данными, ссылаясь на Джилл Дайч, точку зрения Эвана Леви, управление мастер-данными можно разделить на шесть уровней, от низкого до высокого, что отражает разную зрелость управления мастер-данными (MDM). Давайте кратко представим эти шесть уровней.Поскольку уровень 3 обычно используется для общих предприятий, следующее относится только к уровням от 0 до уровня 3. Заинтересованные студенты могут прочитать энциклопедию основных данных:
(Encyclopedia.Baidu.com/item/%E4%B8…
Уровень 0: Управление основными данными (MDM) не реализовано.
В случае уровня 0 это означает, что между различными приложениями предприятия нет совместного использования данных, и во всем предприятии не существует элементов определения данных. Каждая система управляет своими данными, а совместное использование осуществляется посредством переключения сетки.
Уровень 1: Предоставьте список
Предоставьте список, мы можем понять, что система регистрации данных реализована, а регистрация информации о данных осуществляется вручную, включая добавление данных, удаление, обновление и обработку конфликтов. В этой модели уже есть мотивация для унифицированного управления данными и обслуживания, но стоимость модели чрезвычайно высока, а процесс, который сильно зависит от ручного управления, также подвержен ошибкам.
Уровень 2: Равный доступ (через интерфейс каждая система напрямую связана с основным хостом данных)
По сравнению с предоставлением списка вводится идея унифицированного управления регистрацией основных данных. Благодаря установлению стандартов и определений данных и совместному доступу через хранилище в центральном репозитории обеспечивается поддержка определений метаданных для совместного использования данных об использовании между различными системами. Хотя сохраненные данные по-прежнему хранятся отдельно для каждой системы, благодаря унифицированному описанию и определению, а также синхронизации и автоматическому обновлению информации возможности управления и контроля, а также снижение затрат были значительно улучшены. Однако из-за характера децентрализованного хранилища стоимость управления и контроля по-прежнему очень высока.
Уровень 3: Централизованная обработка шины
Централизованная обработка шины разрушает организационные границы отдельных приложений и устанавливает и поддерживает основные данные единообразно, используя стандарты данных, приемлемые для каждой системы. Централизованная обработка означает создание общей объектной платформы для MDM. Эта схема имеет очень сильные ограничения и гарантии для основных данных.Конечно, затраты на создание и сложность также соответственно возрастут, особенно производительность, стабильность и гарантия транзакций основных данных.
1.2 Зачем нужны основные данные?
Зачем нужны основные данные? Чтобы ответить на этот вопрос, нам нужно сначала проанализировать проблемы, возникающие в бизнес-системе.Мы можем грубо свести проблемы к следующим четырем категориям:
Данные разбросаны и избыточны
Каждая система, приложение и даже бизнес-отдел на предприятии будут создавать свою собственную версию данных основных бизнес-объектов. Лучшим примером является построение данных о клиентах. Различные отделы будут создавать данные о клиентах в соответствии со своими уникальными потребностями. Например, система отдела контрактов будет обращать внимание на информацию о клиентах и контрактах, отдел закупок будет обращать внимание на продукты клиента, послепродажное обслуживание и другой контент. Но основные атрибуты клиентов, такие как имя клиента и информация об адресе, неоднократно записываются в каждом уголке предприятия. Это приводит к очень серьезной проблеме (помимо затрат на хранение), избыточность данных приводит к низкому качеству данных, и предприятия не могут полностью понять полный атрибут клиента.
Противоречивые данные, трудно калибровать
На самом деле, из-за несогласованности данных внутри предприятия, на предприятии часто происходит большое количество растраты ресурсов.К потерям ресурсов здесь относятся не только трата времени, денег и человеческих ресурсов, но и влияние на клиентский опыт и продвижение бизнеса Подождите.
Деловое сотрудничество неэффективно
Как только произойдет фрагментация данных, она будет сопровождаться низкой производительностью, неэффективным управлением бизнесом, неунифицированным клиентским опытом, недовольными клиентами и напрасными усилиями отдела маркетинга.
Данные не могут быть ускорены из-за изменений
На предприятии относительно часто бизнес-изменения приводят к инициированию и прекращению проектов Среди таких высокочастотных изменений наименьшее, что должно быть потеряно, - это данные, то есть ускорение бизнеса, но нет применение бизнес-данных мастер-данных, отток данных считается само собой разумеющимся.
Обобщая и анализируя вышеперечисленные проблемы, мы видим, что основная причина возникновения этих проблем заключается в отсутствии нисходящей спецификации управления данными. Суть создания мастер-данных также требует, чтобы предприятия имели стратегию управления данными сверху вниз, чтобы способствовать эффективному продвижению.Предприятия должны установить общекорпоративное управление мастер-данными, чтобы действительно решить проблему мастер-данных, а не уклоняться от создания предприятия Из-за стоимости мастер-данных исходная система модифицируется.
(Library.Baidu.com/view/No 7 Стоимость 9 О…
2. Резюме реальной борьбы с архитектурой мастер-данных
2.1 Анализ предыстории бизнеса
Создание мастер-данных сталкивается с различными проблемами и проблемами, в основном, включая следующие моменты:
2.1.1 Проблемы
-
С ростом бизнеса апплетов Baidu резко возросло количество сервисов бизнес-модулей, и возникла необходимость в изменении и извлечении данных.
-
Стандарты SLA для каждого модуля бизнес-услуг неодинаковы, поэтому сложно предоставить услугу с высокой доступностью для удовлетворения потребностей бизнеса.
-
Сетчатое хранение данных вызывает такие проблемы, как избыточность данных, согласованность данных, безопасность данных и острова данных.
-
Существуют различия в распознавании данных, взаимодействие данных между несколькими системами, перекрестными продуктами и подразделениями затруднено, а унифицированное управление данными невозможно.
2.1.2 Проблемы
-
Разделение границы данных, какие данные должны быть включены в основные данные?
-
Как эффективно управлять моделью данных при изменении модели данных? Как эффективно справиться с быстрым обновлением и итерацией бизнеса?
-
Как обеспечить согласованность, правильность и стабильность данных?
-
Как обеспечить оперативность и точность обмена данными?
2.2 Общая схема архитектурного проектирования и идеи
Сама служба управления мастер-данными также является службой, которая постоянно оптимизируется и развивается.В реальном боевом процессе мы продолжаем исследовать, направлять практику с теорией и обобщать набор методологий, которые соответствуют бизнесу интеллектуальных апплетов Baidu.Мы сначала начинаем со стадии анализа.
2.2.1 Этап анализа
Цель состоит в том, чтобы начать с анализа спроса, сопоставить проблему с проблемным пространством, отсортировать и абстрагировать спрос, понять проблему и предпосылки спроса, провести анализ данных и процессов, проанализировать модель предметной области бизнеса и использовать схема потока данных (Data Flow Diagram): DFD для краткости, чтобы графически выразить логическую функцию системы, логический поток данных в системе и процесс логического преобразования. После того, как панорамный поток событий определен, необходимо выделить границу домена.Обычно для проведения анализа и моделирования домена используется метод шторма событий.
Возьмем в качестве примера процесс создания и использования апплета Baidu: Анализ бизнес-процесса создания и использования апплета Baidu
Процесс создания и использования апплета Baidu, результаты анализа шторма событий:
2.2.2 Этап проектирования и реализации
Сопоставьте проблемное пространство с пространством решений, абстрактными бизнес-областями, моделируйте данные предметной области, разделяйте границы услуг, проектируйте и внедряйте архитектуры, а также рисуйте диаграммы вариантов использования, диаграммы состояний, диаграммы классов сущностей, диаграммы последовательности и ER на основе анализа спроса в Диаграмма гарантирует отсутствие проблем с вариантом использования, ссылаясь на принцип проектирования «основные данные», разделяя границы службы и разделяя модель данных на различные домены вспомогательных услуг и основной домен службы в « "разрезание торта".
Ссылаясь на теорию модели разделения иерархии данных, извлеките ключевые понятия в виде поддоменов и в основном разделите на четыре части: домен клиента, домен продукта, домен пользователя и домен базовых данных.Домен клиента моделируется вокруг клиентов, домен продукта моделируется вокруг апплета. , домен пользователя Домен в основном основан на модели разработчика, а базовый домен данных предоставляет таблицу кодов метаданных. детали следующим образом:
домен продукта: основная модель данных небольших программ, пакетов, категорий, оценок, прав и других бизнес-приложений.
поле основных данных: базовая модель данных, такая как категория апплета, хост и т. д.
домен пользователя: пользовательские домены, такие как пользователи, роли, разрешения и т. д.
клиентский домен: клиентские домены, такие как тема, квалификация и т. д.
2.3 Цели проектирования архитектуры мастер-данных
Основные данные мини-программы направлены на решение проблемы совместного использования данных в нескольких системах, уточнение базовой модели данных бизнеса мини-программы и служат в качестве базовой услуги для предоставления набора решений по управлению данными для базовой модели данных в рамках основные данные, включая предоставление услуг для каждой стороны бизнеса Хранение, поиск, распространение и другие услуги основных данных.
Давайте сначала посмотрим на картинку, на следующей картинке показана основная архитектура развертывания службы данных:
2.3.1 Общие цели проектирования
-
Устранение избыточности данных, обеспечение согласованности и безопасности данных
-
Унифицированное распознавание данных
-
Унифицированное управление данными для предоставления услуг высокой доступности
-
Совместное использование данных, улучшение синергии данных между несколькими системами, кросс-продуктами, кросс-продуктами и кросс-департаментами, а также поддержка распределения данных в нескольких сценариях и измерениях.
2.3.2 Архитектурный дизайн и реальный бой
Знакомство с концепцией службы передачи данных, службы передачи данных, которая поддерживает передачу данных между источниками данных, такими как реляционные базы данных, NoSQL и большие данные (OLAP). Это служба передачи данных, которая объединяет миграцию данных, синхронизацию данных в реальном времени и подписку на данные. Передача данных имеет широкий спектр сценариев приложений в общедоступном облаке, внутреннем частном облаке и частном облаке Paas, создавая безопасную, легко масштабируемую и высокодоступную архитектуру данных для пользователей.
2.3.3 Введение в реализацию ключевых технологических моментов
2.3.3.1 Сделки/компенсация
Анализ сценариев использования транзакций/компенсации: операции ассоциативного хранения с несколькими таблицами, сценарии master-slave, чувствительные к задержкам, с принудительным чтением основной базы данных, временная компенсация/повторная попытка ключевых ненормальных данных в реальном времени.
В процессе разработки системы необходимо сосредоточиться на отправке больших транзакций.Большие транзакции приведут к задержке master-slave, загрузке IO и снижению производительности базы данных.Необходимо разумно оценить уровень данных операции транзакций, и принципы работы с большими пакетами данных:
-
Размер сделки должен быть разумным
-
Контролируемый объем данных
-
Отнимающий много времени и управляемый интерфейс
Для операций вставки/обновления/удаления каждый раз обрабатывается 100~500 элементов и выполняется фиксация
Для операции выбора каждый раз запрашивается от 100 до 500 элементов.
рекомендовать: В пределах допустимого диапазона бизнес-сценария операции разбиты на небольшие транзакции в пакетах.
2.3.3.2 Высокопроизводительное чтение и запись, высокопроизводительный поиск
Основными способами достижения высокой производительности службы являются кэширование, оптимизация базы данных, синхронизация и разделение данных и т. д. На примере службы основных данных можно выделить следующие основные методы повышения производительности службы:
Аспект кэша: для сценариев с большим количеством операций чтения и меньшим количеством операций записи добавьте многоуровневые кэши [распределенные кэши, локальные кэши и т. д.], чтобы уменьшить нагрузку на базу данных и обеспечить горизонтальное расширение служб.
оптимизация базы данных: Начиная с нескольких аспектов, необоснованное крупномасштабное обновление и запись, что приводит к проблеме задержки между ведущими и подчиненными базами данных; проблема глубокого подкачки базы данных; рациональное использование оптимизации подзапросов; проблема сортировки индексов.
Индексы базы данных, отсутствие подходящих индексов, полное сканирование таблицы немного большего размера и небольшой параллелизм могут привести к резкому скачку времени отклика БД или даже лавинообразному снижению производительности БД.
Воспроизведение: Для таких сценариев, как многотабличный поиск и нечеткий поиск, используйте функцию Es для обеспечения высокопроизводительного поиска. Основные ключевые моменты обеспечивают своевременность и точность синхронизации базы данных с Es.
2.3.3.3 Доступность
Мастер-данные — это единственный сервис для каждого бизнес-конца, работающий с основными данными, и необходимо обеспечить высокую доступность сервисов Сервис мастер-данных в режиме реального времени использует архитектуру микросервисов и использует возможности виртуализации ресурсов Baidu для обеспечения управления сервисами. унифицированное управление конфигурацией и распределенное отслеживание ссылок.Он поддерживает балансировку нагрузки запросов, повторные попытки, самозащиту службы (ограничение тока, объединение, переход на более раннюю версию и т. д.) и реализует самовосстановление автоматических сбоев машины, полностью гарантируя доступность службы.
2.3.3.4 Механизм процесса
Дизайнерские ворота: Из-за обновления основных данных влияние относительно велико, рекомендуется иметь профессиональную независимую команду для проверки и подтверждения качества дизайна.
спецификация разработки: обратите внимание на качество кодирования, обеспечьте единые стандарты кодирования, регулярно организуйте проверки кода и улучшайте читабельность и ремонтопригодность кода.
Принятие теста: В дополнение к самотестированию, одиночному тестированию и т. д., мастер-данные также нуждаются в более полном тестировании на системном уровне, которое может реализовать регрессию теста привязки многосторонних служб доступа.
онлайн: Малый трафик, оттенки серого, автоматический откат, управление баном и другие возможности, механизм онлайн-подтверждения.
Эксплуатация и техническое обслуживание: Управление жизненным циклом приложений, управление правами пользователей, возможности наблюдаемого мониторинга, мониторинг в реальном времени и эффективное обнаружение проблем.
2.3.3.5 Синхронизация чувствительных ко времени данных
Схема синхронизации изменения данных мастер-данных в режиме реального времени, основанная на мониторинге бинлога, параллельная запись multi-MQ поддерживает горизонтальное расширение, обеспечивая скорость записи бинлога; унифицированный сервис приема и распределения данных, основанный на контроле версий данных, поддерживает горизонтальное расширение услуг, обеспечивает потребление данных и распределяет своевременность. Мониторинг данных, компенсационные услуги для обеспечения надежности обмена данными.
На следующем рисунке показана основная модель архитектуры распределения синхронизации данных службы данных:
Суммировать: Команда апплета Baidu завершила запуск основной службы данных еще в 2019 году. На основе базовой модели данных апплета Baidu были депонированы сотни моделей данных с максимальной поддержкой 9000+ запросов в секунду, годовая доступность SLA более чем 4,9, включая Baidu 10 + Доступ к линейкам основных бизнес-продуктов, чтобы гарантировать, что общая доступность услуг программ Baidu Smart Mini превышает 4,9. Непротиворечивость данных достигает 4,9 с и компенсируется контролем непротиворечивости для обеспечения окончательной непротиворечивости данных.
3. Думая о расширении основных данных
3.1 Существуют ли более применимые сценарии для основных данных?
Помимо обслуживания онлайновых бизнес-систем в режиме реального времени, приложения с мастер-данными также могут применяться во многих сценариях. Например, на основе мастер-данных для аудита, мониторинга и анализа активов данных, использования мастер-данных в качестве важного актива данных, всестороннего мониторинга их построения, использования и т. д. Это может в определенной степени улучшить поддержку принятия решений и найти проблемы в бизнесе. операций, проводить аудиты в режиме реального времени и способствовать постоянному совершенствованию системы управления и постоянному совершенствованию развития бизнеса. Другим примером является построение бизнес-портретов на основе мастер-данных.При гарантии высокой эффективности и правильности самих мастер-данных в сочетании с относительно полным модельным проектированием мастер-данных стоимость построения бизнес-портрета может быть значительно уменьшенный.
3.2 Как улучшить возможности группы по разработке мастер-данных?
Создание мастер-данных (система MDM) — это основная работа по формированию способности мыслить данными.Это процесс, который требует постоянного совершенствования и прогресса.Процесс построения включает в себя сотрудничество и сотрудничество всех отделов и разработчиков бизнес-систем. Следующее также обобщает соответствующее резюме, надеясь помочь вам улучшить мыслительные способности основных данных:
-
Чтобы укрепить всеобщее изучение и понимание мастер-данных, лучше всего согласовать механизм. Предлагается ввести обязательное требование об участии в строительстве всех субъектов предпринимательской деятельности.
-
Создайте отдельную команду по созданию мастер-данных, выполняйте ее с нейтральной точки зрения и обеспечивайте рациональность, стандартизацию и специализацию построения.
-
Усилить обзор дизайна модели и архитектуры, чтобы обеспечить эффект от процесса реализации, и в то же время усилить сводку, чтобы помочь каждому учиться и улучшать свои способности.
Рекомендуемое чтение:
｜Облачная и интеллектуальная практика управления массивными данными в Baidu Search
｜Как решить совместную информацию о «смешанной рыбе и драконе» в поиске Baidu с помощью ИИ?
｜Быстрое редактирование — мощная практика умного редактирования Duka
---------- END ----------
Байду Гик говорит
Официальный технический общедоступный аккаунт Baidu доступен онлайн!
Технические галантереи · Отраслевая информация · Интернет-салон · Отраслевая конференция
Информация о найме · Внутренняя информация · Технические книги · Периферийные устройства Baidu
Приглашаем студентов обратить внимание