Dữ Liệu Có Giá Trị
Ngày càng rõ ràng rằng dữ liệu của một công ty chứa tiềm năng giá trị khổng lồ. Đối với nhiều tập đoàn Internet khổng lồ như Google, Facebook và những người khác, giá trị của họ chủ yếu bắt nguồn từ dữ liệu của họ. Nhưng bạn không phải là một tập đoàn Internet khổng lồ để có được giá trị từ dữ liệu của mình. Dữ liệu đang được các công ty công nghiệp sử dụng để dự đoán sự cố máy móc, bởi các tổ chức tài chính để quản trị rủi ro tốt hơn, bởi các nhà bán lẻ trực tuyến để tăng tỷ lệ giữ chân khách hàng, và bởi vô số tổ chức khác để khám phá những hiểu biết mới. Có vẻ như một công thức khá đơn giản: cung cấp dữ liệu cho các công cụ phân tích kinh doanh hoặc hệ thống machine learning (ML) và thu được insights. Trong thực tế, nó không đơn giản như vậy. Chúng ta phải thỏa mãn một điều kiện tiên quyết thiết yếu trước khi có thể giải quyết vấn đề phân tích. Chúng ta thực sự phải có dữ liệu chứa các insights đó.
Đây Có Phải Chỉ Là Giải Pháp Data Warehouse Khác Không?
Bạn có thể đang nghĩ, "đây có phải không phải là vấn đề data warehouse giải quyết?" Không thực sự. Data warehouse được xây dựng để giải quyết một tập hợp các vấn đề kinh doanh được định nghĩa. Quy trình ingest dữ liệu data warehouse sử dụng quy trình extract, transform, load (ETL). Dữ liệu được trích xuất từ hệ thống nguồn, chuyển đổi thành cấu trúc của data warehouse, và sau đó tải vào data warehouse. Lúc này, dữ liệu đã được cấu trúc, lọc, và thao tác khác để loại bỏ dữ liệu không liên quan đến tập hợp vấn đề kinh doanh được định nghĩa. Trong quy trình ETL, chúng ta đã, ngầm hoặc rõ ràng, giữ lại một số giá trị dữ liệu và loại bỏ những giá trị khác, tăng cường dữ liệu, hình thành mối quan hệ giữa các mục dữ liệu, và bỏ qua những cái khác. Điều gì xảy ra nếu một vấn đề kinh doanh mới được khám phá cần thông tin bị loại bỏ? Môi trường kinh doanh luôn thay đổi, và các vấn đề trong tương lai không thể được dự đoán. Dù quy trình ETL đúng đắn như thế nào cho tập hợp vấn đề kinh doanh hiện tại, một lượng lớn giá trị tiềm năng trong tương lai đang bị mất đi bằng cách đưa ra các quyết định này khi điền dữ liệu vào data warehouse.
Data Lakes Xuất Hiện
Để giữ lại càng nhiều giá trị tiềm năng càng tốt, chúng ta không thể loại bỏ dữ liệu gốc. Tại sao chúng ta không chỉ giữ tất cả dữ liệu ở định dạng thô và quyết định cách sử dụng nó sau này? Chúng ta có thể để dữ liệu chảy như những con sông vào một kho lưu trữ trung tâm, hình thành một "hồ" của "dữ liệu". :) Nói cách khác, trích xuất và lưu trữ dữ liệu, sau đó chuyển đổi và tải nó khi cần thiết (thường gọi là Extract, Load, and Transform, ELT – hoán đổi 'T' và 'L' trong ETL).
Lịch sử, chi phí lưu trữ và chi phí trích xuất cấu trúc có ý nghĩa tại một ngày nào đó trong tương lai xa vượt xa giá trị tiềm năng của thông tin nó có thể chứa. Tuy nhiên, chi phí lưu trữ và chi phí tinh lọc cấu trúc hữu ích khỏi hỗn loạn đã giảm, khiến việc này ngày càng kinh tế cho ngày càng nhiều công ty.
Mọi Bộ Sưu Tập Dữ Liệu Thô Đều Là Data Lake, Đúng Không?
Được, đủ đơn giản. Chỉ cần đổ tất cả dữ liệu thô vào một vị trí duy nhất, và chúng ta xong, đúng không? Rời xa nó! Ingest dữ liệu phải được thực hiện đúng cách để bảo vệ khách hàng, công ty, và dữ liệu trong khi làm cho nó có sẵn cho các nhà khoa học dữ liệu và analyst trong tương lai. Để làm điều này, chúng ta phải xem xét nhiều yếu tố quan trọng.
- Làm thế nào các nhà khoa học dữ liệu và analyst trong tương lai sẽ tìm thấy những gì họ đang tìm kiếm? Dữ liệu thô phải được lập chỉ mục.
- Làm thế nào dữ liệu có thể được trích xuất một cách hiệu quả? Dữ liệu phải được lưu trữ trong định dạng file hiệu quả, chẳng hạn như định dạng cột.
- Điều gì về Thông Tin Nhận Diện Cá Nhân (PII), Thông Tin Sức Khỏe Được Bảo Vệ (PHI), Dữ Liệu Chủ Thẻ (CD), và dữ liệu nhạy cảm khác? Cần che giấu dữ liệu.
- Làm thế nào bạn sẽ xử lý quyền riêng tư dữ liệu (ví dụ: GDPR), chủ quyền dữ liệu, và kiểm soát truy cập để bạn không xuất hiện trong tiêu đề tin tức vì vi phạm dữ liệu khác? Quản trị danh tính và truy cập phải được triển khai để áp dụng các quyền và kiểm soát truy cập phù hợp.
Điều gì về trùng lặp hoặc khớp các bản ghi không chia sẻ một số khóa nhận diện? Có phải 123 Main St, Some Town, USA là cùng một vị trí với 123 Main Street, Some Town, USA? Làm sao với Robert Smith và Bob Smith? Như bạn có thể tưởng tượng, đây là các senario đơn giản. Các tình huống phức tạp hơn nhiều tồn tại trong các tập dữ liệu thực tế.
Một khi dữ liệu đã ở trong data lake và có lập chỉ mục và kiểm soát thích hợp, nó cần được chuyển đổi thành định dạng có cấu trúc trước khi có thể sử dụng. Thông thường, điều này có nghĩa là áp dụng just-in-time schema khi nó được đọc. Các định dạng nguồn thô khác nhau được chiếu vào một cấu trúc đã biết để chúng có thể được tiêu thụ bởi ML, warehousing, hoặc hệ thống Business Intelligence (BI). (Tôi thích gọi quy trình này là EtS-TL, Extract transform Store – Transform and Load, vì một số chuyển đổi dữ liệu lossless được thực hiện khi dữ liệu đi vào lake. Nhưng thảo luận về thuật ngữ là chủ đề cho một thời điểm khác.)
Sử Dụng Dữ Liệu
Dữ liệu bây giờ đang ở trong lake nhưng không thể sử dụng ở dạng hiện tại. Các quyết định chuyển đổi dữ liệu đã bị trì hoãn bây giờ phải được quyết định. Khi một schema được quyết định và dữ liệu được trích xuất, sau đó nó phải được làm sạch theo cách cụ thể cho schema đó. Dữ liệu không hợp lệ cho một schema/phân tích có thể hoàn toàn hợp lệ cho schema khác. Ví dụ, xem xét tập dữ liệu quyền sở hữu đất đai chứa tên chủ sở hữu, địa chỉ tài sản, giá trị tài sản, nợ thanh toán trễ, sử dụng đất (ví dụ: nhà ở, tòa nhà văn phòng, hoặc công nghiệp), và số tài khoản thuế tài sản. Xác định xem có tương quan giữa sử dụng đất và nợ thanh toán trễ không yêu cầu tên chủ sở hữu. Cùng lúc đó, tìm kiếm tương quan giữa giá trị tài sản và sử dụng đất không yêu cầu dữ liệu nợ. Nếu một mục dữ liệu bị thiếu từ một hàng trong một slice dữ liệu, nó không làm vô hiệu hóa cùng hàng đó cho slice dữ liệu khác. Data Lakes cho phép bạn giữ cho các tùy chọn phân tích dữ liệu của mình mở, nhưng chúng đi kèm với sự phức tạp và chi phí riêng của chúng.
Khi tất cả các bước này hoàn tất, chúng ta đang ở điểm nơi công cụ phân tích dữ liệu, hệ thống BI, hoặc mô hình ML của chúng ta có thể bắt đầu công việc của họ. Tuy nhiên, bằng cách tận dụng data lake, chúng ta không vô tình phá hủy giá trị tiềm năng trong tương lai tìm thấy trong dữ liệu. Các câu hỏi kinh doanh trong tương lai có thể được khám phá mà không cần chúng ta biết tương lai.
Tóm Tắt
Trong khi Data Warehouse được lọc, chuẩn bị, và sẵn sàng sử dụng, data lakes là các hồ chứa, không nhằm mục đích được tiêu thụ dưới dạng thô. Thay vào đó, dữ liệu trong chúng phải được chuẩn bị trước khi có thể tiêu thụ. Giống như bất kỳ hồ chứa nào, chúng phải được quản lý đúng cách để giữ chúng có sẵn cho tiêu thụ trong tương lai. Điều này được thực hiện thông qua quản lý dòng chảy vào (định dạng file lưu trữ và che giấu dữ liệu), hiểu nội dung (lập chỉ mục và trùng lặp), bảo mật khỏi việc sử dụng sai (Quản trị Danh tính và Truy cập), và cơ sở tinh lọc (trích xuất dữ liệu, áp dụng schema, và làm sạch dữ liệu).
Chỉ Là Đỉnh Của Núi Băng
May mắn thay, trong kỷ nguyên đám mây, chúng ta không cần tự xây dựng công cụ và công nghệ để triển khai data lake. Ví dụ, AWS Lake Formation giải quyết trực tiếp các vấn đề công cụ và công nghệ liên quan đến chính data lake. Tuy nhiên, vẫn còn nhiều câu hỏi khó khăn. Bạn có biết cách sử dụng đúng các công cụ này không? Bạn có chuyên môn để thiết lập kết nối mạng thích hợp để cho phép ingest dữ liệu của bạn không? VPN có đủ không, hay bạn cần mạch chuyên dụng (Direct Connect)? Bạn đang đưa một mỏ vàng dữ liệu công ty lên đám mây. Bạn có chắc chắn rằng bạn đã bảo mật nó đúng cách để ngăn chặn truy cập trái phép không? Bạn có truy cập dữ liệu theo cách hiệu quả về chi phí không? Nhớ rằng, truyền dữ liệu ra không miễn phí.
Tại Rackspace, chúng tôi có các Cloud Architect và chuyên môn để giúp bạn đưa data lake của bạn lên và chạy nhanh chóng, an toàn, và hiệu quả. Hãy gọi cho chúng tôi hoặc truy cập Rackspace Managed AWS để biết thêm thông tin.
Sử dụng tab Phản hồi để đưa ra bất kỳ nhận xét hoặc đặt câu hỏi nào.