Druhy podnikových dat

🌐 K dispozici také v 29 jazycích

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)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 2 z 6 kapitoly Porozumění podnikovým datům, kapitoly 4 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Salesforce je jeden systém z mnoha · Další: Systémy kolem Salesforce

Otázka, na kterou tento modul odpovídá: Jaké druhy dat podnik má a proč patří na různá místa?

Záznam zákazníka. Seznam zemí. Objednávka. Definice pole. Pět let souhrnů prodejů. Čtyři miliony fotek z doručení. Všechno jsou to data, ale architektonicky nejde o totéž. Mění se jinak, rostou jinak, používají se jinak, vlastní je různí lidé a neměla by automaticky žít na stejném místě. Když tedy někdo řekne „potřebujeme tato data v Salesforce“, moje další otázka zní: o jaký druh dat jde? Odpověď mi začíná říkat, co s nimi dělat.

Začněte druhem, ne objektem

Jako lidé ze Salesforce převádíme požadavky na struktury skoro okamžitě: zákazník, účet; fotka, soubor; stav, výběrový seznam. Nakonec je to užitečné. Na úrovni podniku chci nejdřív vědět, s jakým druhem informací mám co do činění. Klasifikovat je lze mnoha způsoby (standardní referencí je DAMA body of knowledge) a mně se osvědčilo šest druhů: kmenová, referenční, transakční data, metadata, analytická a nestrukturovaná data. Kategorie nejsou architektura. Jsou způsobem, jak klást lepší otázky.

Kmenová data: věci, které byznys zná

Kmenová data (master data) popisují trvalé věci, kolem kterých se byznys točí: zákazníky, produkty, ceny, zaměstnance, dodavatele, místa, majetek. V prodejním orgu Salesforce jsou to vaše účty a kontakty, vaše produkty a ceníky. Ve Steve Trucking je maloobchodní partner kmenovým údajem. Keystone není událost; je to organizace, se kterou má Steve Trucking trvalý vztah. Kmenovými daty je i devět distribučních center.

Kmenová data přežijí transakce, které je používají: jeden maloobchodní partner může mít miliony doručení. První otázka o nich proto vždycky zní kdo je vlastní? Nemusí to být Salesforce. Produkty může vlastnit ERP. Salesforce může vlastnit potenciální zákazníky, zatímco ERP se stane autoritativním, jakmile jsou z nich zákazníci. Platforma MDM může vlastnit podnikovou identitu zákazníka složenou z několika systémů. Kapitola 6, Kmenová data a identita, jde do hloubky. Prozatím rozpoznejte tvar.

Referenční data: slovník, který byznys sdílí

Referenční data jsou řízený slovník, kterým se klasifikují jiná data: kódy zemí, měny, kategorie produktů, kódy důvodů, stavy. Stavy doručení ve Steve Trucking (naplánováno, naloženo, na cestě, přijíždí, doručeno, nainstalováno, výjimka, vráceno) jsou referenční data. Nejsou to doručení; jsou to slova, kterými se doručení popisují.

Vypadají malá a neškodná, často jako výběrový seznam s osmi hodnotami. Nepleťte si malé s nedůležitým. Pokud Salesforce říká Delivered, ERP říká Complete a maloobchodní partner posílá D, musí někdo definovat, co každá hodnota znamená a jak se mapují. V referenčních datech se schovávají integrační předpoklady.

Transakční data: co se stalo

Transakční data zaznamenávají činnost: zadaná objednávka, provedená platba, dokončené doručení, otevřený případ. Ve stejném prodejním orgu jsou to nabídky a jejich řádky, objednávky a jejich položky, platby: každá ukazuje zpět na zákazníka a produkt. Milion doručení ročně ve Steve Trucking jsou transakční data, stejně jako jejich aktualizace stavu: asi osm na doručení, tedy osm milionů změn stavu ročně, ve firmě, která roste o 30 % ročně.

To je úplně jiná růstová křivka než u kmenových dat. Tři maloobchodní partneři nahoře; miliony řádků pod nimi. Tady záleží na Steveově „počtu nul“: nemůžete se podívat na maloobchodního partnera → doručení → stav a dát každé krabici stejnou váhu. U transakčních dat okamžitě myslím na objem, rychlost, uchovávání, historii, archivaci, integraci a na to, jak je lidé skutečně potřebují najít. Část 2 tomu věnuje hodně času.

Metadata: data o datech

S metadaty pracujete celý kurz: definice objektu, typ pole, jeho popis, jeho vztahy. Má je celý podnik: schémata datových skladů, integrační mapování, datové katalogy, kontrakty API a u každého pole vlastník, úroveň citlivosti, definice, původ dat a pravidlo uchovávání. Hodnoty jsou data; popis toho, co znamenají, jsou metadata. Jak řekla kapitola 3, Flag2__c nikomu nic neřekne, a na tom záleží tím víc, že AI teď čte metadata, aby zjistila, co data znamenají.

Analytická data: data, která jsme vyrobili z jiných dat

„Jaká je naše míra doručení včas podle maloobchodního partnera za posledních pět let?“ není transakce. Je to analytická otázka, na kterou odpovídáme odvozením nových dat z milionů doručení: procento doručení včas, míra poškození, tržby na partnera, kvalita instalací, trendy posádek. A je to jiná práce. Dispečer, který se ptá „jaká je další zastávka kamionu 217?“, nepotřebuje procházet pět let historie. Vedení, které porovnává pět let výkonu včasnosti podle regionu, ano. Proto analytická data obvykle žijí v datovém skladu, lakehouse nebo analytické platformě postavené pro tuto práci. To, že Salesforce něco uložit dokáže, z provozní platformy nedělá místo, kde nad tím spouštět každou analýzu.

Nestrukturovaná data: co se nevejde do řádků

Dokumenty, PDF, obrázky, zvuk, video, e-maily, přepisy, znalostní články. Ve Steve Trucking fotky z doručení: asi čtyři na doručení, víc u instalací, čtyři až pět milionů ročně. Fotka není jen další pole. Je velká, může ukazovat interiér něčího domova, má vlastní pravidla uchovávání a vyhledává se jinak, pokud vůbec.

Tento druh je rok od roku důležitější, protože AI dnes dokáže dělat užitečné věci s informacemi, které dřív ležely mimo strukturovaný model. Přepis jsou data. Manuál v PDF jsou data. Fotka z instalace jsou data. To neznamená, že patří do core Salesforce. Znamená to, že patří do krajiny.

Kliknutím zvětšíte

Šest druhů, u každého čtyři otázky. Odpovědi se druh od druhu mění, a o to jde.

Druh je jen polovina otázky: zátěž

Vědět, jaký druh dat máme, nestačí. Chci také vědět, co s nimi děláme. Záleží tu na třech druzích zátěže a jejich zaměňování vede ke špatné architektuře.

Provozní: řídit byznys. Dispečer aktualizuje doručení, posádka dokončí zastávku, agent otevře případ. Spousta malých čtení a zápisů: najdi tohle, aktualizuj tamto, ukaž mi dnešní zastávky. To je OLTP, online zpracování transakcí, a v tom je Salesforce velmi dobrý; tam žijí administrátoři a vývojáři.

Analytická: rozumět byznysu. Každé doručení za pět let, seskupené podle partnera a DC, porovnané rok s rokem, propojené s financemi. Teď procházíme a agregujeme. To je OLAP, online analytické zpracování, a pro to jsou postavené datové sklady, lakehouse a analytické platformy. Jednoduše řečeno: org byznys řídí; datové sklady a jezera ho analyzují. Klasická chyba je dát tuto zátěž na provozní platformu a divit se, když nuly přibývají. Pokud chce někdo opakovaně procházet obrovská množství historie, neberte to jako „jen další sestavu“. Zeptejte se, jestli je to správná platforma. Část 2 se k tomu vrací v kapitole Návrh pro velké měřítko (coming soon) (nedělejte z core svůj datový sklad) a část 3 ukazuje, jak se analytické struktury stavějí, v kapitole Za hranicí relačních dat (coming soon).

Streamovací: data v pohybu. Události, telemetrie, změny stavu, údaje ze senzorů. Kamiony Steve Trucking posílají asi 200 000 údajů z GPS denně. Dispečera zajímá, kde je kamion 217 teď. Potřebuje Salesforce uchovávat každý minutový údaj z každého kamionu? Možná ne. „Kde je teď?“ a „jaké byly trendy efektivity tras za minulé čtvrtletí?“ pocházejí ze stejného zdroje a vedou k úplně odlišným rozhodnutím o uložení.

Jak rychle se musí data přesouvat?

Pak latence. Ve třídě to říkám takhle: reálný čas je čekat u dveří, až se někdo vrátí. Pošlete ho ven a stojíte tam, protože nemůžete pokračovat, dokud se nevrátí. To je synchronní. Téměř reálný čas je dívat se, jak odchází, a pustit se do něčeho jiného; když se krátce nato vrátí, vyřídíte to. To je asynchronní. A pak je tu dávka: nikdo nechodí ze dveří po jednom. Data čekají a přesouvají se jako skupina podle plánu: každou hodinu, každých pár hodin nebo denně. Je spousta situací, kde dávka stačí, a některé, kde ne. Vědět, která je která, je ta práce. Tyto tři pojmy nejsou jen integrační termíny; jsou to architektonické volby.

Vezměte běžnou integraci s ERP. V 11 hodin dopoledne se v ERP vytvoří nový produkt. Opravdu ho obchod potřebuje prodávat už v poledne? Viděl jsem obě odpovědi. Někteří klienti ho chtějí co nejdřív; jiní říkají, pokud jsme vám to SKU ještě neposlali, nemůžeme čekat, že ho budete prodávat. Produkty tedy obvykle denně, někdy rychleji. Zákazníci nejméně denně; viděl jsem každou hodinu a v extrémních případech téměř reálný čas. Objednávky jsou jiné: musí se rozběhnout vyřizování, takže téměř reálný čas. Obchodník uzavře obchod a jde dál a objednávka dorazí do ERP během sekund až minuty nebo dvou. Pro „podniková data“ neexistuje jedna správná latence. Zeptejte se, co byznys doopravdy potřebuje, a nedělejte všechno v reálném čase jen proto, že to zní působivě. Reálný čas něco stojí.

Čtyři otázky za kategoriemi

Nemusíte chodit kolem a vyhlašovat „tohle jsou transakční data!“ Klasifikace je tu proto, aby u každé důležité sady dat vyvolala čtyři otázky:

• Kdo je vlastní? Který systém je autoritativní? Rozkládám to na tři: kde se vytvářejí, kde se upravují a kde se na ně odkazuje? Kapitola 6 do toho jde hluboko (Vytvořeno, upraveno, odkazováno a jak rychle?).
• Jak rychle se mění? Jednou ročně, denně, desítky až stovky krát za sekundu?
• Jak velká budou? Deset záznamů, deset tisíc, deset milionů, deset miliard?
• Jaký je jejich životní cyklus? Žijí navždy, archivují se, musí se smazat, časem ztrácejí hodnotu?

Tyto čtyři mi řeknou mnohem víc než „dokáže to Salesforce uložit?“ A spojují to, co jsme se už naučili: vlastnictví, životní cyklus, „počet nul“, kde data žijí.

Jeden byznys vytváří všechny druhy

Ve Steve Trucking je maloobchodní partner kmenovým údajem; slovník stavů jsou referenční data; každé doručení je transakční; definice jeho polí jsou metadata; pětiletý přehled včasnosti je analytický; fotka z instalace je nestrukturovaná; a data z GPS jsou streamovací. To všechno jsou „data Steve Trucking“. Nic z toho neznamená, že patří do stejné databáze. To je ten posun.

Nad rámec zkoušky: co mění AI. Aby agent odpověděl na jednu otázku, může potřebovat strukturovaný záznam zákazníka, nedávnou transakci, manuál v PDF, přepis servisního hovoru a živou telemetrii. Nestrukturovaná a streamovací data se stávají plnohodnotnými částmi architektury, i když nepatří do databáze CRM, a architekt pořád musí vědět, kdo vlastní každý zdroj, jak je aktuální a jestli mu má agent věřit.

Co tady rozhoduje architekt

• O jaký druh dat jde u každé důležité sady dat a kdo ji vlastní.
• Zda je její zátěž provozní, analytická, streamovací, nebo kombinace.
• Jak rychle se mění a jak rychle ostatní systémy tu změnu skutečně potřebují vidět.
• Jak objem a životní cyklus ovlivňují, kde data žijí a jak dlouho.
• Zda je má Salesforce vlastnit, držet kopii, odkazovat na ně, nebo je nechat někde, kde lépe sedí na danou zátěž.

Když vám někdo podá požadavek, neskákejte k tomu, jaký objekt, jaké pole, jaké API. Nejdřív se zeptejte, o jaký druh dat jde, kdo je vlastní, jak rychle se mění, jak velká budou, jak dlouho žijí a co s nimi chceme dělat. Účet, událost doručení, pětiletý souhrn a fotografie mohou být pro stejný byznys důležité, aniž by byly stejným architektonickým problémem.

K prozkoumání

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. vydání (2017): standardní reference pro kategorie dat a správu dat.
• Zadání Steve Trucking, oddíl 4 (objemy).