Tạo chiến lược dữ liệu


Võ Tuấn Lâm
1 năm trước
Hữu ích 1 Chia sẻ Viết bình luận 0
Đã xem 6721

Chiến lược dữ liệu là gì?

Hãy tưởng tượng tình huống quen thuộc này: với tư cách là một nhà phân tích trong công ty của bạn, bạn đã được giao nhiệm vụ khó khăn là đồng hóa tất cả dữ liệu của tổ chức để thu thập những hiểu biết độc đáo và toàn diện. Nhưng nói thì dễ hơn làm. Phát triển kinh doanh có nhiều dữ liệu của họ được đưa vào một giải pháp CRM độc quyền, tài chính giúp họ giấu chúng trong bảng tính và các nhà phát triển ứng dụng có luồng dữ liệu SDK và IoT để phân tách cơ sở dữ liệu tại chỗ không có khả năng chịu lỗi được tích hợp. , vấn đề tuân thủ và bảo mật thậm chí không bao giờ được xem xét. Dường như không có vần điệu hoặc lý do cho cách mọi thứ hoạt động, không thể có được một cái nhìn thống nhất từ ​​tất cả các dữ liệu doanh nghiệp. Và "khoa học dữ liệu" chủ yếu được thực hiện xung quanh tổ chức bằng cách lấy mẫu dữ liệu từ các nhóm khác nhau và sau đó thực hiện "

Bạn cần phải có một chiến lược cho dữ liệu của bạn. Làm thế nào bạn sẽ làm điều này? Dữ liệu nào bạn sẽ thu thập? Dữ liệu nào bạn sẽ lưu trữ - và ở đâu? Khán giả cho dữ liệu của bạn là ai? Ai tiêu thụ dữ liệu phân tích của bạn? Loại kiểm soát truy cập và quyền nào bạn muốn có trên dữ liệu của mình?

Blog này sẽ hướng dẫn bạn các loại câu hỏi bạn sẽ cần khám phá khi bạn lập kế hoạch chiến lược dữ liệu và bắt đầu suy nghĩ về kiến ​​trúc dữ liệu của mình.

Nhưng, trước hết, những gì một chiến lược dữ liệu?

  • Tầm nhìn và các bước hành động hướng tới khả năng điều khiển dữ liệu của một tổ chức.
  • Một kế hoạch về cách một tổ chức có được, lưu trữ, đồng hóa, kiểm soát, quản trị và sử dụng dữ liệu.
  • Một lộ trình và danh sách tính năng cho đường ống dữ liệu hôm nay - và ngày mai - .
  • Một danh sách kiểm tra để phát triển lộ trình đó.
  • Một tập hợp các phương thức, thủ tục và công cụ cho mọi thứ mà một tổ chức phải làm với dữ liệu.

Tại sao bạn cần một chiến lược dữ liệu?

Nếu không có chiến lược dữ liệu, tổ chức có thể sẽ không thường xuyên và hỗn loạn về việc sử dụng và ứng dụng dữ liệu của họ trong tổ chức, với sự thiếu quyền sở hữu và mục đích  xung quanh các chức năng điều khiển dữ liệu. Ngoài ra, sẽ khó khăn hơn nhiều để hợp nhất dữ liệu từ nhiều nguồn để có được những hiểu biết nhất quán , có thể lặp lạitoàn diện từ dữ liệu đó.

Một chiến lược dữ liệu làm cho những điều nhất định có thể :

  • Dữ liệu có thể được quản lý và triển khai như một tài sản.
  • Tài sản dữ liệu có thể được sử dụng, theo dõi, phân bổ và di chuyển với nỗ lực tối thiểu.
  • Tất cả các quy trình và phương pháp để thao tác dữ liệu đều có thể lặp lại, đáng tin cậy và nhất quán.
  • Tuân thủ quy định và yêu cầu bảo mật cho dữ liệu được giải quyết.
  • Khi có vấn đề phát sinh, có một phương pháp có thể dự đoán để nhận biết và thực hiện các thay đổi bắt buộc trên chính đường ống dữ liệu và tài sản dữ liệu.

Hơn nữa, một chiến lược dữ liệu có thể được điều khiển bởi các nhu cầu sau:

  • Mong muốn cơ sở hạ tầng dữ liệu và chức năng hoạt động và cung cấp giá trị mà không cần sự can thiệp liên tục.
  • Sắp xếp tầm nhìn, trên toàn doanh nghiệp và CNTT, về việc tận dụng dữ liệu như một tài sản.
  • Định nghĩa các số liệu và tiêu chí thành công để quản lý dữ liệu trên toàn tổ chức và cơ sở người dùng.
  • Động lực hướng tới một nỗ lực quản lý dữ liệu có lợi nhuận, hoặc ít nhất là bằng không.
  • Xóa nợ kỹ thuật, cùng với xu hướng tích lũy nợ kỹ thuật.

Nếu hệ thống dữ liệu và quy trình của bạn hoạt động mà không yêu cầu bạn liên tục dập lửa, bạn có thể tập trung vào việc sử dụng tài sản dữ liệu của mình để tăng thêm giá trị cho doanh nghiệp của mình.

Các nguyên tắc cơ bản

Khi bắt đầu phát triển một chiến lược dữ liệu, có một số câu hỏi bạn sẽ muốn hỏi. Chúng ta hãy lần lượt đi qua từng người:

  • Tôi muốn dữ liệu của mình giao tiếp (hoặc làm gì)? Mục đích nào tôi muốn đường ống dữ liệu của tôi (hoặc đường ống) phục vụ, cụ thể? Tôi muốn thu thập những số liệu nào? Tôi muốn tìm mối tương quan nào (giữa các tập dữ liệu khác nhau)? Những hiểu biết nào khác mà tôi muốn rút ra từ dữ liệu của mình? Những hành động nào (tự động hoặc con người) mà tôi muốn thực hiện như một phần của chiến lược này?

  • Ai là các bên liên quan cho dữ liệu của tôi và / hoặc đường ống dữ liệu? Họ có phải là khách hàng không? Đồng nghiệp chuyên nghiệp? Quản lý cấp cao hay cổ đông? Còn ai nữa không

  • Có gì đường ống dữ liệu của tôi đặc biệt? Đây có phải là một đường ống hỗ trợ một chức năng (hoặc nhiều chức năng) trong một doanh nghiệp không? Là đường ống là cốt lõi của một hệ thống hoặc dịch vụ điều khiển dữ liệu? Là đường ống một sản phẩm hoặc dịch vụ trong và của chính nó?

  • Là đường ống dữ liệu một số ít một chiều nguyên khối, hoặc dùng nó làm tổ nhiều, đường ống hai chiều (ví dụ như một core-to-cạnh hệ thống)? Có các thiết bị thông minh (ví dụ: cảm biến hoặc UI phản hồi) cung cấp các phương tiện kết hợp cho đầu vào và đầu ra không?

  • Cơ sở hạ tầng dữ liệu của tôi nên phục vụ mục đích nào khác ? Ví dụ, đường ống của tôi chỉ chuyển tiếp dữ liệu hay là đầu ra từ một hệ thống đầu vào sang hệ thống khác, giống như một bộ dữ liệu cho đào tạo học máy?

Thu thập dữ liệu

Mục tiêu cho hầu hết mọi cơ sở hạ tầng dữ liệu là kéo dữ liệu từ nhiều hệ thống khác nhau vào một kho lưu trữ dữ liệu chính tắc, toàn diện duy nhất để có những hiểu biết và phân tích độc đáo. Dưới đây là một số câu hỏi bạn có thể hỏi về việc thu thập dữ liệu.

Là dữ liệu của tôi được nhập vào trong thời gian thực, gần thời gian thực, theo đợt hoặc một số phương pháp lai? Một số hệ thống yêu cầu dữ liệu phải được cập nhật ngay lập tức, trong khi những hệ thống khác có thể chịu đựng - hoặc thậm chí yêu cầu - một số chậm trễ.

Bạn sẽ thu thập dữ liệu từ đâu và như thế nào? Có nhiều nguồn dữ liệu tiềm năng để xem xét, bao gồm:

  • SDK phần mềm (các sự kiện được kích hoạt khi mã cụ thể được thực thi).
  • Nhật ký web (như nhấp qua tỷ lệ, xuất phát địa chỉ IP, dấu thời gian, v.v.).
  • Các cảm biến (như các cảm biến cho IoT, tiêu thụ năng lượng, hệ thống sản xuất hoặc cơ sở hạ tầng).
  • Các thiết bị thông minh như TV, mét hoặc hệ thống bảo mật.
  • RDBMS giao dịch.
  • Lưu trữ dữ liệu NoQuery.
  • Kho dữ liệu.
  • Các nền tảng tích hợp như Google Ads và Google Analytics.
  • Các hệ thống doanh nghiệp như hệ thống dành cho ERP, CRM (ví dụ Salesforce, Splunk hoặc Marketo).

Vận chuyển và tải dữ liệu

Vận chuyển dữ liệu không chỉ liên quan đến việc nhập dữ liệu (danh mục này trùng lặp phần nào với việc thu thập dữ liệu), mà còn di chuyển dữ liệu từ nơi này sang nơi khác (hoặc không). Nếu đường ống dữ liệu của bạn không phải là nguyên khối một chiều, bạn có thể cần xem xét một số phương thức vận chuyển và tải khi bạn phát triển chiến lược của mình.

Làm thế nào bạn sẽ tải dữ liệu?

  • SDK.
  • Kết nối.
  • Các trình thu thập nhật ký nguồn mở hoặc 'độc quyền' (như Fluentd hoặc Fluentbit).
  • Bộ tải số lượng lớn (như Embulk).
  • Hàng đợi tin nhắn thời gian thực (như RabbitMQ hoặc ZeroMQ).
  • Một kiến ​​trúc pub-sub (như Apache Pulsar hoặc Apache Kafka).

Lưu trữ và phân tích dữ liệu

Cho rằng, trong tương lai, khối lượng dữ liệu sẽ phát triển nhanh hơn nhiều so với dung lượng lưu trữ, bạn cũng có thể cần phải quyết định dữ liệu để lưu trữ và dữ liệu sẽ vẫn phù du.

Tuy nhiên, khi dữ liệu đòi hỏi sự kiên trì, bạn sẽ lưu trữ dữ liệu của mình ở đâu? Điều đó phụ thuộc vào định dạng dữ liệu nguồn của bạn, tốc độ ghi và tra cứu cho phép và mục đích của dữ liệu, để đặt tên cho một vài tiêu chí. Một số lựa chọn và cân nhắc:

  • Một kho dữ liệu đám mây. Có nhiều khả năng để lựa chọn. Bạn có thể xem lại các tiêu chí ở đây .
  • Một hệ thống RDBMS cho dữ liệu giao dịch, cứng nhắc.
  • Apache Hadoop (sử dụng MapReduce hoặc Apache Spark). Hữu ích cho các bộ dữ liệu cực lớn chạy trên phần cứng hàng hóa. Hadoop phải đọc từ - và ghi vào đĩa, trong khi Apache Spark có thể hoạt động nhanh hơn nhiều trong bộ nhớ, với một phương ngữ giống như SQL để đơn giản hóa các truy vấn.
  • Một cơ sở dữ liệu phân tán, nhất quán, cuối cùng, để viết các sự kiện liên quan đến sổ cái phân tán, trong đó có thể điều chỉnh sự cân bằng giữa tính sẵn có và tính nhất quán.
  • Lưu trữ cột, cho các giao dịch giống như axit trong khi cho phép một số lược đồ linh hoạt.
  • Các cơ sở dữ liệu chuỗi thời gian như InfluxDB, được tối ưu hóa cho dữ liệu được đánh dấu thời gian như dữ liệu có khối lượng và tốc độ cao từ các hệ thống IoT.
  • Một kho lưu trữ khóa-giá trị, để tra cứu dữ liệu nhanh bằng khóa.
  • Một cơ sở dữ liệu tài liệu, như MongoDB, để tra cứu nhanh trên dữ liệu đồ sộ, lỏng lẻo.
  • Một hệ thống tìm kiếm văn bản như Lucene hoặc Elaticsearch, để lưu trữ và truy vấn dữ liệu dựa trên văn bản, không có cấu trúc.
  • Amazon S3 để lưu trữ và truy cập dữ liệu được ghi vào các tệp phẳng, CSV hoặc JSON. S3 cũng cho phép bạn truy cập vào các khả năng ML và AI của Amazon.
  • Kiến trúc lambda kết hợp nhiều hơn một phương thức lưu trữ cho các yêu cầu dữ liệu khác nhau (ví dụ: cơ sở dữ liệu điều khiển tài liệu để tra cứu nhanh dữ liệu gần đây và cụm Hadoop để tìm kiếm dữ liệu lịch sử chậm hơn.)

Hợp nhất dữ liệu từ nhiều nguồn

Để có được những hiểu biết thực sự, bạn sẽ cần khám phá mối tương quan giữa các bộ dữ liệu khác nhau và điều này liên quan đến việc chuyển đổi dữ liệu và kết hợp nó với một cửa hàng chính tắc. Nơi bạn lưu trữ dữ liệu kết hợp này phụ thuộc rất nhiều vào yêu cầu của chính dữ liệu đó, như chúng tôi đã kiểm tra ở trên. Alooma được xây dựng xung quanh ý tưởng kéo dữ liệu từ các nguồn dữ liệu khác nhau vào một kho lưu trữ dữ liệu chính tắc.

Bảo mật dữ liệu

Bảo mật dữ liệu và tuân thủ đáng xem xét quan trọng, đặc biệt khi có thông tin nhận dạng cá nhân (PII) liên quan. Ví dụ, các kiến ​​trúc sử dụng cơ chế pub-sub phải đối phó với thách thức viết tất cả các sự kiện vào nhật ký sự kiện được đặt hàng, không thay đổi, trong khi giữ PII an toàn, cập nhật, xóa theo yêu cầu của người dùng và bị hạn chế đối với tối thiểu cần thiết. Bạn có loại bỏ tất cả PII trước khi viết không? Phân vùng nhật ký sự kiện và bảo mật các phân vùng khác nhau? Hoặc hoàn toàn không di chuyển dữ liệu chứa PII vào hệ thống của bạn (và chạy truy vấn từ xa)? Để được an toàn và tuân thủ các nguyên tắc như GDPR, bạn có thể cần phải chọn trong số các lựa chọn thay thế này.

Xuất dữ liệu

Bây giờ bạn đã ăn, xử lý và lưu trữ dữ liệu của mình, tiếp theo là gì? Là dữ liệu tinh chế của bạn dành cho:

  • Phân tích sâu hơn?
  • Theo dõi xu hướng lịch sử?
  • Hình dung?
  • Chuyển đổi sang các lệnh tự động cho một hệ thống tiếp theo?
  • Máy học đào tạo?
  • Phát hiện bất thường, phân tích hàng xóm gần nhất k, hoặc kiểm tra tương tự?

Tùy thuộc vào mục đích của nó, dữ liệu của bạn có thể yêu cầu thêm các sàng lọc, điều chỉnh hoặc thay đổi lược đồ đích.

Sử dụng khám phá dữ liệu để hiểu tập dữ liệu

Khám phá dữ liệu có nghĩa là thử nghiệm các truy vấn khác nhau, thao tác SQL và thậm chí trực quan hóa bảng điều khiển để xác minh các kết quả và kết quả truy vấn khác nhau. Theo hầu hết các tài khoản, việc khám phá dữ liệu bằng các công cụ như D3.js / Vega, R hoặc Python yêu cầu dữ liệu nằm trong một mảng hai chiều trở lên (hoặc khung dữ liệu).

Có các yêu cầu tương tự đối với dữ liệu được sử dụng trong các công cụ BI như Tableau, Qlikview, Looker, Pentaho hoặc thậm chí Excel.

Tất cả các điểm đến dữ liệu phổ biến đều hỗ trợ các mảng này, làm cho các kỹ thuật khám phá dữ liệu và các công cụ BI trở thành một phần hàng ngày của hộp công cụ khoa học dữ liệu.

Hữu ích 1 Chia sẻ Viết bình luận 0
Đã xem 6721