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

🌐 Також доступно 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 body of knowledge — стандартний довідник), і я вважаю корисними шість видів: основні, довідкові, транзакційні дані, метадані, аналітичні й неструктуровані дані. Категорії — не архітектура. Вони — спосіб ставити кращі запитання.

Основні дані: речі, які знає бізнес

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

Основні дані живуть довше за транзакції, що їх використовують: один роздрібний партнер може мати мільйони доставок. Тож перше запитання про них завжди — хто ними володіє? Це може бути не Salesforce. ERP може володіти продуктами. Salesforce може володіти потенційними клієнтами, а ERP стає авторитетною, щойно вони стали клієнтами. MDM-платформа може володіти корпоративною ідентичністю клієнта, зібраною з кількох систем. Розділ 6, «Основні дані та ідентичність», іде вглиб. Поки що розпізнайте форму.

Довідкові дані: словник, спільний для бізнесу

Довідкові дані — керований словник, яким класифікують інші дані: коди країн, валюти, категорії продуктів, коди причин, статуси. Статуси доставок Steve Trucking (заплановано, завантажено, у дорозі, прибуває, доставлено, встановлено, виняток, повернено) — довідкові дані. Це не доставки; це слова, якими доставки описують.

Вони виглядають маленькими й нешкідливими, часто — список вибору з восьми значень. Не плутайте маленьке з неважливим. Якщо Salesforce каже Delivered, ERP — Complete, а роздрібний партнер надсилає D, хтось має визначити, що кожне означає і як вони зіставляються. У довідкових даних ховаються припущення інтеграцій.

Транзакційні дані: що сталося

Транзакційні дані фіксують діяльність: розміщене замовлення, здійснений платіж, завершена доставка, відкрите звернення. У тій самій org продажів це пропозиції (quotes) та їхні рядки, замовлення та їхні позиції, платежі: кожен із них вказує назад на клієнта й продукт. Мільйон доставок на рік у Steve Trucking — транзакційні дані, як і їхні оновлення статусу: близько восьми на доставку, тобто вісім мільйонів змін статусу на рік, у бізнесі, що зростає на 30% на рік.

Це зовсім інша крива зростання, ніж в основних даних. Три роздрібні партнери вгорі; мільйони рядків під ними. Тут і важлива «кількість нулів» Steve: не можна подивитися на роздрібний партнер → доставка → статус і дати кожному прямокутнику однакову вагу. З транзакційними даними я одразу думаю про обсяг, швидкість, зберігання, історію, архівування, інтеграцію і те, як люди насправді мають їх знаходити. Частина 2 приділяє цьому чимало часу.

Метадані: дані про дані

Ви працювали з метаданими весь курс: визначення об’єкта, тип поля, його опис, його зв’язки. Вони є в усього підприємства: схеми сховища даних, інтеграційні зіставлення, каталоги даних, API-контракти, а для кожного поля — власник, рівень чутливості, визначення, походження і правило зберігання. Значення — це дані; опис того, що вони означають, — метадані. Як сказано в розділі 3, Flag2__c нікому нічого не каже, і це важливіше тепер, коли ШІ читає метадані, щоб з’ясувати, що означають дані.

Аналітичні дані: дані, зроблені з інших даних

«Який у нас відсоток вчасних доставок за роздрібними партнерами за останні п’ять років?» — не транзакція. Це аналітичне запитання, на яке відповідають, виводячи нові дані з мільйонів доставок: відсоток вчасності, частка пошкоджень, дохід на партнера, якість встановлення, тренди бригад. І це інша робота. Диспетчерові, що питає «яка наступна зупинка вантажівки 217?», не треба переглядати п’ять років історії. Керівництву, що порівнює вчасність за регіонами за п’ять років, — треба. Тому аналітичні дані зазвичай живуть у сховищі даних, lakehouse чи аналітичній платформі, збудованій для цієї роботи. Те, що Salesforce може щось зберігати, не робить операційну платформу місцем для кожного аналізу цих даних.

Неструктуровані дані: те, що не вміщується в рядки

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

Цей вид щороку стає важливішим, бо ШІ тепер може робити корисні речі з інформацією, що раніше лежала поза структурованою моделлю. Транскрипт — це дані. PDF-інструкція — це дані. Фото встановлення — це дані. Це не означає, що їм місце в core Salesforce. Це означає, що їм місце на ландшафті.

Click to enlarge

Шість видів, по чотири запитання. Відповіді змінюються від виду до виду, і саме в цьому суть.

Вид — лише половина запитання: навантаження

Знати, який вид даних у нас є, недостатньо. Я також хочу знати, що ми з ними робимо. Тут важливі три навантаження, і плутати їх — значить робити погану архітектуру.

Операційне: вести бізнес. Диспетчер оновлює доставку, бригада закриває зупинку, агент відкриває звернення. Багато дрібних читань і записів: знайди це, онови те, покажи сьогоднішні зупинки. Це OLTP, онлайн-обробка транзакцій, і Salesforce дуже добрий у цьому; тут живуть адміністратори й розробники.

Аналітичне: розуміти бізнес. Кожна доставка за п’ять років, згрупована за партнерами й DC, порівняна рік до року, поєднана з фінансами. Тепер ми переглядаємо й агрегуємо. Це OLAP, онлайн-аналітична обробка, і саме для цього збудовано сховища даних, lakehouses та аналітичні платформи. Простіше кажучи: org веде бізнес; сховища даних і data lakes його аналізують. Класична помилка — покласти це навантаження на операційну платформу і дивуватися, коли ростуть нулі. Якщо хтось хоче постійно переглядати величезні обсяги історії, не ставтеся до цього як до «ще одного звіту». Запитайте, чи це правильна платформа. Частина 2 повертається до цього в розділі Проєктування для масштабу (coming soon) (не робіть ядро своїм сховищем даних), а Частина 3 показує, як будують аналітичні структури, у розділі Поза реляційним (coming soon).

Потокове: дані в русі. Події, телеметрія, зміни статусу, показання датчиків. Вантажівки Steve Trucking надсилають близько 200 000 показань GPS на день. Диспетчера цікавить, де вантажівка 217 зараз. Чи має Salesforce зберігати кожне щохвилинне показання кожної вантажівки? Можливо, ні. «Де вона зараз?» і «які були тренди ефективності маршрутів минулого кварталу?» походять з одного джерела і ведуть до зовсім різних рішень про зберігання.

Як швидко це має рухатися?

Далі затримка. На заняттях я кажу так: реальний час — це чекати біля дверей, доки хтось повернеться. Ви відправляєте людину і стоїте там, бо не можете продовжити, доки вона не повернеться. Це синхронно. Майже реальний час — побачити, як вона пішла, і зайнятися чимось іншим; коли вона невдовзі повернеться, ви з цим розберетеся. Це асинхронно. А ще є пакетна обробка (batch): ніхто не виходить за двері по одному. Дані чекають і переміщуються групою за розкладом: щогодини, раз на кілька годин чи щодня. Є безліч ситуацій, де пакетної обробки досить, і є такі, де ні. Знати, де що, — це і є робота. Ці три — не лише інтеграційні терміни; це архітектурні рішення.

Візьміть звичайну інтеграцію з ERP. Новий продукт створено в ERP об 11:00. Чи справді продажам треба продавати його до полудня? Я бачив обидві відповіді. Одні клієнти хочуть його якнайшвидше; інші кажуть: якщо ми ще не відвантажили вам цей SKU, ми не можемо чекати, що ви вже його продаватимете. Тож продукти зазвичай раз на день, іноді частіше. Клієнти — щонайменше раз на день; я бачив щогодини, а в крайніх випадках майже реальний час. Замовлення — інша справа: має початися виконання, тож майже реальний час. Продавець закриває угоду й іде далі, а замовлення потрапляє в ERP за кілька секунд чи хвилину-дві. Немає однієї правильної затримки для «корпоративних даних». Питайте, що бізнесу насправді потрібно, і не робіть усе в реальному часі, бо це звучить вражаюче. Реальний час має ціну.

Чотири запитання за категоріями

Не треба ходити й оголошувати «це транзакційні дані!» Класифікація існує, щоб викликати чотири запитання про кожен важливий набір даних:

• Хто ними володіє? Яка система авторитетна? Я розбиваю це на три: де їх створюють, де їх редагують і де на них посилаються? Розділ 6 розглядає це глибоко (Створено, редаговано, посилаються — і як швидко?).
• Як швидко вони змінюються? Раз на рік, щодня, від десятків до сотень разів на секунду?
• Наскільки великими вони стають? Десять записів, десять тисяч, десять мільйонів, десять мільярдів?
• Який у них життєвий цикл? Вони живуть вічно, архівуються, мають бути видалені, з часом втрачають цінність?

Ці чотири кажуть мені набагато більше, ніж «чи може Salesforce це зберігати?» І вони зводять разом те, що ми вже вивчили: власність, життєвий цикл, кількість нулів, де живуть дані.

Один бізнес створює всі види

У Steve Trucking роздрібний партнер — основні дані; словник статусів — довідкові дані; кожна доставка — транзакційні; визначення її полів — метадані; п’ятирічний показник вчасності — аналітичні; фото встановлення — неструктуровані; а потік GPS — потокові. Усе це — «дані Steve Trucking». Ніщо з цього не означає, що їм місце в одній базі даних. Це і є зсув.

За межами іспиту: що змінює ШІ. Щоб відповісти на одне запитання, агентові може знадобитися структурований запис клієнта, нещодавня транзакція, PDF-інструкція, транскрипт звернення в сервіс і жива телеметрія. Неструктуровані й потокові дані стають повноправними частинами архітектури, навіть коли їм не місце в базі CRM, і архітектор досі має знати, хто володіє кожним джерелом, наскільки воно актуальне і чи варто агентові йому довіряти.

Що тут вирішує архітектор

• Що це за вид даних — кожен важливий набір — і хто ним володіє.
• Чи його навантаження операційне, аналітичне, потокове чи змішане.
• Як швидко він змінюється і як швидко інші системи справді мають бачити зміну.
• Як обсяг і життєвий цикл визначають, де він живе і як довго.
• Чи має Salesforce ним володіти, тримати копію, посилатися на нього чи лишити його там, де краще для навантаження.

Коли вам дають вимогу, не стрибайте одразу до того, який об’єкт, яке поле, який API. Спершу запитайте, що це за вид даних, хто ними володіє, як швидко вони змінюються, наскільки великими стають, як довго живуть і що ми намагаємося з ними зробити. Account, подія доставки, агрегат за п’ять років і фотографія можуть бути важливими для одного бізнесу, не будучи однією архітектурною задачею.

Додаткові матеріали

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