CÂU HỎI: TÍNH TOÁN TẠI SQL HAY BI TOOL?
CÂU HỎI: TÍNH TOÁN TẠI SQL HAY BI TOOL?
Trên cộng đồng gần đây có nội dung trao đổi mình thấy rất hay và thực sự quan trọng liên quan đến phân tích dữ liệu thế nên Page mốc meo và bận đến mấy cũng phải dành ít phút chia sẻ quan điểm cho anh em để cùng bàn luận và trao đổi nhé. Như tiêu đề, anh em làm Data nhiều khi băn khoăn giữa việc tính toán công thức và các thông tin sẵn trên Database (Sql) hay là tính toán trên các công cụ BI. Rồi có nhiều người bảo mấy ông BI chỉ giỏi visualize thôi còn đừng có mà đòi chiếm chỗ quan trọng của SQL.
Thế thì mình chốt luôn quan điểm dựa trên kinh nghiệm của mình và rất nhiều mentor của mình ở các công ty nước ngoài (CDO) như sau nhé: CÔNG CỤ BI KHÔNG PHẢI CHỈ LÀ VISUALIZE MÀ LÀ CÔNG CỤ PHÂN TÍCH. Các công thức cần tính linh hoạt, cần tính theo nhiều góc độ phân tích và chiều phân tích NÊN VÀ LUÔN LUÔN NÊN tính trên công cụ BI. Việc anh em nghĩ là làm mọi thứ trên SQL để ra số sẵn rồi chỉ kéo lên PBI tạo biểu đô thì mình thấy nó hài hước giống kiểu năm 2023 rồi mà vẫn còn dùng SUMIF tạo Dashboard thay vì DataModeling trong Excel ấy. Bởi vì ai đã dùng Data Model trong Excel thì chả dại gì quay lại viết SUMIF cả (tất nhiên là trừ 1 vài trường hợp bất đắc dĩ)
Mình chia sẻ bài học đầu đời của mình trong lĩnh vực quản trị Database thế này cho anh em dễ hình dung nhé. Mình đã từng có cơ hội được làm trong team Data Engineer của NRG (công ty năng lượng lớn nhất của Mỹ). Các bạn hình dung 1 ngày công ty này có tầm ~ 1 Terabyte data đổ về Datacenter của họ và họ cung cấp thông tin cho hơn 5000 đối tác quốc tế về năng lượng. Team Data Engineer mình tham gia là 1 trong các cơ sở của họ bao gồm tầm 100 nhân sự chỉ có mỗi đúng công việc là đi xử lý ETL và kiểm tra quản trị đống dữ liệu cũng như hiệu năng của các DataCenter (DC nha không phải là 1 cái DB). Các lớp trong Database họ phân ra thành ít nhất 7 tầng cho phần Staging để xử lý thông tin thô từ máy đo điện và năng lượng quy đổi sang thông tin nghiệp vụ cho các phòng ban khác. Yêu cầu thông tin và đầu ra báo cáo không chỉ đến từ nội bộ mà còn là từ đối tác và khách hàng. Tức là nếu chỉ đơn thuần anh em tính toán trên 1 lớp Database nó đã có rất nhiều procedure phải chạy tự động và quản lý chỉ để ETL và chuyển dịch dữ liệu thôi chưa nói đến yêu cầu của nghiệp vụ nha, Hồi đó mình may mắn được tham gia vào để dự thính 1 dự án triển khai rất quan trọng với công ty là triển khai hệ thống SSAS và SSRS (chưa đủ tầm làm chỉ nghe thôi). Mình mới hỏi ông Supervisor và có cả luôn ông Director là tại sao không ETL và làm procudure để ra luôn các bảng view cho khách hàng và nội bộ công ty thì ông phán luôn 1 câu là công ty không đủ tiền để tiếp tục mua thêm Data Center khác và cũng không thể tiếp tục tuyển dụng thêm quá nhiều DE chỉ để tạo ra view cho nghiệp vụ xem với tốc độ yêu cầu tăng chóng mặt. Lúc đấy mình mới hiểu cái đống ELT và procedure quản lý chạy ra các bảng giữa các tàng lưu trữ dù bên mình có khổng lồ thì nó mới chỉ bằng 1/5 các bảng view đang phải quản lý cho bên nghiệp vụ làm. Thời đó khái niệm làm Datawarehouse đã có rồi nhưng còn mới với nhiều công ty. Chưa kể đến khái niệm triển khai Multidimentional Modeling cho nghiệp vụ phân tích. Việc làm theo cách xây dựng các bảng view hoặc thậm chí làm chuẩn hơn là tạo Datamart và các Ad-hoc report system cho nghiệp vụ nó chỉ đáp ứng được nếu các adhoc và view table đó nằm ở một con số nhỏ và vừa với số lượng nhân sự cần xử lý nhưng với tầm 5000 đối tác và yêu cầu xem thông tin của họ để mua bán năng lượng thay đổi theo ngày thì lượng nhân sự DE để thiết kế các bảng view đó rồi việc quản trị các bảng view (phần lớn là xây và xem trong tầm 2-3 tuần rồi lại đổi hoặc đổi 2-3 lần 1 ngày) là không khả thi.
Thời đó khái niệm Self-servicing BI và Analytics là chưa có vì các doanh nghiệp lớn họ vẫn làm theo quy trình là nghiệp vụ cần gì thì phòng DA (Database Admin) sẽ xây dựng và cơ cấu thành các DB riêng và các bảng view riêng cho họ truy cập. Điều đó đẫn đến các vấn đề sau:
1/ Lượng Data tăng đột biến vì thực tế ta đang tạo thêm bảng dữ liệu để xem các nội dung từ các bảng gốc thô ở các tầng Staging
2/ Yêu cầu nghiệp vụ thay đổi và tăng lên khiến khả năng đáp ứng của team Data không đáp ứng được (100 ông DE phục vụ cho tầm 2000 request khác nhau mỗi ngày không khả thi)
3/ Việc quản lý logic thông tin tính toán và kết quả cũng như các lỗi xây query và quản trị nó trở nên cồng kềnh
4/ DE bị tách khỏi mục đích chính của họ là quản trị các procedure xử lý dữ liệu thô và quản lý hiệu năng của Database và Datacenter và bị cử đi phục vụ cho bên nghiệp vụ (chưa kế 2 bên nhiều khi không hiểu nhau không chung quan điểm => sai thông tin)
Quay trở lại với câu hỏi chính, vậy thì nếu chúng ta đang triển khai các giải pháp phân tích, lưu trữ dữ liệu và BI thì nên tính ở đâu. Các bạn cứ hình dung hình ảnh dưới là 1 kiến trúc chuẩn của các dịch vụ dữ liệu thời nay (hàu hết là on cloud). Đây là kiến trúc của DataWarehouse chính hiệu phục vục cho việc phân tích. Hãy chú ý đến Database vài trò của nó chỉ vỏn vẹn từ phần Data Sources thôi nha. Đừng kể đến các khái niệm và công nghệ mới như Data Lake, Analyis Service là nền tảng công nghệ khác. Trong các kiến trúc đã trở thành cẩm nang của Data Architecture như Kimball và Inmon thì cũng chỉ ra rằng SQL với vai trò là 1 database chỉ là 1 thành phần của DataWarehouse kiến trúc phục vụ cho phân tích thôi. Mặc dù chúng ta có thể xây các bảng dữ liệu tính sẵn trên SQL database nhưng nó không đóng vai trò chuẩn cho việc phân tích.
Bạn nào bảo làm mọi thứ tính hết và tạo các bảng view các bảng summarized trên SQL thì mình xin phép nói thẳng và hơi phũ chút là bạn nên tìm hiểu rộng hơn vai trò của các công cụ khác. Thực trạng có thể thấy ở Việt Nam vì tiết kiệm chi phí nên 90% các công ty chỉ có dùng DB rồi đổ ra Excel hoặc BI tool để làm báo cáo. Và hiện nay nhu cầu của các công ty thậm chí là tập đoàn lớn ở VN chưa có nhiều văn hóa làm việc cùng dữ liệu, báo cáo toàn quanh quẩn ở các báo cáo giao ban, các đơn vị phòng ban chưa có ý thức khai thác dữ liệu và phân tích đa chiều nên sẽ gặp tình huống là cứ đẩy về SQL làm. Mình không nói 100% cách tính trên SQL là sai nha, nhiều tình huống phải tính trên SQL đó là tại sao phải có các procedure để tính toán tự động nhưng mà các tính toán mà nghiệp vụ cần thì nó đòi hỏi nhiều hơn. Thay vì mất 10 công để làm 1 thứ các bạn nên tìm cách mất 1 công làm được 10 thứ. Thực sự ra mà nói khi mình dùng cả SQL lẫn nhiều tool BI thì công thức trên BI nó sinh ra là dễ hơn so với việc dùng SQL để tính và THÔNG MÌNH HƠN NHIỀU~ Lý do các công cụ BI ra đời 1 phần là để tách các vai trò phân tích phụ thuộc vào DB và làm đúng vai trò của 1 DB đối với ngôn ngữ SQL (ngôn ngữ truy vấn và xử lý hạ tầng dữ liệu)
Lấy đơn giản như trường hợp trên tại sao cách đây hàng chục năm người ta phát minh ra khái niệm Datawarehouse rồi sau đó xây dựng ra các công nghệ như SSAS (analysis service hoặc Azure Synapse hoặc Google Big Query Analytics hoặc AWS Kinesis và Athena ....) bởi vì nhu cầu của BI và phân tích nghiệp càng ngày càng tăng và họ cần là tự có thể sử dụng các mô hình kéo thả phân tích đa chiều theo cấu trúc mô hình hóa phân tích chứ không phải xem rời rạc thành các bảng riêng và phụ thuộc và người khác query cho mình.
Một vài anh em sẽ có câu hỏi như sau trong đầu:
1/ Nếu tôi xây dựng các tính toán và mô hình trên các tool BI lỡ công ty họ đổi tool thì sao? => thì mô hình bạn xây dựng có thể migrate sang tool khác vì BI tool bh làm việc đều trên nền tảng Dimensional Modeling nên cái gốc rễ của model là giữ nguyên chỉ có khác nhau ở chỗ dùng hàm hoặc cách dùng kéo thả khác thôi nha. Đồng thời như sơ đồ dưới 1 công ty mà họ làm chuẩn thì họ sẽ sử dụng các dịch vụ phân tích như Synapse, Analytics Service rồi mới cắm vào BI (tức là thay vì dùng cơ chế của PBI thì họ dùng nền tảng riêng là model và công thức) khi đó bạn migrate thì nhanh chóng mặt. Cách đây 15 năm các doanh nghiệp nước ngoài lớn họ đã ứng dụng Multidimensional để nhân sự tự kéo thả tạo pivot phân tích đa chiều rồi chứ k phải đợi đến tool BI ra đời đâu ạ.
2/ Nếu tôi xây trên PBI thì data tôi lưu ở bên thứ 3 có bảo mât không? Quá buồn cười khi chúng ta lưu tài liệu văn bản trên Google drive, SharePoint, Dropbox thường xuyên rất an tâm hoặc gửi tài liệu qua email mà lại đi lo data lưu ở bên thứ 3 =))) thế văn bản không phải thông tin à mà các anh chị dùng 3rd party vendor như thật vậy. Và lưu ý rằng Microsoft họ không dại gì mà break agreement bảo mật thông tin ạ. Thêm nữa đừng quên các công cụ BI đều có hệ thông Onpremise tự xây và quản lý data trên server nội bộ. Chưa kể chỉ 5-10 năm nữa thôi các bạn sẽ nghe đến các khái niệm như Private Blockchain Data Network thì vendor muốn cũng không động được vào data của bạn
3/ Nếu mà công ty tôi thay đổi mô hình phân tích thì sao? Đã kiến trúc mô hình là người ta đã bao quát đầy đủ các tình huống phân tích rồi, việc 1 công ty thay đổi liên tục yêu cầu phân tích hàng ngày phải được bao quát từ kiến trúc hạ tầng dữ liệu và mô hình hóa của dữ liệu cũng như việc mở rộng nó ra sao. Mình nghĩ là thay vì quay tâm việc họ thay đổi cách kinh doanh hoặc mô hình thì bạn nên quan tâm đến việc thay đổi yêu cầu phân tích hàng ngày, điều mà chỉ có các Analysis Service hoặc BI tool mới đáp ứng đượic còn SQL thì các bạn tha hồ mà chạy theo để tạo bảng nhé.
4/ Lỡ PowerBI hay BI tool nó update rồi nó hỏng hết hàm của mình tạo ra thì sao? => chả lẽ SQL không thay đổi? Mình nghĩ là việc trong tương lai các công ty thay đổi dần chuyển từ Structured Database sang dùng DataLake hoặc từ SQL sang No-SQL hoặc mix là chắc chắn chứ còn Microsoft họ mà có update thay đổi thì cũng phải có kế hoạch chứ không tự dưng họ tự hủy sản phẩm mình vậy đâu. Bạn nào dùng PBI cũng thấy update liên tục hàng tháng để tăng tính năng và trải nghiệm người dùng chứ không phải để người dùng thấy khó mà không dùng.
P/S: Mình chốt lại bằng câu quote này "Information wants to be FREE" tức là thông tin là quan trọng và ngày nay việc nghiệp vụ hay người xem sử dụng thông tin càng cần khả năng tự khai thác và tự xử lý thông tin từ dữ liệu. Các công cụ BI sinh ra KHÔNG PHẢI CHỈ ĐỂ LÀM ĐẸP mà là ĐỂ TĂNG KHẢ NĂNG TỰ KHAI THÁC DỮ LIỆU VÀ THÔNG TIN. Thời đại này với việc chuyển đổi số và nhu cầu khai thác thông tin tăng dần mà anh em cứ chăm chăm đi làm theo cách cũ thì chỉ làm được với quy mô nhỏ thôi chứ đừng nói tưới việc áp dụng AI để đọc insight tự động :))
Mình đưa ra quan điểm cũng các luận điểm để anh em trong cộng đồng cùng trao đổi thảo luận học hỏi lẫn nhau nhé.
Replies
Quỳnh Hoa
Tri Le Duong ụa a đang làm giống thầy Đức nói r còn tag gì nữa
Quỳnh Hoa giống đâu, tag em vào cùng học hỏi 😌
Tri Le Duong a little bit
Đơn giản là tùy trường hợp :d Công cụ BI đem tính khối lượng lớn lăn ra chết thì lại đặt lại câu hỏi hiệu năng, vận hành và bảo trì
thế nó mới sinh ra analytics service để lo vụ data lớn trên BI tool đấy
Lê Nguyễn Anh Minh vấn đề mỗi tội là chi phí nên hầu hết toàn tiết kiệm k dùng chứ mà công ty bảo cho dùng analysis service với cả synapse á =))) tha hồ mà 150 triệu dòng data cũng xử lý ngon
Vương Hà mời chuyên gia
Pham Tan Tai chuyên quần về làm việc đi em trai
Vương Hà haha đang nghỉ trưa mà a
với cái file PBI cỡ này, mỗi lần đặt tay viết hàm cẩn thận vãi chưởng ko thì đi toi mất mấy phút cuộc đời.
Nguyễn Nguyễn Bạn mà làm file PBI thế này thì do chưa biết cách optimize thôi 1 là data lớn phải tinh chỉnh lại bằng Power Query hoặc chọn dùng Data flow hoặc 2 nếu thực sự là tính toán quá nhiều mà nó nở ra thì cân nhắc dùng Analysis Service
Nguyễn Nguyễn vẫn ít mà maximum 100G PPU license lận mà. =))
Nguyễn Nguyễn nhìn thì sợ đấy nhưng vẫn có giải pháp thôi. Tất nhiên là phải đánh giá 1 cách tổng quát xem vấn đề nó là gì thì mới có giải pháp phù hợp được, chưa chắc nặng đã tốn thời gian khi bạn có 1 model đủ tốt, một phương án phân mảnh đủ mạnh thì chẳng có gì là ko có giải pháp cả
gần 2GB 1 file PBI luôn. Sao nặng dữ vậy bạn?
Leo Pham mình có 13tr dòng daily record ở 1 fact, ko tính toán được ở sql nên tính hết ở PBI.
Nguyễn Nguyễn bạn query từ sql 13tr rows luôn hả? Mỗi lần refresh nhanh không?
Leo Pham nghe là thấy lâu rồi, nhưng cũng tùy nếu server nhiều cpu thì sẽ nhanh thôi.
Nói cho hay, vậy đợi cty có 5000 đối tác cùng sử dụng cùng lúc hãy nói chuyện tiếp. Thời 2012 oracle xây OBIEE cũng xây modeling trên 1 server riêng chứ ko phải xây dưới DB. Tuy nhiên bây giờ số lượng doanh nghiệp lớn cỡ xây data model để phục vụ thì khá ít, đa phần 1 doanh nghiệp nhỏ quy tầm 100 nhân sự trở lại rất nhiều. Khả năng tư duy để thuê 1 nhân sự master về BI về làm model , làm vĩ mô không có. Đa phần 90% report ở mức vận hành, theo dõi, thống kê và kiểm soát. Sau khi có các báo cáo đó rồi thì lãnh đạo mới nhờ phân tích đa chiều hơn và tư duy theo các dự đoán định hướng, định lượng. Thời xưa, đa phần nghiệp vụ ko rành về sql về python, mọi thứ excel làm ko được thì phải nhờ IT hỗ trợ. Thời bây giờ làm sql ầm ầm, chỉ cần hiểu sếp muốn gì, khai thác tiêu chí gì, query phát ra rồi, còn lúc đó có muốn kéo pbi để xem insight cho dễ dàng hoặc vận hành cho nó trơn tru hơn thôi. Bản chất vẫn là tính toán, chứ bạn ko có tự đẻ ra được mấy cái thuật toán hay cơ chế nhận định hiệu quả đâu mà bảo rằng trên BI có thể quyết hết, rồi kéo cái đống đó lên cho bên thứ 3 nó ôm dùm, khi nó sập thì ai sẽ là người đi hốt ???
Vân Phạm thời bh sql ầm ầm đó chỉ là góc nhìn của bạn thôi ai bảo anh bh sql ầm ầm mà sql ầm ầm là sql để truy vấn ai trong doanh nghiệp cho làm sql để đọng vào core db đâu mà chỉ cho sql để truy vấn :)))
Bản chất sq cũng không phải là để tính mà để tạo và cấu trúc data, sinh ra data mới và đổi cấu trúc giữa các tầng dữ liệu, bạn dùng sql để tính là tính các yếu tố đơn giản thôi như có nói nếu bảo 1 công thức phức tạp mà đã xem theo 10 góc nhìn khác nhau thì lúc đó a tạo ra 10 cái view hay thế nào? Đồng thời ai nói sql k phải là bên thứ 3 ??
Duc Nguyen server csdl mình làm chủ thì ít nhất mình cũng quản trị được rủi ro. Còn bạn bảo làm data mà ko đc truy vấn về db thì nghe hơi lạ. Cần phân biệt giữa db cho system , db cho ODS, db cho DWH, db cho Datamart của từng phòng ban nghiệp vụ. Bây giờ mô hình doanh nghiệp, phòng ban nào cũng có server lưu trữ csdl của họ, họ tự làm chủ data để bảo mật các vấn đề chuyên môn, họ ko thích cho cái đám IT chọt vào, họ tự quản. Và mục tiêu cuối cùng là đảm bảo cho doanh nghiệp phát triển và đáp ứng nhanh khi có nhu cầu.
Chỉ có bên ngân hàng mới đi bảo nhân viên tự xây db hoặc lấy backup từ IT về làm db thôi anh và mình thấy cách đó là không hợp lý thâmn chí cho nhân viên các phòng data xong. Bảo họ tự tạo 1 version db riêng và quản trị thì ddi ngược theo nguyên tắc centralize management rồi. Nếu làm dúng cách thì IT họ phân quyền vào các db riêng cho phòng của họ và phân user vào các DB phục vụ cho báo cáo và datamart chứ để phòng tự tao db tè file backup r mỗi phòng 1 data riêng thì chắc ngồi đó khớ số thôi cũng toang.
Thế nên mình mới nói sql mà boả a cũng đang học là sql để truy vấn để có khả năng truy vấn vào server được cấp cứ bảo phòng nghiệp vụ tự quản lý tự tạo db là quản lý dạng loa tơ mơ toàn tự dựng bảo riêng k biết cấu trúc db cũng chỉ có lưu data vào đo và lấy ra gọi gì là “ nắm rõ sql” nên hiểu data engineer khác mà dùng sql để làm phân tích khác đố ông nào dám cho 1 ông nghiệp vụ qha r lý db gốc của công ty đấy
Duc Nguyen cũng có 2 quản điểm đó Đức, 1 quản điểm centralize và 1 quan điểm decentralize. Nhưng quan điểm nào thì DB cũng cần được thiết kế mà manage bởi DBA và IT, business user thì chỉ được query ở level cao hơn là data warehouse, data mart để tránh ảnh hưởng đến core db chứ ai cũng vào query được thì sập core DB là chắc chắn. Mà dữ liệu đã lên được DWH và data mart rồi thì phần xử lý trên Power BI trở nên đơn giản và tối ưu. Xu hưởng mấy năm gần đây đã là self-BI rồi, tiến lên dùng DWH và BI tool, không còn quay về làm ad-hoc report bằng sql như trước nữa.
Lê Nguyễn Anh Minh đúng anh em cũng đồng tình với 2 quan điểm đó thực tế e làm với bên bank là toàn decentralize bên It đẩy cho backup xong về các team tự xậy db quản lý nhưng đúng là vai trò nó khác nhau mà em thấy team khác tạo db toàn để lưu bảng rời thôi chứ chưa tính đến việc xây dựng thành 1 cụm db chuẩn may ra nếu team có thêm ông DBA (thường là bank sẽ cho 1 ông DBA vào team giúp quản lý) thì mới ổn được.
Nhưng mà e vẫn nghĩ nếu là decentralize thì nó nên decentralize ở tầng BI hoặc từ Datamart đổ ra để team nghiệp vụ họ quản lý cái model riêng của họ. Học và làm trên BI dễ hơn nhiều ao với việc học để biết làm full trên SQL.
Viết dài dữ em :))
Hoang Dong em ngồi 1 lúc k nghĩ nó cũng dài thế 😂 thôi để nh nội dung trao đổi nghe thảo luận mng khác như nào
mình nghĩ tính tại sql oke hơn vì đưa vào tool nào củng sử dụng đc ko cần viết lại
Bạn co the cho db mẫu của 5000 khach hang ra sao.để phan tich
Lyly Giang 5000 ông này lấy dữ liệu tiêu thụ điện tren công tơ điện và các năng lượng khác như gas, nl mặt trời … từ đó cáp cho các ông đối tác khác xem chứ k phải của 5000 ông khách hàng
