Helpex - Trao đổi & giúp đỡ Đăng nhập

Đường ống dữ liệu của ngày mai

Vào thời điểm con người bắt đầu tạo ra các hệ thống nhập dữ liệu người dùng theo các khoảng thời gian cố định thường xuyên (ví dụ: các ngân hàng tải lên hàng đêm qua ETL), họ cũng bắt đầu thấy tiềm năng của dữ liệu đầu vào để cung cấp vòng phản hồi hiệu quả trên chính hệ thống. Cuối cùng, dữ liệu không chỉ là một thông điệp , mà là một phần quan trọng trong cách thức đường ống dữ liệu - hoặc tổ chức sử dụng nó - sẽ tự xây dựng và hài hòa.

Trong các hệ thống kinh doanh, dữ liệu phân tích cũng được sử dụng để cải thiện quy trình hoặc sản phẩm được đề cập. Ví dụ, dữ liệu ngân hàng được đưa trở lại cho người tiêu dùng dưới dạng báo cáo số dư tài khoản, đồng thời được sử dụng để tối ưu hóa quy trình kinh doanh. Ví dụ, dữ liệu được sử dụng để tự động tính lãi suất và phí ưu đãi cho chủ tài khoản và xác định cho chủ sở hữu sản phẩm nhân khẩu học nào ưa thích sản phẩm tài chính nào.

Nơi mọi thứ hôm nay và nơi họ đang đứng đầu

Ngày nay, dữ liệu (và đường ống dữ liệu ) khá phổ biến: dữ liệu không còn chảy đơn thuần từ việc nhập hàng loạt vào các cửa hàng dữ liệu trung tâm và ra bảng điều khiển của người dùng, mà thường theo cả hai hướng. Các thiết bị tiêu dùng thậm chí có thể có các đường ống dữ liệu riêng được tích hợp sẵn, cung cấp đầu vào và phản hồi cho hệ thống lớn hơn. Tính đa hướng của dữ liệu chảy qua các hệ thống như vậy chỉ là một trong nhiều yếu tố khiến cho lượng dữ liệu trong vùng dữ liệu lớn hơn tăng theo cấp số nhân.

Thật vậy, như IDC chỉ ra, 16,1 zettabyte dữ liệu người dùng được tạo trên toàn thế giới vào năm 2016 dự kiến ​​sẽ tăng gấp 10 lần lên 163 zettabyte vào năm 2025. Khác xa với những ngày của chu kỳ nhập khẩu hàng đêm tại ngân hàng, người dùng trên thế giới này sẽ tương tác với điểm cuối trung bình dựa trên dữ liệu trung bình cứ sau 18 giây.

Để hiểu rõ hơn về tương lai này, chúng ta sẽ xem xét dữ liệu - và đường ống dữ liệu - từ một số quan điểm khác nhau: hướng dữ liệu của tương lai sẽ chảy , những gì các kỹ sư dữ liệu có thể mong đợi với các công nghệ sổ cái phân tán và blockchain , và cách tuân thủ quy định sẽ làm việc trong tương lai với nhật ký sự kiện bất biến, được đặt hàng . Chúng tôi cũng sẽ xem xét các yêu cầu về đường ống như các yêu cầu về khả năng mở rộng, hiệu suấtthiết kế (khả năng) cho các đường ống trong tương lai của chúng tôi.

Từ đơn hướng đến cốt lõi đến điểm cuối

Ngày nay, dữ liệu thường chạy trong thời gian gần, đa phương, khá phổ biến đối với người dùng và thậm chí có thể giúp cứu sống. Xem xét đường ống dữ liệu từ đầu đến cuối (còn được gọi là đường ống dữ liệu từ lõi đến cạnh hoặc C2E ).

Đường ống dữ liệu của ngày maiMột hệ thống điểm cuối cốt lõi

Trước đây, đường ống dữ liệu là thứ mà dữ liệu đi vào một đầu (thường là nhập hàng loạt) và xuất hiện ở đầu kia, dưới dạng phân tích hoặc bảng điều khiển giúp người dùng (một nhóm thường khá hạn chế) hiểu dữ liệu.

Trong mô hình C2E, dữ liệu có thể chạy đa hướng, nghĩa là, từ nhiều điểm nhập trở lại kho lưu trữ dữ liệu trung tâm hoặc cạnh để xử lý, tổng hợp hoặc phân tích, sau đó quay lại thiết bị đầu cuối hoặc bảng điều khiển để xử lý nhiều hơn. Dữ liệu cũng có thể đóng vai trò là hướng dẫn hoặc dữ liệu huấn luyện cho các hệ thống tiếp theo chạy trên AI (nhiều hơn về điều này sau). Không còn một kích cỡ phù hợp cho tất cả các đường ống dữ liệu nữa.

Chúng ta có thể thấy các ví dụ về đường ống C2E ở đâu?

  • IoT
  • Ô tô
  • Dữ liệu thời gian thực di động
  • Trò chơi trực tuyến nhiều người chơi
  • Cơ sở hạ tầng
  • Và hơn thế nữa...

Blockchain và Sổ cái phân tán

Thứ tự là rất quan trọng cho các giao dịch trên blockchain. Bạn có thể mong đợi rằng, nếu các sự kiện được viết theo thứ tự tùy ý, sẽ không thể xây dựng lại trạng thái dữ liệu của bạn tại bất kỳ thời điểm nào hoặc ai đã làm gì với ai và khi nào trong một giao dịch nhất định.

Tuy nhiên, bất cứ khi nào dữ liệu được phân vùng và phân phối trên một mạng, người ta phải xem xét Định lý CAP , nghĩa là, người dùng của một mạng như vậy có thể, ở quy mô, cần phải điều chỉnh sự cân bằng giữa tính nhất quán và tính sẵn có của dữ liệu. Vì lý do này, chúng tôi hy vọng sẽ thấy nhiều người dùng triển khai sổ cái phân tán của họ dưới dạng cơ sở dữ liệu phân tán phù hợp nhất quán .

Pub-Sub, Tuân thủ và Nhật ký sự kiện không thay đổi, được đặt hàng

Hiện tại, kiến ​​trúc pub-sub là thứ di chuyển dữ liệu từ kho dữ liệu hoặc vị trí này sang kho dữ liệu khác.

Làm thế nào nó hoạt động? Các giải pháp như Apache Kafka , Apache PulsarAmazon Kinesis có các nhà sản xuất xuất bản tất cả các mặt hàng của họ theo tuần tự cho một số dạng nhật ký, trong khi người tiêu dùng chọn và chọn (hoặc đăng ký ) loại sự kiện họ sẽ tiêu thụ. Cơ chế pub-sub ngăn chặn sự phức tạp N * N của tích hợp điểm-điểm, đồng thời loại bỏ các quy tắc định tuyến dữ liệu phức tạp khỏi các nhà sản xuất bằng cách đưa onus vào người tiêu dùng dữ liệu để tiêu thụ dựa trên sở thích.

Đường ống dữ liệu của ngày maiCơ chế pub-sub

Với một nhật ký bất biến, nơi tất cả các sự kiện được viết, bạn sẽ tuân thủ các quy tắc như GDPR, quy định, trong số những điều khác, công dân EU có thể rút lại sự đồng ý để lưu trữ dữ liệu cá nhân của họ? Các quy tắc cũng cho rằng dữ liệu của người dùng phải được giữ an toàn, cập nhật và giới hạn ở mức tối thiểu cần thiết.

Tất nhiên, bạn có thể chỉ cần loại bỏ PII (thông tin nhận dạng cá nhân) trước khi thực sự viết nó (điều này cũng giải quyết vấn đề lưu trữ dữ liệu). Yair Weinberger của Alooma, trong một phiên hỏi đáp gần đây tại hội nghị Alooma CONNECT, đã đề xuất ba cách khác để bảo mật nhật ký sự kiện được phân vùng:

  1. Nếu dữ liệu không thể truy cập, nó không tồn tại. Viết các phân vùng khác nhau của một bản ghi đến các vị trí khác nhau. Khi quyền hoàng hôn, loại bỏ quyền truy cập vào các vị trí dữ liệu liên quan.
  2. Tự động ẩn danh thông tin nhận dạng thông qua hàm băm khi nó được tạo hoặc viết.
  3. Mã hóa các phân vùng khác nhau bằng một khóa khác nhau. Khi hết thời gian, thu hồi / hủy khóa .

Đường ống dữ liệu của ngày maiMã hóa nhật ký sự kiện theo phân vùng

Ngoài các phương thức đó, có thể chỉ cần truy vấn nhật ký và thực hiện phân tích từ xa , do đó tránh - hoặc giảm thiểu - yêu cầu lưu trữ dữ liệu cục bộ.

Kỹ sư dữ liệu của tương lai sẽ có thể chọn - và sẽ cần phải quyết định - giữa các phương pháp này.

Khả năng mở rộng, độ tin cậy và hiệu suất

Để phát triển theo quy mô, chủ sở hữu đường ống dữ liệu có thể cần đưa ra một vài quyết định về dữ liệu mà họ lưu trữ khi nghỉ ngơi. Trong tương lai, số lượng dữ liệu được tạo ngay cả trong một hệ thống có thể sẽ vượt quá khả năng lưu trữ tất cả. Do đó, các kỹ sư dữ liệu của tương lai sẽ cần xem xét các câu hỏi sau:

  1. Dữ liệu nào sẽ vẫn không ổn định (chỉ trong bộ nhớ) và tạm thời?
  2. Dữ liệu nào được lưu giữ liên tục và được lưu trữ ở đâu đó?

Đối với dữ liệu được lưu trữ, dung lượng lưu trữ của đường ống sẽ cần tự động ồ ạt, trong khi xử lý các định dạng ngày càng mơ hồ.

Điều này giải thích tại sao bây giờ chúng ta thấy các đường ống dữ liệu với một số loại lưu trữ dữ liệu khác nhau chạy cạnh nhau. Ví dụ, Elaticsearch hoạt động tuyệt vời để lưu trữ dữ liệu dựa trên văn bản không có cấu trúc (hoặc bán cấu trúc) và có thể được chạy cùng với Redis (kho lưu trữ khóa-giá trị) khi cần tra cứu siêu nhanh hoặc cơ sở dữ liệu phân tán có chứa sổ cái.

Độ tin cậy: Cách MTTF →

Độ tin cậy của bất kỳ hệ thống nào thường được đo bằng chỉ số thời gian trung bình đến thất bại  (MTTF) . MTTF có thể có nghĩa là lượng thời gian của một hệ thống trước khi nó bị lỗi hoặc số lượng sự kiện mà nó có thể xử lý trước khi nó gặp sự cố.

Nói một cách đơn giản, MTTF của các đường ống dữ liệu sẽ tiếp cận, nhưng không bao giờ đạt tới, mãi mãi. Với các đường ống và dữ liệu của chúng tăng lên với khối lượng ngày càng tăng và ngày càng nghiêm trọng, những thất bại ảnh hưởng đến tính khả dụng của một hệ thống sẽ chỉ được dung nạp ít hơn theo thời gian. Tất nhiên, khả năng chịu lỗi có thể được giảm nhẹ phần nào trong một số phần của đường ống bằng cách thay đổi sự đánh đổi tính nhất quán / sẵn có, như đã đề cập trước đó.

Hiệu suất trong tương lai

Trên một lưu ý tương tự, chúng tôi dự đoán rằng độ trễ của việc truy cập vào kho lưu trữ dữ liệu - và thời gian cần thiết để chạy truy vấn - sẽ tiếp tục thu hẹp. Điều này có liên quan nhiều đến nhu cầu các cửa hàng dữ liệu phải đồng bộ hóa càng nhiều càng tốt và để người dùng có thể hành động theo kết quả dữ liệu của họ trong thời gian thực. Hiệu suất tính toán và độ trễ sẽ tiếp tục được cải thiện - với thời gian xử lý được thu hẹp - cho dù việc xử lý đang diễn ra ở lõi hay tại một thiết bị đầu cuối.

Thiết kế đường ống của ngày mai

Bạn có biết SQL không? Nhiều người đã quan sát thấy rằng bước tiếp theo liên quan đến việc xóa bỏ rào cản khái niệm giữa dữ liệu đang chuyển động hoặc được lưu trữ và tất cả dữ liệu trong một đường ống sẽ có sẵn từ một giao diện truy vấn duy nhất. Confluent đã nói về tính đối ngẫu của bảng / luồng . Ngày nay, chúng ta đang chứng kiến ​​sự khởi đầu của một xu hướng nơi dữ liệu có thể được truy vấn từ bất kỳ nơi nào trong đường ống - ngay cả khi đang chuyển động - bằng cách sử dụng luân phiên một biến thể giống như SQL như KSQL, SQL trên Amazon Kinesis, Apache Calcite và Apache SQL xung.

Chúng tôi cũng tin rằng các đường ống sẽ giống như Alooma ngày nay, có sẵn như một dịch vụ, với các cấu hình đầy đủ, phổ biến có sẵn ngoài hộp.

Chúng tôi đã xem xét một vài khía cạnh của dữ liệu - và đường ống dữ liệu - của tương lai: tính định hướng , khả năng tương thích với các công nghệ mới nổituân thủ quy định với nhật ký sự kiện được đặt hàng bất biến . Chúng tôi cũng đã xem xét khả năng mở rộng , hiệu suấtthiết kế (khả năng) trong tương lai.

Liên hệ với chúng tôi để tìm hiểu thêm.

6 hữu ích 0 bình luận 7.3k xem chia sẻ

Có thể bạn quan tâm

loading