Hỏi đáp về IT
Mã xác nhận Thay đổi một

Công thức đường ống dữ liệu lớn

Duyệt qua: 162
Giới thiệu
Nếu bạn đang bắt đầu với Dữ liệu lớn, bạn thường cảm thấy choáng ngợp trước một số lượng lớn các công cụ, khuôn khổ và tùy chọn để lựa chọn. Trong bài viết này, tôi sẽ cố gắng tóm tắt các thành phần và công thức cơ bản để giúp bạn bắt đầu hành trình Dữ liệu lớn của mình. Mục tiêu của tôi là phân loại các công cụ khác nhau và cố gắng giải thích mục đích của từng công cụ và cách chúng phù hợp với hệ sinh thái.Trước tiên, hãy xem xét một số cân nhắc và để kiểm tra xem bạn có thực sự gặp sự cố về Dữ liệu lớn hay không . Tôi sẽ tập trung vào các giải pháp mã nguồn mở có thể được triển khai tại chỗ . Các nhà cung cấp đám mây cung cấp một số giải pháp cho nhu cầu dữ liệu của bạn và tôi sẽ đề cập một chút đến chúng. Nếu bạn đang chạy trên đám mây, bạn thực sự nên kiểm tra xem các tùy chọn nào có sẵn cho mình và so sánh với các giải pháp nguồn mở xem xét chi phí, khả năng hoạt động, khả năng quản lý, giám sát và thời gian đến kích thước thị trường.
Hình ảnh cho bài đăng
Hệ sinh thái dữ liệu lớnCân nhắc dữ liệu(Nếu bạn có kinh nghiệm với dữ liệu lớn, hãy chuyển sang phần tiếp theo…)Dữ liệu lớn rất phức tạp , đừng nhảy vào nó trừ khi bạn hoàn toàn phải làm. Để có được thông tin chi tiết, hãy bắt đầu từ quy mô nhỏ, có thể sử dụng Elastic Search và Prometheus / Grafana để bắt đầu thu thập thông tin và tạo trang tổng quan để nhận thông tin về doanh nghiệp của bạn. Khi dữ liệu của bạn mở rộng, những công cụ này có thể không đủ tốt hoặc quá đắt để duy trì. Đây là lúc bạn nên bắt đầu xem xét hồ dữ liệu hoặc kho dữ liệu; và chuyển đổi tư duy của bạn để bắt đầu suy nghĩ lớn .Kiểm tra dung lượng dữ liệu của bạn , dung lượng bạn có và bạn cần lưu trữ trong bao lâu. Kiểm tra nhiệt độ ! của dữ liệu, nó mất giá trị theo thời gian, vậy bạn cần lưu trữ dữ liệu trong bao lâu? bạn cần bao nhiêu lớp bảo quản (nóng / ấm / lạnh)? bạn có thể lưu trữ hoặc xóa dữ liệu?Các câu hỏi khác bạn cần tự hỏi là: Loại dữ liệu bạn đang lưu trữ? bạn sử dụng định dạng nào? bạn có bất kỳ nghĩa vụ pháp lý? bạn cần nhập dữ liệu nhanh như thế nào? bạn cần dữ liệu có sẵn để truy vấn nhanh đến mức nào? Bạn đang mong đợi loại truy vấn nào? OLTP hay OLAP? Những hạn chế về cơ sở hạ tầng của bạn là gì? Loại dữ liệu của bạn là gì? Có quan hệ? Đồ thị? Tài liệu? Bạn có một lược đồ để thực thi không?Tôi có thể viết một số bài báo về điều này, điều rất quan trọng là bạn phải hiểu dữ liệu của mình, đặt ranh giới , yêu cầu, nghĩa vụ, v.v. để công thức này hoạt động.
 
Hình ảnh cho bài đăng
4V của Dữ liệu lớnKhối lượng dữ liệu là chìa khóa quan trọng, nếu bạn xử lý hàng tỷ sự kiện mỗi ngày hoặc tập dữ liệu lớn, bạn cần áp dụng các nguyên tắc Dữ liệu lớn cho quy trình của mình. Tuy nhiên, không có một ranh giới nào ngăn cách dữ liệu “ nhỏ ” với dữ liệu “ lớn ” và các khía cạnh khác như tốc độ , tổ chức nhóm của bạn , quy mô công ty , loại phân tích được yêu cầu, cơ sở hạ tầng hoặc mục tiêu kinh doanh sẽ ảnh hưởng hành trình dữ liệu lớn của bạn. Hãy xem lại một số trong số chúng…OLTP so với OLAPCách đây vài năm, các doanh nghiệp từng có các ứng dụng trực tuyến được hỗ trợ bởi cơ sở dữ liệu quan hệ được sử dụng để lưu trữ người dùng và dữ liệu có cấu trúc khác ( OLTP ). Qua đêm, dữ liệu này được lưu trữ bằng cách sử dụng các công việc phức tạp vào một kho dữ liệu được tối ưu hóa cho phân tích dữ liệu và kinh doanh thông minh ( OLAP ). Dữ liệu lịch sử đã được sao chép vào kho dữ liệu và được sử dụng để tạo các báo cáo được sử dụng để đưa ra các quyết định kinh doanh.Data Warehouse so với Data LakeKhi dữ liệu ngày càng lớn, các kho dữ liệu trở nên đắt đỏ và khó quản lý. Ngoài ra, các công ty bắt đầu lưu trữ và xử lý dữ liệu phi cấu trúc như hình ảnh hoặc nhật ký. Với Dữ liệu lớn , các công ty bắt đầu tạo các hồ dữ liệu để tập trung dữ liệu có cấu trúc và dữ liệu phi cấu trúc của họ, tạo ra một kho lưu trữ duy nhất với tất cả dữ liệu.
 
Hình ảnh cho bài đăng
Nói tóm lại, data lake nó chỉ là một tập hợp các nút máy tính lưu trữ dữ liệu trong hệ thống tệp HA và một tập hợp các công cụ để xử lý và nhận thông tin chi tiết từ dữ liệu. Dựa trên Map Reduce, một hệ sinh thái khổng lồ gồm các công cụ như Spark đã được tạo ra để xử lý bất kỳ loại dữ liệu nào bằng cách sử dụng phần cứng hàng hóa, hiệu quả hơn về chi phí . sử dụng cơ sở dữ liệu nhưng dựa trên các định dạng tệp và lược đồ bên ngoài mà chúng ta sẽ thảo luận sau. Hadoop sử dụng hệ thống tệp HDFS để lưu trữ dữ liệu với chi phí hiệu quả.Đối với OLTP , trong những năm gần đây, đã có sự chuyển hướng sang NoSQL , sử dụng các cơ sở dữ liệu như MongoDB hoặc Cassandra , có thể mở rộng quy mô vượt quá các giới hạn của cơ sở dữ liệu SQL. Tuy nhiên, các cơ sở dữ liệu gần đây có thể xử lý một lượng lớn dữ liệu và có thể được sử dụng cho cả OLTP và OLAP, đồng thời thực hiện việc này với chi phí thấp cho cả quá trình xử lý theo luồng và hàng loạt; ngay cả cơ sở dữ liệu giao dịch như YugaByteDBcó thể xử lý lượng dữ liệu khổng lồ. Các tổ chức lớn với nhiều hệ thống, ứng dụng, nguồn và loại dữ liệu sẽ cần một kho dữ liệu và / hoặc hồ dữ liệu để đáp ứng nhu cầu phân tích của họ, nhưng nếu công ty của bạn không có quá nhiều kênh thông tin và / hoặc bạn chạy trên đám mây, một cơ sở dữ liệu khổng lồ duy nhất có thể đủ đơn giản hóa kiến trúc của bạn và giảm đáng kể chi phí .Hadoop hoặc Không HadoopKể từ khi phát hành vào năm 2006, Hadoop đã là tài liệu tham khảo chính trong thế giới Dữ liệu lớn. Dựa trên mô hình lập trình MapReduce , nó cho phép xử lý một lượng lớn dữ liệu bằng một mô hình lập trình đơn giản. Hệ sinh thái phát triển theo cấp số nhân trong những năm qua tạo ra một hệ sinh thái phong phú để giải quyết mọi trường hợp sử dụng.Gần đây, đã có một số lời chỉ trích về Hệ sinh thái Hadoop và rõ ràng là việc sử dụng đã giảm dần trong vài năm qua. Các công cụ OLAP mới có khả năng nhập và truy vấn với độ trễ cực thấp bằng cách sử dụng các định dạng dữ liệu riêng của chúng đã và đang thay thế một số công cụ truy vấn phổ biến nhất trong Hadoop; nhưng tác động lớn nhất là sự gia tăng số lượng các giải pháp Serverless Analytics được phát hành bởi các nhà cung cấp đám mây, nơi bạn có thể thực hiện bất kỳ tác vụ Dữ liệu lớn nào mà không cần quản lý bất kỳ cơ sở hạ tầng nào .
Hình ảnh cho bài đăng
Hệ sinh thái Hadoop được đơn giản hóaVới quy mô của hệ sinh thái Hadoop và cơ sở người dùng khổng lồ, có vẻ như còn lâu mới chết và nhiều giải pháp mới hơn không có lựa chọn nào khác ngoài việc tạo các API tương thích và tích hợp với Hệ sinh thái Hadoop. Mặc dù HDFS là cốt lõi của hệ sinh thái, nhưng giờ đây nó chỉ được sử dụng tại chỗ vì các nhà cung cấp đám mây đã xây dựng các hệ thống lưu trữ sâu rẻ hơn và tốt hơn như S3 hoặc GCS . Các nhà cung cấp đám mây cũng cung cấp các cụm Hadoop được quản lýngoài cái hộp. Vì vậy, có vẻ như Hadoop vẫn còn tồn tại và phát triển nhưng bạn nên nhớ rằng có những lựa chọn thay thế mới hơn trước khi bạn bắt đầu xây dựng hệ sinh thái Hadoop của mình. Trong bài viết này, tôi sẽ cố gắng đề cập đến những công cụ nào là một phần của hệ sinh thái Hadoop, những công cụ nào tương thích với nó và những công cụ nào không thuộc hệ sinh thái Hadoop.Hàng loạt so với Truyền trực tuyếnDựa trên phân tích của bạn về nhiệt độ dữ liệu, bạn cần quyết định xem bạn cần phát trực tuyến theo thời gian thực, xử lý hàng loạt hay trong nhiều trường hợp, cả hai .Trong một thế giới hoàn hảo, bạn sẽ nhận được tất cả thông tin chi tiết của mình từ dữ liệu trực tiếp trong thời gian thực, thực hiện tổng hợp dựa trên cửa sổ. Tuy nhiên, đối với một số trường hợp sử dụng, điều này là không thể và đối với những trường hợp khác, nó không hiệu quả về chi phí; đây là lý do tại sao nhiều công ty sử dụng cả xử lý hàng loạt và luồng . Bạn nên kiểm tra nhu cầu kinh doanh của mình và quyết định phương pháp nào phù hợp với bạn hơn. Ví dụ: nếu bạn chỉ cần tạo một số báo cáo, xử lý hàng loạt là đủ. Lô đơn giản hơn và rẻ hơn .
 
Hình ảnh cho bài đăng
Các công cụ xử lý mới nhất như Apache Flink hoặc Apache Beam , còn được gọi là thế hệ thứ 4 của công cụ dữ liệu lớn , cung cấp một mô hình lập trình thống nhất cho dữ liệu hàng loạt và truyền trực tuyến trong đó hàng loạt chỉ xử lý luồng được thực hiện sau mỗi 24 giờ. Điều này đơn giản hóa mô hình lập trình.Mô hình phổ biến là có dữ liệu truyền trực tuyến cho những thông tin chi tiết quan trọng về thời gian như gian lận thẻ tín dụng và hàng loạt để báo cáo và phân tích. Các công cụ OLAP mới hơn cho phép truy vấn cả hai theo một cách thống nhất.ETL và ELTTùy thuộc vào trường hợp sử dụng của bạn, bạn có thể muốn chuyển đổi dữ liệu khi tải hoặc khi đọc . ELT có nghĩa là bạn có thể thực hiện các truy vấn biến đổi và tổng hợp dữ liệu như một phần của truy vấn, điều này có thể thực hiện bằng cách sử dụng SQL nơi bạn có thể áp dụng các hàm, lọc dữ liệu, đổi tên cột, tạo chế độ xem, v.v. Điều này có thể thực hiện được với công cụ Big Data OLAP cung cấp cách truy vấn thời gian thực và hàng loạt theo kiểu ELT. Tùy chọn khác là chuyển đổi dữ liệu khi tải ( ETL ) nhưng lưu ý rằng thực hiện các phép nối và tổng hợp trong quá trình xử lý đó không phải là một nhiệm vụ tầm thường. Nói chung, các kho dữ liệu sử dụng ETL vì chúng có xu hướng yêu cầu một lược đồ cố định (hình sao hoặc bông tuyết) trong khi các hồ dữ liệu linh hoạt hơn và có thể đọc ELT và lược đồ .Mỗi phương pháp đều có những ưu điểm và nhược điểm riêng. Nói tóm lại, các phép biến đổi và tổng hợp khi đọc chậm hơn nhưng mang lại sự linh hoạt hơn. Nếu truy vấn của bạn chậm, bạn có thể cần tham gia trước hoặc tổng hợp trong giai đoạn xử lý. Công cụ OLAP được thảo luận sau, có thể thực hiện tổng hợp trước trong quá trình nhập.Cơ cấu nhóm và phương pháp luậnCuối cùng, các chính sách, tổ chức, phương pháp luận, cơ sở hạ tầng, cấu trúc nhóm và kỹ năng của công ty bạn đóng vai trò quan trọng trong các quyết định về Dữ liệu lớn của bạn . Ví dụ: bạn có thể gặp sự cố dữ liệu yêu cầu bạn tạo một đường dẫn nhưng bạn không phải xử lý lượng dữ liệu khổng lồ, trong trường hợp này, bạn có thể viết một ứng dụng luồng nơi bạn thực hiện nhập, bổ sung và chuyển đổi trong đường ống đơn dễ dàng hơn; nhưng nếu công ty của bạn đã có hồ dữ liệu, bạn có thể muốn sử dụng nền tảng hiện có, đây là thứ bạn sẽ không xây dựng từ đầu.Một ví dụ khác là ETL vs ELT. Các nhà phát triển có xu hướng xây dựng các hệ thống ETL trong đó dữ liệu sẵn sàng truy vấn ở định dạng đơn giản, vì vậy các nhân viên không chuyên về kỹ thuật có thể xây dựng trang tổng quan và nhận thông tin chi tiết. Tuy nhiên, nếu bạn có một nhóm phân tích dữ liệu mạnh và một nhóm nhà phát triển nhỏ, bạn có thể thích cách tiếp cận ELT nơi các nhà phát triển chỉ tập trung vào việc nhập; và các nhà phân tích dữ liệu viết các truy vấn phức tạp để biến đổi và tổng hợp dữ liệu. Điều này cho thấy tầm quan trọng của việc xem xét cấu trúc nhóm và các kỹ năng trong hành trình dữ liệu lớn của bạn.Nên có một nhóm đa dạng với các kỹ năng và nền tảng khác nhau làm việc cùng nhau vì dữ liệu là một khía cạnh chức năng chéo trong toàn bộ tổ chức. Các hồ dữ liệu cực kỳ tốt trong việc cho phép cộng tác dễ dàng trong khi duy trì quản trị và bảo mật dữ liệu .Thành phầnSau khi xem xét một số khía cạnh của thế giới Dữ liệu lớn, hãy xem các thành phần cơ bản là gì.Dữ liệu (Lưu trữ)Điều đầu tiên bạn cần là một nơi để lưu trữ tất cả dữ liệu của bạn. Thật không may, không có một sản phẩm nào phù hợp với nhu cầu của bạn, đó là lý do tại sao bạn cần lựa chọn bộ lưu trữ phù hợp dựa trên các trường hợp sử dụng của mình.Để nhập dữ liệu thời gian thực , người ta thường sử dụng một nhật ký phụ để lưu trữ các sự kiện thời gian thực, công cụ nổi tiếng nhất là Kafka . Một giải pháp thay thế là Apache Pulsar . Cả hai, cung cấp khả năng phát trực tuyến mà còn lưu trữ cho các sự kiện của bạn. Đây thường là lưu trữ ngắn hạn cho dữ liệu nóng (hãy nhớ về nhiệt độ dữ liệu!) Vì nó không tiết kiệm chi phí. Có những công cụ khác như Apache NiFi được sử dụng để nhập dữ liệu có bộ nhớ riêng. Cuối cùng, từ nhật ký phụ, dữ liệu được chuyển sang một bộ lưu trữ khác có thể là cơ sở dữ liệu hoặc hệ thống tệp.Cơ sở dữ liệu lớnTuy nhiên, Hadoop HDFS là định dạng phổ biến nhất cho các hồ dữ liệu; cơ sở dữ liệu quy mô lớn có thể được sử dụng làm phần cuối cho đường dẫn dữ liệu của bạn thay vì hệ thống tệp; kiểm tra bài viết trước của tôi về Cơ sở dữ liệu quy mô lớn để biết thêm thông tin. Tóm lại, các cơ sở dữ liệu như Cassandra , YugaByteDB hoặc BigTable có thể lưu trữ và xử lý một lượng lớn dữ liệu nhanh hơn nhiều so với một hồ dữ liệu có thể nhưng không rẻ bằng; tuy nhiên, khoảng cách về giá giữa hệ thống tệp dữ liệu và cơ sở dữ liệu ngày càng nhỏ hơn mỗi năm; đây là điều bạn cần xem xét như một phần của quyết định Hadoop / NoHadoop của bạn. Ngày càng có nhiều công ty lựa chọn cơ sở dữ liệu lớn thay vì hồ dữ liệu cho nhu cầu dữ liệu của họ và sử dụng hệ thống tệp lưu trữ sâu chỉ để lưu trữ.Tóm tắt các cơ sở dữ liệu và các tùy chọn lưu trữ bên ngoài hệ sinh thái Hadoop cần xem xét là:Cassandra : Cơ sở dữ liệu NoSQL có thể lưu trữ lượng lớn dữ liệu, cung cấp tính nhất quán cuối cùng và nhiều tùy chọn cấu hình. Tuyệt vời cho OLTP nhưng có thể được sử dụng cho OLAP với các tổng hợp được tính toán trước (không linh hoạt). Một giải pháp thay thế là ScyllaDB nhanh hơn và tốt hơn nhiều cho OLAP (bộ lập lịch nâng cao )YugaByteDB : Cơ sở dữ liệu quan hệ quy mô lớn có thể xử lý các giao dịch toàn cầu. Tùy chọn tốt nhất của bạn cho dữ liệu quan hệ.MongoDB : Cơ sở dữ liệu NoSQL dựa trên tài liệu mạnh mẽ, có thể được sử dụng để nhập (lưu trữ tạm thời) hoặc làm lớp dữ liệu nhanh cho trang tổng quan của bạnInfluxDB cho dữ liệu chuỗi thời gian.Prometheus để giám sát dữ liệu.ElasticSearch : Chỉ mục đảo ngược phân tán có thể lưu trữ lượng lớn dữ liệu. Đôi khi bị nhiều người bỏ qua hoặc chỉ được sử dụng để lưu trữ nhật ký, ElasticSearch có thể được sử dụng cho nhiều trường hợp sử dụng bao gồm phân tích OLAP, học máy, lưu trữ nhật ký, lưu trữ dữ liệu phi cấu trúc và hơn thế nữa. Chắc chắn là một công cụ cần có trong hệ sinh thái Dữ liệu lớn của bạn.Hãy nhớ sự khác biệt giữa SQL và NoSQL , trong thế giới NoSQL, bạn không lập mô hình dữ liệu, bạn lập mô hình các truy vấn của mình.So sánh DBCơ sở dữ liệu HadoopHBase là cơ sở dữ liệu phổ biến nhất bên trong hệ sinh thái Hadoop . Nó có thể chứa một lượng lớn dữ liệu ở định dạng cột. Nó dựa trên BigTable .Hệ thống tệp (Lưu trữ sâu)Đối với các hồ dữ liệu , trong hệ sinh thái Hadoop, hệ thống tệp HDFS được sử dụng. Tuy nhiên, hầu hết các nhà cung cấp dịch vụ đám mây đã thay thế nó bằng hệ thống lưu trữ sâu của riêng họ như S3 hoặc GCS .Các hệ thống tệp hoặc hệ thống lưu trữ sâu này rẻ hơn cơ sở dữ liệu nhưng chỉ cung cấp bộ nhớ cơ bản và không cung cấp đảm bảo ACID mạnh mẽ .Bạn sẽ cần phải chọn bộ nhớ phù hợp cho trường hợp sử dụng của mình dựa trên nhu cầu và ngân sách của bạn. Ví dụ: bạn có thể sử dụng cơ sở dữ liệu để nhập nếu ngân sách cho phép và sau đó khi dữ liệu được chuyển đổi, hãy lưu trữ nó trong hồ dữ liệu của bạn để phân tích OLAP. Hoặc bạn có thể lưu trữ mọi thứ trong bộ nhớ sâu nhưng một tập nhỏ dữ liệu nóng trong hệ thống lưu trữ nhanh như cơ sở dữ liệu quan hệ.Định dạng tệpMột quyết định quan trọng khác nếu bạn sử dụng HDFS là định dạng bạn sẽ sử dụng để lưu trữ tệp của mình. Lưu ý rằng hệ thống lưu trữ sâu lưu trữ dữ liệu dưới dạng tệp và các định dạng tệp khác nhau và các thuật toán nén mang lại lợi ích cho các trường hợp sử dụng nhất định.Cách bạn lưu trữ dữ liệu trong hồ dữ liệu của mình là rất quan trọng và bạn cần xem xét định dạng, nén và đặc biệt bạn thế nào vách ngăn dữ liệu của bạn.Các định dạng phổ biến nhất là CSV, JSON, AVRO , Bộ đệm giao thức , Parquet và ORC .
Hình ảnh cho bài đăng
So sánh giữa các định dạng tệpMột số điều cần cân nhắc khi chọn định dạng là:Cấu trúc dữ liệu của bạn : Một số định dạng chấp nhận dữ liệu lồng nhau như JSON, Avro hoặc Parquet và những định dạng khác thì không. Thậm chí, những cái làm được, có thể không được tối ưu hóa cao cho nó. Avro là định dạng hiệu quả nhất cho dữ liệu lồng nhau, tôi khuyên bạn không nên sử dụng kiểu lồng nhau của Parquet vì chúng rất kém hiệu quả. Quy trình JSON lồng nhau cũng rất tốn CPU. Nói chung, bạn nên làm phẳng dữ liệu khi nhập nó.Hiệu suất : Một số định dạng như Avro và Parquet hoạt động tốt hơn các định dạng JSON khác. Ngay cả giữa Avro và Parquet cho các trường hợp sử dụng khác nhau, một loại sẽ tốt hơn các loại khác. Ví dụ: vì Parquet là một định dạng dựa trên cột, nên thật tuyệt khi truy vấn hồ dữ liệu của bạn bằng SQL trong khi Avro tốt hơn cho việc chuyển đổi cấp độ hàng ETL.Dễ đọc : Cân nhắc xem bạn có cần mọi người đọc dữ liệu hay không. JSON hoặc CSV là các định dạng văn bản và con người có thể đọc được trong khi các định dạng hiệu quả hơn như parquet hoặc Avro là nhị phân.Nén : Một số định dạng cung cấp tốc độ nén cao hơn những định dạng khác.Sự phát triển của lược đồ : Việc thêm hoặc xóa các trường trong hồ dữ liệu phức tạp hơn nhiều so với trong cơ sở dữ liệu. Một số định dạng như Avro hoặc Parquet cung cấp một số mức độ phát triển của lược đồ cho phép bạn thay đổi lược đồ dữ liệu và vẫn truy vấn dữ liệu. Các công cụ định dạng Delta Lake như vậy cung cấp các công cụ tốt hơn để đối phó với những thay đổi trong các Lược đồ.Khả năng tương thích : JSON hoặc CSV được chấp nhận rộng rãi và tương thích với hầu hết mọi công cụ trong khi các tùy chọn hiệu suất hơn có ít điểm tích hợp hơn.Như chúng ta có thể thấy, CSV và JSON là các định dạng dễ sử dụng, con người có thể đọc được và phổ biến nhưng thiếu nhiều khả năng của các định dạng khác, khiến nó quá chậm để được sử dụng để truy vấn hồ dữ liệu. ORC và Parquet được sử dụng rộng rãi trong hệ sinh thái Hadoop để truy vấn dữ liệu trong khi Avro cũng được sử dụng bên ngoài Hadoop, đặc biệt là cùng với Kafka để nhập, nó rất tốt cho việc xử lý ETL cấp hàng . Các định dạng hướng hàng có khả năng phát triển lược đồ tốt hơn các định dạng hướng cột, làm cho chúng trở thành một lựa chọn tuyệt vời để nhập dữ liệu.Cuối cùng, bạn cũng cần xem xét cách nén dữ liệu trong tệp của mình khi cân nhắc sự cân bằng giữa kích thước tệp và chi phí CPU. Một số thuật toán nén nhanh hơn nhưng với kích thước tệp lớn hơn và những thuật toán khác chậm hơn nhưng với tốc độ nén tốt hơn. Để biết thêm chi tiết hãy kiểm tra bài viết này .
 
Hình ảnh cho bài đăng
Các tùy chọn nénTôi khuyên bạn nên sử dụng snappy để truyền dữ liệu trực tuyến vì nó không yêu cầu quá nhiều sức mạnh của CPU. Đối với lô bzip2 là một lựa chọn tuyệt vời.Một lần nữa, bạn cần xem xét các cân nhắc mà chúng tôi đã đề cập trước đó và quyết định dựa trên tất cả các khía cạnh mà chúng tôi đã xem xét. Hãy xem xét một số trường hợp sử dụng làm ví dụ:Trường hợp sử dụngBạn cần nhập dữ liệu thời gian thực và lưu trữ ở đâu đó để xử lý thêm như một phần của đường dẫn ETL. Nếu hiệu suất là quan trọng và ngân sách không phải là vấn đề, bạn có thể sử dụng Cassandra. Cách tiếp cận tiêu chuẩn là lưu trữ nó trong HDFS bằng cách sử dụng định dạng được tối ưu hóa là AVRO .Bạn cần xử lý dữ liệu và dung lượng lưu trữ của mình ở đâu đó để được sử dụng bởi một ứng dụng tương tác cao với người dùng mà độ trễ là quan trọng (OLTP), bạn biết trước các truy vấn. Trong trường hợp này, hãy sử dụng Cassandra hoặc một cơ sở dữ liệu khác tùy thuộc vào khối lượng dữ liệu của bạn.Bạn cần cung cấp dữ liệu đã xử lý cho cơ sở người dùng của mình, tính nhất quán là rất quan trọng và bạn không biết trước các truy vấn vì giao diện người dùng cung cấp các truy vấn nâng cao. Trong trường hợp này, bạn cần một cơ sở dữ liệu SQL quan hệ, tùy thuộc vào phía bạn, một SQL DB cổ điển MySQL như vậy sẽ đủ hoặc bạn có thể cần sử dụng YugaByteDB hoặc cơ sở dữ liệu quy mô lớn quan hệ khác.Bạn cần lưu trữ dữ liệu đã xử lý của mình để phân tích OLAP cho nhóm nội bộ của mình để họ có thể chạy các truy vấn đặc biệt và tạo báo cáo. Trong trường hợp này, bạn có thể lưu trữ dữ liệu trong hệ thống tệp lưu trữ sâu của mình ở định dạng Parquet hoặc ORC.Bạn cần sử dụng SQL để chạy các truy vấn đặc biệt về dữ liệu lịch sử nhưng bạn cũng cần các bảng điều khiển cần phản hồi trong vòng chưa đầy một giây. Trong trường hợp này, bạn cần một phương pháp kết hợp trong đó bạn lưu trữ một tập hợp con dữ liệu trong một bộ lưu trữ nhanh như cơ sở dữ liệu MySQL và dữ liệu lịch sử ở định dạng Parquet trong hồ dữ liệu. Sau đó, sử dụng công cụ truy vấn để truy vấn trên các nguồn dữ liệu khác nhau bằng SQL.Bạn cần thực hiện các truy vấn thực sự phức tạp cần trả lời chỉ trong vài mili giây, bạn cũng có thể cần thực hiện tổng hợp khi đọc. Trong trường hợp này, hãy sử dụng ElasticSearch để lưu trữ dữ liệu hoặc một số hệ thống OLAP mới hơn như Apache Pinot mà chúng ta sẽ thảo luận sau.Bạn cần tìm kiếm văn bản không có cấu trúc. Trong trường hợp này, hãy sử dụng ElasticSearch.Cơ sở hạ tầngCơ sở hạ tầng hiện tại của bạn có thể giới hạn các tùy chọn của bạn khi quyết định sử dụng công cụ nào. Câu hỏi đầu tiên cần đặt ra là: Cloud vs On-Prem . Các nhà cung cấp đám mây cung cấp nhiều tùy chọn và tính linh hoạt. Hơn nữa, họ cung cấp các giải pháp Serverless cho nhu cầu Dữ liệu lớn của bạn, dễ quản lý và giám sát hơn. Chắc chắn, đám mây là nơi dành cho Dữ liệu lớn; ngay cả đối với hệ sinh thái Hadoop, các nhà cung cấp đám mây cung cấp các cụm được quản lý và lưu trữ rẻ hơn tại chỗ. Kiểm tra các bài viết khác của tôi về các giải pháp đám mây.Nếu bạn đang chạy tại cơ sở, bạn nên nghĩ về những điều sau:Tôi chạy khối lượng công việc của mình ở đâu? Chắc chắn Kubernetes hoặc Apache Mesos cung cấp một khung điều phối thống nhất để chạy các ứng dụng của bạn theo một cách thống nhất. Các khía cạnh triển khai, giám sát và cảnh báo sẽ giống nhau bất kể bạn sử dụng khuôn khổ nào. Ngược lại, nếu bạn chạy trên kim loại trần, bạn cần phải suy nghĩ và quản lý tất cả các khía cạnh xuyên suốt của việc triển khai của bạn. Trong trường hợp này, các cụm và công cụ được quản lý sẽ phù hợp hơn các thư viện và khuôn khổ.Tôi có loại phần cứng nào? Nếu bạn có phần cứng chuyên dụng với SSD nhanh và máy chủ cao cấp, thì bạn có thể triển khai cơ sở dữ liệu khổng lồ như Cassandra và có được hiệu suất tuyệt vời. Nếu bạn chỉ sở hữu phần cứng hàng hóa, hệ sinh thái Hadoop sẽ là một lựa chọn tốt hơn. Lý tưởng nhất là bạn muốn có một số loại máy chủ cho các khối lượng công việc khác nhau; các yêu cầu đối với Cassandra khác xa so với HDFS.Giám sát và Cảnh báoThành phần tiếp theo rất cần thiết cho sự thành công của đường dẫn dữ liệu của bạn. Trong thế giới dữ liệu lớn, bạn cần phản hồi liên tục về quy trình và dữ liệu của mình. Bạn cần thu thập số liệu, thu thập nhật ký, giám sát hệ thống của mình, tạo cảnh báo , trang tổng quan và hơn thế nữa.Sử dụng các công cụ mã nguồn mở như Prometheus và Grafana để theo dõi và cảnh báo. Sử dụng các công nghệ tổng hợp nhật ký để thu thập nhật ký và lưu trữ chúng ở đâu đó như ElasticSearch .
Hình ảnh cho bài đăngHình ảnh cho bài đăng
Giám sát GrafanaTận dụng các khả năng của nhà cung cấp đám mây để giám sát và cảnh báo khi có thể. Tùy thuộc vào nền tảng của bạn, bạn sẽ sử dụng một bộ công cụ khác nhau. Đối với nền tảng Cloud Serverless, bạn sẽ dựa vào các công cụ của nhà cung cấp đám mây và các phương pháp hay nhất. Đối với Kubernetes, bạn sẽ sử dụng các giải pháp màn hình nguồn mở hoặc tích hợp doanh nghiệp. Tôi thực sự giới thiệu trang web này , nơi bạn có thể duyệt và kiểm tra các giải pháp khác nhau và xây dựng giải pháp APM của riêng bạn .Một điều khác cần xem xét trong thế giới Dữ liệu lớn là khả năng kiểm toán và trách nhiệm giải trình. Do các quy định khác nhau, bạn có thể được yêu cầu theo dõi dữ liệu, nắm bắt và ghi lại mọi thay đổi khi dữ liệu chảy qua đường ống. Đây được gọi là nguồn gốc dữ liệu hoặc dòng dõi . Các công cụ như Apache Atlas được sử dụng để kiểm soát, ghi lại và quản lý dữ liệu của bạn. Các công cụ khác như Apache NiFi hỗ trợ truyền dữ liệu ra khỏi hộp. Để biết dấu vết thời gian thực, hãy kiểm tra Open Telemetry hoặc Jaeger . Cũng có rất nhiều dịch vụ đám mây Datadog như vậy .Để sử dụng Hadoop, Ganglia .Bảo vệApache Ranger cung cấp một khung giám sát bảo mật thống nhất cho nền tảng Hadoop của bạn. Cung cấp quản trị bảo mật tập trung để quản lý tất cả các tác vụ liên quan đến bảo mật trong giao diện người dùng trung tâm. Nó cung cấp ủy quyền bằng các phương pháp khác nhau và cũng có thể kiểm tra đầy đủ trên toàn bộ nền tảng Hadoop.Mọi ngườiNhóm của bạn là chìa khóa thành công. Kỹ sư Dữ liệu lớn có thể khó tìm. Đầu tư vào đào tạo, nâng cao kỹ năng, hội thảo. Loại bỏ silo và băng đỏ, thực hiện lặp lại đơn giản và sử dụng Thiết kế theo hướng miền để đặt ranh giới và trách nhiệm cho nhóm của bạn.Đối với Dữ liệu lớn, bạn sẽ có hai danh mục chính :Kỹ sư dữ liệu để nhập, làm giàu và chuyển đổi. Các kỹ sư này có nền tảng hoạt động và phát triển mạnh mẽ và chịu trách nhiệm tạo ra đường ống dữ liệu. Nhà phát triển, Quản trị viên, Chuyên gia DevOps, v.v. sẽ thuộc danh mục này.Nhà khoa học dữ liệu : Đây có thể là các chuyên gia BI, nhà phân tích dữ liệu, v.v. chịu trách nhiệm tạo báo cáo, trang tổng quan và thu thập thông tin chi tiết. Tập trung vào OLAP và với hiểu biết kinh doanh vững chắc, những người này thu thập dữ liệu sẽ được sử dụng để đưa ra các quyết định kinh doanh quan trọng. Mạnh về SQL và trực quan nhưng yếu về phát triển phần mềm. Các chuyên gia về Học máy cũng có thể thuộc loại này.Ngân sáchĐây là một cân nhắc quan trọng, bạn cần tiền để mua tất cả các thành phần khác, và đây là một nguồn lực hạn chế. Nếu bạn có số tiền không giới hạn, bạn có thể triển khai một cơ sở dữ liệu khổng lồ và sử dụng nó cho nhu cầu dữ liệu lớn của mình mà không có nhiều phức tạp nhưng bạn sẽ phải trả phí. Vì vậy, mỗi công nghệ được đề cập trong bài viết này đòi hỏi những người có kỹ năng sử dụng, triển khai và bảo trì nó. Một số công nghệ phức tạp hơn những công nghệ khác, vì vậy bạn cần phải tính đến điều này.Công thứcBây giờ chúng ta đã có nguyên liệu, hãy nấu công thức dữ liệu lớn của chúng ta. Trong một nutshell quá trình này là đơn giản; bạn cần nhập dữ liệu từ các nguồn khác nhau, làm phong phú dữ liệu, lưu trữ ở đâu đó, lưu trữ siêu dữ liệu (lược đồ), làm sạch nó, chuẩn hóa nó, xử lý nó, cách ly dữ liệu xấu, tổng hợp dữ liệu một cách tối ưu và cuối cùng là lưu trữ ở đâu đó để các hệ thống hạ nguồn sử dụng .Hãy xem xét chi tiết hơn một chút cho từng bước…Nuốt phảiBước đầu tiên là lấy dữ liệu, mục tiêu của giai đoạn này là lấy tất cả dữ liệu bạn cần và lưu trữ ở định dạng thô trong một kho lưu trữ duy nhất. Điều này thường thuộc sở hữu của các nhóm khác, những người đẩy dữ liệu của họ vào Kafka hoặc một cửa hàng dữ liệu.Đối với các đường ống đơn giản với lượng dữ liệu không lớn, bạn có thể xây dựng một quy trình làm việc microservices đơn giản có thể nhập, làm phong phú và chuyển đổi dữ liệu trong một đường ống duy nhất (nhập + chuyển đổi), bạn có thể sử dụng các công cụ như Apache Airflow để sắp xếp các phần phụ thuộc. Tuy nhiên, đối với Dữ liệu lớn, bạn nên tách việc nhập ra khỏi quá trình xử lý , các công cụ xử lý lớn có thể chạy song song không tuyệt vời để xử lý các cuộc gọi chặn, thử lại, áp lực ngược, v.v. Vì vậy, tất cả dữ liệu được khuyến nghị nên lưu trước bạn bắt đầu xử lý nó. Bạn nên làm giàu dữ liệu của mình như một phần của quá trình nhập bằng cách gọi các hệ thống khác để đảm bảo tất cả dữ liệu, bao gồm cả dữ liệu tham chiếu đã được đưa vào hồ trước khi xử lý.Có hai phương thức nhập:Kéo : Kéo dữ liệu từ một nơi nào đó như cơ sở dữ liệu, hệ thống tệp, hàng đợi hoặc APIĐẩy : Các ứng dụng cũng có thể đẩy dữ liệu vào hồ của bạn nhưng bạn nên có một nền tảng nhắn tin như Kafka ở giữa. Một mô hình phổ biến là Change Data Capture ( CDC ) cho phép chúng ta di chuyển dữ liệu vào hồ theo thời gian thực từ cơ sở dữ liệu và các hệ thống khác.Như chúng tôi đã đề cập, việc sử dụng Kafka hoặc Pulsar làm trung gian cho việc nhập dữ liệu của bạn là cực kỳ phổ biến để kích hoạt tính bền bỉ, áp lực ngược, song song và giám sát quá trình nhập của bạn. Sau đó, sử dụng Kafka Connect để lưu dữ liệu vào hồ dữ liệu của bạn. Ý tưởng là hệ thống OLTP của bạn sẽ xuất bản các sự kiện lên Kafka và sau đó nhập chúng vào hồ của bạn. Tránh nhập dữ liệu hàng loạt trực tiếp thông qua các API ; bạn có thể gọi điểm cuối HTTP để làm giàu dữ liệu nhưng hãy nhớ rằng việc nhập dữ liệu từ các API không phải là ý kiến ​​hay trong thế giới dữ liệu lớn vì nó chậm, dễ xảy ra lỗi (sự cố mạng, độ trễ…) và có thể làm hỏng hệ thống nguồn. Mặc dù, API rất tuyệt vời để đặt ranh giới miền trong thế giới OLTP, những ranh giới này được đặt bởi kho dữ liệu (hàng loạt) hoặc chủ đề (thời gian thực) trong Kafka trong thế giới Dữ liệu lớn . Tất nhiên, nó luôn phụ thuộc vào kích thước dữ liệu của bạn nhưng hãy cố gắng sử dụng Kafka hoặc Pulsar khi có thể và nếu bạn không có bất kỳ lựa chọn nào khác; lấy một lượng nhỏ dữ liệu theo cách truyền trực tuyến từ các API, không phải theo lô. Đối với cơ sở dữ liệu, hãy sử dụng các công cụ như Debezium để truyền dữ liệu tới Kafka (CDC).Để giảm thiểu sự phụ thuộc, luôn dễ dàng hơn nếu hệ thống nguồn đẩy dữ liệu đến Kafka hơn là nhóm của bạn kéo dữ liệu vì bạn sẽ được kết hợp chặt chẽ với các hệ thống nguồn khác. Nếu điều này không thể thực hiện được và bạn vẫn cần phải sở hữu quy trình nhập, chúng tôi có thể xem xét hai danh mục lớn để nhập:Giải pháp chưa được quản lý : Đây là những ứng dụng mà bạn phát triển để nhập dữ liệu vào hồ dữ liệu của mình; bạn có thể chạy chúng ở bất cứ đâu. Điều này rất phổ biến khi nhập dữ liệu từ các API hoặc hệ thống chặn I / O khác không có giải pháp ngoại vi hoặc khi bạn không sử dụng hệ sinh thái Hadoop. Ý tưởng là sử dụng thư viện trực tuyến để nhập dữ liệu từ các chủ đề, điểm cuối, hàng đợi hoặc hệ thống tệp khác nhau. Vì bạn đang phát triển ứng dụng nên bạn có toàn quyền linh hoạt . Hầu hết các thư viện cung cấp thử lại, áp lực ngược, giám sát, phân phối và nhiều hơn nữa. Đây là một cách tự tiếp cận mã , vì vậy bạn sẽ cần các công cụ khác để điều phối và triển khai. Bạn kiểm soát nhiều hơn và hiệu suất tốt hơn nhưng cần nhiều nỗ lực hơn. Bạn có thể có một khối duy nhất hoặc microservices giao tiếp bằng cách sử dụng một bus dịch vụ hoặc được sắp xếp bằng một công cụ bên ngoài. Một số thư viện có sẵn là Apache Camel hoặc Akka Ecosystem ( Akka HTTP + Akka Streams + Akka Cluster + Akka Persistence + Alpakka ). Bạn có thể triển khai nó dưới dạng nguyên khối hoặc dưới dạng microservices tùy thuộc vào mức độ phức tạp của đường dẫn nhập. Nếu bạn sử dụng Kafka hoặc Pulsar , bạn có thể sử dụng chúng làm công cụ điều phối nhập để lấy dữ liệu và làm phong phú dữ liệu. Mỗi giai đoạn sẽ chuyển dữ liệu sang một chủ đề mới tạo ra một DAG
       
trong chính cơ sở hạ tầngbằng cách sử dụng các chủ đề để quản lý sự phụ thuộc. Nếu bạn không có Kafka và bạn muốn một quy trình làm việc trực quan hơn, bạn có thể sử dụng Apache Airflow để sắp xếp các phần phụ thuộc và chạy DAG. Ý tưởng là có một loạt các dịch vụ ăn sâu và làm phong phú thêm ngày tháng và sau đó, lưu trữ nó ở đâu đó. Sau khi mỗi bước hoàn tất, bước tiếp theo được thực hiện và điều phối bởi Luồng khí. Cuối cùng, dữ liệu được lưu trữ trong một số loại lưu trữ.Giải pháp được quản lý : Trong trường hợp này, bạn có thể sử dụng các công cụ được triển khai trong cụm của bạn và được sử dụng để nhập. Điều này phổ biến trong hệ sinh thái Hadoop nơi bạn có các công cụ như Sqoop để nhập dữ liệu từ cơ sở dữ liệu OLTP của bạn và Flume để nhập dữ liệu truyền trực tuyến. Các công cụ này cung cấp khả năng giám sát, thử lại, tải gia tăng, nén và hơn thế nữa.Apache NiFiNiFi là một trong những công cụ khó phân loại. Nó là một con thú của riêng nó. Nó có thể được sử dụng để nhập, điều phối và thậm chí là các phép biến đổi đơn giản. Vì vậy, về lý thuyết, nó có thể giải quyết các vấn đề dữ liệu lớn đơn giản. Nó là một giải pháp được quản lý . Nó có giao diện trực quan , nơi bạn có thể chỉ cần kéo và thả các thành phần và sử dụng chúng để nhập và làm giàu dữ liệu. Nó có hơn 300 bộ vi xử lý được xây dựng trong đó thực hiện nhiều tác vụ và bạn có thể mở rộng nó bằng cách triển khai của riêng bạn.
 
Hình ảnh cho bài đăng
Quy trình làm việc NiFiNó có kiến ​​trúc riêng, vì vậy nó không sử dụng bất kỳ cơ sở dữ liệu HDFS nào nhưng nó có tích hợp với nhiều công cụ trong Hệ sinh thái Hadoop . Bạn có thể gọi các API, tích hợp với Kafka, FTP, nhiều hệ thống tệp và lưu trữ đám mây. Bạn có thể quản lý luồng dữ liệu thực hiện định tuyến, lọc và ETL cơ bản. Đối với một số trường hợp sử dụng, NiFi có thể là tất cả những gì bạn cần.Tuy nhiên, NiFi không thể mở rộng quy mô vượt quá một điểm nhất định, vì giao tiếp giữa các nút hơn 10 nút trong cụm trở nên kém hiệu quả. Nó có xu hướng mở rộng quy mô theo chiều dọc tốt hơn, nhưng bạn có thể đạt đến giới hạn của nó, đặc biệt là đối với ETL phức tạp. Tuy nhiên, bạn có thể tích hợp nó với các công cụ như Spark để xử lý dữ liệu. NiFi là một công cụ tuyệt vời để nhập và làm phong phú dữ liệu của bạn.
Các công cụ OLAP hiện đại như Druid hoặc Pinot cũng cung cấp tự động nhập dữ liệu hàng loạt và truyền trực tuyến, chúng ta sẽ nói về chúng trong phần khác.Bạn cũng có thể thực hiện một số xác thực ban đầu và làm sạch dữ liệu trong quá trình nhập, miễn là chúng không phải là các phép tính tốn kém hoặc không vượt qua ngữ cảnh bị giới hạn, hãy nhớ rằng trường rỗng có thể không liên quan đến bạn nhưng quan trọng đối với nhóm khác.Bước cuối cùng là quyết định nơi lấy dữ liệu, chúng ta đã nói về điều này. Bạn có thể sử dụng cơ sở dữ liệu hoặc hệ thống lưu trữ sâu. Đối với một data lake, thông thường sẽ lưu trữ nó ở dạng HDFS, định dạng sẽ tùy thuộc vào bước tiếp theo; nếu bạn đang có kế hoạch thực hiện các thao tác cấp hàng, Avro là một lựa chọn tuyệt vời. Avro cũng hỗ trợ sự phát triển lược đồ bằng cách sử dụng sổ đăng ký bên ngoài cho phép bạn thay đổi lược đồ cho dữ liệu đã nhập của mình một cách tương đối dễ dàng.metadataBước tiếp theo sau khi lưu trữ dữ liệu của bạn, là lưu siêu dữ liệu của nó (thông tin về chính dữ liệu). Siêu dữ liệu phổ biến nhất là lược đồ . Bằng cách sử dụng kho lưu trữ siêu dữ liệu bên ngoài, các công cụ khác nhau trong hồ dữ liệu hoặc đường ống dữ liệu của bạn có thể truy vấn nó để suy ra giản đồ dữ liệu.Nếu bạn sử dụng Avro cho dữ liệu thô, thì sổ đăng ký bên ngoài là một lựa chọn tốt. Bằng cách này, bạn có thể dễ dàng loại bỏ một số chất ăn vào trong quá trình chế biến.Khi dữ liệu được nhập, để được các công cụ OLAP truy vấn, việc sử dụng SQL DDL là rất phổ biến . Công cụ dữ liệu / kho dữ liệu được sử dụng nhiều nhất trong hệ sinh thái Hadoop là Apache Hive , cung cấp kho siêu dữ liệu để bạn có thể sử dụng data lake như một kho dữ liệu với một lược đồ xác định. Bạn có thể chạy các truy vấn SQL trên Hive và kết nối nhiều công cụ khác như Spark để chạy các truy vấn SQL bằng Spark SQL . Hive là một công cụ quan trọng bên trong hệ sinh thái Hadoop cung cấp cơ sở dữ liệu meta tập trung cho các truy vấn phân tích của bạn. Các công cụ khác như Apache Tajo được xây dựng trên Hive để cung cấp khả năng lưu trữ dữ liệu trong hồ dữ liệu của bạn.
 
Hình ảnh cho bài đăng
Apache Impala là cơ sở dữ liệu phân tích gốcdành cho Hadoop, cung cấp kho siêu dữ liệu, bạn vẫn có thể kết nối với Hive để lấy siêu dữ liệu bằng Hcatalog .Apache Phoenix cũng có một di căn và có thể hoạt động với Hive. Phoenix tập trung vào OLTP cho phép các truy vấn có thuộc tính ACID đến các giao dịch. Nó linh hoạt và cung cấp khả năng đọc lược đồ từ thế giới NoSQL bằng cách tận dụng HBase làm kho dự trữ của nó. Apache Druid hoặc Pinot cũng cung cấp kho siêu dữ liệu.Chế biếnMục tiêu của giai đoạn này là làm sạch, chuẩn hóa, xử lý và lưu dữ liệu bằng một lược đồ duy nhất. Kết quả cuối cùng là một tập dữ liệu đáng tin cậy với một lược đồ được xác định rõ.Nói chung, bạn sẽ cần thực hiện một số loại xử lý như:Xác thực : Xác thực dữ liệu và cách ly dữ liệu xấu bằng cách lưu trữ nó trong một bộ nhớ riêng. Gửi cảnh báo khi đạt đến một ngưỡng nhất định dựa trên yêu cầu chất lượng dữ liệu của bạn.Wrangling and Cleansing : Làm sạch dữ liệu của bạn và lưu trữ ở định dạng khác để xử lý thêm, ví dụ như thay thế JSON không hiệu quả bằng Avro.Chuẩn hóa và Chuẩn hóa các giá trịĐổi tên trường…Hãy nhớ rằng, mục tiêu là tạo một tập dữ liệu đáng tin cậy mà sau này có thể được sử dụng cho các hệ thống hạ nguồn. Đây là một vai trò quan trọng của một kỹ sư dữ liệu. Điều này có thể được thực hiện theo luồng hoặc theo đợt.Quá trình xử lý đường ống có thể được chia thành ba giai đoạn trong trường hợp xử lý hàng loạt :Giai đoạn xử lý trước : Nếu dữ liệu thô không sạch hoặc không đúng định dạng, bạn cần phải xử lý trước. Giai đoạn này bao gồm một số xác nhận cơ bản, nhưng mục tiêu là chuẩn bị dữ liệu để được xử lý hiệu quả cho giai đoạn tiếp theo. Trong giai đoạn này, bạn nên cố gắng làm phẳng dữ liệu và lưu nó ở định dạng nhị phân như Avro. Điều này sẽ tăng tốc độ xử lý tiếp theo. Ý tưởng là giai đoạn tiếp theo sẽ thực hiện các hoạt động cấp hàng và các truy vấn lồng nhau rất tốn kém, vì vậy việc làm phẳng dữ liệu bây giờ sẽ cải thiện hiệu suất giai đoạn tiếp theo.Giai đoạn tin cậy : Dữ liệu được xác thực, làm sạch, chuẩn hóa và chuyển đổi thành một lược đồ chung được lưu trữ trong Hive . Mục đích là tạo ra một tập dữ liệu chung đáng tin cậy được chủ sở hữu dữ liệu hiểu. Thông thường, một đặc tả dữ liệu được tạo và vai trò của kỹ sư dữ liệu là áp dụng các phép biến đổi để phù hợp với đặc tả. Kết quả cuối cùng là một tập dữ liệu ở định dạng Parquet có thể dễ dàng truy vấn. Điều quan trọng là bạn phải chọn đúng phân vùng và tối ưu hóa dữ liệu để thực hiện các truy vấn nội bộ. Bạn có thể muốn tính toán trước một phần một số tổng hợp ở giai đoạn này để cải thiện hiệu suất truy vấn.Giai đoạn Báo cáo : Bước này là tùy chọn nhưng thường bắt buộc. Thật không may, khi sử dụng một hồ dữ liệu, một lược đồ sẽ không phục vụ tất cả các trường hợp sử dụng ; đây là một điểm khác biệt giữa kho dữ liệu và hồ dữ liệu. Truy vấn HDFS không hiệu quả như cơ sở dữ liệu hoặc kho dữ liệu, vì vậy cần phải tối ưu hóa thêm. Trong giai đoạn này, bạn có thể cần phải chuẩn hóa dữ liệu để lưu trữ bằng các phân vùng khác nhau để các bên liên quan khác nhau có thể truy vấn hiệu quả hơn. Ý tưởng là tạo các chế độ xem khác nhau được tối ưu hóa cho các hệ thống hạ nguồn khác nhau ( data mart). Trong giai đoạn này, bạn cũng có thể tính toán tổng hợp nếu bạn không sử dụng công cụ OLAP (xem phần tiếp theo). Giai đoạn tin cậy không biết bất cứ điều gì về người sẽ truy vấn dữ liệu, giai đoạn này tối ưu hóa dữ liệu cho người tiêu dùng . Nếu một máy khách có tính tương tác cao, bạn có thể muốn giới thiệu một lớp lưu trữ nhanh trong giai đoạn này như một cơ sở dữ liệu quan hệ cho các truy vấn nhanh. Ngoài ra, bạn có thể sử dụng công cụ OLAP mà chúng ta sẽ thảo luận sau.Đối với việc truyền trực tuyến, logic giống nhau nhưng nó sẽ chạy bên trong một DAG xác định theo kiểu truyền trực tuyến. Spark cho phép bạn tham gia luồng với dữ liệu lịch sử nhưng nó có một số hạn chế . Chúng ta sẽ thảo luận sau về công cụ OLAP , công cụ này phù hợp hơn để hợp nhất thời gian thực với dữ liệu lịch sử.Khung xử lýMột số công cụ bạn có thể sử dụng để xử lý là:Apache Spark : Đây là khuôn khổ nổi tiếng nhất để xử lý hàng loạt. Một phần của hệ sinh thái Hadoop, nó là mộtcụm được quản lý cung cấp khả nănggiám sát, song song đáng kinh ngạcvà một giao diện người dùng tuyệt vời. Nó cũng hỗ trợ xử lý luồng ( luồng cấu trúc ). Về cơ bản Spark chạy các công việc MapReduce trong bộ nhớ, tăng gấp 100 lần hiệu suất MapReduce thông thường. Nó tích hợp với Hive để hỗ trợ SQL và có thể được sử dụng để tạo các bảng, dạng xem Hive hoặc để truy vấn dữ liệu. Nó có rất nhiều tích hợp, hỗ trợ nhiều định dạng và có một cộng đồng lớn. Nó được hỗ trợ bởi tất cả các nhà cung cấp đám mây. Nó có thể chạy trên YARNlà một phần của cụm Hadoop mà còn trong Kubernetes và các nền tảng khác. Nó có nhiều thư viện cho các trường hợp sử dụng cụ thể như SQL hoặc máy học.
 
Hình ảnh cho bài đăng
Apache Flink : Công cụ đầu tiên hợp nhất hàng loạt và phát trực tuyến nhưng tập trung nhiều vào phát trực tuyến . Nó có thể được sử dụng như một xương sống cho các microservices như Kafka. Nó có thể chạy trên YARN như một phần của cụm Hadoop nhưng kể từ khi thành lập, nó cũng đã được tối ưu hóa cho các nền tảng khác như Kubernetes hoặc Mesos. Nó cực kỳ nhanh và cung cấp tính năng phát trực tuyến theo thời gian thực, khiến nó trở thành một lựa chọn tốt hơn Spark đểxử lý luồng có độ trễ thấp , đặc biệt là đối với các luồng trạng thái . Nó cũng có các thư viện cho SQL, Machine Learning và nhiều hơn nữa.
Hình ảnh cho bài đăng
Apache Storm : Apache Storm là một hệ thống tính toán thời gian thực phân tán mã nguồn mở miễn phí, tập trung vào phát trực tuyến và nó là một phần giải pháp được quản lý của hệ sinh thái Hadoop. Nó có khả năng mở rộng, chịu được lỗi, đảm bảo dữ liệu của bạn sẽ được xử lý, đồng thời dễ thiết lập và vận hành.Apache Samza : Một công cụ xử lý luồng trạng thái tuyệt vời khác. Samza cho phép bạn xây dựng các ứng dụng trạng thái xử lý dữ liệu trong thời gian thực từ nhiều nguồn bao gồm Apache Kafka. Một phần giải pháp được quản lý của Hệ sinh thái Hadoop chạy trên YARN.
Hình ảnh cho bài đăng
Apache Beam : Apache Beam, bản thân nó không phải là một engine mà là một đặc điểm kỹ thuật của một mô hình lập trình thống nhất tập hợp tất cả các engine khác lại. Nó cung cấp một mô hình lập trình có thể được sử dụng với các ngôn ngữ khác nhau , vì vậy các nhà phát triển không phải học ngôn ngữ mới khi xử lý các đường ống dữ liệu lớn. Sau đó, nó cắm các đầu cuối khác nhau cho bước xử lý có thể chạy trên đám mây hoặc tại chỗ. Beam hỗ trợ tất cả các công cụ được đề cập trước đây và bạn có thể dễ dàng chuyển đổi giữa chúng và chạy chúng trong bất kỳ nền tảng nào: đám mây, YARN, Mesos, Kubernetes. Nếu bạn đang bắt đầu một dự án mới, tôi thực sự khuyên bạn nên bắt đầu với Beam để đảm bảo đường dẫn dữ liệu của bạn là bằng chứng trong tương lai.
Hình ảnh cho bài đăng
Vào cuối giai đoạn xử lý này, bạn đã nấu chín dữ liệu của mình và hiện đã sẵn sàng để tiêu thụ !, nhưng để nấu được, đầu bếp phải phối hợp với nhóm của mình…Dàn nhạcĐiều phối đường ống dữ liệu là một quá trình xuyên suốt quản lý sự phụ thuộc giữa tất cả các nhiệm vụ khác. Nếu bạn sử dụng xử lý luồng, bạn cần sắp xếp các phần phụ thuộc của từng ứng dụng phát trực tuyến, đối với hàng loạt, bạn cần lên lịch và sắp xếp các công việc.Các tác vụ và ứng dụng có thể bị lỗi, vì vậy bạn cần một cách để lên lịch , lên lịch lại, phát lại , theo dõi , thử lại và gỡ lỗi toàn bộ đường ống dữ liệu của mình theo một cách thống nhất.Các khung công tác mới hơn như Dagster hoặc Prefect bổ sung nhiều khả năng hơn và cho phép bạn theo dõi các nội dung dữ liệu thêm ngữ nghĩa vào đường dẫn của bạn.Một số tùy chọn là:Apache Oozie : Oozie đó là một bộ lập lịch cho Hadoop, các công việc được tạo dưới dạng DAG và có thể được kích hoạt theo thời gian hoặc tính khả dụng của dữ liệu. Nó có tích hợp với các công cụ nhập như Sqoop và các khung xử lý như Spark.Apache Airflow : Airflow là một nền tảng cho phép lập lịch, chạy và giám sát quy trình làm việc . Sử dụng DAG để tạo quy trình công việc phức tạp. Mỗi nút trong biểu đồ là một nhiệm vụ và các cạnh xác định sự phụ thuộc giữa các nhiệm vụ. Bộ lập lịch luồng không khí thực thi nhiệm vụ của bạn trên một loạt nhân viên trong khi tuân theo các phần phụ thuộc được chỉ định do bạn mô tả. Nó tạo DAG để bạn tối đa hóa tính song song . Các DAG được viết bằng Python , vì vậy bạn có thể chạy chúng cục bộ, kiểm tra đơn vị và tích hợp chúng với quy trình phát triển của bạn. Nó cũng hỗ trợ SLA và cảnh báo . Luigi là một sự thay thế cho Luigi với chức năng tương tự nhưng Luigi có nhiều chức năng hơn và mở rộng quy mô tốt hơn Luigi.Dagster là một trình điều phối mới hơn cho học máy, phân tích và ETL. Điểm khác biệt chính là bạn có thể theo dõi các đầu vào và đầu ra của dữ liệu, tương tự như Apache NiFi tạo giải pháp luồng dữ liệu. Bạn cũng có thể hiện thực hóa các giá trị khác như một phần nhiệm vụ của mình. Nó cũng có thể chạy một số công việc song song, dễ dàng thêm tham số, dễ kiểm tra, cung cấp phiên bản đơn giản và hơn thế nữa. Nó vẫn còn một chút trưởng thành và do thực tế là nó cần phải theo dõi dữ liệu, nó có thể khó mở rộng, đó là một vấn đề được chia sẻ với NiFi.Prefect tương tự như Dagster, cung cấp thử nghiệm cục bộ, lập phiên bản, quản lý tham số và hơn thế nữa. Điều làm cho Prefect khác biệt so với phần còn lại là nhằm mục đích khắc phục những hạn chế của công cụ thực thi Luồng không khí như bộ lập lịch cải tiến, quy trình làm việc được tham số hóa, quy trình làm việc động, lập phiên bản và cải tiến thử nghiệm. Nó có một hệ thống quản lý quy trình làm việc nguồn mở cốt lõi và cũng có mộtdịch vụ đám mây mà không cần thiết lập gì cả.Apache NiFi : NiFi cũng có thể lên lịch công việc, giám sát, định tuyến dữ liệu, cảnh báo và hơn thế nữa. Nó tập trung vào luồng dữ liệu nhưng bạn cũng có thể xử lý hàng loạt. Nó chạy bên ngoài Hadoop nhưng có thể kích hoạt các công việc Spark và kết nối với HDFS / S3.Tóm lại, nếu yêu cầu của bạn chỉ là dàn xếp các tác vụ độc lập không yêu cầu chia sẻ dữ liệu, hãy sử dụng Airflow hoặc Ozzie. Đối với các ứng dụng luồng dữ liệu yêu cầu truyền dữ liệu và theo dõi, hãy sử dụng NiFi cho người không phải nhà phát triển hoặc Dagster hoặc Prefect cho nhà phát triển.Chất lượng dữ liệuMột khía cạnh quan trọng trong Dữ liệu lớn, thường bị bỏ qua là chất lượng và đảm bảo dữ liệu. Các công ty mất hàng tấn tiền mỗi năm vì các vấn đề chất lượng dữ liệu. Vấn đề là đây vẫn còn là một lĩnh vực chưa trưởng thành trong khoa học dữ liệu, các nhà phát triển đã làm việc trong lĩnh vực này trong nhiều thập kỷ và họ có các khung và phương pháp thử nghiệm tuyệt vời như BDD hoặc TDD , nhưng làm thế nào để bạn kiểm tra đường ống của mình?Có hai vấn đề phổ biến trong lĩnh vực này:Yêu cầu sai : Thông thường, logic chuyển đổi và điều phối có thể trở nên rất phức tạp. Business Analyst có thể viết các yêu cầu bằng ngôn ngữ miền của họ cần được các nhà phát triển thường mắc lỗi giải thích và lập kế hoạch, phát triển, thử nghiệm và triển khai các giải pháp đúng về mặt kỹ thuật nhưng sai yêu cầu. Những lỗi kiểu này rất tốn kém.Xác thực dữ liệu : Kiểm tra đường ống khá khác với mã. Khi phát triển phần mềm, bạn kiểm tra các chức năng, đó là kiểm thử hộp đen, mang tính xác định. Đối với một đầu vào nhất định, bạn luôn nhận được cùng một đầu ra. Đối với nội dung dữ liệu, việc kiểm tra phức tạp hơn: bạn cần xác nhận các loại dữ liệu, giá trị, ràng buộc và hơn thế nữa. Hơn nữa, bạn cần áp dụng tổng hợp để xác minh tập dữ liệu nhằm đảm bảo rằng số hàng hoặc cột là đúng. Ví dụ: rất khó phát hiện xem một ngày nào đó bạn có giảm 10% kích thước dữ liệu của mình hay không hoặc một số giá trị nhất định có được điền chính xác hay không.Các công ty vẫn còn ở giai đoạn sơ khai về chất lượng dữ liệu và kiểm tra , điều này tạo ra một khoản nợ kỹ thuật lớn . Tôi thực sự khuyên bạn nên kiểm tra bài viết này để biết thêm thông tin.Để giảm thiểu những vấn đề này, hãy cố gắng tuân theo các nguyên tắc DDD và đảm bảo rằng các ranh giới được thiết lập và sử dụng một ngôn ngữ chung. Sử dụng các khuôn khổ hỗ trợ truyền dữ liệu như NiFi hoặc Dagster.Một số công cụ tập trung vào chất lượng dữ liệu là:Apache Griffin : Một phần của Hệ sinh thái Hadoop, công cụ này cung cấp một quy trình thống nhất để đo lường chất lượng dữ liệu của bạn từ các khía cạnh khác nhau, giúp bạn xây dựng nội dung dữ liệu đáng tin cậy. Nó cung cấp một DSL mà bạn có thể sử dụng để tạo xác nhận cho dữ liệu của mình và xác minh chúng như một phần của đường dẫn của bạn. Nó được tích hợp với Spark. Bạn có thể thêm các quy tắc và xác nhận cho tập dữ liệu của mình và sau đó chạy xác thực như một công việc Spark. Vấn đề với Griffin là thực tế DSL có thể trở nên khó quản lý (JSON) và rất khó để giải thích bởi những người không phải là kỹ thuật, có nghĩa là nó không giải quyết được vấn đề yêu cầu bị hiểu nhầm.
Hình ảnh cho bài đăng
Quy trình Apache GriffinKỳ vọng lớn: Đây là một công cụ mới hơn được viết bằng Python và tập trung vào chất lượng dữ liệu, kiểm tra đường ống và đảm bảo chất lượng. Nó có thể dễ dàng tích hợp với Airflow hoặc các công cụ điều phối khác và cung cấp xác thực dữ liệu tự động. Điều làm nên sự khác biệt của công cụ này là con người có thể đọc được và có thể được sử dụng bởi nhà phân tích dữ liệu, BA và các nhà phát triển. Nó cung cấp một giao diện người dùng trực quan nhưng cũng tự động hóa hoàn toàn để bạn có thể chạy các xác thực như một phần của quy trình sản xuất của mình và xem kết quả trong một giao diện người dùng đẹp. Những người không am hiểu kỹ thuật có thể viết bằng Notebookcung cấp tài liệu và các yêu cầu chính thức mà nhà phát triển có thể dễ dàng hiểu, dịch sang mã và sử dụng để thử nghiệm. BA hoặc người kiểm tra viết các xác nhận dữ liệu ( Kỳ vọng ) được chuyển thành kiểm tra có thể đọc được của con người trong giao diện người dùng để mọi người có thể nhìn thấy chúng và xác minh chúng. Nó cũng có thể làm hồ sơ dữ liệu để tạo ra một số xác nhận cho bạn. Nó có thể kết nối trực tiếp với cơ sở dữ liệu hoặc hệ thống tệp của bạn tại chỗ hoặc trên đám mây. Nó rất dễ sử dụng và quản lý. Các kỳ vọng có thể được cam kết với kho mã nguồn và sau đó được tích hợp trong đường dẫn của bạn. Great Expectations tạo ra một ngôn ngữ chung và khuôn khổ cho tất cả các bên liên quan đến chất lượng dữ liệu , làm cho nó rất dễ dàng để tự động hóa và kiểm tra đường ống của bạn với nỗ lực tối thiểu.
 
Hình ảnh cho bài đăng
Giao diện người dùng kỳ vọng tuyệt vờiTruy vấn dữ liệu của bạnBây giờ bạn đã có công thức nấu ăn của mình, đã đến lúc nhận được giá trị từ nó. Đến thời điểm này, bạn đã lưu trữ dữ liệu trong hồ dữ liệu của mình bằng cách sử dụng một số lưu trữ sâu HDFS như vậy ở định dạng có thể truy vấn như Parquet hoặc trong cơ sở dữ liệu OLAP .Có một loạt các công cụ được sử dụng để truy vấn dữ liệu, mỗi công cụ đều có ưu và nhược điểm. Hầu hết chúng tập trung vào OLAP nhưng một số ít cũng được tối ưu hóa cho OLTP. Một số sử dụng các định dạng tiêu chuẩn và chỉ tập trung vào việc chạy các truy vấn trong khi những người khác sử dụng định dạng / lưu trữ của riêng họ để đẩy quá trình xử lý đến nguồn nhằm cải thiện hiệu suất. Một số được tối ưu hóa để lưu trữ dữ liệu bằng cách sử dụng giản đồ hình sao hoặc bông tuyết trong khi một số khác linh hoạt hơn. Tóm lại, đây là những cân nhắc khác nhau:Kho dữ liệu và hồ dữ liệuHadoop vs Độc lậpOLAP so với OLTPCông cụ truy vấn so với Công cụ OLAPChúng ta cũng nên xem xét các công cụ xử lý có khả năng truy vấn.Động cơ chế biếnHầu hết các công cụ mà chúng tôi đã mô tả trong phần trước có thể kết nối với máy chủ siêu dữ liệu như Hive và chạy truy vấn, tạo chế độ xem, v.v. Đây là trường hợp sử dụng phổ biến để tạo các lớp báo cáo tinh chỉnh.Spark SQL cung cấp một cách kết hợp liền mạch các truy vấn SQL với các chương trình Spark, vì vậy bạn có thể kết hợpAPI DataFrame với SQL. Nó có tích hợp Hive và kết nối tiêu chuẩn thông qua JDBC hoặc ODBC; để bạn có thể kết nối Tableau , Looker hoặc bất kỳ công cụ BI nào với dữ liệu của mình thông qua Spark.
Hình ảnh cho bài đăng
Apache Flink cũng cung cấp API SQL . Hỗ trợ SQL của Flink dựa trên Apache Calcite triển khai tiêu chuẩn SQL. Nó cũng tích hợp với Hive thông qua HiveCatalog. Ví dụ: người dùng có thể lưu trữ các bảng Kafka hoặc ElasticSearch của họ trong Hive Metastore bằng cách sử dụng HiveCatalogvà sử dụng lại chúng sau này trong các truy vấn SQL.Công cụ truy vấnLoại công cụ này tập trung vào việc truy vấn các nguồn và định dạng dữ liệu khác nhau theo một cách thống nhất . Ý tưởng là truy vấn hồ dữ liệu của bạn bằng cách sử dụng các truy vấn SQL như thể nó là một cơ sở dữ liệu quan hệ, mặc dù nó có một số hạn chế. Một số công cụ này cũng có thể truy vấn cơ sở dữ liệu NoSQL và hơn thế nữa. Các công cụ này cung cấp giao diện JDBC cho các công cụ bên ngoài, chẳng hạn như Tableau hoặc Looker , để kết nối theo cách an toàn với hồ dữ liệu của bạn. Công cụ truy vấn là tùy chọn chậm nhất nhưng cung cấp tính linh hoạt tối đa.Apache Pig : Nó là một trong những ngôn ngữ truy vấn đầu tiên cùng với Hive. Nó có ngôn ngữ riêng khác với SQL. Đặc tính nổi bật của các chương trình Pig là cấu trúc của chúng có thể phù hợp để song song hóa đáng kể, do đó cho phép chúng xử lý các tập dữ liệu rất lớn. Bây giờ nó đang giảm ưu tiên cho các công cụ dựa trên SQL mới hơn.Presto : Được Facebook phát hành dưới dạng mã nguồn mở, đây là một công cụ truy vấn SQL phân tán mã nguồn mởđể chạy các truy vấn phân tích tương tác dựa trên các nguồn dữ liệu thuộc mọi kích thước. Presto cho phép truy vấn dữ liệu nơi nó tồn tại, bao gồm Hive, Cassandra, cơ sở dữ liệu quan hệ và hệ thống tệp. Nó có thể thực hiện các truy vấn trên các tập dữ liệu lớn trong vài giây. Nó độc lập với Hadoop nhưng tích hợp với hầu hết các công cụ của nó, đặc biệt là Hive để chạy các truy vấn SQL.Apache Drill : Cung cấp Công cụ truy vấn SQL không có giản đồ cho Hadoop, NoSQL và thậm chí cả lưu trữ đám mây. Nó độc lập với Hadoop nhưng có nhiều tích hợp với các công cụ hệ sinh thái như Hive. Một truy vấn có thể kết hợp dữ liệu từ nhiều kho dữ liệu thực hiện tối ưu hóa cụ thể cho từng kho dữ liệu. Nó rất tốt trong việc cho phép các nhà phân tích xử lý bất kỳ dữ liệu nào giống như một bảng, ngay cả khi họ đang đọc một tệp ở dưới mui xe. Drill hỗ trợ đầy đủ SQL tiêu chuẩn . Người dùng doanh nghiệp, nhà phân tích và nhà khoa học dữ liệu có thể sử dụng các công cụ phân tích / BI tiêu chuẩn như Tableau , Qlikvà Excel để tương tác với các kho dữ liệu không quan hệ bằng cách tận dụng các trình điều khiển JDBC và ODBC của Drill. Hơn nữa, các nhà phát triển có thể tận dụng API REST đơn giản của Drill trong các ứng dụng tùy chỉnh của họ để tạo ra các hình ảnh trực quan đẹp mắt.
Hình ảnh cho bài đăng
Mô hình khoanCơ sở dữ liệu OLTPMặc dù, Hadoop được tối ưu hóa cho OLAP vẫn có một số tùy chọn nếu bạn muốn thực hiện các truy vấn OLTP cho một ứng dụng tương tác.HBase có các thuộc tính ACID rất hạn chế theo thiết kế, vì nó được xây dựng để mở rộng quy mô và không cung cấp khả năng ACID bên ngoài nhưng nó có thể được sử dụng cho một số tình huống OLTP.Apache Phoenix được xây dựng dựa trên HBase và cung cấp cách thực hiện các truy vấn OTLP trong hệ sinh thái Hadoop. Apache Phoenix được tích hợp đầy đủ với các sản phẩm Hadoop khác như Spark, Hive, Pig, Flume và Map Reduce. Nó cũng có thể lưu trữ siêu dữ liệu và nó hỗ trợ tạo bảng và thay đổi phiên bản gia tăng thông qua các lệnh DDL. Nó khá nhanh , nhanh hơn so với sử dụng Drill hoặc công cụ truy vấn khác.Bạn có thể sử dụng bất kỳ cơ sở dữ liệu quy mô lớn nào bên ngoài hệ sinh thái Hadoop như Cassandra, YugaByteDB, ScyllaDB cho OTLP .Cuối cùng, rất phổ biến có một tập hợp con dữ liệu, thường là mới nhất, trong cơ sở dữ liệu nhanh thuộc bất kỳ loại nào như MongoDB hoặc MySQL. Các công cụ truy vấn được đề cập ở trên có thể kết hợp dữ liệu giữa lưu trữ dữ liệu chậm và nhanh trong một truy vấn duy nhất.Chỉ mục tìm kiếm được phân phốiNhững công cụ này cung cấp một cách để lưu trữ và tìm kiếm dữ liệu văn bản phi cấu trúc và chúng sống bên ngoài hệ sinh thái Hadoop vì chúng cần những cấu trúc đặc biệt để lưu trữ dữ liệu. Ý tưởng là sử dụng một chỉ mục đảo ngược để thực hiện tra cứu nhanh. Bên cạnh tìm kiếm văn bản, công nghệ này có thể được sử dụng cho một loạt các trường hợp sử dụng như lưu trữ nhật ký, sự kiện, v.v. Có hai tùy chọn chính:Solr : nó là một nền tảng tìm kiếm doanh nghiệp mã nguồn mở phổ biến, nhanh chóng, được xây dựng trên Apache Lucene . Solr đáng tin cậy, có thể mở rộng và chịu được lỗi, cung cấp khả năng lập chỉ mục phân tán, sao chép và truy vấn cân bằng tải, tự động chuyển đổi và phục hồi dự phòng, cấu hình tập trung và hơn thế nữa. Nó rất tốt cho tìm kiếm văn bản nhưng các trường hợp sử dụng của nó bị hạn chế so với ElasticSearch .ElasticSearch : Đây cũng là một chỉ mục phân tán rất phổ biến nhưng nó đã phát triển thành hệ sinh thái của riêng mình bao gồm nhiều trường hợp sử dụng như APM , tìm kiếm, lưu trữ văn bản, phân tích, bảng điều khiển, học máy và hơn thế nữa. Nó chắc chắn là một công cụ cần có trong hộp công cụ của bạn cho DevOps hoặc cho đường dẫn dữ liệu của bạn vì nó rất linh hoạt. Nó cũng có thể lưu trữ và tìm kiếm video và hình ảnh.ElasticSearch có thể được sử dụng như một lớp lưu trữ nhanh f hoặc hồ dữ liệu của bạn cho chức năng tìm kiếm nâng cao. Nếu bạn lưu trữ dữ liệu của mình trong một cơ sở dữ liệu lớn có giá trị khóa, như HBase hoặc Cassandra, cung cấp khả năng tìm kiếm rất hạn chế do thiếu các liên kết; bạn có thể đặt ElasticSearch phía trước để thực hiện các truy vấn, trả lại các ID và sau đó thực hiện tra cứu nhanh trên cơ sở dữ liệu của mình.Nó cũng có thể được sử dụng để phân tích ; bạn có thể xuất dữ liệu của mình, lập chỉ mục và sau đó truy vấn nó bằng Kibana , tạo trang tổng quan, báo cáo và hơn thế nữa, bạn có thể thêm biểu đồ, tổng hợp phức tạp và thậm chí chạy các thuật toán máy học trên dữ liệu của mình. Hệ sinh thái đàn hồi rất lớn và đáng khám phá.
Hình ảnh cho bài đăng
Hình ảnh cho bài đăng
Cơ sở dữ liệu OLAPTrong danh mục này, chúng tôi có cơ sở dữ liệu có thể cung cấp kho siêu dữ liệu cho các lược đồ và khả năng truy vấn. So với các công cụ truy vấn, các công cụ này cũng cung cấp khả năng lưu trữ và có thể thực thi các lược đồ nhất định trong trường hợp có kho dữ liệu (lược đồ hình sao). Các công cụ này sử dụng cú pháp SQL và Spark và các khuôn khổ khác có thể tương tác với chúng.Apache Hive : Chúng ta đã thảo luận về Hive như một kho lưu trữ lược đồ trung tâm cho Spark và các công cụ khác để chúng có thể sử dụng SQL , nhưng Hive cũng có thể lưu trữ dữ liệu, vì vậy bạn có thể sử dụng nó như một kho dữ liệu. Nó có thể truy cập HDFS hoặc HBase . Khi truy vấn Hive, nó sử dụng Apache Tez , Apache Spark hoặc MapReduce , trở thành Tez hoặc Spark nhanh hơn nhiều. Nó cũng có một ngôn ngữ thủ tục được gọi là HPL-SQL.Apache Impala : Đây là một cơ sở dữ liệu phân tích gốccho Hadoop, bạn có thể sử dụng để lưu trữ dữ liệu và truy vấn nó một cách hiệu quả. Nó có thể kết nối với Hive để lấy siêu dữ liệu bằng Hcatalog . Impala cung cấp độ trễ thấp và đồng thời cao cho các truy vấn BI / phân tích trên Hadoop (không được phân phối bởi các khuôn khổ hàng loạt như Apache Hive). Impala cũng mở rộng quy mô tuyến tính, ngay cả trong môi trường nhiều đối tượng, tạo ra một giải pháp thay thế tốt hơn cho các truy vấn so với Hive. Impala được tích hợp với bảo mật Hadoop gốc và Kerberos để xác thực, vì vậy bạn có thể truy cập dữ liệu được quản lý một cách an toàn. Nó sử dụng HBase và HDFS để lưu trữ dữ liệu.
Hình ảnh cho bài đăng
Apache Tajo : Đây là một kho dữ liệu kháccho Hadoop. Tajo được thiết kế cho các truy vấn đặc biệt có độ trễ thấp và có thể mở rộng, tổng hợp trực tuyến và ETL trên các tập dữ liệu lớn được lưu trữ trên HDFS và các nguồn dữ liệu khác. Nó có tích hợp với Hive Metastore để truy cập các lược đồ chung. Nó có nhiều tối ưu hóa truy vấn, có thể mở rộng, chịu được lỗi và cung cấp giao diện JDBC.Apache Kylin : Apache Kylin là một Kho dữ liệu phân tích phân tán mới hơn. Kylin cực kỳ nhanh , vì vậy nó có thể được sử dụng để bổ sung cho một số cơ sở dữ liệu khác như Hive cho các trường hợp sử dụng mà hiệu suất là quan trọng như bảng điều khiển hoặc báo cáo tương tác, nó có lẽ là kho dữ liệu OLAP tốt nhất nhưng khó sử dụng hơn, khác vấn đề là do kích thước cao, bạn cần nhiều bộ nhớ hơn. Ý tưởng là nếu các công cụ truy vấn hoặc Hive không đủ nhanh, bạn có thể tạo một " Cube " trong Kylin, một bảng đa chiều được tối ưu hóa cho OLAP với tính toán trướcgiá trị mà bạn có thể truy vấn từ trang tổng quan hoặc báo cáo tương tác của mình. Nó có thể xây dựng các hình khối trực tiếp từ Spark và thậm chí trong thời gian gần thực từ Kafka.
Hình ảnh cho bài đăng
Động cơ OLAPTrong danh mục này, tôi bao gồm các công cụ mới hơn là sự phát triển của cơ sở dữ liệu OLAP trước đây, cung cấp nhiều chức năng hơn để tạo ra một nền tảng phân tích tất cả trong một . Trên thực tế, chúng là sự kết hợp của hai danh mục trước đó thêm việc lập chỉ mục vào cơ sở dữ liệu OLAP của bạn. Chúng sống bên ngoài nền tảng Hadoop nhưng được tích hợp chặt chẽ. Trong trường hợp này, bạn thường sẽ bỏ qua giai đoạn xử lý và nhập trực tiếp bằng các công cụ này.Họ cố gắng giải quyết vấn đề truy vấn dữ liệu lịch sử và thời gian thực một cách thống nhất, vì vậy bạn có thể truy vấn dữ liệu thời gian thực ngay lập tức ngay khi dữ liệu đó có sẵn cùng với dữ liệu lịch sử với độ trễ thấp để bạn có thể xây dựng các ứng dụng và trang tổng quan tương tác. Trong nhiều trường hợp, các công cụ này cho phép truy vấn dữ liệu thô mà hầu như không có biến đổi theo kiểu ELT nhưng với hiệu suất tuyệt vời, tốt hơn cơ sở dữ liệu OLAP thông thường.Điểm chung của chúng là chúng đã cung cấp một cái nhìn thống nhất về dữ liệu, nhập dữ liệu theo thời gian thực và hàng loạt, lập chỉ mục phân tán, định dạng dữ liệu riêng, hỗ trợ SQL, giao diện JDBC, hỗ trợ dữ liệu nóng-lạnh, nhiều tích hợp và kho siêu dữ liệu.Apache Druid : Đây là công cụ OLAP thời gian thực nổi tiếng nhất. Nó tập trung vào dữ liệu chuỗi thời gian nhưng nó có thể được sử dụng cho bất kỳ loại dữ liệu nào. Nó sử dụng định dạng cột riêngcó thể nén dữ liệu nhiều và nó có rất nhiều tính năng tối ưu hóa được tích hợp sẵn như chỉ số đảo ngược , mã hóa văn bản, cuộn dữ liệu tự động và hơn thế nữa. Dữ liệu được nhập trong thời gian thực bằng cách sử dụng Tranquility hoặc Kafka có độ trễ rất thấp, dữ liệu được lưu giữ trong bộ nhớ ở định dạng hàng được tối ưu hóa cho việc ghi nhưng ngay khi nó đến sẽ có sẵn để truy vấn giống như dữ liệu đã nhập trước đó. Một nhiệm vụ nền phụ trách việc di chuyển dữ liệu không đồng bộ sang hệ thống lưu trữ sâu HDFS. Khi dữ liệu được chuyển đến bộ nhớ sâu, nó sẽ được chuyển đổi thành các phần nhỏ hơn được phân vùng theo thời gian được gọi làphân đoạn được tối ưu hóa cao cho các truy vấn có độ trễ thấp. Mỗi phân đoạn có một dấu thời gian, một số thứ nguyên mà bạn có thể sử dụng để lọc và thực hiện tổng hợp; và các chỉ số là các tổng hợp được tính toán trước. Đối với nhập hàng loạt, nó lưu dữ liệu trực tiếp vào Phân đoạn. Nó hỗ trợ đẩy và kéo nhập. Nó có tích hợp với Hive, Spark và thậm chí cả NiFi . Nó có thể sử dụng Hive di căn và nó hỗ trợ các truy vấn Hive SQL sau đó được chuyển đổi thành các truy vấn JSON được Druid sử dụng. Tích hợp Hive hỗ trợ JDBC để bạn có thể kết nối bất kỳ công cụ BI nào. Nó cũng có kho siêu dữ liệu riêng, thường là MySQL. Nó có thể lấy một lượng lớn dữ liệu và mở rộng quy mô rất tốt. Vấn đề chính là nó có rất nhiều thành phần và nókhó quản lý và triển khai.
 
Hình ảnh cho bài đăng
Kiến trúc DruidApache Pinot : Nó là một giải pháp thay thế mới hơn cho Druid mở do LinkedIn cung cấp. So với Druid, nó cung cấp độ trễ thấp hơn nhờchỉ số Startree cung cấp tính toán trước một phần, vì vậy nó có thể được sử dụng cho các ứng dụng đối mặt với người dùng (nó được sử dụng để lấy nguồn cấp dữ liệu LinkedIn). Nó sử dụng một chỉ mục được sắp xếp thay vì chỉ mục đảo ngược, nhanh hơn. Nó có kiến ​​trúc plugin có thể mở rộng và cũng có nhiều tích hợp nhưng không hỗ trợ Hive. Nó cũng thống nhất hàng loạt và thời gian thực, cung cấp khả năng nhập nhanh, lập chỉ mục thông minh và lưu trữ dữ liệu trong các phân đoạn. Nó dễ triển khai hơn và nhanh hơn so với Druid nhưng nó còn hơi non nớt ở thời điểm hiện tại.
Hình ảnh cho bài đăng
Apache PinotClickHouse : Được viết bằng C ++, công cụ này cung cấp hiệu suất đáng kinh ngạc cho các truy vấn OLAP, đặc biệt là tổng hợp. Nó trông giống như một cơ sở dữ liệu quan hệ nên bạn có thể lập mô hình dữ liệu rất dễ dàng. Nó rất dễ thiết lập và có nhiều tích hợp.
Hình ảnh cho bài đăng
ClickHouseKiểm tra bài viết này để so sánh chi tiết 3 động cơ. Một lần nữa, hãy bắt đầu từ việc nhỏ và biết dữ liệu của bạn trước khi đưa ra quyết định, những công cụ mới này rất mạnh mẽ nhưng khó sử dụng . Nếu bạn có thể đợi vài giờ, hãy sử dụng xử lý hàng loạt và cơ sở dữ liệu như Hive hoặc Tajo; sau đó sử dụng Kylin để tăng tốc các truy vấn OLAP của bạn để làm cho chúng tương tác hơn. Nếu điều đó là không đủ và bạn cần dữ liệu thời gian thực và độ trễ thấp hơn nữa, hãy xem xét các công cụ OLAP. Druid phù hợp hơn cho phân tích thời gian thực. Kylin tập trung hơn vào các trường hợp OLAP. Druid tích hợp tốt với Kafka như phát trực tuyến thời gian thực; Kylin lấy dữ liệu từ Hive hoặc Kafka theo lô; mặc dù quá trình nhập theo thời gian thực đã được lên kế hoạch cho tương lai gần.Cuối cùng, Greenplum là một công cụ OLAP khác tập trung nhiều hơn vào AI .
Hình ảnh cho bài đăng
Presto / Drill cung cấp tính linh hoạt hơn, độ trễ lớn Kylin, Druid và Pinot, những thứ tốt nhất của cả hai thế giới.Cuối cùng, để hình dung, bạn có một số công cụ thương mại như Qlik , Looker hoặc Tableau . Đối với Mã nguồn mở, hãy kiểm tra SuperSet , một công cụ tuyệt vời hỗ trợ tất cả các công cụ mà chúng tôi đã đề cập, có một trình chỉnh sửa tuyệt vời và nó thực sự nhanh chóng. Metabase hoặc Falcon là những lựa chọn tuyệt vời khác.Phần kết luậnChúng ta đã nói rất nhiều về dữ liệu : các hình dạng, định dạng khác nhau, cách xử lý, lưu trữ và nhiều hơn thế nữa. Hãy nhớ: Biết dữ liệu của bạn và mô hình kinh doanh của bạn . Sử dụng quy trình lặp đi lặp lại và bắt đầu xây dựng nền tảng dữ liệu lớn của bạn một cách từ từ ; không phải bằng cách giới thiệu các khuôn khổ mới mà bằng cách đặt những câu hỏi phù hợp và tìm kiếm công cụ tốt nhất cho bạn câu trả lời phù hợp.Xem lại các cân nhắc khác nhau đối với dữ liệu của bạn, chọn bộ lưu trữ phù hợp dựa trên mô hình dữ liệu (SQL), truy vấn (NoSQL), cơ sở hạ tầng và ngân sách của bạn. Hãy nhớ tham gia với nhà cung cấp đám mây của bạn và đánh giá các dịch vụ đám mây cho dữ liệu lớn (mua so với xây dựng). Rất phổ biến là bắt đầu với đường ống phân tích Serverless và từ từ chuyển sang các giải pháp nguồn mở khi chi phí tăng lên.Nhập dữ liệu là rất quan trọng và phức tạp do sự phụ thuộc vào các hệ thống nằm ngoài tầm kiểm soát của bạn; cố gắng quản lý những phụ thuộc đó và tạo luồng dữ liệu đáng tin cậy để nhập dữ liệu đúng cách. Nếu có thể, hãy yêu cầu các nhóm khác sở hữu việc nhập dữ liệu. Hãy nhớ thêm số liệu, nhật ký và dấu vết để theo dõi dữ liệu. Bật tính năng phát triển lược đồ và đảm bảo rằng bạn đã thiết lập bảo mật thích hợp trong nền tảng của mình.Sử dụng công cụ phù hợp cho công việc và không mất nhiều hơn bạn có thể nhai. Các công cụ như Cassandra, Druid hoặc ElasticSearch là những công nghệ tuyệt vời nhưng đòi hỏi nhiều kiến ​​thức để sử dụng và quản lý đúng cách. Nếu bạn chỉ cần phân tích hàng loạt OLAP cho các truy vấn và báo cáo đặc biệt, hãy sử dụng Hive hoặc Tajo. Nếu bạn cần hiệu suất tốt hơn, hãy thêm Kylin. Nếu bạn cũng cần kết hợp với các nguồn dữ liệu khác, hãy thêm các công cụ truy vấn như Drill hoặc Presto. Hơn nữa, nếu bạn cần truy vấn thời gian thực và sử dụng hàng loạt ClickHouse, Druid hoặc Pinot.

,

laptrinh 2020/11/3 9:48

Để lại dấu chân

Bước trên một chân

Bình luận

copyright © laptrinh 2010-2020
Processed in 0 seconds, 0 queries