Rodzaje danych w przedsiębiorstwie

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 2 z 6 w rozdziale Zrozumieć dane przedsiębiorstwa, rozdziale 4 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Salesforce to jeden system z wielu · Dalej: Systemy wokół Salesforce

Pytanie, na które odpowiada ten moduł: jakie rodzaje danych ma przedsiębiorstwo i dlaczego należą do różnych miejsc?

Rekord klienta. Lista krajów. Zamówienie. Definicja pola. Pięć lat sum sprzedaży. Cztery miliony zdjęć z dostaw. To wszystko dane, ale architektonicznie to nie to samo. Zmieniają się inaczej, rosną inaczej, są inaczej używane i należą do innych ludzi, więc nie powinny automatycznie mieszkać w tym samym miejscu. Kiedy więc ktoś mówi „potrzebujemy tych danych w Salesforce”, moje następne pytanie brzmi: jakiego rodzaju to dane? Odpowiedź zaczyna mi mówić, co z nimi zrobić.

Zacznij od rodzaju, nie od obiektu

Jako ludzie od Salesforce niemal natychmiast przekładamy wymagania na struktury: klient, konto; zdjęcie, plik; status, lista wyboru. W końcu to się przydaje. Na poziomie przedsiębiorstwa najpierw chcę wiedzieć, z jakim rodzajem informacji mam do czynienia. Jest wiele sposobów ich klasyfikowania (standardowym źródłem jest zbiór wiedzy DAMA), a ja uważam za przydatne sześć rodzajów: dane podstawowe, referencyjne, transakcyjne, metadane, analityczne i nieustrukturyzowane. Kategorie to nie architektura. To sposób na zadawanie lepszych pytań.

Dane podstawowe: rzeczy, które biznes zna

Dane podstawowe (master data) opisują trwałe rzeczy, wokół których kręci się biznes: klientów, produkty, ceny, pracowników, dostawców, lokalizacje, środki trwałe. W orgu sprzedażowym Salesforce to twoje konta i kontakty, produkty i cenniki. W Steve Trucking partner detaliczny to dane podstawowe. Keystone to nie zdarzenie; to organizacja, z którą Steve Trucking ma trwałą relację. Dziewięć centrów dystrybucyjnych to również dane podstawowe.

Dane podstawowe żyją dłużej niż transakcje, które z nich korzystają: jeden partner detaliczny może mieć miliony dostaw. Pierwsze pytanie o nie brzmi więc zawsze: kto jest ich właścicielem? To może nie być Salesforce. ERP może być właścicielem produktów. Salesforce może być właścicielem potencjalnych klientów, a ERP staje się nadrzędny, gdy zostają klientami. Platforma MDM może być właścicielem tożsamości klienta w skali przedsiębiorstwa, złożonej z kilku systemów. Rozdział 6, Dane podstawowe i tożsamość, wchodzi w to głęboko. Na razie rozpoznaj kształt.

Dane referencyjne: wspólne słownictwo biznesu

Dane referencyjne to kontrolowane słownictwo, którym klasyfikuje się inne dane: kody krajów, waluty, kategorie produktów, kody przyczyn, statusy. Statusy dostaw Steve Trucking (zaplanowana, załadowana, w drodze, na miejscu za chwilę, dostarczona, zainstalowana, wyjątek, zwrócona) to dane referencyjne. To nie są dostawy; to słowa, którymi opisuje się dostawy.

Wyglądają na małe i nieszkodliwe, często to lista wyboru z ośmioma wartościami. Nie myl małego z nieważnym. Jeśli Salesforce mówi Delivered, ERP mówi Complete, a partner detaliczny wysyła D, ktoś musi zdefiniować, co każde z nich znaczy i jak się ze sobą mapują. W danych referencyjnych ukrywają się założenia integracyjne.

Dane transakcyjne: co się wydarzyło

Dane transakcyjne rejestrują aktywność: złożone zamówienie, dokonaną płatność, zrealizowaną dostawę, otwarte zgłoszenie. W tym samym orgu sprzedażowym to oferty i pozycje ofert, zamówienia i pozycje zamówień, płatności: każde z nich wskazuje z powrotem na klienta i produkt. Milion dostaw rocznie w Steve Trucking to dane transakcyjne, podobnie jak ich aktualizacje statusu: około ośmiu na dostawę, czyli osiem milionów zmian statusu rocznie, w firmie rosnącej o 30% rocznie.

To zupełnie inna krzywa wzrostu niż w przypadku danych podstawowych. Trzech partnerów detalicznych na górze; miliony wierszy pod spodem. Tu ma znaczenie Liczba Zer Steve’a: nie możesz patrzeć na partner detaliczny → dostawa → status i dawać każdemu prostokątowi tej samej wagi. Przy danych transakcyjnych od razu myślę o wolumenie, tempie, retencji, historii, archiwizacji, integracji i o tym, jak ludzie naprawdę muszą je znajdować. Część 2 spędza tam dużo czasu.

Metadane: dane o danych

Z metadanymi pracujesz przez cały kurs: definicja obiektu, typ pola, jego opis, relacje. Ma je całe przedsiębiorstwo: schematy hurtowni, mapowania integracji, katalogi danych, kontrakty API, a dla każdego pola właściciela, poziom wrażliwości, definicję, pochodzenie i regułę retencji. Wartości to dane; opis tego, co znaczą, to metadane. Jak mówił rozdział 3, Flag2__c nikomu nic nie mówi, a ma to tym większe znaczenie teraz, gdy AI czyta metadane, żeby ustalić, co znaczą dane.

Dane analityczne: dane, które zrobiliśmy z innych danych

„Jaki jest nasz odsetek dostaw na czas według partnera detalicznego w ciągu ostatnich pięciu lat?” to nie transakcja. To pytanie analityczne, na które odpowiada się, wyprowadzając nowe dane z milionów dostaw: odsetek dostaw na czas, wskaźnik uszkodzeń, przychód na partnera, jakość instalacji, trendy ekip. I to inna praca. Dyspozytor pytający „jaki jest następny przystanek ciężarówki 217?” nie musi przeszukiwać pięciu lat historii. Zarząd porównujący pięć lat punktualności według regionów musi. Dlatego dane analityczne zwykle mieszkają w hurtowni, lakehouse albo na platformie analitycznej zbudowanej do tej pracy. To, że Salesforce może coś przechowywać, nie czyni platformy operacyjnej miejscem do uruchamiania na tym każdej analizy.

Dane nieustrukturyzowane: to, co nie mieści się w wierszach

Dokumenty, PDF-y, obrazy, dźwięk, wideo, e-maile, transkrypcje, artykuły bazy wiedzy. W Steve Trucking zdjęcia z dostaw: około czterech na dostawę, więcej przy instalacjach, cztery do pięciu milionów rocznie. Zdjęcie to nie po prostu kolejne pole. Jest duże, może pokazywać wnętrze czyjegoś domu, ma własne reguły retencji i przeszukuje się je inaczej, jeśli w ogóle.

Ten rodzaj z roku na rok zyskuje na znaczeniu, bo AI potrafi teraz robić użyteczne rzeczy z informacjami, które kiedyś leżały poza modelem ustrukturyzowanym. Transkrypcja to dane. Instrukcja w PDF to dane. Zdjęcie z instalacji to dane. To nie znaczy, że należą do core Salesforce. Znaczy, że należą do krajobrazu.

Click to enlarge

Sześć rodzajów, po cztery pytania. Odpowiedzi zmieniają się od rodzaju do rodzaju i właśnie o to chodzi.

Rodzaj to tylko połowa pytania: obciążenie

Wiedza, jakiego rodzaju dane mamy, nie wystarczy. Chcę też wiedzieć, co z nimi robimy. Liczą się tu trzy rodzaje obciążenia, a mylenie ich prowadzi do złej architektury.

Operacyjne: prowadzenie biznesu. Dyspozytor aktualizuje dostawę, ekipa zamyka przystanek, agent otwiera zgłoszenie. Mnóstwo małych odczytów i zapisów: znajdź to, zaktualizuj tamto, pokaż mi dzisiejsze przystanki. To jest OLTP, przetwarzanie transakcyjne online, i Salesforce jest w tym bardzo dobry; to tu mieszkają administratorzy i programiści.

Analityczne: rozumienie biznesu. Każda dostawa z pięciu lat, pogrupowana według partnera i CD, porównana rok do roku, połączona z danymi finansowymi. Teraz przeszukujemy i agregujemy. To jest OLAP, przetwarzanie analityczne online, i do tego są zbudowane hurtownie, lakehouse’y i platformy analityczne. Mówiąc prosto: org prowadzi biznes; hurtownie i data lake’i go analizują. Klasyczny błąd to umieszczenie takiego obciążenia na platformie operacyjnej i zdziwienie, gdy przybywa zer. Jeśli ktoś chce wielokrotnie przeszukiwać ogromne ilości historii, nie traktuj tego jako „kolejnego raportu”. Zapytaj, czy to właściwa platforma. Część 2 wraca do tego w rozdziale Projektowanie pod skalę (coming soon) (nie rób z core swojej hurtowni), a część 3 pokazuje, jak buduje się struktury analityczne, w rozdziale Poza modelem relacyjnym (coming soon).

Strumieniowe: dane w ruchu. Zdarzenia, telemetria, zmiany statusu, odczyty czujników. Ciężarówki Steve Trucking wysyłają około 200 000 odczytów GPS dziennie. Dyspozytora obchodzi, gdzie ciężarówka 217 jest teraz. Czy Salesforce musi przechowywać każdy minutowy odczyt z każdej ciężarówki? Może nie. „Gdzie jest teraz?” i „jakie były trendy efektywności tras w zeszłym kwartale?” pochodzą z tego samego źródła i prowadzą do zupełnie różnych decyzji o przechowywaniu.

Jak szybko muszą się przemieszczać?

Potem opóźnienie. Na zajęciach ujmuję to tak: czas rzeczywisty to czekanie w drzwiach, aż ktoś wróci. Wysyłasz kogoś i stoisz, bo nie możesz nic dalej robić, dopóki nie wróci. To jest synchroniczne. Prawie czas rzeczywisty to patrzenie, jak ktoś wychodzi, i zajęcie się czymś innym; gdy wkrótce wróci, zajmujesz się tym. To jest asynchroniczne. A potem jest przetwarzanie wsadowe (batch): nikt nie wychodzi za drzwi pojedynczo. Dane czekają i przemieszczają się grupą według harmonogramu: co godzinę, co kilka godzin albo raz dziennie. Jest mnóstwo sytuacji, w których przetwarzanie wsadowe wystarcza, i są takie, w których nie wystarcza. Odróżnienie jednych od drugich to właśnie ta praca. Te trzy pojęcia to nie są tylko terminy integracyjne; to wybory architektoniczne.

Weźmy typową integrację z ERP. Nowy produkt powstaje w ERP o 11 rano. Czy dział sprzedaży naprawdę musi go sprzedawać już w południe? Widziałem obie odpowiedzi. Niektórzy klienci chcą go jak najszybciej; inni mówią: jeśli jeszcze nie wysłaliśmy wam tego SKU, nie możemy oczekiwać, że już go sprzedajecie. Dlatego produkty zwykle idą raz dziennie, czasem szybciej. Klienci co najmniej raz dziennie; widziałem co godzinę, a w skrajnych przypadkach prawie w czasie rzeczywistym. Zamówienia to co innego: realizacja musi się zacząć, więc prawie w czasie rzeczywistym. Handlowiec zamyka transakcję i idzie dalej, a zamówienie ląduje w ERP w ciągu kilku sekund do minuty czy dwóch. Nie ma jednego właściwego opóźnienia dla „danych przedsiębiorstwa”. Zapytaj, czego biznes naprawdę potrzebuje, i nie rób wszystkiego w czasie rzeczywistym tylko dlatego, że brzmi to imponująco. Czas rzeczywisty kosztuje.

Cztery pytania za kategoriami

Nie musisz chodzić i ogłaszać „to są dane transakcyjne!”. Klasyfikacja ma uruchomić cztery pytania o każdy ważny zbiór danych:

• Kto jest ich właścicielem? Który system jest nadrzędny? Rozbijam to na trzy pytania: gdzie dane są tworzone, gdzie są edytowane i gdzie są wskazywane? Rozdział 6 wchodzi w to głęboko (Tworzone, edytowane, wskazywane i jak szybko?).
• Jak szybko się zmieniają? Raz w roku, codziennie, od dziesiątek do setek razy na sekundę?
• Jak bardzo rosną? Dziesięć rekordów, dziesięć tysięcy, dziesięć milionów, dziesięć miliardów?
• Jaki mają cykl życia? Żyją wiecznie, są archiwizowane, muszą być usuwane, z czasem tracą wartość?

Te cztery mówią mi dużo więcej niż „czy Salesforce może to przechowywać?”. I spinają to, czego już się nauczyliśmy: własność, cykl życia, Liczbę Zer, miejsce, w którym mieszkają dane.

Jeden biznes wytwarza każdy rodzaj

W Steve Trucking partner detaliczny to dane podstawowe; słownik statusów to dane referencyjne; każda dostawa to dane transakcyjne; definicje jej pól to metadane; pięcioletnia karta punktualności to dane analityczne; zdjęcie z instalacji to dane nieustrukturyzowane; a strumień GPS to dane strumieniowe. Wszystko to „dane Steve Trucking”. Nic z tego nie znaczy, że należą do tej samej bazy danych. Na tym polega zmiana.

Poza egzaminem: co zmienia AI. Żeby odpowiedzieć na jedno pytanie, agent może potrzebować ustrukturyzowanego rekordu klienta, niedawnej transakcji, instrukcji w PDF, transkrypcji rozmowy serwisowej i telemetrii na żywo. Dane nieustrukturyzowane i strumieniowe stają się pełnoprawnymi częściami architektury, nawet jeśli nie należą do bazy danych CRM, a architekt nadal musi wiedzieć, kto jest właścicielem każdego źródła, jak bardzo jest aktualne i czy agent powinien mu ufać.

Co tu decyduje architekt

• Jakiego rodzaju danymi jest każdy ważny zbiór danych i kto jest jego właścicielem.
• Czy jego obciążenie jest operacyjne, analityczne, strumieniowe, czy mieszane.
• Jak szybko się zmienia i jak szybko inne systemy naprawdę muszą widzieć zmianę.
• Jak wolumen i cykl życia kształtują to, gdzie dane mieszkają i jak długo.
• Czy Salesforce powinien być ich właścicielem, trzymać kopię, wskazywać na nie, czy zostawić je w miejscu lepiej dopasowanym do obciążenia.

Kiedy ktoś daje ci wymaganie, nie skacz od razu do tego, jaki obiekt, jakie pole, jakie API. Najpierw zapytaj, jakiego rodzaju to dane, kto jest ich właścicielem, jak szybko się zmieniają, jak bardzo rosną, jak długo żyją i co próbujemy z nimi zrobić. Konto, zdarzenie dostawy, pięcioletni agregat i fotografia mogą być ważne dla tego samego biznesu, nie będąc tym samym problemem architektonicznym.

Do zgłębienia

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, wydanie 2 (2017): standardowe źródło na temat kategorii danych i zarządzania danymi.
• Opis Steve Trucking (po angielsku), sekcja 4 (wolumeny).