![]() |
|
Thread Tools |
#21
|
|||
|
|||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
Mình nói thật đấy.
__________________
Quote:
Code:
I can type 15 languages but 12 of them can only be understood by computer! |
#22
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
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. ![]() Last edited by hninja222; 29-09-2019 at 16:46. |
#23
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
![]() 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/ ![]() 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) |
#24
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
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. ![]() Last edited by hninja222; 29-09-2019 at 18:59. |
#25
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
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í. |
#26
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
![]() 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 |
#27
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
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. ![]() 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. ![]() |
#28
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
![]() 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 ![]() ![]() Quote:
![]() 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 ![]() |
#29
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
À 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. ![]() Quote:
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 ![]() ![]() ________________________ À 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. ![]() Last edited by hninja222; 15-10-2019 at 14:02. |
#30
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
Sau project này thì mạnh dạn x3 lương nhé mai fen ![]() |
![]() |
Thread Tools | |
|
|