Tableau trong bán lẻ, thật sao?

Thời gian báo cáo bằng Excel đang nhanh chóng biến mất - xu hướng hướng tới các công cụ tiện lợi để trình bày và phân tích thông tin đang hiện diện ở mọi lĩnh vực. Chúng tôi đã thảo luận nội bộ về việc số hóa báo cáo trong một thời gian dài và chọn hệ thống phân tích tự phục vụ và trực quan hóa Tableau. Alexander Bezugly, trưởng bộ phận giải pháp phân tích và báo cáo của Tập đoàn M.Video-Eldorado, đã phát biểu về kinh nghiệm và kết quả xây dựng bảng điều khiển chiến đấu.

Tôi sẽ nói ngay rằng không phải mọi thứ đã lên kế hoạch đều thành hiện thực, nhưng trải nghiệm này rất thú vị, tôi hy vọng nó cũng sẽ hữu ích với bạn. Và nếu ai đó có bất kỳ ý tưởng nào về cách có thể thực hiện tốt hơn, tôi sẽ rất biết ơn lời khuyên và ý tưởng của bạn.

Tableau trong bán lẻ, thật sao?

Phần bên dưới là về những gì chúng tôi đã gặp và những gì chúng tôi đã học được.

Chúng ta đã bắt đầu từ đâu?

M.Video-Eldorado có mô hình dữ liệu được phát triển tốt: thông tin có cấu trúc với độ sâu lưu trữ cần thiết và số lượng lớn các báo cáo dạng cố định (xem thêm chi tiết đây là bài viết này). Từ đó, các nhà phân tích tạo ra các bảng tổng hợp hoặc các bản tin được định dạng trong Excel hoặc các bản trình bày PowerPoint đẹp mắt cho người dùng cuối.

Khoảng hai năm trước, thay vì báo cáo dạng cố định, chúng tôi bắt đầu tạo báo cáo phân tích trong Phân tích SAP (một tiện ích bổ sung Excel, về cơ bản là bảng tổng hợp trên công cụ OLAP). Nhưng công cụ này không thể đáp ứng được nhu cầu của tất cả người dùng, phần lớn vẫn tiếp tục sử dụng thông tin được các nhà phân tích xử lý bổ sung.

Người dùng cuối của chúng tôi thuộc ba loại:

Quản lý hàng đầu. Yêu cầu thông tin được trình bày tốt và rõ ràng.

Quản li trung gian, người dùng cao cấp. Quan tâm đến việc khám phá dữ liệu và có thể xây dựng báo cáo một cách độc lập nếu có sẵn công cụ. Họ trở thành người dùng chính của các báo cáo phân tích trong Phân tích SAP.

Người dùng đại chúng. Họ không quan tâm đến việc phân tích dữ liệu một cách độc lập; họ sử dụng các báo cáo với mức độ tự do hạn chế, ở định dạng bản tin và bảng tổng hợp trong Excel.

Ý tưởng của chúng tôi là đáp ứng nhu cầu của tất cả người dùng và cung cấp cho họ một công cụ tiện lợi, duy nhất. Chúng tôi quyết định bắt đầu với sự quản lý cấp cao. Họ cần những bảng thông tin dễ sử dụng để phân tích các kết quả kinh doanh chính. Vì vậy, chúng tôi bắt đầu với Tableau và trước tiên chọn hai hướng: các chỉ số bán lẻ và bán hàng trực tuyến với độ sâu và bề rộng phân tích hạn chế, sẽ bao gồm khoảng 80% dữ liệu mà ban lãnh đạo cấp cao yêu cầu.

Vì người dùng bảng thông tin là quản lý cấp cao nên một KPI bổ sung khác của sản phẩm đã xuất hiện - tốc độ phản hồi. Sẽ không có ai đợi 20-30 giây để dữ liệu được cập nhật. Việc điều hướng lẽ ra phải được thực hiện trong vòng 4-5 giây hoặc tốt hơn là được thực hiện ngay lập tức. Và than ôi, chúng tôi đã không đạt được điều này.

Đây là cách bố trí trang tổng quan chính của chúng tôi trông như thế nào:

Tableau trong bán lẻ, thật sao?

Ý tưởng chính là kết hợp các yếu tố thúc đẩy KPI chính, trong đó có tổng cộng 19 yếu tố ở bên trái và trình bày động lực cũng như sự phân tích của chúng theo các thuộc tính chính ở bên phải. Nhiệm vụ có vẻ đơn giản, hình ảnh trực quan hợp lý và dễ hiểu cho đến khi bạn đi sâu vào chi tiết.

Chi tiết 1. Khối lượng dữ liệu

Bảng chính của chúng tôi về doanh số hàng năm chiếm khoảng 300 triệu hàng. Vì cần phải phản ánh động lực của năm ngoái và năm trước đó nên chỉ riêng khối lượng dữ liệu về doanh số bán hàng thực tế là khoảng 1 tỷ dòng. Thông tin về dữ liệu theo kế hoạch và khối bán hàng trực tuyến cũng được lưu trữ riêng biệt. Do đó, mặc dù chúng tôi đã sử dụng DB SAP HANA dạng cột trong bộ nhớ, tốc độ truy vấn nhanh chóng với việc chọn tất cả các chỉ báo trong một tuần từ bộ nhớ hiện tại là khoảng 15-20 giây. Giải pháp cho vấn đề này tự nó gợi ý - hiện thực hóa dữ liệu bổ sung. Nhưng nó cũng có những cạm bẫy, hãy tìm hiểu thêm về chúng bên dưới.

Chi tiết 2. Chỉ tiêu không phụ gia

Nhiều KPI của chúng tôi gắn liền với số lượng hóa đơn. Và chỉ báo này thể hiện COUNT DISTINCT của số hàng (kiểm tra tiêu đề) và hiển thị số lượng khác nhau tùy thuộc vào thuộc tính đã chọn. Ví dụ: cách tính chỉ báo này và đạo hàm của nó:

Tableau trong bán lẻ, thật sao?

Để thực hiện tính toán chính xác, bạn có thể:

  • Tính toán các chỉ số đó một cách nhanh chóng trong kho;
  • Thực hiện tính toán trên toàn bộ khối lượng dữ liệu trong Tableau, tức là theo yêu cầu ở Tableau, cung cấp tất cả dữ liệu theo các bộ lọc đã chọn ở mức độ chi tiết của vị trí biên nhận;
  • Tạo một chương trình giới thiệu cụ thể hóa trong đó tất cả các chỉ số sẽ được tính toán trong tất cả các tùy chọn mẫu để đưa ra các kết quả không phụ gia khác nhau.

Rõ ràng là trong ví dụ UTE1 và UTE2 là các thuộc tính vật liệu đại diện cho hệ thống phân cấp sản phẩm. Đây không phải là một điều cố định; việc quản lý trong công ty diễn ra thông qua nó, bởi vì Các nhà quản lý khác nhau chịu trách nhiệm về các nhóm sản phẩm khác nhau. Chúng tôi đã có nhiều bản sửa đổi toàn cầu về hệ thống phân cấp này, khi tất cả các cấp độ thay đổi, khi các mối quan hệ được sửa đổi và các điểm thay đổi liên tục khi một nhóm chuyển từ nút này sang nút khác. Trong báo cáo thông thường, tất cả điều này được tính toán nhanh chóng từ các thuộc tính của tài liệu; trong trường hợp cụ thể hóa dữ liệu này, cần phát triển một cơ chế theo dõi những thay đổi đó và tự động tải lại dữ liệu lịch sử. Một nhiệm vụ rất không hề tầm thường.

Chi tiết 3. So sánh dữ liệu

Điểm này tương tự như điểm trước. Điểm mấu chốt là khi phân tích một công ty, người ta thường hình thành một số cấp độ so sánh với giai đoạn trước:

So sánh với kỳ trước (ngày này qua ngày khác, tuần này sang tuần khác, tháng này sang tháng khác)

Trong so sánh này, giả định rằng tùy thuộc vào khoảng thời gian được người dùng chọn (ví dụ: tuần thứ 33 trong năm), chúng tôi sẽ hiển thị động lực trước tuần thứ 32; nếu chúng tôi chọn dữ liệu cho một tháng, chẳng hạn như tháng XNUMX , thì sự so sánh này sẽ cho thấy động lực vào tháng XNUMX.

So sánh với năm ngoái

Sắc thái chính ở đây là khi so sánh theo ngày và theo tuần, bạn không lấy cùng một ngày của năm ngoái, tức là. bạn không thể chỉ lấy năm hiện tại trừ đi một. Bạn phải nhìn vào ngày trong tuần mà bạn đang so sánh. Ngược lại, khi so sánh các tháng, bạn cần lấy đúng ngày dương lịch của năm ngoái. Cũng có những sắc thái với năm nhuận. Trong kho lưu trữ ban đầu, tất cả thông tin được phân phối theo ngày, không có trường riêng biệt theo tuần, tháng hoặc năm. Do đó, để có được mặt cắt phân tích hoàn chỉnh trong bảng điều khiển, bạn cần tính không phải một khoảng thời gian, chẳng hạn như một tuần, mà là 4 tuần, sau đó so sánh các dữ liệu này, phản ánh động lực, độ lệch. Theo đó, logic này để tạo ra các so sánh về động lực học cũng có thể được triển khai trong Tableau hoặc ở phía cửa hàng. Có, và tất nhiên chúng tôi đã biết và nghĩ đến những chi tiết này ở giai đoạn thiết kế, nhưng rất khó để dự đoán tác động của chúng đối với hiệu suất của bảng điều khiển cuối cùng.

Khi triển khai bảng thông tin, chúng tôi đã đi theo con đường Agile dài. Nhiệm vụ của chúng tôi là cung cấp một công cụ làm việc với dữ liệu cần thiết để thử nghiệm càng nhanh càng tốt. Do đó, chúng tôi đã chạy nước rút và bắt đầu từ việc giảm thiểu công việc đối với bộ nhớ hiện tại.

Phần 1: Niềm tin vào Tableau

Để đơn giản hóa việc hỗ trợ CNTT và nhanh chóng triển khai các thay đổi, chúng tôi đã quyết định tạo ra logic để tính toán các chỉ số không cộng gộp và so sánh các giai đoạn trước đây trong Tableau.

Giai đoạn 1. Mọi thứ đều Trực tiếp, không có sửa đổi cửa sổ.

Ở giai đoạn này, chúng tôi đã kết nối Tableau với các cửa hàng hiện tại và quyết định xem cách tính số lượng hóa đơn trong một năm.

Kết quả:

Câu trả lời thật đáng buồn - 20 phút. Truyền dữ liệu qua mạng, tải cao trên Tableau. Chúng tôi nhận thấy rằng logic với các chỉ báo không phụ gia cần phải được triển khai trên HANA. Điều này không làm chúng tôi lo lắng nhiều, chúng tôi đã có kinh nghiệm tương tự với BO và Phân tích, đồng thời chúng tôi biết cách xây dựng các chương trình giới thiệu nhanh trong HANA để tạo ra các chỉ báo không phụ gia được tính toán chính xác. Bây giờ tất cả những gì còn lại là điều chỉnh chúng cho phù hợp với Tableau.

Giai đoạn 2. Chúng tôi điều chỉnh các hộp trưng bày, không hiện thực hóa, mọi thứ đều diễn ra nhanh chóng.

Chúng tôi đã tạo một chương trình giới thiệu mới riêng biệt để tạo ra dữ liệu cần thiết cho TABLEAU một cách nhanh chóng. Nhìn chung, chúng tôi đã đạt được kết quả tốt, chúng tôi đã giảm thời gian tạo tất cả các chỉ báo trong một tuần xuống còn 9-10 giây. Và chúng tôi thực lòng mong đợi rằng ở Tableau, thời gian phản hồi của bảng điều khiển sẽ là 20-30 giây ở lần mở đầu tiên và sau đó do bộ đệm từ 10 đến 12, nhìn chung sẽ phù hợp với chúng tôi.

Kết quả:

Trang tổng quan mở lần đầu: 4-5 phút
Nhấp chuột bất kỳ: 3-4 phút
Không ai mong đợi sự gia tăng bổ sung như vậy trong công việc của mặt tiền cửa hàng.

Phần 2. Đi sâu vào Tableau

Giai đoạn 1. Phân tích hiệu suất Tableau và điều chỉnh nhanh

Chúng tôi bắt đầu phân tích nơi Tableau dành phần lớn thời gian. Và có những công cụ khá tốt cho việc này, tất nhiên, đó là một điểm cộng của Tableau. Vấn đề chính mà chúng tôi xác định là các truy vấn SQL rất phức tạp mà Tableau đang xây dựng. Chúng chủ yếu được liên kết với:

- chuyển đổi dữ liệu. Vì Tableau không có công cụ chuyển đổi tập dữ liệu nên để xây dựng phía bên trái của bảng thông tin với phần trình bày chi tiết về tất cả các KPI, chúng tôi phải tạo một bảng bằng cách sử dụng một trường hợp. Kích thước của truy vấn SQL trong cơ sở dữ liệu đạt tới 120 ký tự.

Tableau trong bán lẻ, thật sao?

- sự lựa chọn của khoảng thời gian. Một truy vấn như vậy ở cấp cơ sở dữ liệu mất nhiều thời gian để biên dịch hơn là thực thi:

Tableau trong bán lẻ, thật sao?

Những thứ kia. xử lý yêu cầu 12 giây + thực hiện 5 giây.

Chúng tôi quyết định đơn giản hóa logic tính toán ở phía Tableau và chuyển một phần tính toán khác sang cấp độ mặt tiền cửa hàng và cơ sở dữ liệu. Điều này mang lại kết quả tốt.

Đầu tiên, chúng tôi thực hiện chuyển vị một cách nhanh chóng, chúng tôi đã thực hiện nó thông qua phép nối ngoài đầy đủ ở giai đoạn cuối của phép tính VIEW, theo cách tiếp cận này được mô tả trên wiki Chuyển vị - Wikipedia, bách khoa toàn thư miễn phí и Ma trận cơ bản - Wikipedia, bách khoa toàn thư miễn phí.

Tableau trong bán lẻ, thật sao?

Nghĩa là, chúng tôi đã tạo một bảng cài đặt - ma trận chuyển vị (21x21) và nhận tất cả các chỉ báo theo phân tích theo từng hàng.

Đó là:
Tableau trong bán lẻ, thật sao?

Nó đã trở thành:
Tableau trong bán lẻ, thật sao?

Hầu như không có thời gian dành cho việc chuyển đổi cơ sở dữ liệu. Yêu cầu về tất cả các chỉ số trong tuần tiếp tục được xử lý trong khoảng 10 giây. Nhưng mặt khác, tính linh hoạt đã bị mất đi khi xây dựng bảng điều khiển dựa trên một chỉ báo cụ thể, tức là. đối với phía bên phải của bảng điều khiển, nơi trình bày động lực và phân tích chi tiết của một chỉ báo cụ thể, trước đây cửa sổ hiển thị hoạt động trong 1-3 giây, bởi vì yêu cầu dựa trên một chỉ báo và bây giờ cơ sở dữ liệu luôn chọn tất cả các chỉ báo và lọc kết quả trước khi trả kết quả về Tableau.

Kết quả là tốc độ của bảng điều khiển giảm gần 3 lần.

Kết quả:

  1. 5 giây – phân tích bảng thông tin, trực quan hóa
  2. 15-20 giây - chuẩn bị biên dịch các truy vấn bằng cách thực hiện các phép tính trước trong Tableau
  3. 35-45 giây - tổng hợp các truy vấn SQL và thực thi tuần tự song song của chúng trong Hana
  4. 5 giây – xử lý kết quả, sắp xếp, tính toán lại trực quan hóa trong Tableau
  5. Tất nhiên, kết quả như vậy không phù hợp với doanh nghiệp và chúng tôi tiếp tục tối ưu hóa.

Giai đoạn 2. Logic tối thiểu trong Tableau, hiện thực hóa hoàn chỉnh

Chúng tôi hiểu rằng không thể xây dựng một trang tổng quan có thời gian phản hồi vài giây trên mặt tiền cửa hàng chạy trong 10 giây và chúng tôi đã xem xét các tùy chọn để hiện thực hóa dữ liệu ở phía cơ sở dữ liệu dành riêng cho trang tổng quan được yêu cầu. Nhưng chúng tôi đã gặp phải một vấn đề toàn cầu được mô tả ở trên - các chỉ số không phụ gia. Chúng tôi không thể đảm bảo rằng khi thay đổi bộ lọc hoặc thông tin chi tiết, Tableau đã chuyển đổi linh hoạt giữa các mặt tiền cửa hàng và cấp độ khác nhau được thiết kế sẵn cho các hệ thống phân cấp sản phẩm khác nhau (trong ví dụ: ba truy vấn không có UTE, với UTE1 và UTE2 tạo ra các kết quả khác nhau). Do đó, chúng tôi quyết định đơn giản hóa trang tổng quan, loại bỏ hệ thống phân cấp sản phẩm trong trang tổng quan và xem tốc độ của nó trong phiên bản đơn giản hóa.

Vì vậy, ở giai đoạn cuối cùng này, chúng tôi đã tập hợp một kho lưu trữ riêng biệt trong đó chúng tôi đã thêm tất cả KPI ở dạng chuyển đổi. Về phía cơ sở dữ liệu, mọi yêu cầu đối với bộ lưu trữ như vậy đều được xử lý trong 0,1 - 0,3 giây. Trong bảng điều khiển, chúng tôi nhận được kết quả sau:

Lần mở đầu tiên: 8-10 giây
Nhấp chuột bất kỳ: 6-7 giây

Thời gian dành cho Tableau bao gồm:

  1. 0,3 giây. - phân tích bảng điều khiển và biên dịch các truy vấn SQL
  2. 1,5-3 giây. — thực thi các truy vấn SQL trong Hana để trực quan hóa chính (chạy song song với bước 1)
  3. 1,5-2 giây. - hiển thị, tính toán lại trực quan hóa
  4. 1,3 giây. — thực hiện các truy vấn SQL bổ sung để thu được các giá trị bộ lọc có liên quan (Thương hiệu, Bộ phận, Thành phố, Cửa hàng), phân tích kết quả

Tóm lại một cách ngắn gọn

Chúng tôi thích công cụ Tableau từ góc độ trực quan hóa. Ở giai đoạn tạo mẫu, chúng tôi đã xem xét nhiều yếu tố trực quan hóa khác nhau và tìm thấy tất cả chúng trong thư viện, bao gồm phân đoạn đa cấp phức tạp và thác nước đa trình điều khiển.

Trong khi triển khai bảng thông tin với các chỉ số bán hàng chính, chúng tôi đã gặp phải những khó khăn về hiệu suất mà chúng tôi vẫn chưa thể khắc phục. Chúng tôi đã dành hơn hai tháng và nhận được một trang tổng quan chưa hoàn thiện về mặt chức năng, tốc độ phản hồi của nó ở mức có thể chấp nhận được. Và chúng tôi đã rút ra kết luận cho chính mình:

  1. Tableau không thể hoạt động với lượng lớn dữ liệu. Nếu trong mô hình dữ liệu gốc, bạn có hơn 10 GB dữ liệu (khoảng 200 triệu X 50 hàng), thì trang tổng quan sẽ chậm lại nghiêm trọng - từ 10 giây đến vài phút cho mỗi lần nhấp. Chúng tôi đã thử nghiệm cả kết nối trực tiếp và trích xuất. Tốc độ hoạt động có thể so sánh được.
  2. Hạn chế khi sử dụng nhiều kho (bộ dữ liệu). Không có cách nào để chỉ ra mối quan hệ giữa các bộ dữ liệu bằng các phương tiện tiêu chuẩn. Nếu bạn sử dụng giải pháp thay thế để kết nối các tập dữ liệu, điều này sẽ ảnh hưởng lớn đến hiệu suất. Trong trường hợp của chúng tôi, chúng tôi đã xem xét tùy chọn cụ thể hóa dữ liệu trong từng phần chế độ xem được yêu cầu và thực hiện chuyển đổi trên các tập dữ liệu cụ thể hóa này trong khi vẫn giữ nguyên các bộ lọc đã chọn trước đó - điều này hóa ra là không thể thực hiện được trong Tableau.
  3. Không thể tạo các tham số động trong Tableau. Bạn không thể điền tham số được sử dụng để lọc tập dữ liệu trong một bản trích xuất hoặc trong khi kết nối trực tiếp với kết quả của một lựa chọn khác từ tập dữ liệu hoặc kết quả của một truy vấn SQL khác, chỉ đầu vào của người dùng gốc hoặc một hằng số.
  4. Những hạn chế liên quan đến việc xây dựng bảng thông tin với các phần tử OLAP|PivotTable.
    Trong MSTR, SAP SAC, SAP Analysis, nếu bạn thêm tập dữ liệu vào báo cáo thì theo mặc định, tất cả các đối tượng trên đó đều có liên quan với nhau. Tableau không có cái này; kết nối phải được cấu hình thủ công. Điều này có thể linh hoạt hơn, nhưng đối với tất cả các bảng thông tin của chúng tôi, đây là yêu cầu bắt buộc đối với các thành phần - vì vậy đây là chi phí lao động bổ sung. Hơn nữa, nếu bạn tạo các bộ lọc liên quan, chẳng hạn như khi lọc một khu vực, danh sách các thành phố chỉ bị giới hạn ở các thành phố của khu vực này, bạn sẽ ngay lập tức kết thúc bằng các truy vấn liên tiếp tới cơ sở dữ liệu hoặc Trích xuất, điều này làm chậm đáng kể tốc độ xử lý. bảng điều khiển.
  5. Hạn chế về chức năng. Không thể thực hiện các phép biến đổi hàng loạt trên bản trích xuất hoặc ĐẶC BIỆT trên tập dữ liệu từ Live-connecta. Điều này có thể được thực hiện thông qua Tableau Prep, nhưng đây là công việc bổ sung và một công cụ khác cần tìm hiểu và duy trì. Ví dụ: bạn không thể chuyển đổi dữ liệu hoặc nối dữ liệu đó với chính nó. Những gì được đóng thông qua các phép biến đổi trên các cột hoặc trường riêng lẻ, phải được chọn thông qua trường hợp hoặc nếu, và điều này tạo ra các truy vấn SQL rất phức tạp, trong đó cơ sở dữ liệu dành phần lớn thời gian để biên dịch văn bản truy vấn. Tính không linh hoạt này của công cụ phải được giải quyết ở cấp độ trưng bày, dẫn đến việc lưu trữ phức tạp hơn, tải xuống và chuyển đổi bổ sung.

Chúng tôi chưa từ bỏ Tableau. Nhưng chúng tôi không coi Tableau là một công cụ có khả năng xây dựng bảng điều khiển công nghiệp và là công cụ để thay thế và số hóa toàn bộ hệ thống báo cáo công ty của công ty.

Chúng tôi hiện đang tích cực phát triển một bảng thông tin tương tự trong một công cụ khác, đồng thời cố gắng sửa đổi kiến ​​trúc bảng thông tin trong Tableau để đơn giản hóa nó hơn nữa. Nếu cộng đồng quan tâm, chúng tôi sẽ cho bạn biết về kết quả.

Chúng tôi cũng đang chờ ý tưởng hoặc lời khuyên của bạn về cách tại Tabeau, bạn có thể xây dựng trang tổng quan nhanh chóng trên khối lượng dữ liệu lớn như vậy, bởi vì chúng tôi có một trang web có nhiều dữ liệu hơn so với trong bán lẻ.

Nguồn: www.habr.com

Thêm một lời nhận xét