Đây là phần thứ hai của loạt bài viết về hệ thống phân tích ().
Ngày nay không còn nghi ngờ gì nữa rằng việc xử lý dữ liệu cẩn thận và diễn giải kết quả có thể giúp ích cho hầu hết mọi loại hình kinh doanh. Về vấn đề này, các hệ thống phân tích ngày càng chứa nhiều thông số và số lượng trình kích hoạt cũng như sự kiện của người dùng trong các ứng dụng ngày càng tăng.
Vì điều này, các công ty đang cung cấp cho các nhà phân tích của họ ngày càng nhiều thông tin thô để phân tích và đưa ra các quyết định đúng đắn. Không nên đánh giá thấp tầm quan trọng của hệ thống phân tích đối với một công ty và bản thân hệ thống này phải đáng tin cậy và ổn định.
Nhà phân tích khách hàng
Phân tích khách hàng là dịch vụ mà một công ty kết nối với trang web hoặc ứng dụng của mình thông qua SDK chính thức, tích hợp vào cơ sở mã riêng của công ty và chọn trình kích hoạt sự kiện. Có một nhược điểm rõ ràng của phương pháp này: tất cả dữ liệu được thu thập có thể không được xử lý chính xác như bạn mong muốn do những hạn chế của bất kỳ dịch vụ nào bạn chọn. Ví dụ: trên một hệ thống, việc chạy các tác vụ MapReduce sẽ không dễ dàng, trên hệ thống khác, bạn sẽ không thể chạy mô hình của mình. Một nhược điểm khác sẽ là hóa đơn dịch vụ thường xuyên (ấn tượng).
Có rất nhiều giải pháp phân tích khách hàng trên thị trường, nhưng sớm hay muộn các nhà phân tích cũng phải đối mặt với thực tế là không có một dịch vụ phổ quát nào phù hợp cho mọi nhiệm vụ (trong khi giá của tất cả các dịch vụ này luôn tăng lên). Trong tình huống như vậy, các công ty thường quyết định tạo hệ thống phân tích của riêng mình với tất cả các khả năng và cài đặt tùy chỉnh cần thiết.
Nhà phân tích máy chủ
Phân tích phía máy chủ là một dịch vụ có thể được triển khai trong nội bộ công ty trên các máy chủ của chính công ty đó và (thường) bằng nỗ lực của chính công ty đó. Trong mô hình này, tất cả các sự kiện của người dùng đều được lưu trữ trên các máy chủ nội bộ, cho phép các nhà phát triển thử các cơ sở dữ liệu lưu trữ khác nhau và chọn kiến trúc thuận tiện nhất. Và ngay cả khi bạn vẫn muốn sử dụng phân tích khách hàng của bên thứ ba cho một số nhiệm vụ, điều đó vẫn có thể thực hiện được.
Phân tích phía máy chủ có thể được triển khai theo hai cách. Đầu tiên: chọn một số tiện ích nguồn mở, triển khai chúng trên máy của bạn và phát triển logic nghiệp vụ.
Ưu điểm
Nhược điểm
Bạn có thể tùy chỉnh bất cứ điều gì bạn muốn
Điều này thường rất khó khăn và đòi hỏi các nhà phát triển riêng biệt
Thứ hai: sử dụng các dịch vụ SaaS (Amazon, Google, Azure) thay vì tự triển khai. Chúng ta sẽ nói về SaaS chi tiết hơn trong phần thứ ba.
Ưu điểm
Nhược điểm
Nó có thể rẻ hơn với khối lượng trung bình, nhưng với mức tăng trưởng lớn, nó vẫn sẽ trở nên quá đắt
Sẽ không thể kiểm soát được mọi thông số
Việc quản lý được chuyển hoàn toàn sang vai của nhà cung cấp dịch vụ
Không phải lúc nào cũng biết bên trong dịch vụ có những gì (có thể không cần thiết)
Cách thu thập phân tích máy chủ
Nếu chúng ta muốn ngừng sử dụng phân tích khách hàng và xây dựng phân tích của riêng mình, trước hết chúng ta cần suy nghĩ kỹ về kiến trúc của hệ thống mới. Dưới đây tôi sẽ cho bạn biết từng bước những gì bạn cần xem xét, tại sao mỗi bước lại cần thiết và những công cụ nào bạn có thể sử dụng.
1. Nhận dữ liệu
Cũng giống như trường hợp phân tích khách hàng, trước hết, các nhà phân tích của công ty chọn loại sự kiện mà họ muốn nghiên cứu trong tương lai và thu thập chúng vào danh sách. Thông thường, những sự kiện này xảy ra theo một thứ tự cụ thể, được gọi là "mẫu sự kiện".
Tiếp theo, hãy tưởng tượng rằng một ứng dụng di động (trang web) có người dùng (thiết bị) thường xuyên và nhiều máy chủ. Để chuyển các sự kiện từ thiết bị sang máy chủ một cách an toàn, cần có một lớp trung gian. Tùy thuộc vào kiến trúc, có thể có một số hàng đợi sự kiện khác nhau.
- , được sử dụng làm hàng đợi để thu thập các sự kiện.
Theo vào năm 2014, người tạo ra Apache Kafka đã quyết định đặt tên phần mềm này theo tên Franz Kafka vì “đây là một hệ thống được tối ưu hóa cho việc viết” và vì ông yêu thích các tác phẩm của Kafka. —
Trong ví dụ của chúng tôi, có nhiều nhà sản xuất dữ liệu và người tiêu dùng dữ liệu (thiết bị và máy chủ) và Kafka giúp kết nối họ với nhau. Người tiêu dùng sẽ được mô tả chi tiết hơn trong các bước sau, trong đó họ sẽ là đối tượng chính. Bây giờ chúng ta sẽ chỉ xem xét các nhà sản xuất dữ liệu (sự kiện).
Kafka gói gọn các khái niệm về hàng đợi và phân vùng; tốt hơn nên đọc cụ thể hơn về điều này ở nơi khác (ví dụ: trong ). Không đi sâu vào chi tiết, hãy tưởng tượng rằng một ứng dụng di động được khởi chạy cho hai hệ điều hành khác nhau. Sau đó, mỗi phiên bản sẽ tạo luồng sự kiện riêng. Nhà sản xuất gửi sự kiện đến Kafka, chúng được ghi vào hàng đợi phù hợp.
(hình ảnh )
Đồng thời, Kafka cho phép bạn đọc theo từng đoạn và xử lý một luồng sự kiện theo từng đợt nhỏ. Kafka là một công cụ rất tiện lợi, có khả năng mở rộng quy mô phù hợp với nhu cầu ngày càng tăng (ví dụ: theo vị trí địa lý của các sự kiện).
Thông thường, một phân đoạn là đủ, nhưng mọi thứ trở nên phức tạp hơn khi mở rộng quy mô (như mọi khi). Có lẽ sẽ không ai muốn chỉ sử dụng một phân đoạn vật lý trong quá trình sản xuất vì kiến trúc phải có khả năng chịu lỗi. Ngoài Kafka, còn có một giải pháp nổi tiếng khác - RabbitMQ. Chúng tôi không sử dụng nó trong sản xuất làm hàng đợi phân tích sự kiện (nếu bạn có trải nghiệm như vậy, hãy cho chúng tôi biết về điều đó trong phần nhận xét!). Tuy nhiên, chúng tôi đã sử dụng AWS Kinesis.
Trước khi chuyển sang bước tiếp theo, chúng ta cần đề cập đến một lớp bổ sung nữa của hệ thống - lưu trữ nhật ký thô. Đây không phải là lớp bắt buộc, nhưng nó sẽ hữu ích nếu có sự cố xảy ra và hàng đợi sự kiện trong Kafka được đặt lại. Lưu trữ nhật ký thô không yêu cầu giải pháp phức tạp và tốn kém, bạn chỉ cần viết chúng ở đâu đó theo đúng thứ tự (ngay cả trên ổ cứng).
2. Xử lý luồng sự kiện
Sau khi chúng tôi đã chuẩn bị tất cả các sự kiện và đặt chúng vào hàng đợi thích hợp, chúng tôi chuyển sang bước xử lý. Ở đây tôi sẽ cho bạn biết về hai tùy chọn xử lý phổ biến nhất.
Tùy chọn đầu tiên là kích hoạt Spark Streaming trong hệ thống Apache. Tất cả các sản phẩm Apache đều hoạt động trên HDFS, một hệ thống tệp an toàn với các bản sao tệp. Spark Streaming là một công cụ dễ sử dụng, xử lý dữ liệu phát trực tuyến và chia tỷ lệ tốt. Tuy nhiên, nó có thể khó bảo trì.
Một tùy chọn khác là xây dựng trình xử lý sự kiện của riêng bạn. Để làm điều này, chẳng hạn, bạn cần viết một ứng dụng Python, xây dựng nó trong Docker và đăng ký hàng đợi Kafka. Khi trình kích hoạt đến trình xử lý docker, quá trình xử lý sẽ bắt đầu. Với phương pháp này, bạn cần giữ cho các ứng dụng luôn chạy.
Giả sử rằng chúng tôi đã chọn một trong các tùy chọn được mô tả ở trên và chuyển sang quá trình xử lý. Bộ xử lý nên bắt đầu bằng cách kiểm tra tính hợp lệ của dữ liệu, lọc rác và các sự kiện “bị hỏng”. Để xác nhận chúng tôi thường sử dụng . Sau này, bạn có thể thực hiện ánh xạ dữ liệu: dữ liệu từ các nguồn khác nhau được chuẩn hóa và chuẩn hóa để được thêm vào một bảng chung.
3. Cơ sở dữ liệu
Bước thứ ba là duy trì các sự kiện bình thường hóa. Khi làm việc với một hệ thống phân tích làm sẵn, chúng ta sẽ phải truy cập chúng thường xuyên, vì vậy điều quan trọng là phải chọn một cơ sở dữ liệu thuận tiện.
Nếu dữ liệu phù hợp với một sơ đồ cố định, bạn có thể chọn hoặc một số cơ sở dữ liệu cột khác. Bằng cách này, việc tổng hợp sẽ hoạt động rất nhanh. Nhược điểm là sơ đồ được cố định một cách cứng nhắc và do đó sẽ không thể thêm các đối tượng tùy ý mà không sửa đổi (ví dụ: khi xảy ra một sự kiện không chuẩn). Nhưng bạn có thể đếm rất nhanh.
Đối với dữ liệu phi cấu trúc, bạn có thể lấy NoSQL chẳng hạn: . Nó chạy trên HDFS, sao chép tốt, bạn có thể đưa ra nhiều phiên bản và có khả năng chịu lỗi.
Bạn cũng có thể nâng cao một cái gì đó đơn giản hơn, ví dụ: . Nó khá chậm và với khối lượng nhỏ. Nhưng điểm cộng là nó rất đơn giản và do đó thích hợp để bắt đầu.
4. Tập hợp
Sau khi lưu cẩn thận tất cả các sự kiện, chúng tôi muốn thu thập tất cả thông tin quan trọng từ lô đã đến và cập nhật cơ sở dữ liệu. Trên toàn cầu, chúng tôi muốn có được các trang tổng quan và số liệu có liên quan. Ví dụ: thu thập hồ sơ người dùng từ các sự kiện và bằng cách nào đó đo lường hành vi. Các sự kiện được tổng hợp, thu thập và lưu lại (trong bảng người dùng). Đồng thời, bạn có thể xây dựng một hệ thống để có thể kết nối bộ lọc với bộ điều phối tổng hợp: chỉ thu thập người dùng từ một loại sự kiện nhất định.
Sau đó, nếu ai đó trong nhóm chỉ cần phân tích cấp cao, hệ thống phân tích bên ngoài có thể được kết nối. Bạn có thể dùng lại Mixpanel. nhưng vì nó khá đắt nên không phải tất cả các sự kiện của người dùng đều được gửi đến đó mà chỉ những gì cần thiết. Để làm điều này, chúng tôi cần tạo một điều phối viên sẽ chuyển một số sự kiện thô hoặc thứ gì đó mà chúng tôi đã tổng hợp trước đó sang các hệ thống, API hoặc nền tảng quảng cáo bên ngoài.
5. Giao diện người dùng
Bạn cần kết nối giao diện người dùng với hệ thống đã tạo. Một ví dụ điển hình là dịch vụ , là GUI cơ sở dữ liệu giúp xây dựng trang tổng quan. Cách tương tác hoạt động:
- Người dùng thực hiện một truy vấn SQL.
- Đáp lại, anh ta nhận được một dấu hiệu.
- Nó tạo ra một 'hình ảnh trực quan mới' cho nó và có được một biểu đồ đẹp mắt mà bạn có thể lưu lại cho chính mình.
Hình ảnh trực quan trong dịch vụ được tự động cập nhật, bạn có thể tùy chỉnh và theo dõi quá trình giám sát của mình. Redash miễn phí nếu tự lưu trữ, nhưng vì SaaS nên nó sẽ có giá 50 USD mỗi tháng.
Kết luận
Sau khi hoàn thành tất cả các bước trên, bạn sẽ tạo phân tích máy chủ của mình. Xin lưu ý rằng việc này không đơn giản chỉ là kết nối phân tích khách hàng vì mọi thứ cần phải được tự cấu hình. Do đó, trước khi tạo hệ thống của riêng mình, bạn nên so sánh nhu cầu về một hệ thống phân tích nghiêm túc với các tài nguyên mà bạn sẵn sàng phân bổ cho nó.
Nếu bạn đã tính toán và nhận thấy chi phí quá cao thì trong phần tiếp theo tôi sẽ nói về cách tạo phiên bản phân tích phía máy chủ rẻ hơn.
Cảm ơn vì đã đọc! Tôi sẽ vui mừng đặt câu hỏi trong các ý kiến.
Nguồn: www.habr.com