Виды корпоративных данных

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 2 из 6 главы Понимание корпоративных данных, глава 4 курса Data Architect. Каждый модуль самостоятелен. Назад: Salesforce — одна система из многих · Далее: Системы вокруг Salesforce

Вопрос, на который отвечает этот модуль: какие виды данных есть у предприятия и почему им место в разных местах?

Запись клиента. Список стран. Заказ. Определение поля. Итоги продаж за пять лет. Четыре миллиона фотографий доставок. Все это данные, но с точки зрения архитектуры это не одно и то же. Они по-разному меняются, по-разному растут, по-разному используются, ими владеют разные люди, и они не должны автоматически жить в одном месте. Поэтому, когда кто-то говорит «нам нужны эти данные в Salesforce», мой следующий вопрос: какой это вид данных? Ответ начинает подсказывать, что с ними делать.

Начните с вида, а не с объекта

Мы, люди Salesforce, переводим требования в структуры почти мгновенно: клиент — Account; фотография — File; статус — список выбора. Со временем это пригодится. Но на уровне предприятия я сначала хочу понять, с какой информацией имею дело. Классифицировать ее можно по-разному (свод знаний DAMA — стандартный справочник), и мне полезны шесть видов: мастер-данные, справочные, транзакционные, метаданные, аналитические и неструктурированные. Категории — это не архитектура. Это способ задавать вопросы получше.

Мастер-данные: то, что бизнес знает

Мастер-данные описывают долговечные сущности, вокруг которых работает бизнес: клиенты, продукты, цены, сотрудники, поставщики, места, активы. В org Salesforce для продаж это ваши организации и контакты, ваши продукты и прайс-листы. В Steve Trucking розничный партнер (Retail Partner) — это мастер-данные. Keystone — не событие; это организация, с которой у Steve Trucking постоянные отношения. Девять распределительных центров — тоже мастер-данные.

Мастер-данные живут дольше транзакций, которые их используют: у одного розничного партнера могут быть миллионы доставок. Поэтому первый вопрос о них всегда кто ими владеет? Это может быть не Salesforce. Продуктами может владеть ERP. Salesforce может владеть потенциальными клиентами, а ERP становится авторитетной, когда они становятся клиентами. MDM-платформа может владеть корпоративной идентичностью клиента, собранной из нескольких систем. Глава 6, «Мастер-данные и идентичность», разбирает это глубоко. А пока научитесь узнавать форму.

Справочные данные: общий словарь бизнеса

Справочные данные — это контролируемый словарь, которым классифицируют другие данные: коды стран, валюты, категории продуктов, коды причин, статусы. Статусы доставок Steve Trucking (запланирована, загружена, в пути, прибывает, доставлена, установлена, исключение, возвращена) — это справочные данные. Это не доставки; это слова, которыми доставки описывают.

Они выглядят маленькими и безобидными — часто это список выбора из восьми значений. Не путайте маленькое с неважным. Если Salesforce говорит Delivered, ERP говорит Complete, а розничный партнер присылает D, кто-то должен определить, что означает каждое и как они сопоставляются. Именно в справочных данных прячутся допущения интеграции.

Транзакционные данные: что произошло

Транзакционные данные фиксируют активность: размещенный заказ, проведенный платеж, выполненную доставку, открытое обращение. В том же org для продаж это предложения и их строки, заказы и их позиции, платежи: каждая запись указывает обратно на клиента и продукт. Миллион доставок в год у Steve Trucking — транзакционные данные, как и обновления их статусов: около восьми на доставку, то есть восемь миллионов изменений статуса в год у бизнеса, который растет на 30 % в год.

Это совсем другая кривая роста, чем у мастер-данных. Три розничных партнера наверху; миллионы строк под ними. Вот где важно «число нулей» Steve (Steve’s Number of Zeros): нельзя смотреть на цепочку розничный партнер → доставка → статус и придавать каждому прямоугольнику одинаковый вес. С транзакционными данными я сразу думаю об объеме, скорости, хранении, истории, архивировании, интеграции и о том, как людям на самом деле нужно их находить. Часть 2 проводит там много времени.

Метаданные: данные о данных

Вы весь курс работали с метаданными: определение объекта, тип поля, его описание, его связи. Они есть на всем предприятии: схемы хранилищ данных, сопоставления интеграций, каталоги данных, контракты API, а для каждого поля — владелец, уровень чувствительности, определение, происхождение и правило хранения. Значения — это данные; описание того, что они означают, — метаданные. Как говорилось в главе 3, Flag2__c никому ничего не говорит, и теперь, когда ИИ читает метаданные, чтобы понять смысл данных, это важнее, чем когда-либо.

Аналитические данные: данные, полученные из других данных

«Какова наша доля своевременных доставок по розничным партнерам за последние пять лет?» — это не транзакция. Это аналитический вопрос, и на него отвечают, выводя новые данные из миллионов доставок: процент своевременности, доля повреждений, выручка на партнера, качество установки, тенденции по бригадам. И это другая работа. Диспетчеру, который спрашивает «какая следующая остановка у грузовика 217?», не нужно просматривать пять лет истории. Руководству, которое сравнивает своевременность за пять лет по регионам, нужно. Поэтому аналитические данные обычно живут в хранилище данных, lakehouse или аналитической платформе, построенной для этой работы. То, что Salesforce может что-то хранить, не делает операционную платформу местом для любого анализа этих данных.

Неструктурированные данные: то, что не помещается в строки

Документы, PDF, изображения, аудио, видео, письма, расшифровки, статьи базы знаний. В Steve Trucking это фотографии доставок: около четырех на доставку, больше при установке, четыре-пять миллионов в год. Фотография — не просто еще одно поле. Она большая, на ней может быть видно, что у человека дома, у нее свои правила хранения, и ищут по ней иначе, если ищут вообще.

Этот вид с каждым годом важнее, потому что ИИ теперь умеет делать полезные вещи с информацией, которая раньше лежала за пределами структурированной модели. Расшифровка — это данные. PDF-руководство — это данные. Фотография установки — это данные. Это не значит, что ей место в ядре Salesforce. Это значит, что ей место на ландшафте.

Click to enlarge

Шесть видов, по четыре вопроса на каждый. Ответы меняются от вида к виду, и в этом весь смысл.

Вид — это только половина вопроса: нагрузка

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

Операционная: вести бизнес. Диспетчер обновляет доставку, бригада завершает остановку, агент поддержки открывает обращение. Множество мелких операций чтения и записи: найди это, обнови то, покажи сегодняшние остановки. Это OLTP, оперативная обработка транзакций, и Salesforce очень хорош в этом; здесь живут администраторы и разработчики.

Аналитическая: понимать бизнес. Каждая доставка за пять лет, сгруппированная по партнерам и DC, сравнение год к году, объединение с финансами. Теперь мы сканируем и агрегируем. Это OLAP, оперативная аналитическая обработка, и именно для нее построены хранилища данных, lakehouse и аналитические платформы. Проще говоря: org ведет бизнес; хранилища и озера данных его анализируют. Классическая ошибка — поставить эту нагрузку на операционную платформу и удивляться, когда растут нули. Если кто-то хочет многократно сканировать огромные объемы истории, не считайте это «просто еще одним отчетом». Спросите, та ли это платформа. Часть 2 возвращается к этому в главе Проектирование для масштаба (coming soon) (не делайте ядро своим хранилищем данных), а часть 3 показывает, как строятся аналитические структуры, в главе За пределами реляционной модели (coming soon).

Потоковая: данные в движении. События, телеметрия, изменения статусов, показания датчиков. Грузовики Steve Trucking присылают около 200 000 показаний GPS в день. Диспетчеру важно, где грузовик 217 сейчас. Нужно ли Salesforce хранить каждое ежеминутное показание каждого грузовика? Может, и нет. «Где он сейчас?» и «какими были тенденции эффективности маршрутов в прошлом квартале?» берутся из одного источника, но ведут к совершенно разным решениям о хранении.

Как быстро это должно двигаться?

Затем задержка. На занятиях я объясняю это так: реальное время — это ждать у двери, пока кто-то вернется. Вы отправляете человека и стоите там, потому что не можете продолжать, пока он не вернется. Это синхронно. Почти реальное время — это проводить его взглядом и заняться чем-то другим; когда он вскоре вернется, вы с этим разберетесь. Это асинхронно. А еще есть пакетная обработка: никто не выходит за дверь по одному. Данные ждут и перемещаются группой по расписанию: раз в час, раз в несколько часов или раз в день. Есть множество ситуаций, когда пакетной обработки достаточно, и некоторые, когда нет. Знать, где какая, — это и есть работа. Эти три понятия — не просто термины интеграции; это архитектурные решения.

Возьмем типовую интеграцию с ERP. Новый продукт создан в ERP в 11 утра. Действительно ли продажам нужно продавать его к полудню? Я видел оба ответа. Одни клиенты хотят его как можно скорее; другие говорят: если мы еще не отгрузили вам этот SKU, мы не можем ждать, что вы будете его продавать. Поэтому продукты обычно синхронизируются раз в день, иногда быстрее. Клиенты — как минимум раз в день; я видел и раз в час, а в крайних случаях почти в реальном времени. С заказами иначе: должно начаться исполнение, поэтому почти реальное время. Продавец закрывает сделку и идет дальше, а заказ попадает в ERP за время от нескольких секунд до минуты-двух. Единственно правильной задержки для «корпоративных данных» не существует. Спросите, что на самом деле нужно бизнесу, и не делайте все в реальном времени только потому, что это звучит впечатляюще. У реального времени есть цена.

Четыре вопроса за категориями

Не нужно ходить и объявлять: «это транзакционные данные!» Классификация нужна, чтобы задать четыре вопроса о каждом важном наборе данных:

• Кто им владеет? Какая система авторитетна? Я разбиваю это на три части: где он создается, где редактируется и где на него ссылаются? Глава 6 разбирает это глубоко (Где создается, редактируется, используется — и как быстро?).
• Как быстро он меняется? Раз в год, раз в день, от десятков до сотен раз в секунду?
• Насколько большим он становится? Десять записей, десять тысяч, десять миллионов, десять миллиардов?
• Каков его жизненный цикл? Живет ли он вечно, архивируется, должен быть удален, теряет ценность со временем?

Эти четыре вопроса говорят мне гораздо больше, чем «может ли Salesforce это хранить?». И они сводят вместе то, что мы уже узнали: владение, жизненный цикл, «число нулей», где живут данные.

Один бизнес производит все виды

В Steve Trucking розничный партнер — мастер-данные; словарь статусов — справочные данные; каждая доставка — транзакционные; определения ее полей — метаданные; пятилетняя сводка по своевременности — аналитические; фотография установки — неструктурированные; а поток GPS — потоковые. Все это «данные Steve Trucking». Ничто из этого не означает, что им место в одной базе данных. В этом и сдвиг.

За пределами экзамена: что меняет ИИ. Чтобы ответить на один вопрос, агенту может понадобиться структурированная запись клиента, недавняя транзакция, PDF-руководство, расшифровка обращения в поддержку и живая телеметрия. Неструктурированные и потоковые данные становятся полноправными частями архитектуры, даже когда им не место в базе данных CRM, а архитектору по-прежнему нужно знать, кто владеет каждым источником, насколько он актуален и стоит ли агенту ему доверять.

Что здесь решает архитектор

• К какому виду относится каждый важный набор данных и кто им владеет.
• Какая у него нагрузка: операционная, аналитическая, потоковая или смешанная.
• Как быстро он меняется и как быстро другим системам действительно нужно видеть изменение.
• Как объем и жизненный цикл определяют, где он живет и как долго.
• Должен ли Salesforce им владеть, хранить копию, ссылаться на него или оставить его там, где он лучше подходит для нагрузки.

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

Дополнительно

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2-е издание (2017): стандартный справочник по категориям данных и управлению данными (на английском).
• Бриф Steve Trucking, раздел 4 (объемы).