Как обмениваться данными в организации

Question

Каковы хорошие способы организации обмениваться ключевыми данными между многими отделами и приложениями?

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

Есть ли другие хорошие подходы к обмену данными?И как ваши подходы соотносятся с приведенными выше в отношении таких проблем, как:

повторяющиеся данные

процессы синхронизации данных, подверженные ошибкам

плотный против.слабая связь (уменьшение зависимостей/хрупкости/координации тестирования)

архитектурное упрощение

безопасность

производительность

четко определенные интерфейсы

другие соответствующие проблемы?

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

Спасибо за ваши предложения и советы...

Answer 1

Я уверен, что вы предвидели это: «Это зависит».

Это зависит от всего.И решение по обмену данными о клиентах для отдела А может быть совершенно другим для обмена данными о клиентах с отделом Б.

Моя любимая концепция, возникшая на протяжении многих лет, — это концепция «Событийной последовательности».Этот термин пришел из Amazon, когда речь шла о распределенных системах.

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

Например, когда запись о клиенте обновляется в системе A, данные о клиенте в системе B становятся устаревшими и не совпадают.Но «в конце концов» запись из A будет отправлена ​​в B посредством какого-то процесса.Итак, в конечном итоге два экземпляра совпадут.

Когда вы работаете с одной системой, у вас нет «EC», а есть мгновенные обновления, единый «источник истины» и, как правило, механизм блокировки для обработки условий гонки и конфликтов.

Чем лучше ваши подразделения могут работать с данными «EC», тем легче будет разделить эти системы.Простой пример — хранилище данных, используемое отделом продаж.Они используют DW для создания своих ежедневных отчетов, но они не запускают свои отчеты до раннего утра и всегда смотрят на «вчерашние» (или более ранние) данные.Таким образом, нет необходимости в реальном времени обеспечивать полное соответствие DW системе ежедневных операций.Вполне приемлемо, чтобы процесс запускался, скажем, в конце рабочего дня и массово переносил дневные транзакции и действия в рамках большой единой операции обновления.

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

Это крайний, упрощенный и очень грубый пример ЕС.

Но рассмотрим такую ​​большую систему, как Google.Как потребитель поиска, мы понятия не имеем, когда и сколько времени потребуется, чтобы результат поиска, который собирает Google, оказался на странице поиска.1 мс?1 с?10 секунд?10 часов?Легко представить, что если вы зайдете на серверы Google на западном побережье, вы вполне можете получить другой результат поиска, чем если бы вы зашли на их серверы на восточном побережье.Ни в каком смысле эти два примера не являются полностью совместимыми.Но по большому счету они в основном последовательны.И что касается их варианта использования, их потребители на самом деле не страдают от задержек и задержек.

Рассмотрим электронную почту.A хочет отправить сообщение B, но в процессе сообщение проходит через системы C, D и E.Каждая система принимает сообщение, принимает на себя полную ответственность за него, а затем передает его другой.Отправитель видит, что письмо отправляется в путь.Получатель на самом деле не упускает этого, потому что он не обязательно знает, что оно придет.Таким образом, существует большой промежуток времени, который может потребоваться для того, чтобы это сообщение прошло через систему, и никто не будет знать или заботиться о том, насколько быстро оно проходит.

С другой стороны, А мог разговаривать по телефону с Б.«Я только что отправил, ты уже получил?Сейчас?Сейчас?Получи это сейчас?"

Таким образом, существует некий основной, подразумеваемый уровень производительности и реакции.В конце концов, «в конце концов» исходящие сообщения А совпадают с входящим ящиком Б.

Эти задержки, принятие устаревших данных, будь то день или 1–5 секунд, — вот что контролирует окончательное соединение ваших систем.Чем слабее это требование, тем слабее связь и тем больше гибкости в вашем распоряжении с точки зрения проектирования.

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

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

Редактировать, в ответ на первый комментарий.

Правильно, именно.Например, игра здесь: если B не может изменить данные о клиенте, то какой вред от изменения данных о клиенте?Можете ли вы «рискнуть» тем, что он устареет на короткое время?Возможно, данные о ваших клиентах поступают достаточно медленно, чтобы вы могли немедленно реплицировать их из пункта А в пункт Б.Скажем, изменение помещено в очередь, которая из-за небольшого объема легко подхватывается (< 1 с), но даже при этом оно будет «вне транзакции» с исходным изменением, и поэтому есть небольшое окно, в котором А мог бы данные, которых нет у B.

Теперь ум действительно начинает вращаться.Что происходит в течение этой секунды «задержки», каков наихудший возможный сценарий.И можете ли вы это обойти?Если вы можете спроектировать задержку в 1 с, возможно, вы сможете спроектировать задержку в 5 с, 1 м или даже дольше.Какой объем данных о клиентах вы на самом деле используете в B?Возможно, B — это система, предназначенная для облегчения комплектации заказов со склада.Трудно представить себе что-то большее, чем просто идентификатор клиента и, возможно, имя.Просто что-то, чтобы грубо определить, для кого предназначен заказ, пока он собирается.

Системе комплектования не обязательно распечатывать всю информацию о клиенте до самого конца процесса комплектования, и к тому времени заказ может быть переведен в другую систему, которая, возможно, более актуальна, особенно с информацией о доставке, поэтому в конце концов, системе комплектования практически не нужны данные о клиентах.Фактически, вы можете ВСТРОИТЬ и денормализовать информацию о клиенте в заказе на комплектацию, поэтому нет необходимости или ожидания синхронизации в дальнейшем.Если идентификатор клиента верен (который в любом случае никогда не изменится) и имя (которое меняется так редко, что его не стоит обсуждать), это единственная реальная справочная информация, которая вам нужна, и все ваши квитанции об отборе товаров совершенно точны на момент отправки. создание.

Хитрость заключается в мышлении: разбить системы и сосредоточиться на важных данных, необходимых для выполнения задачи.Данные, которые вам не нужны, не нужно реплицировать или синхронизировать.Людей раздражают такие вещи, как денормализация и сокращение данных, особенно когда они из мира реляционного моделирования данных.И не без оснований, к этому следует относиться с осторожностью.Но как только вы переходите к распределению, вы неявно денормализуетесь.Черт возьми, ты сейчас копируешь это оптом.Так что, возможно, вы тоже будете умнее.

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

Но самое сложное — это вначале разорвать цепочку с центральной БД и объяснить людям, что они не могут «иметь все», как они могут ожидать, когда у вас есть единое, централизованное, идеальное хранилище информации.

Answer 2

Это определенно не полный ответ. Извините, для моего длинного поста и надеюсь, что он добавляет к мыслям, которые будут представлены здесь.

У меня есть несколько наблюдений на одном из упомянутых вами аспекта.

duplicate data

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

well-defined interfaces

Большинство интерфейсов определяются с приятным намерением для других ограничений. Однако у нас просто привычка расти из ограничений, размещенных ранее определенными интерфейсами. Опять дело для непрерывного рефакторинга.

tight coupling vs loose coupling

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

architectural simplification

Для меня это ключ к борьбе со всеми проблемами, которые вы упомянули в вашем вопросе. SIP VS H.323 VoIP-история приходит мне в голову. SIP очень упрощена, легко построить, в то время как H.323, как типичный стандарт Telecom, пытался предусматривать каждую проблему на планете о VoIP и обеспечить для него решения. Конечный результат, SIP вырос намного быстрее. Это боль в соответствии с решением H.323. Фактически, соблюдение H.323 - это индустрия мегабастов.

On a few architectural fads that I have grown up to.

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

Answer 3

Чтобы решить количество этих вопросов, мне нравится концепция центральных «хаб данных». HUB Data представляет собой «единый источник истины» для определенного объекта, но только хранит идентификаторы, нет информации, таких как имена и т. Д. Фактически, он только хранит карты ID - например, эти карты идентификатора клиента в системе A, для Номер клиента из системы B, а также к номеру клиента в системе C. Интерфейсы между системами используют концентратор, чтобы узнать, как связывать информацию в одной системе на другую.

Это как центральный перевод; Вместо того, чтобы написать определенный код для сопоставления из A-> B, A-> C, и B-> C, с его экспоненциальным увеличением посещаемости, поскольку вы добавляете больше систем, вам нужно только преобразовать в / из концентратора: A- > HUB, B-> HUB, C-> HUB, D-> HUB и т. Д.