Các loại dữ liệu doanh nghiệp

Cũng có bằng 28 ngôn ngữ khác

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

A kitchen where each kind of food is kept its own way: bins and jars on the pantry shelves, fresh food on the counter, the fridge and freezer, a recipe book. — Hình ảnh được tạo bằng AI

Mô-đun 2 trong 6 của chương Hiểu dữ liệu doanh nghiệp, chương 4 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Salesforce là một hệ thống giữa nhiều hệ thống · Tiếp theo: Các hệ thống quanh Salesforce

Câu hỏi mô-đun này trả lời: Một doanh nghiệp nắm giữ những loại dữ liệu nào, và vì sao chúng thuộc về những nơi khác nhau?

Một bản ghi khách hàng. Một danh sách quốc gia. Một đơn hàng. Một định nghĩa trường. Tổng doanh số năm năm. Bốn triệu ảnh giao hàng. Tất cả đều là dữ liệu, nhưng về mặt kiến trúc chúng không giống nhau. Chúng thay đổi khác nhau, tăng trưởng khác nhau, được dùng khác nhau và do những người khác nhau sở hữu, và chúng không nên tự động nằm cùng một chỗ. Vì vậy khi ai đó nói “chúng tôi cần dữ liệu này trong Salesforce”, câu hỏi tiếp theo của tôi là: đó là loại dữ liệu gì? Câu trả lời bắt đầu cho tôi biết nên làm gì với nó.

Bắt đầu từ loại dữ liệu, không phải đối tượng

Là người làm Salesforce, chúng ta dịch yêu cầu thành cấu trúc gần như ngay lập tức: khách hàng, Tài khoản; ảnh, File; trạng thái, danh sách chọn. Điều đó cuối cùng cũng hữu ích. Ở cấp doanh nghiệp, trước tiên tôi muốn biết mình đang xử lý loại thông tin gì. Có nhiều cách phân loại (bộ tri thức DAMA là tài liệu tham chiếu chuẩn), và tôi thấy sáu loại hữu ích: dữ liệu chủ, dữ liệu tham chiếu, dữ liệu giao dịch, siêu dữ liệu, dữ liệu phân tích và dữ liệu phi cấu trúc. Các phân loại không phải là kiến trúc. Chúng là một cách để đặt câu hỏi tốt hơn.

Dữ liệu chủ: những thứ doanh nghiệp biết

Dữ liệu chủ mô tả những thứ bền vững mà doanh nghiệp vận hành xung quanh: khách hàng, sản phẩm, giá, nhân viên, nhà cung cấp, địa điểm, tài sản. Trong một org bán hàng của Salesforce, đó là Tài khoản và Liên hệ, sản phẩm và sổ giá của bạn. Ở Steve Trucking, một Đối tác bán lẻ là dữ liệu chủ. Keystone không phải một sự kiện; đó là một tổ chức mà Steve Trucking có quan hệ lâu dài. Chín trung tâm phân phối cũng là dữ liệu chủ.

Dữ liệu chủ sống lâu hơn các giao dịch dùng nó: một Đối tác bán lẻ có thể có hàng triệu lần giao hàng. Vì vậy câu hỏi đầu tiên về nó luôn là ai sở hữu nó? Có thể không phải Salesforce. ERP có thể sở hữu sản phẩm. Salesforce có thể sở hữu khách hàng tiềm năng trong khi ERP trở thành bên có thẩm quyền khi họ đã là khách hàng. Một nền tảng MDM có thể sở hữu danh tính doanh nghiệp của một khách hàng được ghép từ nhiều hệ thống. Chương 6, Dữ liệu chủ và danh tính, đi sâu vào đó. Hiện tại, hãy nhận ra hình dáng của nó.

Dữ liệu tham chiếu: bộ từ vựng doanh nghiệp dùng chung

Dữ liệu tham chiếu là bộ từ vựng được kiểm soát dùng để phân loại dữ liệu khác: mã quốc gia, tiền tệ, danh mục sản phẩm, mã lý do, trạng thái. Các trạng thái giao hàng của Steve Trucking (đã xếp lịch, đã chất hàng, đang đi giao, sắp đến, đã giao, đã lắp đặt, ngoại lệ, đã trả lại) là dữ liệu tham chiếu. Chúng không phải các lần giao hàng; chúng là những từ dùng để mô tả các lần giao hàng.

Nó trông nhỏ bé và vô hại, thường là một danh sách chọn với tám giá trị. Đừng nhầm nhỏ với không quan trọng. Nếu Salesforce nói Delivered, ERP nói Complete và một Đối tác bán lẻ gửi D, phải có ai đó định nghĩa mỗi giá trị nghĩa là gì và chúng ánh xạ với nhau thế nào. Dữ liệu tham chiếu là nơi các giả định về tích hợp ẩn nấp.

Dữ liệu giao dịch: điều gì đã xảy ra

Dữ liệu giao dịch ghi lại hoạt động: một đơn hàng được đặt, một khoản thanh toán được thực hiện, một lần giao hàng hoàn tất, một trường hợp được mở. Trong cùng org bán hàng đó, đó là báo giá và dòng báo giá, đơn hàng và mục đơn hàng, thanh toán: mỗi thứ đều trỏ ngược về một khách hàng và một sản phẩm. Một triệu lần giao hàng mỗi năm của Steve Trucking là dữ liệu giao dịch, và các cập nhật trạng thái của chúng cũng vậy: khoảng tám lần mỗi lần giao, tức tám triệu lần thay đổi trạng thái mỗi năm, ở một doanh nghiệp tăng trưởng 30% mỗi năm.

Đó là một đường cong tăng trưởng hoàn toàn khác với dữ liệu chủ. Ba Đối tác bán lẻ ở trên cùng; hàng triệu dòng bên dưới. Đây là chỗ Số chữ số 0 của Steve quan trọng: bạn không thể nhìn Đối tác bán lẻ → Giao hàng → Trạng thái và cho mỗi hộp cùng một trọng lượng. Với dữ liệu giao dịch, tôi lập tức nghĩ đến khối lượng, tốc độ, lưu giữ, lịch sử, lưu trữ, tích hợp, và cách người ta thực sự cần tìm nó. Phần 2 dành rất nhiều thời gian cho điều đó.

Siêu dữ liệu: dữ liệu về dữ liệu

Bạn đã làm việc với siêu dữ liệu suốt khóa học: định nghĩa của một đối tượng, kiểu của một trường, mô tả của nó, các quan hệ của nó. Cả doanh nghiệp đều có nó: lược đồ kho dữ liệu, ánh xạ tích hợp, danh mục dữ liệu, hợp đồng API, và với mỗi trường là chủ sở hữu, mức độ nhạy cảm, định nghĩa, dòng dõi dữ liệu và quy tắc lưu giữ. Các giá trị là dữ liệu; mô tả về ý nghĩa của chúng là siêu dữ liệu. Như chương 3 đã nói, Flag2__c chẳng cho ai biết gì, và điều đó càng quan trọng hơn bây giờ khi AI đọc siêu dữ liệu để hiểu dữ liệu có nghĩa là gì.

Dữ liệu phân tích: dữ liệu chúng ta tạo ra từ dữ liệu khác

“Tỷ lệ đúng hẹn của chúng ta theo Đối tác bán lẻ trong năm năm qua là bao nhiêu?” không phải là một giao dịch. Đó là một câu hỏi phân tích, được trả lời bằng cách suy ra dữ liệu mới từ hàng triệu lần giao hàng: phần trăm đúng hẹn, tỷ lệ hư hỏng, doanh thu mỗi đối tác, chất lượng lắp đặt, xu hướng của tổ giao hàng. Và đó là một công việc khác. Điều phối viên hỏi “điểm dừng tiếp theo của xe 217 là gì?” không cần quét năm năm lịch sử. Ban lãnh đạo so sánh năm năm hiệu suất đúng hẹn theo khu vực thì cần. Đó là lý do dữ liệu phân tích thường nằm trong một kho dữ liệu, một lakehouse hay một nền tảng phân tích được xây cho công việc đó. Việc Salesforce có thể lưu một thứ không biến nền tảng vận hành thành nơi chạy mọi phân tích trên nó.

Dữ liệu phi cấu trúc: những gì không vừa vào các dòng

Tài liệu, PDF, hình ảnh, âm thanh, video, email, bản ghi lời thoại, bài viết kiến thức. Ở Steve Trucking là ảnh giao hàng: khoảng bốn ảnh mỗi lần giao, nhiều hơn với lắp đặt, bốn đến năm triệu ảnh mỗi năm. Một bức ảnh không chỉ là một trường nữa. Nó lớn, nó có thể cho thấy bên trong nhà của ai đó, nó có quy tắc lưu giữ riêng, và nó được tìm kiếm theo cách khác, nếu có.

Loại này mỗi năm càng quan trọng hơn, vì giờ AI có thể làm những việc hữu ích với thông tin trước đây nằm ngoài mô hình có cấu trúc. Một bản ghi lời thoại là dữ liệu. Một sổ tay PDF là dữ liệu. Một bức ảnh lắp đặt là dữ liệu. Điều đó không có nghĩa nó thuộc về lõi của Salesforce. Nó có nghĩa là nó thuộc về bản đồ hệ thống.

Click to enlarge

Sáu loại, mỗi loại bốn câu hỏi. Câu trả lời thay đổi theo từng loại, và đó chính là điểm mấu chốt.

Loại dữ liệu chỉ là một nửa câu hỏi: khối lượng công việc

Biết chúng ta có loại dữ liệu gì là chưa đủ. Tôi còn muốn biết chúng ta đang làm gì với nó. Ba khối lượng công việc quan trọng ở đây, và nhầm lẫn chúng tạo ra kiến trúc tồi.

Vận hành: điều hành doanh nghiệp. Một điều phối viên cập nhật một lần giao hàng, một tổ hoàn tất một điểm dừng, một nhân viên mở một trường hợp. Rất nhiều thao tác đọc và ghi nhỏ: tìm cái này, cập nhật cái kia, cho tôi xem các điểm dừng hôm nay. Đây là OLTP, xử lý giao dịch trực tuyến (online transaction processing), và Salesforce rất giỏi việc này; đó là nơi quản trị viên và lập trình viên sinh sống.

Phân tích: hiểu doanh nghiệp. Mọi lần giao hàng trong năm năm, nhóm theo đối tác và DC, so sánh qua từng năm, kết hợp với tài chính. Giờ chúng ta đang quét và tổng hợp. Đây là OLAP, xử lý phân tích trực tuyến (online analytical processing), và đó là thứ mà kho dữ liệu, lakehouse và các nền tảng phân tích được xây ra để làm. Nói đơn giản: org điều hành doanh nghiệp; kho và hồ dữ liệu phân tích nó. Một sai lầm kinh điển là đặt khối lượng công việc đó lên nền tảng vận hành rồi ngạc nhiên khi các chữ số 0 tăng lên. Nếu ai đó muốn quét lặp đi lặp lại khối lượng lịch sử khổng lồ, đừng coi đó là “chỉ thêm một báo cáo nữa”. Hãy hỏi đó có phải là nền tảng phù hợp không. Phần 2 quay lại chuyện này trong Thiết kế cho quy mô lớn (coming soon) (đừng biến lõi thành kho dữ liệu của bạn), và Phần 3 cho thấy các cấu trúc phân tích được xây thế nào trong Vượt ra ngoài mô hình quan hệ (Beyond Relational) (coming soon).

Luồng: dữ liệu đang chuyển động. Sự kiện, dữ liệu đo xa, thay đổi trạng thái, số đọc cảm biến. Xe tải của Steve Trucking gửi khoảng 200.000 lần đọc GPS mỗi ngày. Điều phối viên quan tâm xe 217 đang ở đâu ngay bây giờ. Salesforce có cần giữ từng lần đọc theo phút từ mọi xe tải không? Có thể không. “Bây giờ nó ở đâu?” và “xu hướng hiệu quả tuyến của quý trước là gì?” đến từ cùng một nguồn và dẫn đến những quyết định lưu trữ hoàn toàn khác nhau.

Nó cần di chuyển nhanh đến đâu?

Rồi đến độ trễ. Trong lớp tôi nói thế này: thời gian thực là đứng chờ trước cửa cho ai đó quay về. Bạn cử họ đi và đứng đó, vì bạn không thể làm tiếp cho đến khi họ trở lại. Đó là đồng bộ. Gần thời gian thực là nhìn họ đi rồi làm việc khác; khi họ quay về ngay sau đó, bạn mới xử lý. Đó là bất đồng bộ. Rồi còn theo lô (batch): không ai đi ra cửa từng người một. Dữ liệu chờ và di chuyển thành một nhóm theo lịch: hằng giờ, vài giờ một lần, hoặc hằng ngày. Có rất nhiều tình huống mà theo lô là đủ, và có những tình huống thì không. Biết cái nào là cái nào chính là công việc. Ba khái niệm đó không chỉ là thuật ngữ tích hợp; đó là những lựa chọn kiến trúc.

Lấy kiểu tích hợp ERP phổ biến. Một sản phẩm mới được tạo trong ERP lúc 11:00. Bộ phận kinh doanh có thực sự cần bán nó trước 12:00 không? Tôi đã gặp cả hai câu trả lời. Có khách hàng muốn có nó càng sớm càng tốt; người khác thì nói, nếu chúng tôi chưa chuyển SKU đó đến cho bạn, chúng tôi không thể mong bạn bán nó ngay. Vì vậy sản phẩm thường cập nhật hằng ngày, đôi khi nhanh hơn. Khách hàng, tối thiểu hằng ngày; tôi đã thấy hằng giờ, và trong trường hợp cực đoan là gần thời gian thực. Đơn hàng thì khác: việc thực hiện đơn phải bắt đầu, nên cần gần thời gian thực. Nhân viên kinh doanh chốt giao dịch rồi làm việc khác, và đơn hàng đến ERP trong vài giây đến một hai phút. Không có một độ trễ đúng duy nhất cho “dữ liệu doanh nghiệp”. Hãy hỏi nghiệp vụ thực sự cần gì, và đừng biến mọi thứ thành thời gian thực chỉ vì nghe ấn tượng. Thời gian thực có cái giá của nó.

Bốn câu hỏi đằng sau các phân loại

Bạn không cần đi khắp nơi tuyên bố “đây là dữ liệu giao dịch!” Việc phân loại tồn tại để khơi ra bốn câu hỏi về mỗi tập dữ liệu quan trọng:

Ai sở hữu nó? Hệ thống nào có thẩm quyền? Tôi chia câu hỏi này thành ba: nó được tạo ở đâu, được sửa ở đâu, và được tham chiếu ở đâu? Chương 6 đi sâu vào những câu hỏi này (Được tạo, được sửa, được tham chiếu, và nhanh đến đâu?).
Nó thay đổi nhanh đến đâu? Mỗi năm một lần, hằng ngày, hàng chục đến hàng trăm lần mỗi giây?
Nó lớn đến đâu? Mười bản ghi, mười nghìn, mười triệu, mười tỷ?
Vòng đời của nó là gì? Nó sống mãi, được lưu trữ, phải bị xóa, hay mất giá trị theo thời gian?

Bốn câu hỏi đó cho tôi biết nhiều hơn hẳn “Salesforce có lưu được cái này không?” Và chúng gom lại những gì chúng ta đã học: quyền sở hữu, vòng đời, Số chữ số 0, dữ liệu nằm ở đâu.

Một doanh nghiệp tạo ra mọi loại

Ở Steve Trucking, Đối tác bán lẻ là dữ liệu chủ; bộ từ vựng trạng thái là dữ liệu tham chiếu; mỗi lần giao hàng là dữ liệu giao dịch; định nghĩa các trường của nó là siêu dữ liệu; bảng điểm đúng hẹn năm năm là dữ liệu phân tích; ảnh lắp đặt là dữ liệu phi cấu trúc; và luồng GPS là dữ liệu luồng. Tất cả đều là “dữ liệu Steve Trucking”. Không điều nào trong đó có nghĩa chúng thuộc về cùng một cơ sở dữ liệu. Đó chính là bước chuyển.

Ngoài kỳ thi: AI thay đổi điều gì. Để trả lời một câu hỏi, một tác tử có thể cần một bản ghi khách hàng có cấu trúc, một giao dịch gần đây, một sổ tay PDF, một bản ghi lời thoại dịch vụ và dữ liệu đo xa trực tiếp. Dữ liệu phi cấu trúc và dữ liệu luồng trở thành những phần hạng nhất của kiến trúc ngay cả khi chúng không thuộc về cơ sở dữ liệu CRM, và kiến trúc sư vẫn phải biết ai sở hữu mỗi nguồn, nó cập nhật đến đâu, và tác tử có nên tin nó không.

Kiến trúc sư quyết định gì ở đây

Mỗi tập dữ liệu quan trọng thuộc loại dữ liệu nào, và ai sở hữu nó.
Khối lượng công việc của nó là vận hành, phân tích, luồng, hay kết hợp.
Nó thay đổi nhanh đến đâu, và các hệ thống khác thực sự cần thấy thay đổi nhanh đến đâu.
Khối lượng và vòng đời định hình nơi nó nằm và nằm trong bao lâu như thế nào.
Salesforce nên sở hữu nó, giữ một bản sao, tham chiếu nó, hay để nó ở một nơi phù hợp hơn với khối lượng công việc.

Khi ai đó đưa cho bạn một yêu cầu, đừng nhảy ngay vào đối tượng nào, trường nào, API nào. Trước tiên hãy hỏi đó là loại dữ liệu gì, ai sở hữu nó, nó thay đổi nhanh đến đâu, nó lớn đến đâu, nó sống bao lâu, và chúng ta đang cố làm gì với nó. Một Tài khoản, một sự kiện giao hàng, một số liệu tổng hợp năm năm và một bức ảnh đều có thể quan trọng với cùng một doanh nghiệp mà không phải là cùng một bài toán kiến trúc.

Tìm hiểu thêm

DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, ấn bản thứ 2 (2017, tiếng Anh): tài liệu tham chiếu chuẩn về các loại dữ liệu và quản lý dữ liệu.
Bản mô tả Steve Trucking, mục 4 (khối lượng).