7-Eleven-Việt-Nam-dùng-Data-Studio-BigQuery-thế-nào

7-Eleven Việt Nam dùng Data Studio & BigQuery thế nào?

Nếu muốn dây dựng văn hóa data-driven cho một tổ chức, điều đầu tiên cần nghĩ đến là phải làm cách nào để tất cả người trong tổ chức có thể tiếp cận được data họ cần một cách thuận tiện. Khó có thể gọi là “văn hóa” khi data chỉ được tiếp cận và sử dụng bởi nhóm nhỏ các managers. Đó là điều kiện cần để data là luận cứ cho các cuộc thảo luận (thay vì nói sản phẩm A bán rất tốt, ta phải nói bán tốt là bán bao nhiêu, so với cái gì, ở khu vực nào…), để từng cá nhân có thể theo dõi KPI của mình, từ đó hoàn thành KPI chung. Tổ chức càng lớn, việc phân quyền và quản lý data trở nên phức tạp hơn, ở 7-Eleven, ta cần tính đến việc cung cấp những con số xung quanh store performance đến các nhân viên của hàng trăm, hàng ngàn cửa hàng trong hệ thống.

7-Eleven Việt Nam sở hữu lợi thế lớn khi có in-house tech team xây hệ thống quản lý bán lẻ từ những ngày đầu. Sẽ không quá phức tạp để phát triển một report module cho cửa hàng sử dụng Ruby on Rail & ReactJs…

Những gì xảy ra tiếp theo: sau sprint hai tuần, ta có thể có report module sẵn sàng cho UAT (User Acceptance Testing), và lên production một tuần sau đó nếu may mắn không có sự thay đổi nào. Ba tuần có lẽ là khá nhanh để develop và release một chức năng trong hệ thống, tuy nhiên, dưới đây tôi sẽ nói về một giải pháp thay thế mà chỉ cần ba tiếng.

Lợi thế của việc dùng Google Cloud Platform

Về giải pháp Business intelligence (BI), tôi đã thử TableauHolistics và DOMO. Cả ba đều vô cùng mạnh và tiện lợi đặc biệt là business user. Tuy nhiên việc tính phí bằng số lượng user hoặc object (dataset/connections/visualization) của các tool này có vẻ không phù hợp, bởi với tốc độ gia tăng số lượng cửa hàng dự tính thì 7-Eleven sẽ có một con số khổng lồ các user và report cần tạo ra.

Trong khi đó Google BigQuery tính tiền theo lượng data được xử lý (charges by data processed), miễn là ta có partitioning và caching hợp lý thì mức giá sẽ vô cùng phù hợp. Điều này không có nghĩa là tôi đang so sánh những dịch vụ ở trên với BigQuery, tất cả cơ bản là rất khác nhau, khó mà so sánh toàn diện, chỉ là ý kiến cá nhân về pricing model. Thực tế, tất cả những dịch vụ trên sẽ sẵn sàng offer custom pricing bundle để phù hợp với từng enterprise. Để chọn một giải pháp phù hợp sẽ phụ thuộc nhiều vào set up hiện tại của team (scale hoặc startup, mức đầu tư vào in-house tech/data effort…).

Setup data pipeline cho BigQuery sẽ là một đề tài khác, hãy xem như ta đã có mọi thứ sẵn sàng: tất cả dữ liệu chúng tôi cần đều có thể query từ BigQuery datasets. Giờ đây, điều ta hướng đến là tạo ra một single sales report từ những sales transaction dataset. Sau đó, report này sẽ được cung cấp cho mỗi cửa hàng trưởng. Và đảm bảo rằng họ chỉ có thể xem được safes của cửa hàng mình mà không biết được sales của các cửa hàng khác.

Sử dụng Google Suite từ lúc đầu là một lợi thế lớn, ta có thể tận dụng cơ chế authentication sẵn có của Google Account. Gần đây Google Cloud Platform đang phát triển rất nhanh. Và AppsScript là một ví dụ, bởi nó chẳng những cung cấp sự hỗ trợ mạnh mẽ mà còn dễ dàng để bắt đầu. Nó cũng là một phần quan trọng đối với business solutions của chúng tôi. Thế nên tôi sẽ giành một chủ đề riêng để viết về nó.

Row-level permission với BigQuery

Row-level permission (hoặc Personalized permission, User filter, Row-level security) là để kiểm soát quyền truy cập đối với các dòng trong bảng dữ liệu dựa trên các thuộc tính của người thực hiện query. Trong trường hợp này: trong table sale transactions của toàn chuỗi, chỉ nên để các store manager xem được những transactions của cửa hàng họ.

Thật ra, row-level permission in BigQuery đã được giới thiệu từ 3 năm trước (3 years old Google’s blog post), tuy nhiên không có một hướng dẫn chính thức về việc nó thực sự được áp dụng như thế nào. Mà đến một Google Solutions Engineer từ Singapore (người đã giúp tôi set up Google Cloud Platform vài tháng trước) cũng gợi ý rằng tôi nên tạo ra từng view riêng cho mỗi cửa hàng thay vì tìm giải pháp cho row-permission. Chỉ mới gần đây, tôi mới thấy this article giải thích một cách hợp lý điều tôi vừa đề cập đến, nó cũng mô tả chính xác những gì tôi làm. Trong bài viết này tôi xin được giải thích nó theo quan điểm của mình với một business use case thực tế (chỉ trong 4 bước).

Trung tâm của BigQuery row-level permission chính là function SESSION_USER() , nó return email của user đang chạy query. Giờ thì tạm gác lại vấn đề này một chút bởi trước hết chúng ta cần có các permission table.

1. Setup Permission Tables

Dưới đây là database schema cơ bản để handle assignment của nhân viên cửa hàng. Ta sẽ lọc các transactions bằng credential của người xem report thông qua cửa hàng họ được assign (email của người này sẽ đến từ SESSION_USER()).

Staff assignment setup A1digihub
Staff assignment setup

Ngoài staff assignment table, một số thành viên đặc biệt như CEO hay các Director và manager ở HQ level cũng sẽ cần xem dữ liệu của toàn bộ chuỗi. Để không phải mất công cập nhật assignment của các vị này mỗi khi có cửa hàng mới mở, ta nên có thêm một table cho mục đích này. Cuối cùng ta sẽ có 2 views như sau: sales_report_permission danh sách email và store ID tương ứng, sales_report_viewer danh sách email của những người có full access. Chúng sẽ được sử dụng trong bước tiếp theo.

Tips: Để verify kết quả dễ hơn, bạn có thể tạo hai table bên trên bằng Google Sheet và have it saved as a table in BigQuery. Ta cũng có thể dễ dàng thay đổi email và test kết quả trong query tức thì.

2. Tạo BigQuery Views

Giả sử rằng ta đã có một view cho sales report với tất cả những tính toán cần thiết gọi là sales_report_view. Tuy nhiên, nó chưa lọc được dữ liệu theo người xem. Do đó, ta sẽ tạo một wrapper view như dưới đây (Standard SQL) và lưu là sales_report_by_viewer_view.

Bây giờ ta có một view mà kết quả sẽ được lọc bởi login user hiện tại, thế là xong phải không? Chưa đâu, ta sẽ cần phải share view này với những người cần query data từ nó, và đây chính là một vấn đề thực sự.

Đáng tiếc là BigQuery không cho phép ta share view, nhưng ta có thể share dataset. Điều đó có nghĩa là nếu nếu ta chia sẻ dataset mà ta đang làm việc, ta sẽ phải để lộ tất cả table/schema/query trong dataset đó cho tất cả user (nhân viên cửa hàng) mà ta muốn share. Ta sẽ không muốn điều đó, mà chỉ muốn cho nhân viên cửa hàng thấy đúng một view trên. Đó là lý do tại sao ta cần tạo một dataset khác cho mục đích chia sẻ và nó chỉ bao gồm table/view mà bạn có ý định chia sẻ. Hãy đặt tên cho nó là dataset_shared, trong đó, ta tạo một view khác gọi là sales_report_shared đơn giản như dưới đây.

Cuối cùng ta sẽ có setup như bên dưới. Bằng cách này, những ai tiếp cận với dataset được chia sẻ chỉ có thể khám phá thông tin mà ta muốn chia sẻ. Mọi thứ (real query, calucaltion, table schema, authorization setup) được gói gọn trong một query đơn giản mà không có ý nghĩa gì với hầu hết mọi người.

Bước tiếp theo ta sẽ tìm cách chia sẻ dataset_shared.

Đọc thêm: 6 Lợi ích tốt nhất của Dashboard A1 trong kinh doanh

3. Setup BigQuery Permission

Để view (sales_report_shared) có thể query data từ view khác từ dataset khác, ta cần set up Authorized View: mở mục sharing option của dataset(dataset chứa view sales_report_by_viewer_view), chọn Authorized View, sau đó chọn view sales_report_shared từ dataset_shared như hình dưới.

 

 

Sharing the dataset to an authorized view A1digihub
Sharing the dataset to an authorized view

Sau khi save, sales_report_shared view đã có thể lấy được data từ view sales_report_by_viewer_view. Tuy nhiên, các nhân viên cửa hàng vẫn chưa access được dữ liệu. Identity and Access Management (IAM) setup sẽ cho phép ta thực hiện điều này.

Đầu tiên, hãy tạo một custom role (trong hình ta đặt nó là DataStudio Viewer), add một và chỉ một permission dưới đây. Nó là permission duy nhất cần để user có thể run query. Những permission của default role BigQuery User là không cần thiết cho mục tiêu đã xác định của ta.

bigquery.jobs.create

 Create new role with just this permission
Create new role with just this permission

Thứ hai, đến member page,nơi bạn có thể add emails của các nhân viên cửa hàng vào role DataStudio Viewer. Để quản lý danh sách những người có thể access reports một cách dễ dàng nhất, ta có thể add email domain của công ty (hoặc các email group). Bằng cách đó, mặc dù người không liên quan có thể access được các report, họ sẽ không thấy được dữ liệu nào vì ta đã kiểm soát permission ở tầng dữ liệu rồi.

 

Add your domain or email group to the DataStudio Viewer
Add your domain or email group to the DataStudio Viewer

Thế đấy, vào thời điểm này bạn có thể thử login với email của một nhân viên cửa hàng (hoặc thay đổi các permission tables bên trên một chút với email khác của bạn) vào BigQuery và run view sales_report_shared để verify xem kết quả được filter theo login user.

4. Visualize on DataStudio

DataStudio là một công cụ để vẽ report, ở giai đoạn đầu phát triển nhưng vẫn đủ mạnh để các enterprise dùng. Quan trọng là nó trong Google Cloud Platform ecosystem nên có thuận lợi kết nối với BigQuey. Nếu bạn không thông thạo Data Studio thì điều bạn cần lúc này là tìm hiểu về nó trước khi đọc tiếp. Nhưng thực ra vẽ report với Data Studio cũng đơn giản như tạo một slide thuyết trình sử dụng Google Slide.

Update Mar 2019: Google has just introduced online course for Data Studio beginner which you can enroll for free https://analytics.google.com/analytics/academy/course/10

 

A sample dashboard from Google Data Studio team
A sample dashboard from Google Data Studio team

Việc bạn phải làm bây giờ là kết nối BigQuery như một datasource, và chọn view sales_report_shared.

Trong bước review datasource schema, đảm bảo flag USING VIEWER’S CREDENTIALS được ON.

Khi nó được mở, query khi được run sẽ dùng quyền của viewer thay vì người tạo ra report

 Make sure flag USING VIEWER’S CREDENTIALS is on
Make sure flag USING VIEWER’S CREDENTIALS is on

Sau khi ta vẽ xong report trong Data Studio (có thể là pivot table hay là các loại chart), bước cuối là chia sẻ report này cho nhân viên cửa hàng. Sử dụng share option của Data Studio (tương tự như share một Google Docs). Bạn có thể tự tin chia sẻ nó với cả tổ chức hoặc với email nhóm của các nhân viên cửa hàng, bởi vì: permission đã được kiểm soát ở tầng data rồi.

Sharing the Data Studio file
Sharing the Data Studio file

Final thoughts

Bước cuối cùng (optional) là nhúng hẳn link Data Studio report vào store portal (một dạng intranet) để nhân viên cửa hàng tiếp cận report tiện lợi hơn.

Điều tuyệt vời là khi ta cần thay đổi vài thứ cho report, như là thêm metric hay thay đổi công thức, bạn chỉ cần làm một lần, sự thay đổi sẽ ảnh hưởng mọi nơi, mọi người đều được cập nhật tức thì.

Mặc dù các nhân viên cửa hàng (nếu họ đủ tò mò) sẽ có thể vào BigQuery của ta và chạy query (ở cái view mà họ được chia sẻ) một cách trực tiếp, nhưng tôi không nghĩ nó là một vấn đề lớn vì ta đã kiểm soát permission ở cấp độ data.

Với tôi, điều đáng hài lòng nhất với setup này là tôi không phải quản lý các user và phân quyền mỗi khi có nhân viên mới, cửa hàng mới (diễn ra hàng ngày). Bộ phận HR, người quản lý trực tiếp nhân viên thông qua G suite sẽ làm việc đó.

Tất cả những bước trên, như tôi đã nói, chỉ mất ba tiếng là có thể thay thế ba tuần nỗ lực của backend, frontend devs và QA. Và nó là một scalable solution, không chỉ là một quick hack hay work around. Khi số lượng cửa hàng tăng lên, số lượng các record của table sale transactions sẽ trở nên khổng lồ, ta sẽ cần làm partition và cache.

Google Cloud Platform đang đổi mới rất nhanh, mỗi tuần ta đều có thể see some changes in their products. Nó mở ra các cách tiếp cận mới để thiết kế giải pháp cho doanh nghiệp. Thông qua quá trình phát triển software (thậm chí với Aile) không phải là lựa chọn duy nhất, nếu bạn có một setup đúng.

Bạn có thể quan tâm

Early-stage rounds — Where have you been?

 

 

 

Nguồn: medium.com