[tieubavuong1312]

Hiện giờ mong muốn của bên trên là họ muốn xem thông tin chi tiết, ví dụ những câu hỏi như kiểu tìm thông tin của các đơn hàng mà được thực hiện bởi khách hàng A, gói cước B, bên thứ 3 là C, mà có hóa đơn được xử lý hoàn tất bằng kiểu D... chứ không phải là aggregation, vd kiểu tìm tổng giá tiền và số lượng đơn hàng của công ty A sử dụng gói cước B, hay tìm tổng số tiền được xuất hóa đơn được sử dụng gói cước B của bên thứ 3 là C....

Sau khi bạn làm được cái này thì sếp của bạn sẽ tiễn bạn đi.

Mình nói thật đấy.

[hninja222]

Originally Posted by tieubavuong1312

Sau khi bạn làm được cái này thì sếp của bạn sẽ tiễn bạn đi.

Mình nói thật đấy.

Có thể giải thích rõ cho mình dc k bác.

Mình thì cảm thấy mấy tool bi và cai gọi là Business Intelligence nó ko phải để làm mấy việc như query data chi tiết, ngay từ đầu mình đã thấy vậy. Nhưng việc họ giao thì mình vẫn phải làm. Bên trên họ và những người khác họ chỉ cần biết là báo cáo thì họ đẩy sang hết thôi. Mình cố gắng làm ra 1 hệ thống làm dc cả 2 việc nhưng e là mình đang cố làm 1 việc ko đúng scope.

Mình đã từng hỏi rõ ông chủ tịch về vụ này, thì ổng bảo là cứ dính đến chữ report thì là việc của bọn mày hết.

[amarifleur]

Originally Posted by hninja222

Có thể giải thích rõ cho mình dc k bác.

Mình thì cảm thấy mấy tool bi và cai gọi là Business Intelligence nó ko phải để làm mấy việc như query data chi tiết, ngay từ đầu mình đã thấy vậy. Nhưng việc họ giao thì mình vẫn phải làm. Bên trên họ và những người khác họ chỉ cần biết là báo cáo thì họ đẩy sang hết thôi. Mình cố gắng làm ra 1 hệ thống làm dc cả 2 việc nhưng e là mình đang cố làm 1 việc ko đúng scope.

Mình đã từng hỏi rõ ông chủ tịch về vụ này, thì ổng bảo là cứ dính đến chữ report thì là việc của bọn mày hết.

Tại vì làm sai công ty thôi, lời khuyên này, nghỉ việc tìm một công ty khác.
Vấn đề của Data warehouse là không phải công ty nào cũng có nhu cầu và không cần nhất thiết phải có data warehouse để làm báo cáo.
Hoặc thay vì đi hỏi nhu cầu có không thì đi làm giải pháp rồi bán như đội này này https://www.holistics.io/ Không quá phức tạp nhưng giải quyết được nhu cầu của doanh nghiệp.
ps : Chi phí của DW có khi chiếm hơn 50% tiền hạ tầng nếu dùng các giải pháp bên ngoài, trước có nói chuyện với thằng này, chi phí đâu tầm hơn 40k$/ năm
https://www.hitachivantara.com/go/pentaho.html.
Sau đấy thì tự build dùng stack của aws (S3, Redshift, Glue)

[hninja222]

Originally Posted by amarifleur

Tại vì làm sai công ty thôi, lời khuyên này, nghỉ việc tìm một công ty khác.
Vấn đề của Data warehouse là không phải công ty nào cũng có nhu cầu và không cần nhất thiết phải có data warehouse để làm báo cáo.
Hoặc thay vì đi hỏi nhu cầu có không thì đi làm giải pháp rồi bán như đội này này https://www.holistics.io/ Không quá phức tạp nhưng giải quyết được nhu cầu của doanh nghiệp.
ps : Chi phí của DW có khi chiếm hơn 50% tiền hạ tầng nếu dùng các giải pháp bên ngoài, trước có nói chuyện với thằng này, chi phí đâu tầm hơn 40k$/ năm
https://www.hitachivantara.com/go/pentaho.html.
Sau đấy thì tự build dùng stack của aws (S3, Redshift, Glue)

Mình đang tính khi mình tròn 3 tháng trong vai trò mới này thì mình sẽ ra ngoài phỏng vấn thử để biết mình đang ở đâu đây. Cũng hơi ngại là giờ cũng cuối năm gần tết, phỏng vấn rồi nghỉ nó cũng khó. Chưa kể dù sao công ty cũng đối xử không tồi với mình từ khi mình mới vào làm fresher, mà giờ mình ngồi ăn lương đều đều nhưng lại chưa đóng góp đc gì mà đã bỏ chạy thì cũng hơi tệ.

Vụ data warehouse có cần hay không thì ngay đầu topic mình đã nhận thức rõ là mình nghi ngờ việc có thực sự cần data warehouse hay ko khi mà mục đích chủ yếu của nó thì công ty mình lại không cần đến. Mình hoàn toàn nhận thức rõ là Spark cũng có thể analytic và report. Data Warehouse với SQL cũng có thể phân tích và làm report... thậm chí 1 mình cũng hiểu luôn Power BI nó là gộp của bộ 3 Power Query, Power Pivot, Power View nghĩa là 1 mình nó hoàn toàn có thể ETL rồi đẻ ra report luôn, khỏi cần mấy thằng kia luôn cũng được. (Mình nói điều này ra mà mấy ông senior tròn mắt, kêu mình "em hiểu sai về Power BI rồi đấy, nó chỉ là công cụ để tạo report thôi, vì anh đã từng thấy người ta xài rồi" )

Vấn đề là bên trên người ta chỉ định mình làm việc đấy, mà mình thì cũng không đủ rành, kinh nghiệm về mấy vụ này để mà tự trả lời cho chính mình cái đó có làm được không, có nên làm không, có đúng scope không, biết đâu nó làm được thật thì sao, biết đâu nó thực sự thuộc scope của mình thì sao => Lại bỏ công ra đọc, nghiên cứu + chạy thử, chứng minh. Chứ đừng nói là đi thuyết phục được người khác nghe mình.

Mình đã và đang đề xuất là dẹp cái tư tưởng đánh đồng report raw data thuần và analytic vào làm 1, vì thực sự là công cuộc này mình cũng đã đi vào ngõ cụt rồi. Chứ câu hỏi những việc như là thống kê số lượng, tổng, trung bình, xu hướng, phân bố của đơn hàng được mua bởi công ty A qua Process B thì mình làm thử thấy cũng ra hết, không có gì đặc biệt. Chỉ có điều đây không phải là cái mà cấp trên họ cảm thấy cần được báo cáo hơn vào ngay lúc này. Mà dù sao mình cũng là người phải làm theo ý họ muốn, ít nhất là trong lúc mình còn đang làm và ăn lương của họ.

[phamhuythang]

Theo mình bác cứ tận dụng cơ hội này nghiên cứu về Kafka và Spark.
Đơn giản nhất là cài Kafka và Kafka connector lên con DB slave để nó stream data về Kafka.
https://debezium.io/documentation/re...sqlserver.html
Sau đó bác sử dụng data từ các topics của Kafka để tổng hợp report.
Đảm bảo rằng những thứ bác nghiên cứu và thực hành như kia sẽ ko bao giờ lãng phí.

[Robin Phan Persie]

Originally Posted by hninja222

Mình đang tính khi mình tròn 3 tháng trong vai trò mới này thì mình sẽ ra ngoài phỏng vấn thử để biết mình đang ở đâu đây. Cũng hơi ngại là giờ cũng cuối năm gần tết, phỏng vấn rồi nghỉ nó cũng khó. Chưa kể dù sao công ty cũng đối xử không tồi với mình từ khi mình mới vào làm fresher, mà giờ mình ngồi ăn lương đều đều nhưng lại chưa đóng góp đc gì mà đã bỏ chạy thì cũng hơi tệ.

Vụ data warehouse có cần hay không thì ngay đầu topic mình đã nhận thức rõ là mình nghi ngờ việc có thực sự cần data warehouse hay ko khi mà mục đích chủ yếu của nó thì công ty mình lại không cần đến. Mình hoàn toàn nhận thức rõ là Spark cũng có thể analytic và report. Data Warehouse với SQL cũng có thể phân tích và làm report... thậm chí 1 mình cũng hiểu luôn Power BI nó là gộp của bộ 3 Power Query, Power Pivot, Power View nghĩa là 1 mình nó hoàn toàn có thể ETL rồi đẻ ra report luôn, khỏi cần mấy thằng kia luôn cũng được. (Mình nói điều này ra mà mấy ông senior tròn mắt, kêu mình "em hiểu sai về Power BI rồi đấy, nó chỉ là công cụ để tạo report thôi, vì anh đã từng thấy người ta xài rồi" )

Vấn đề là bên trên người ta chỉ định mình làm việc đấy, mà mình thì cũng không đủ rành, kinh nghiệm về mấy vụ này để mà tự trả lời cho chính mình cái đó có làm được không, có nên làm không, có đúng scope không, biết đâu nó làm được thật thì sao, biết đâu nó thực sự thuộc scope của mình thì sao => Lại bỏ công ra đọc, nghiên cứu + chạy thử, chứng minh. Chứ đừng nói là đi thuyết phục được người khác nghe mình.

Mình đã và đang đề xuất là dẹp cái tư tưởng đánh đồng report raw data thuần và analytic vào làm 1, vì thực sự là công cuộc này mình cũng đã đi vào ngõ cụt rồi. Chứ câu hỏi những việc như là thống kê số lượng, tổng, trung bình, xu hướng, phân bố của đơn hàng được mua bởi công ty A qua Process B thì mình làm thử thấy cũng ra hết, không có gì đặc biệt. Chỉ có điều đây không phải là cái mà cấp trên họ cảm thấy cần được báo cáo hơn vào ngay lúc này. Mà dù sao mình cũng là người phải làm theo ý họ muốn, ít nhất là trong lúc mình còn đang làm và ăn lương của họ.

Thế nào rồi bạn? Tình hình sáng sủa hơn chưa
Bạn nói chi tiết thêm output ra report cần chi tiết những gì biết đâu mình hay ai đó có giải pháp rõ ràng hơn đấy

[hninja222]

Originally Posted by Robin Phan Persie

Thế nào rồi bạn? Tình hình sáng sủa hơn chưa
Bạn nói chi tiết thêm output ra report cần chi tiết những gì biết đâu mình hay ai đó có giải pháp rõ ràng hơn đấy

À sau đó mình có thảo luận luôn với sếp thì nói chung là mình quyết định là cái hệ thống này sẽ chỉ cung cấp các report mang tính insights, aggregation.

Còn những report mang tính information, raw data không được aggregate lên thì sẽ được giải quyết bằng cách dùng T-SQL query hoặc trực tiếp trên Data Warehouse hoặc query trực tiếp trên database của production nếu như Data Warehouse hiện tại không có. (Do mình thiết kế theo phương thức Top-Down của Kimball nên các datamart sẽ xuất hiện dần dần chứ không phải cái nào cũng có ngay được. Mà yêu cầu thì có thể là bất cứ thứ gì, nên nếu rơi vào trường hợp không có thì vẫn sẽ là query trên DB production.)

Hiện giờ những report mà mình xem là "cung cấp insights" là những report dựa vào aggregation, như tìm ra số lượng đơn hàng và lợi nhuận của các đơn hàng mua điện thoại được của những người mua hàng ở khu vực TP.HCM chẳng hạn. Những report này được tính theo tổng, trung bình, số lượng trên một cái góc nhìn nào đó (mặt hàng điện thoại, khu vực tp.hcm) rồi từ đó đúc rút ra những nhận xét "kiểu người ở TP.HCM hay có khuynh hướng chi nhiều tiền cho điện thoại" chẳng hạn. Rồi trending những tháng gần đây là việc mua điện thoại tăng hay giảm. Có thể là dự đoán nữa.

Còn những report kiểu liệt kê chi tiết đơn hàng được đặt vào ngày 11/10/2019 chẳng hạn, xuất ra đầy đủ thông tin người mua, giá tiền, sản phẩm, giờ mua như dưới đây

Nguyễn Văn A | iPhone 11 | 21.000.000 | 1:00 11/10/2019
Nguyễn Văn B | iPhone 12 | 22.000.000 | 2:00 11/10/2019
Nguyễn Thị C | iPhone 12 | 23.000.000 | 2:00 11/10/2019

Nói chung là những report thông tin chung chung, không được aggregate lên. Đây là kiểu report mà mấy người bên công ty mẹ rất hay yêu cầu. Hiện giờ thì mình quyết định là những report kiểu này không thuộc scope của BI, nếu họ vẫn muốn có thông tin kiểu đó, thì mình sẽ thực hiện theo cách khác và xem nó là nằm ngoài scope.

Nói chung sếp (CEO) mình hiểu sự khác biệt giữa report insights và các report đơn thuần. Chủ yếu là mình ngại mấy người bên công ty mẹ với ông chủ tịt thôi. Mấy người họ thì cứ report là tống sang team BI hết.

________________________

Mấy hôm nay mình nghiên cứu về vụ xử lý clean/transform data bằng Spark, thì có nghiên cứu mấy vụ, chẳng biết là có lạc đề hay không. Là hiện giờ mình cũng tương đối hiểu nếu sử dụng data để làm Analytic thì họ cần data như thế nào. Nhưng nếu cần data để làm machine learning thì họ cần clean data thế nào và transform data ra sao để đổ vào ML model. Nên mình lên Kaggle chơi mấy khóa về... Machine Learning và Deep learning.

Mình chẳng biết bên ngoài họ làm machine learning như thế nào. Nhưng theo như những gì mình xem trên mấy cái course trên Kaggle thì thấy chủ yếu toàn là clean với chế cháo data sao cho phù hợp rồi đổ vào model để train, chứ model gì có sẵn hết, gọi hàm truyền tham số phù hợp tí là xong. Thấy trong bài dạy nó có câu đùa là Data Scientist dành 60% thời gian hàng ngày để clean data và 40% còn lại để phàn nàn về chất lượng data.

Mà quan điểm của mình là mấy vụ chế cháo dataset là việc của Data Engineer cơ.

Lúc đầu mình cứ nghĩ đám làm data scientist phải là đám ngồi nghiên cứu toán học cao siêu để chế ra model ấy. Mà mình xem đến cái course intermediate rồi mà thấy toàn là chế cháo dataset để nhét vào ML model thôi.

[Robin Phan Persie]

Originally Posted by hninja222

À sau đó mình có thảo luận luôn với sếp thì nói chung là mình quyết định là cái hệ thống này sẽ chỉ cung cấp các report mang tính insights, aggregation.

Còn những report mang tính information, raw data không được aggregate lên thì sẽ được giải quyết bằng cách dùng T-SQL query hoặc trực tiếp trên Data Warehouse hoặc query trực tiếp trên database của production nếu như Data Warehouse hiện tại không có. (Do mình thiết kế theo phương thức Top-Down của Kimball nên các datamart sẽ xuất hiện dần dần chứ không phải cái nào cũng có ngay được. Mà yêu cầu thì có thể là bất cứ thứ gì, nên nếu rơi vào trường hợp không có thì vẫn sẽ là query trên DB production.)

Hiện giờ những report mà mình xem là "cung cấp insights" là những report dựa vào aggregation, như tìm ra số lượng đơn hàng và lợi nhuận của các đơn hàng mua điện thoại được của những người mua hàng ở khu vực TP.HCM chẳng hạn. Những report này được tính theo tổng, trung bình, số lượng trên một cái góc nhìn nào đó (mặt hàng điện thoại, khu vực tp.hcm) rồi từ đó đúc rút ra những nhận xét "kiểu người ở TP.HCM hay có khuynh hướng chi nhiều tiền cho điện thoại" chẳng hạn. Rồi trending những tháng gần đây là việc mua điện thoại tăng hay giảm. Có thể là dự đoán nữa.

Còn những report kiểu liệt kê chi tiết đơn hàng được đặt vào ngày 11/10/2019 chẳng hạn, xuất ra đầy đủ thông tin người mua, giá tiền, sản phẩm, giờ mua như dưới đây

Nguyễn Văn A | iPhone 11 | 21.000.000 | 1:00 11/10/2019
Nguyễn Văn B | iPhone 12 | 22.000.000 | 2:00 11/10/2019
Nguyễn Thị C | iPhone 12 | 23.000.000 | 2:00 11/10/2019

Nói chung là những report thông tin chung chung, không được aggregate lên. Đây là kiểu report mà mấy người bên công ty mẹ rất hay yêu cầu. Hiện giờ thì mình quyết định là những report kiểu này không thuộc scope của BI, nếu họ vẫn muốn có thông tin kiểu đó, thì mình sẽ thực hiện theo cách khác và xem nó là nằm ngoài scope.

Nói chung sếp (CEO) mình hiểu sự khác biệt giữa report insights và các report đơn thuần. Chủ yếu là mình ngại mấy người bên công ty mẹ với ông chủ tịt thôi. Mấy người họ thì cứ report là tống sang team BI hết.

________________________

Mấy hôm nay mình nghiên cứu về vụ xử lý clean/transform data bằng Spark, thì có nghiên cứu mấy vụ, chẳng biết là có lạc đề hay không. Là hiện giờ mình cũng tương đối hiểu nếu sử dụng data để làm Analytic thì họ cần data như thế nào. Nhưng nếu cần data để làm machine learning thì họ cần clean data thế nào và transform data ra sao để đổ vào ML model. Nên mình lên Kaggle chơi mấy khóa về... Machine Learning và Deep learning.

Mình chẳng biết bên ngoài họ làm machine learning như thế nào. Nhưng theo như những gì mình xem trên mấy cái course trên Kaggle thì thấy chủ yếu toàn là clean với chế cháo data sao cho phù hợp rồi đổ vào model để train, chứ model gì có sẵn hết, gọi hàm truyền tham số phù hợp tí là xong. Thấy trong bài dạy nó có câu đùa là Data Scientist dành 60% thời gian hàng ngày để clean data và 40% còn lại để phàn nàn về chất lượng data.

Mà quan điểm của mình là mấy vụ chế cháo dataset là việc của Data Engineer cơ.

Lúc đầu mình cứ nghĩ đám làm data scientist phải là đám ngồi nghiên cứu toán học cao siêu để chế ra model ấy. Mà mình xem đến cái course intermediate rồi mà thấy toàn là chế cháo dataset để nhét vào ML model thôi.

Không phải ý gì đâu nhưng trước mình có làm tí liên quan tới nhà nước, những dự án vẽ ra cần đủ đáp ứng Use cases là được thì sếp k khắt khe đâu, nên để bạn thoải mái phóng tác vậy

Còn mình có tí kinh nghiệm trước làm việc với SAP về BI viết ra nếu ai cần có thể tham khảo
- Đầu tiên làm về data lớn thì đa luồng là việc tận dụng tối đa, VD như 1 bảng có 100 tỉ bản ghi, VD đơn thuần bạn cần báo cáo doanh số theo tháng, khó có thể viết nhiều query chạy cùng lúc trên 1 bảng cùng 1 thời điểm, hay không thể lấy 100 tỉ bản ghi về ram rồi chạy 100000 threads để tổng hợp số liệu. Bên mình trước đây, sau khi ETL thì băm luôn ra, lưu vào DW 1 bảng đủ 100 tỉ bản ghi là bản gốc, song song với đó ghi động ra N (100) bảng, mỗi bảng 1 tỉ bản ghi, sau đó chạy query trên 100 bảng này, sau đó query trên 100 results. Tốc độ nhanh hơn cả nghìn lần. Mỗi tội mua licence của SAP bản có 10 core, nên chạy được có 10 luồng , Để băm được ra N bảng này thì bạn phải tổng hợp xem tất cả các báo cáo bạn cần xuất ra có thể chia làm bao nhiêu loại, từ đó tổng hợp 1 query tổng có thể lấy dữ liệu 1 lần cho nhiều reports nhất có thể, sau đó ghi ra bảng dành cho Reports, sau này các reports chỉ query vào đây, không bao giờ động vào dữ liệu lớn. À xử lý xong nhớ xóa hết N bảng tạm kia đi

Còn những report kiểu liệt kê chi tiết đơn hàng được đặt vào ngày 11/10/2019 chẳng hạn, xuất ra đầy đủ thông tin người mua, giá tiền, sản phẩm, giờ mua như dưới đây

Nguyễn Văn A | iPhone 11 | 21.000.000 | 1:00 11/10/2019
Nguyễn Văn B | iPhone 12 | 22.000.000 | 2:00 11/10/2019
Nguyễn Thị C | iPhone 12 | 23.000.000 | 2:00 11/10/2019

Làm reports bao giờ họ cũng cần details mà, những dữ liệu kiểu này khi chạy dữ liệu tổng hợp bạn cũng quăng ra luôn 1 bảng phẳng, lưu tất cả thông tin để hiển thị, không cần relationship hay bất cứ thứ gì hết, có thể chia bảng ra theo tháng hay theo năm nếu dữ liệu lớn, sau này khi get bạn query động theo tháng hay năm user đưa ra, đừng đề dữ liệu 1 bảng bị phình to
Nếu các sếp yêu cầu realtime nhất có thể, thì dữ liệu chạy tổng hợp ra được bạn vất vào 1 góc, dữ liệu mới chưa được tổng hợp vất vào 1 góc, sau đó union đống data đấy. Cứ khi nào chạy tổng hợp thì lại xóa đống dữ liệu tạm này đi. Đừng query trên production db, không ổn đâu, định kỳ lấy data vào đống dữ liệu tạm mình bảo ấy, thay đổi nhiều thì 5 phút hay 3 phút hay 1 phút đồng bộ 1 lần, 1 lần đồng bộ bạn có thể phục vụ cho cả trăm thằng vào lấy BC, query trên product db sẽ ảnh hưởng tới người dùng, hơn nữa tốc độ cũng bị chậm hơn dùng ở bảng tạm.

Nhớ xử lý partition, index các kiểu cho khéo vào nhé, config cho bảng nào ưu tiên đọc/ghi, bảng nào cần thì dùng memory table luôn, nhũng thứ config này tùy thằng bạn dùng nó hỗ trợ tới đâu nên mình cũng không dám chém

[hninja222]

Originally Posted by phamhuythang

Theo mình bác cứ tận dụng cơ hội này nghiên cứu về Kafka và Spark.
Đơn giản nhất là cài Kafka và Kafka connector lên con DB slave để nó stream data về Kafka.
https://debezium.io/documentation/re...sqlserver.html
Sau đó bác sử dụng data từ các topics của Kafka để tổng hợp report.
Đảm bảo rằng những thứ bác nghiên cứu và thực hành như kia sẽ ko bao giờ lãng phí.

Ừ, hiện giờ mình đang đẩy mạnh mảng Spark + Python để có gì có thể tiến hóa lên Machine Learning luôn. Còn cái Kafka thì hiện giờ công ty mình chưa có nhu cầu về real-time analytics nên Kafka mình chỉ tìm hiểu nó làm cái gì và mô hình sử dụng nó như thế nào để sẵn sàng sử dụng khi có đề xuất thôi.

À mà cho mình hỏi 1 chút, cái con DB Slave là sao nhỉ. Theo mình đọc từ này thì tưởng tượng ra trong con SQL Server sẽ có 1 bộ phận listener lắng nghe tất cả các các thay đổi trong DB, rồi sau đó ghi thay đổi đó vào Kafka.

Trước đến giờ theo mình hiểu thì cái đường data pipeline về Kafka nó sẽ là thế này cơ: Web application mỗi khi xử lý gì đó thì thường thường sẽ ghi lại log đúng không, thì nó sẽ đồng thời gọi hàm kết nối vào Kafka ghi luôn cái đó vào 1 topic vào Kafka, thậm chí là thay thế luôn kiểu ghi file log truyền thống luôn. Chứ nếu mà là kĩ thuật DB listener như trên mình chưa biết đến luôn.

Rồi mình có thể dùng Storm hoặc SparkStreaming để ghi can thiệp topic. Rồi phân tích hoặc ghi cái đó ra chỗ khác.

Mình nói đúng không nhỉ, vì cái này mình chỉ đọc thôi chứ chưa bắt tay vô làm thật cái này.

Originally Posted by Robin Phan Persie

Không phải ý gì đâu nhưng trước mình có làm tí liên quan tới nhà nước, những dự án vẽ ra cần đủ đáp ứng Use cases là được thì sếp k khắt khe đâu, nên để bạn thoải mái phóng tác vậy

Còn mình có tí kinh nghiệm trước làm việc với SAP về BI viết ra nếu ai cần có thể tham khảo
- Đầu tiên làm về data lớn thì đa luồng là việc tận dụng tối đa, VD như 1 bảng có 100 tỉ bản ghi, VD đơn thuần bạn cần báo cáo doanh số theo tháng, khó có thể viết nhiều query chạy cùng lúc trên 1 bảng cùng 1 thời điểm, hay không thể lấy 100 tỉ bản ghi về ram rồi chạy 100000 threads để tổng hợp số liệu. Bên mình trước đây, sau khi ETL thì băm luôn ra, lưu vào DW 1 bảng đủ 100 tỉ bản ghi là bản gốc, song song với đó ghi động ra N (100) bảng, mỗi bảng 1 tỉ bản ghi, sau đó chạy query trên 100 bảng này, sau đó query trên 100 results. Tốc độ nhanh hơn cả nghìn lần. Mỗi tội mua licence của SAP bản có 10 core, nên chạy được có 10 luồng , Để băm được ra N bảng này thì bạn phải tổng hợp xem tất cả các báo cáo bạn cần xuất ra có thể chia làm bao nhiêu loại, từ đó tổng hợp 1 query tổng có thể lấy dữ liệu 1 lần cho nhiều reports nhất có thể, sau đó ghi ra bảng dành cho Reports, sau này các reports chỉ query vào đây, không bao giờ động vào dữ liệu lớn. À xử lý xong nhớ xóa hết N bảng tạm kia đi


Làm reports bao giờ họ cũng cần details mà, những dữ liệu kiểu này khi chạy dữ liệu tổng hợp bạn cũng quăng ra luôn 1 bảng phẳng, lưu tất cả thông tin để hiển thị, không cần relationship hay bất cứ thứ gì hết, có thể chia bảng ra theo tháng hay theo năm nếu dữ liệu lớn, sau này khi get bạn query động theo tháng hay năm user đưa ra, đừng đề dữ liệu 1 bảng bị phình to
Nếu các sếp yêu cầu realtime nhất có thể, thì dữ liệu chạy tổng hợp ra được bạn vất vào 1 góc, dữ liệu mới chưa được tổng hợp vất vào 1 góc, sau đó union đống data đấy. Cứ khi nào chạy tổng hợp thì lại xóa đống dữ liệu tạm này đi. Đừng query trên production db, không ổn đâu, định kỳ lấy data vào đống dữ liệu tạm mình bảo ấy, thay đổi nhiều thì 5 phút hay 3 phút hay 1 phút đồng bộ 1 lần, 1 lần đồng bộ bạn có thể phục vụ cho cả trăm thằng vào lấy BC, query trên product db sẽ ảnh hưởng tới người dùng, hơn nữa tốc độ cũng bị chậm hơn dùng ở bảng tạm.

Nhớ xử lý partition, index các kiểu cho khéo vào nhé, config cho bảng nào ưu tiên đọc/ghi, bảng nào cần thì dùng memory table luôn, nhũng thứ config này tùy thằng bạn dùng nó hỗ trợ tới đâu nên mình cũng không dám chém

Dữ liệu của bác lớn ghê nhỉ, chứ hệ thống của mình thì dữ liệu chỉ đến tầm triệu ở các bảng fact chính và chục triệu ở bảng fact phụ là cùng thôi.

Không biết bác dùng cái gì để query chứ bên mình xài stack của Microsoft có Analysis Services Tabular model làm mấy cái aggregate ở dữ liệu test cứ gọi là nhanh như điện xẹt luôn. Mình khảo sát dữ liệu ở production và test thì production chỉ hơn test 2, 3 lần thôi. Nên nếu không có gì bất thường và công ty chấp nhận xài 1 gói cước chấp nhận được cỡ gói hạng 10 hạng 9 trên tổng cộng 12 thôi) thì mình nghĩ sẽ không có bất cứ vấn đề gì về performance cả.

Cái vụ query detail, chủ yếu là do mình dùng cái Analysis Services nó rất mạnh phần aggregate, cực nhanh lại gần như auto, rất dễ dùng cho người không biết tech xài, nhưng vụ query detailed data thì rất hạn chế (cũng chính do mấy cái auto này). Nói chung mình cũng nghĩ đến giải pháp của bác là ủi 1 cái table join sẵn hết những detail cần thiết hết vào (Nhưng cũng chỉ thể ủi được những thông tin chính nhất vào thôi ). Khi làm flat table như thế này thì Analysis Service nó có thể query detail khá OK, chủ yếu nó chỉ tạch khi join để lấy detail từ nhiều bảng, do cơ chế của Analysis Services này nó tự động dựa trên hướng của filter propagation, chưa kể mấy cái trò Auto-Exists và Empty Row removal của nó khiến việc query phải nói là khá khó khăn thôi (Vì mấy cái chức năng này nó sinh ra để phục vụ cho aggregate tự động).

________________________

À mình bổ sung thêm 1 cái, là vấn đề hiện giờ của mình, ít nhất là với cái data warehouse và tabular model test đang được host trên cái PC ghẻ của mình thì vấn đề không phải là có tạo được report BI cần thiết hay không, hay performance của chúng (Vì mình test đều OK hết, performance của aggregation gần như ngay lập tức), mà chủ yếu vấn đề hiện tại của mình là hòa hợp được lý thuyết thiết kế và yêu cầu thực tế. Có những yêu cầu, thậm chí chỉ là do lo ngại "người dùng có thể hiểu nhầm", khiến cho thiết kế của mình chệch đi so với lí thuyết thiết kế. Hay là BI có thực sự là làm về những report này hay không. Hay là thiết kế kiểu này hiện tại tuy chạy được, chậy nhanh nhưng tương lai sẽ ra sao.... Hay có những bảng fact được set ở grain thấp nhất cho đúng lý thuyết thiết kế, nhưng lại rất vô nghĩa, vì người ta chỉ quan tâm đến fact của grain cao hơn, làm cho mình còn phải... allocate fact ngược xuống grain thấp hơn với công thức rất ngớ ngẩn là .... chia trung bình, do không thể tìm ra công thức cụ thể.

Những sự bất cập giữa lý thuyết thiết kế và nhu cầu thực tế, mong muốn của người dùng và tên gọi của hệ thống thực sự mới là vấn đề khiến mình đau đầu nhất hiện tại trong giai đoạn thiết kế prototype này.

[Robin Phan Persie]

Originally Posted by hninja222

Dữ liệu của bác lớn ghê nhỉ, chứ hệ thống của mình thì dữ liệu chỉ đến tầm triệu ở các bảng fact chính và chục triệu ở bảng fact phụ là cùng thôi.

Không biết bác dùng cái gì để query chứ bên mình xài stack của Microsoft có Analysis Services Tabular model làm mấy cái aggregate ở dữ liệu test cứ gọi là nhanh như điện xẹt luôn. Mình khảo sát dữ liệu ở production và test thì production chỉ hơn test 2, 3 lần thôi. Nên nếu không có gì bất thường và công ty chấp nhận xài 1 gói cước chấp nhận được cỡ gói hạng 10 hạng 9 trên tổng cộng 12 thôi) thì mình nghĩ sẽ không có bất cứ vấn đề gì về performance cả.

Cái vụ query detail, chủ yếu là do mình dùng cái Analysis Services nó rất mạnh phần aggregate, cực nhanh lại gần như auto, rất dễ dùng cho người không biết tech xài, nhưng vụ query detailed data thì rất hạn chế (cũng chính do mấy cái auto này). Nói chung mình cũng nghĩ đến giải pháp của bác là ủi 1 cái table join sẵn hết những detail cần thiết hết vào (Nhưng cũng chỉ thể ủi được những thông tin chính nhất vào thôi ). Khi làm flat table như thế này thì Analysis Service nó có thể query detail khá OK, chủ yếu nó chỉ tạch khi join để lấy detail từ nhiều bảng, do cơ chế của Analysis Services này nó tự động dựa trên hướng của filter propagation, chưa kể mấy cái trò Auto-Exists và Empty Row removal của nó khiến việc query phải nói là khá khó khăn thôi (Vì mấy cái chức năng này nó sinh ra để phục vụ cho aggregate tự động).

Ngon thế, dữ liệu k quá lớn làm thế nhàn hẳn, nhẹ đầu, lại hạn chế cực nhiều lỗi. Bọn mình trước team phase 1 dùng tool tự động nhiều cuối cùng chạy mất 3 tiếng cho 1 lần tổng hợp dữ liệu cho 1 ngày, false quá nên phase sau team mình viết tay hết, kết quả chạy mất 15p, chạy nhanh hơn nhưng code khổ thêm nhiều
Sau project này thì mạnh dạn x3 lương nhé mai fen