Chiến lược xây dựng dữ liệu cho doanh nghiệp nhỏ bắt đầu từ đâu ? Ưu và nhược điểm của các công cụ thủ công là gì ?
Bài viết này sẽ từng bước giải đáp và nâng tầm dữ liệu cho doanh nghiệp nhỏ, được chia sẻ bởi anh Nam Nguyễn - Lead Solution Engineer tại Salesforce.
Nội dung bài viết
Đừng phụ thuộc vào Excel
Excel có lẽ là thứ mà ai cũng nghĩ đến đầu tiên khi cần tập hợp dữ liệu: khả năng lưu trữ lên đến 1 triệu dòng, xử lý dữ liệu vô cùng linh hoạt với hàng ngàn hàm và công thức, thiết kế biểu đồ đa dạng cùng với sự vi diệu của Macro và trên hết là chi phí chỉ bằng con muỗi khi so với giải pháp khác.
Nhưng dữ liệu doanh nghiệp cần nhiều hơn như thế. Nó đòi hỏi sự tương tác của nhiều phòng ban đội nhóm, với sự phân quyền về chức năng (tạo, xóa, sửa) - và truy xuất dữ liệu (ai được thấy, thao tác dữ liệu nào). Vì thế, dù xuất sắc trong việc quản lý dữ liệu cá nhân, nhưng Excel đành ngậm ngùi rút khỏi cuộc chơi.
Chia tay Excel sớm để không luyến tiếc và mất thời gian nhấp nhổm “nên hay không Excel”, chúng ta thẳng tiến tới việc xây dựng một chiến lược thực sự.
Hai nhóm khách hàng của doanh nghiệp
Bất kỳ doanh nghiệp nào cũng có thể chia khách hàng thành 2 nhóm: chưa phải khách hàng và đã trở thành khách hàng.
Nhóm “chưa phải khách hàng” thường nằm trên CRM và rải trên 3 phân hệ: Marketing, Sales và Service. Nhóm “đã trở thành khách hàng” quan trọng hơn nên nếu đầu tư phần mềm sẽ được đầu tư trước: Core banking của ngân hàng, Core Insurance của công ty Bảo hiểm, bệnh án điện tử của bệnh viện, eCommerce của công ty thương mại điện tử, POS, hệ thống bảo hành, khách hàng thân thiết...
Thông thường, theo quy trình bán, mỗi nhóm khách hàng lại được chia thành nhiều giai đoạn nhỏ hơn, và mỗi giai đoạn đó lại dùng một ứng dụng khác nhau. Vì vậy, nhu cầu kết nối dữ liệu giữa là hoàn toàn thuận theo tự nhiên, đem lại rất nhiều giá trị, và cũng là lý do có loạt bài này.
Về mặt kỹ thuật, có thể chia thành 2 xu hướng kết nối: bền vững và linh hoạt.
1. Xu hướng bền vững
Có mục tiêu xây dựng “kho trung tâm” - Golden record of Data, hay System of Record, là nơi kết nối toàn bộ dữ liệu của tất cả các nguồn vào một nơi tập trung, dọn dẹp và làm đẹp đến mức dữ liệu trở thành mẫu mực và sẵn sàng phục vụ cho các mục đích khác. Các công nghệ liên quan có thể kể đến:
- Datalake hay Data pool: dữ liệu được tập trung nhưng chưa được xử lý
- Data warehouse: dữ liệu được tập trung và sơ chế một phần
- MDM - Master Data management chính là dạng thức đỉnh cao, dữ liệu đạt đến tiệm cận của sự hoàn hảo
Quá trình xây dựng dữ liệu thông thường gồm các bước: tập hợp, lọc trùng, chuẩn hoá, thống nhất và sử dụng. Tuy tên khác nhau nhưng tất cả các bước đều có điểm chung là phức tạp.
- Tập hợp: quá trình này có 3 bước cơ bản là ETL. Extract - xuất từ hệ thống cũ, Transform - chuyển đổi định dạng và Load- Nhập vào hệ thống mới. Do tính chất “Bền vững”, nên yếu tố thời gian thực thường không đặt nặng. Dữ liệu được đổ vào kho trung tâm theo tần suất xác định, phổ biến là hàng ngày - vào đêm khuya hoặc lúc hệ thống không bận rộn.
- Lọc trùng: quá trình này tưởng dễ mà khó muốn chết. Có 2 giai đoạn: lọc trùng dữ liệu trước khi đưa vào hệ thống, và lọc trùng dữ liệu mới với dữ liệu đã có trong hệ thống. Cái khó nằm ở chỗ định nghĩa như thế nào là “trùng” nó quá phức tạp. Một dữ liệu có nhiều trường thông tin: Trùng hết tất cả các trường chắc chắn là trùng nhưng trùng một phần cũng là trùng
Ví dụ: (1) Nam Nguyễn- Thành phố HCM và (2) Nam Nguyễn - TP HCM và (3) Nguyễn Nam - Thành phố HCM, cái nào là trùng cái nào?
Ở cấp cơ bản, hệ thống chỉ có thể định nghĩa trùng theo tiêu chí xác định: trùng tên và số điện thoại là trùng - tức là trùng 100%. Theo cơ chế này, cả 3 dữ liệu trên đều không trùng.
Nhưng ở cấp độ cao cấp, hệ thống có thể cho phép mã hoá thông tin các trường thành các dãy số và dùng một ngưỡng mờ (fuzzy), ví dụ là 80% để so trùng. Theo cơ chế này, cả 3 dữ liệu trên đều trùng.
Ở cấp độ vũ trụ, hệ thống quan sát cách xử lý của người dùng rồi đưa ra cách xử lý linh hoạt cho từng trường hợp.
Tất nhiên là phương án nào cũng có sai số, nhưng với tập dữ liệu quá lớn thì phải đánh đổi và chấp nhận một tỉ lệ sai sót nhất định. Tỉ lệ này thường được gọi là các ngưỡng rủi ro- risk thresholds.
Các hệ thống hịn, cho phép linh hoạt cài đặt tỉ lệ này cho cả phần kiểm tra trùng lẫn xử lý gộp. Ví dụ: nếu tỉ lệ trùng trên 80% thì cho phép hệ thống tự lọc trùng và gộp, nếu dưới 80% thì sẽ gởi Mail cho Admin để xử lý bằng cơm.
Sau khi được làm sạch, dữ liệu được đưa về các vùng dữ liệu (datamart), hoặc phân loại, hoặc nằm im chẳng cần phân chia gì...và chờ hệ thống khác tới query.
Tới đây, chúng ta đã điểm qua vài nét chính của xu hướng “Bền vững”, hãy tiến thêm bước nữa tới xu hướng “Linh hoạt”, một xu hướng ngày càng trở nên phổ biến và có nhiều ưu điểm vượt trội.
2. Xu hướng “Linh hoạt”
Chính là cơ sở của việc triển khai Micro-service, có 3 trụ cột chính: Mapping, Phân quyền và Trao đổi thông tin.
- Mapping: Thay vì tập hợp hết dữ liệu lại một chỗ như “Bền vững”, xu hướng “Linh hoạt” không đòi hỏi điều đó. Dữ liệu cứ lưu chỗ nó đang ở, chỉ cần khai báo địa chỉ. Sẽ có một cơ chế mapping dữ liệu với địa chỉ tương ứng để truy xuất khi cần thiết.
Nghĩa là, thông tin Khách hàng được quy định tên, email và địa chỉ nhà nằm ở ứng dụng eCommerce, số điện thoại thì lấy từ ứng dụng Giao hàng, tài khoản Facebook thì từ ứng dụng chăm sóc khách hàng. Khi bất kỳ hệ thống nào cần truy xuất thông tin khách hàng, hệ thống sẽ tự động truy xuất tới các ứng dụng tương ứng để tổng hợp.
- Phân quyền: đối với một doanh nghiệp có nhiều ứng dụng, việc quy định tài khoản nào được truy cập dữ liệu/ứng dụng/hệ thống nào với quyền gì (ghi/xoá/đọc/thay đổi) rất phức tạp và thường xuyên thay đổi. Một giải pháp nhạc trưởng điều phối tài nguyên và truy cập sẽ đảm đương việc này. Giải pháp thường được dùng chính là Kubernetes, một ứng dụng mã nguồn mở dùng để quản lý ứng dụng và service.
- Trao đổi thông tin: Sau khi đã hoàn chỉnh việc phân quyền và mapping, các ứng dụng sẽ bắt đầu truy xuất dữ liệu và cần một cơ chế điều phối để đảm bảo hiệu năng khi lượng dữ liệu lớn và thông tin đáp ứng trên thời gian thực hoặc gần thực. Giải pháp thường được dùng chính là Kafka, nền tảng event streaming mã nguồn mở của Apache.
Bộ đôi Kubernetes và Kafka là một trong những lựa chọn hàng đầu của việc xây dựng hạ tầng kiến trúc của xu hướng linh hoạt trong thời gian gần đây.
