Bỏ qua để đến nội dung
SteveTechArcSteveTechArc Courses

Tư duy như một kiến trúc sư dữ liệu

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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp.
Hình ảnh được tạo bằng AI

Hướng dẫn ôn tập cho chương 1 của khóa học Data Architect. Hãy đọc bảy mô-đun trước; trang này giúp bạn kiểm tra những gì đã đọng lại.

Về hướng dẫn ôn tập này. Nó chỉ được xây dựng từ nội dung của chính khóa học này và danh sách mục tiêu trong hướng dẫn thi đã công bố của Salesforce. Nó không bao giờ dựa trên câu hỏi thi thật, và không tự nhận biết trong đề thi có gì. Nếu bạn đã thi, xin đừng gửi cho tôi câu hỏi trong đề: thỏa thuận chứng chỉ cấm chia sẻ chúng, và dù sao học thuộc đáp án cũng là cách sai để trở thành kiến trúc sư.

Chương này ít kiến thức thi hơn, và đó là cố ý. Nó nói về cách một kiến trúc sư suy nghĩ, và không mục tiêu thi nào chỉ thuộc riêng về nó. Nhưng kỳ thi được xây từ các tình huống: một doanh nghiệp, vài con số, một ràng buộc, và vài đáp án đều có thể đúng. Những thói quen trong chương này là cách bạn đọc các tình huống đó. Vì vậy danh sách kiểm tra dưới đây nói mỗi điểm hỗ trợ mục tiêu nào, thay vì khẳng định nó được kiểm tra trực tiếp.

Cho kỳ thi

Phần tiêu đề “Cho kỳ thi ”

Hãy đánh dấu khi bạn đi qua. Mỗi điểm đều liên kết đến nơi nó được giảng dạy.

Đọc một tình huống như một kiến trúc sư (hỗ trợ mọi mục tiêu)

Mô hình dữ liệu (hỗ trợ DM-1)

Thay đổi những gì đã có (hỗ trợ DM-1 và SDM-2)

  • Tôi biết vì sao đổi kiểu của một trường, hay đặt một trường hiện có thành Bắt buộc, có thể làm hỏng mọi thứ về sau, và vì sao nền tảng chặn việc đổi kiểu khi mã hoặc flow đang tham chiếu đến trường. (Hãy cẩn thận khi thay đổi bộ xương)
  • Tôi biết mẫu bổ sung thay vì biến đổi, ngừng dùng có báo trước thay vì gây bất ngờ, và Field Usage có thể đánh dấu một trường là ứng viên ngừng dùng. (Hãy cẩn thận khi thay đổi bộ xương)
  • Tôi biết những dữ kiện về quan hệ chính-chi tiết đằng sau Phép thử khả năng đảo ngược: quyền truy cập và quyền sở hữu của bản ghi chi tiết đi theo bản ghi chính, xóa bản ghi chính sẽ xóa các bản ghi chi tiết, trường tổng hợp cuộn lên cần quan hệ chính-chi tiết, và một quan hệ tra cứu chỉ chuyển được thành chính-chi tiết khi mọi bản ghi đều có giá trị. (Phép thử khả năng đảo ngược, Tìm hiểu thêm)

Giấy phép và chia sẻ (hỗ trợ SDM-1)

  • Tôi biết người dùng cộng đồng khối lượng lớn (trong đó có Customer Community) không có vai trò và không dùng mô hình chia sẻ, nên quyền truy cập đến từ bộ chia sẻ và nhóm chia sẻ, và Apex sharing không với tới họ được. (Một ví dụ minh họa: Apex Sharing)

Thất bại (hỗ trợ MIG-1 và các chương về tích hợp)

Ngoài kỳ thi

Phần tiêu đề “Ngoài kỳ thi ”

Kỳ thi là sàn, không phải trần. Đây là những thói quen từ chương này mà một kiến trúc sư cần, dù có câu hỏi nào hỏi về chúng hay không.

  • Phải có ai đó cầm bản thiết kế. Kiến trúc là đưa ra quyết định tốt với thông tin chưa đầy đủ, và biết hệ quả của chúng.
  • Mô hình dữ liệu là bộ xương. Mọi thứ khác được xây trên nó.
  • Phép thử khả năng đảo ngược: đảo ngược điều này khó đến mức nào, và bao nhiêu thứ sẽ phụ thuộc vào nó?
  • Kiến trúc tạo ra lực hấp dẫn. Sự phụ thuộc làm cho thay đổi tốn kém, chứ không phải bản thân sự thay đổi.
  • Hãy nghĩ về phạm vi ảnh hưởng, bên trong Salesforce và trên toàn doanh nghiệp. Kiến trúc là giao thông hai chiều.
  • Hãy ghi lại lý do: bối cảnh, phương án, quyết định, hệ quả, người chịu trách nhiệm, mốc xem xét lại. Thay thế bằng quyết định mới; đừng xóa.
  • Tốt nhất về mặt nào? Một quyết định chưa tối ưu có thể là một phần của một kiến trúc tối ưu, nếu bạn biết mình đang đưa ra nó.
  • Hãy mang theo một hình ảnh về tối ưu, để biết mình đang rời xa nó theo hướng nào, và tại sao.
  • Think Correct. Think Fast. Tốc độ đến từ những suy nghĩ đã có trước khoảnh khắc đó.
  • Xây cho hôm nay. Lên kế hoạch cho ngày mai. Lên kế hoạch cho thất bại. Và dùng mức tăng trưởng 30 phần trăm khi không ai cho bạn một con số.
  • Hãy học chín câu hỏi, không chỉ các câu trả lời.
  • AI là tên lửa đẩy. Sinh ra không phải là phán đoán, không thể đảo ngược vẫn là không thể đảo ngược, và xem xét của con người không phải là nghi thức. Tin nhưng phải kiểm chứng.

Thuật ngữ cần biết

Phần tiêu đề “Thuật ngữ cần biết ”
Thuật ngữTrong một dòng
Quyết định kiến trúcQuyết định khó đảo ngược, với nhiều thứ phụ thuộc vào nó
Phép thử khả năng đảo ngượcĐảo ngược điều này khó đến mức nào, và bao nhiêu thứ sẽ phụ thuộc vào nó?
Lực hấp dẫnNhững sự phụ thuộc tích tụ quanh một quyết định theo thời gian
Phạm vi ảnh hưởngMọi thứ khác dịch chuyển theo khi một quyết định thay đổi
Hồ sơ quyết địnhBối cảnh, phương án, quyết định, hệ quả, người chịu trách nhiệm và mốc xem xét lại, giữ ngắn gọn
Đánh đổiĐiều một phương án mang lại, và điều nó từ bỏ để có được điều đó
Yêu cầu ngầm địnhĐiều doanh nghiệp mong đợi mà không cần nói ra, như khả năng phục hồi khi một lần tải dữ liệu thất bại
Steve’s Number of Zeros (Số chữ số 0 của Steve)Thêm một chữ số 0 vào khối lượng có thể thay đổi toàn bộ kiến trúc
Đối soátSo sánh điều lẽ ra phải xảy ra với điều đã xảy ra, từng bản ghi một
Ngừng dùng (deprecate)Đánh dấu một thứ đang trên đường bị loại bỏ, rồi cho nó nghỉ hưu có chủ đích, thay vì thay đổi nó tại chỗ
Người dùng khối lượng lớnMột người dùng cộng đồng (trong các giấy phép có Customer Community) không có vai trò, nằm ngoài mô hình chia sẻ
Lược đồ phình toCác đối tượng và trường chất đống vì tạo ra quá rẻ, cho đến khi không ai thiết kế mô hình nữa

Tự kiểm tra

Phần tiêu đề “Tự kiểm tra ”

Những tình huống ngắn theo phong cách của khóa học. Hãy quyết định câu trả lời trước khi mở ra.

1. Một đội bán hàng yêu cầu trường Approver 2 và Approver 3, mỗi trường kèm một ngày, trên Cơ hội. Bạn hỏi gì, và có thể xây gì?

Hãy hỏi tại sao, và có thể có bao nhiêu lần phê duyệt. Nếu có thể nhiều hơn hai hay ba, yêu cầu là theo dõi mọi lần phê duyệt, không phải thêm trường: một đối tượng con, mỗi lần phê duyệt một bản ghi. Đọc lại Đừng chỉ nhận yêu cầu.

2. Một người muốn đổi nhãn của một trường, và một người khác muốn đổi định dạng của mã định danh khách hàng mà năm hệ thống đã lưu. Việc nào đáng để bạn quan tâm hơn, và tại sao?

Mã định danh. Đổi nhãn thì rẻ. Mã định danh không qua được Phép thử khả năng đảo ngược: khó đảo ngược, và rất nhiều thứ đã phụ thuộc vào nó. Hãy dành sự chú ý tương xứng với cái giá của việc sai. Đọc lại Có những quyết định thay đổi rất rẻ.

3. Một trường văn bản đã được dùng nhiều năm. Giờ phía nghiệp vụ muốn nó chứa một con số. Cách tiếp cận của bạn là gì?

Đừng biến đổi nó tại chỗ. Hãy tìm những gì phụ thuộc vào nó (Flow, Apex, báo cáo, tích hợp, tác tử) và điều gì xảy ra với dữ liệu cũ. Thường thì: thêm một trường mới, di chuyển dữ liệu có chủ đích, và ngừng dùng trường cũ. Đọc lại Hãy cẩn thận khi thay đổi bộ xương.

4. 1.200 địa điểm, mỗi địa điểm 100 lịch hẹn một ngày, khoảng 305 ngày một năm, hai bản ghi cho mỗi lịch hẹn, lưu giữ năm năm, tăng trưởng 30 phần trăm. Đại khái bao nhiêu bản ghi, và vì sao điều đó quan trọng?

Khoảng 73 triệu bản ghi trong năm đầu tiên (36,6 triệu lịch hẹn, mỗi lịch hẹn hai bản ghi), và hơn 650 triệu trong năm năm cùng mức tăng trưởng. Cùng tính năng, thêm vài chữ số 0, một kiến trúc rất khác. Đọc lại Hãy biết các con số của bạn.

5. Một lần tải dữ liệu ban đêm báo “hoàn tất” với một triệu bản ghi. Làm sao bạn biết nó đã thành công?

Bạn đối soát. Phía nhận xác nhận từng bản ghi nó đã lưu; phía gửi so sánh những gì đã gửi với những gì được xác nhận. Thiếu xác nhận nghĩa là chưa thành công, bất kể trạng thái tác vụ nói gì, và cho bạn biết bản ghi nào cần thử lại, chuyển cho một người, hoặc phát cảnh báo. Đọc lại Thành công một phần vẫn là thất bại mà bạn cần hiểu.

6. Một cộng đồng 15 triệu người dùng Customer Community cần quyền truy cập bản ghi phức tạp. Ai đó đề xuất Apex sharing. Vấn đề là gì?

Họ là người dùng khối lượng lớn: không có vai trò, nằm ngoài mô hình chia sẻ, nên không có bản ghi chia sẻ nào để Apex ghi. Quyền truy cập đến từ bộ chia sẻ và nhóm chia sẻ. Giấy phép đã quyết định những công cụ chia sẻ nào tồn tại. Đọc lại Một ví dụ minh họa: Apex Sharing.

7. Một công cụ AI sinh ra hai mươi đối tượng cho một ứng dụng mới trong vài phút. Giờ việc của kiến trúc sư là gì?

Quyết định liệu chúng ta có nên chỉ có năm. Hiểu mô hình đủ rõ để bảo vệ nó: tại sao là những đối tượng và quan hệ này, khóa và dữ liệu chủ nằm ở đâu, điều gì xảy ra ở quy mô lớn. Kiểm chứng những dữ kiện mà nó dựa vào. Sinh ra không phải là phán đoán. Đọc lại Triển khai rẻ đi làm giá trị dịch chuyển.

Tìm hiểu thêm

Phần tiêu đề “Tìm hiểu thêm ”