Tình hình là mình muốn tìm hiểu sâu hơn về Datawarehouse mà chưa có roadmap cụ thể nào. Bro nào có kinh nghiệm cho mình xin roadmap hoặc các course (paid) với.
Role hiện tại của mình là BA + DA
Role hiện tại của mình là BA + DA
thắc mắc Course Datawarehouse
Trang 1/1
Hóng.
Role DA+BA chính xác là việc gì nhỉ. Trong mắt mình thì Business Analyst là người làm cầu nối giữa khách hàng và team Dev, còn DA là người đọc data ra insight, trend, đưa ra nhận định, hỗ trợ quyết định... 2 cái này với mình không giống nhau lắm. Mà bạn muốn làm về Datawarehouse thì bạn muốn làm như Data Engineer xây hệ thống hay vẫn tiếp tục làm ở tầng phân tích data như là 1 Data Analyst?
Mình đang làm cho team Data của 1 công ty, cũng đang làm hệ thống data warehouse theo cách mà bọn mình hiểu từ tài liệu và nhu cầu của công ty. Công ty mình cỡ nhỏ thôi, cũng chỉ mới làm đc khoảng 1 năm, bọn mình xây từ đầu, nhu cầu cũng có đặc thù riêng, có thể nó sẽ không giống các chỗ khác, bạn có thể tham khảo.
Bọn mình làm stack của microsoft, theo mô hình Modern data warehouse.
https://azure.microsoft.com/en-in/solutions/architecture/modern-data-warehouse/
Trước hết thì mình nghĩ cái phải hiểu đầu tiên là, tôn chỉ của cái hệ thống modern data warehouse này là giúp cho các analyst làm việc dễ với data thoải mái và dễ dàng hơn. Analyst có thể là bất cứ ai, từ analyst chuyên lẫn bất cứ 1 ai đó trong công ty cần đọc data để đưa ra quyết định. Analyst chỉ cần làm việc với PowerBI hoặc sâu hơn sẽ là Databricks Spark, tất cả những việc còn lại như gom nhận data, lưu data dạng thô, clean, transform, model data sẵn cho việc analyze, xây semantic model & aggregation engine của tầng serve sẽ do Data Engineer làm.
Sau đó mình nghĩ bạn sẽ cần hiểu data dc tổ chức như thế nào thì analyst mới dùng được, dùng nhanh, dùng dễ dàng, có khả năng bảo trì, có khả năng scale, có thể lưu trữ tốt. Đây là data modeling. Với 1 hệ thống analytic thì có thể model theo flat table hoặc dimensional modeling. Có một số thứ, một số trường hợp dimensional modeling làm tốt hơn flat table và ngược lại.
Sau khi bạn biết được cách model khiến data dùng được rồi, bạn sẽ học các kĩ thuật đi gom, làm sạch và chỉnh sửa data sao cho data đó về dạng mà bạn đã model. Có trường hợp bạn sẽ được access trực tiếp vào database để lấy giữ liệu (nếu là hệ thống trong công ty), nhưng cũng có khi bạn sẽ phải đi crawl web. Bạn gom xong rồi thì dùng công nghệ tùy nhu cầu để làm sạch và biến đổi data gom đc thành dạng chuẩn model (SQL, Spark hoặc 1 tool nào đó tùy bạn....). Một khi bạn gom đc data thành dạng chuẩn vô trong tầng model rồi, bạn đẩy data qua tầng serve (trong cái mô hình trên thì là analysis services) xong thì bạn đã có được một hệ thống data chạy được, tầng report cứ chọc vào Analysis Service xài là xong.
Sau đó phải hiểu cách mà từng cái thành phần trong cái mô hình trên nó hoạt động thế nào, rồi tinh chỉnh dần dần sao cho nó chạy đúng, nhanh, tiết kiệm, hiệu quả nhất, có khả năng scale, maintain, phát triển thêm.....
Mình đang làm cho team Data của 1 công ty, cũng đang làm hệ thống data warehouse theo cách mà bọn mình hiểu từ tài liệu và nhu cầu của công ty. Công ty mình cỡ nhỏ thôi, cũng chỉ mới làm đc khoảng 1 năm, bọn mình xây từ đầu, nhu cầu cũng có đặc thù riêng, có thể nó sẽ không giống các chỗ khác, bạn có thể tham khảo.
Bọn mình làm stack của microsoft, theo mô hình Modern data warehouse.
https://azure.microsoft.com/en-in/solutions/architecture/modern-data-warehouse/
Trước hết thì mình nghĩ cái phải hiểu đầu tiên là, tôn chỉ của cái hệ thống modern data warehouse này là giúp cho các analyst làm việc dễ với data thoải mái và dễ dàng hơn. Analyst có thể là bất cứ ai, từ analyst chuyên lẫn bất cứ 1 ai đó trong công ty cần đọc data để đưa ra quyết định. Analyst chỉ cần làm việc với PowerBI hoặc sâu hơn sẽ là Databricks Spark, tất cả những việc còn lại như gom nhận data, lưu data dạng thô, clean, transform, model data sẵn cho việc analyze, xây semantic model & aggregation engine của tầng serve sẽ do Data Engineer làm.
Sau đó mình nghĩ bạn sẽ cần hiểu data dc tổ chức như thế nào thì analyst mới dùng được, dùng nhanh, dùng dễ dàng, có khả năng bảo trì, có khả năng scale, có thể lưu trữ tốt. Đây là data modeling. Với 1 hệ thống analytic thì có thể model theo flat table hoặc dimensional modeling. Có một số thứ, một số trường hợp dimensional modeling làm tốt hơn flat table và ngược lại.
Sau khi bạn biết được cách model khiến data dùng được rồi, bạn sẽ học các kĩ thuật đi gom, làm sạch và chỉnh sửa data sao cho data đó về dạng mà bạn đã model. Có trường hợp bạn sẽ được access trực tiếp vào database để lấy giữ liệu (nếu là hệ thống trong công ty), nhưng cũng có khi bạn sẽ phải đi crawl web. Bạn gom xong rồi thì dùng công nghệ tùy nhu cầu để làm sạch và biến đổi data gom đc thành dạng chuẩn model (SQL, Spark hoặc 1 tool nào đó tùy bạn....). Một khi bạn gom đc data thành dạng chuẩn vô trong tầng model rồi, bạn đẩy data qua tầng serve (trong cái mô hình trên thì là analysis services) xong thì bạn đã có được một hệ thống data chạy được, tầng report cứ chọc vào Analysis Service xài là xong.
Sau đó phải hiểu cách mà từng cái thành phần trong cái mô hình trên nó hoạt động thế nào, rồi tinh chỉnh dần dần sao cho nó chạy đúng, nhanh, tiết kiệm, hiệu quả nhất, có khả năng scale, maintain, phát triển thêm.....
datawarehouse ? Bác mún lấn qua Data Engineer luôn à
Mình là dạng IT BA có technical skills ấy.
Hơn 1 năm nay thì học và làm sâu hơn vào DA.
Cái này hôm bữa sếp mình cũng present cho xem, nói là nghiên cứu thêm đi vì tương lai gần sẽ có đất dùng.
Mình cũng mới đọc về databricks, chính nó đó bác
Đến chỗ này là mình cảm thấy nhiều nhiều rồi.
Thank bác đã chỉ dẫn
Cái này hôm bữa sếp mình cũng present cho xem, nói là nghiên cứu thêm đi vì tương lai gần sẽ có đất dùng.
Mình cũng mới đọc về databricks, chính nó đó bác
Đến chỗ này là mình cảm thấy nhiều nhiều rồi.
Thank bác đã chỉ dẫn
Mình tưởng chỉ có công ty mình mới dùng mô hình của Microsoft thôi chứ, thấy bên ngoài tuyển dụng toàn thấy dùng stack của Google với Amazon, mình cũng chẳng biết mô hình của họ thế nào.
Kinh nghiệm của team mình, team từ tờ giấy trắng đi lên, ko có người hướng dẫn, lãnh đạo họ chỉ nói nhu cầu là "muốn kiểm soát công ty tốt hơn", lúc đầu nó mù mờ khủng khiếp, bọn mình thậm chí chẳng hiểu analytic là gì....
- Sau đó một thời gian thì hiểu được analytic thực sự là gì, chính là "tổng hợp data dựa trên các góc nhìn khác nhau".
- Sau đó tiếp tục hiểu được một câu query thế nào là một câu query có tính analytic?: "Filter - Group By - Sum/Count/AVG/Min/Max"
- Sau đó hiểu được Modeling data thế nào để nhìn được data trên các góc nhìn khác nhau: Dimensional modeling/Flat table
Thi khi đó chẳng còn ách tắc gì nữa hết, SQL database, Analysis Services, PowerBI, Databricks, Data Lake tìm tòi học hỏi tí là hiểu, rồi quen tay, chẳng có gì khó khăn. Vì nói cho cùng mấy tool trên quy hết về là để phục vụ các tôn chỉ trên, biết được mục đích mình thực sự phải làm gì để đến đích thì việc gồng sức chạy chỉ là chuyện nhỏ. Đáng sợ nhất với mình là quãng thời gian mới bắt đầu mơ hồ, sức thì thừa nhưng chẳng biết chạy về hướng nào....
Mình thì chuyên về SQL query với PBI, sếp bảo học thêm databricks mà tìm hiểu nó có xu hướng phục vụ công việc của Data Engineer nhiều hơn nên cũng hơi lưỡng lự.
Cái khó nhất của Analytic với mình là tìm được Metrics để phản ánh insight của Data.
Cái databricks này nếu là Engineer thì họ dùng để biến đổi data từ dạng gốc sang dạng mong muốn rồi ghi vào data warehouse. Còn nếu là analyst thì họ dùng cái này để query, groupby, aggregate tính toán kết quả rồi visualize. Cũng chả khác gì SQL ở SQL server mấy, kết quả mục đích đầu ra cũng vậy, khác biệt ở cái cách tiếp cận là distributed computing, nghĩa là dùng rất nhiều máy để xử lý 1 tập data. Và làm sao để phân nhiệm vụ, điều khiển, quản lý các máy con, tổng hợp kết quả từ máy con lên chính là nhiệm vụ của mấy cái distributed computing cluster như Databricks Spark này.
Tất nhiên là Databricks Spark này nó có một số thư viện khác như Structured Streaming, GraphFrame, MLLib, hay các thư viện bên Python.... Bạn có thể dùng nó để làm 1 số việc khác mà SQL trên SQL Server ko làm được.
_________________
Cái metric của bạn ý là kiểu tìm ra 1 con số nào để nhìn thấy bản chất của vấn đề đúng ko, kiểu như dịch Corona, một nước tuy có số nhiễm rất cao nhưng chưa chắc đã nguy hiểm, vì số cao nhiễm cao là do xét nghiệm nhiều, nên chỉ dùng con số tổng số ca nhiễm là chưa phản ánh đúng thực trạng. Ý là cái này phải ko nhỉ.
Nếu mà là cái này thì analyst bên mình cũng bị nhiều, cũng họp bàn thảo luận tranh cãi ko ít. Mình engineer cũng bị lôi vào không ít.
Reactions:
hieu and JUchi