![]() |
|
Thread Tools |
#11
|
|||
|
|||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
![]() Không có ai hướng dẫn bài bản nên tự bơi hơi mệt ![]()
__________________
Món ngon, deal chất! https://www.meete.co/ |
#12
|
|||
|
|||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
Quote:
Kafka thì cũng ko bắt buộc. Đừng có đi nghe mấy cái tech talk hay facebook chém gió của các Architect tự phong ở VN làm gì. Chủ thớt nên tìm hiểu cách collect, tranform và load data. Cách kết hợp giữa Relation Database và NoSQL. Cách xử lý raw data, clean data, processed data, aggregated data, summarized data, visualized data. Mỗi một domain (fintech, e-com, iot,..) sẽ khác nhau nên cần hiều rõ domain mình đang làm và define được schema data, cần dimension, metrics gì. Đừng quan tâm gì lắm đến Azure, AWS, GCP, Kafka,....khi hiểu được mấy cái kia rồi thì sẽ biết dùng cái gì cho mục đích gì. Azure/AWS/GCP nó đều support hết nên nếu sếp thích dùng hãng nào thì cứ làm trên stack đó thôi, khi nào cần thì lại migrate qua stack khác. Last edited by _sharp_; 23-08-2019 at 22:41. |
#13
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
BI dùng tool gì thế thím? PowerBI hả?
|
#14
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
bookmark
![]() |
#15
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
![]() Quote:
![]() Cho mình hỏi một số thứ như chính xác thì mấy cái như extract/collect, transform, load raw data, clean data, aggreate data là gì. Vì mình ko dám chắc là mình hiểu đúng. Transform có phải là đồng hóa model của các data giữa các nguồn dữ liệu với nhau, rồi thống nhất tên tuổi (ví dụ tên người có nguồn nó ghi là Mr. A còn có nguồn nó chỉ ghi mỗi A, thì transform cho chúng thành 1 dạng đồng nhất, vd thành A hết chẳng hạn), rồi parse vd date 1-1-2001 thành 01012001 cho nó thành 1 cái ID để match với bảng DIM_Date? Clean/Verify data mình chưa hiểu cần phải làm ngay sau khi extract hay transform rồi mới làm. Hay được làm trước khi load vào data warehouse? Clean, Verify có phải là các hành động kiểu như "nếu dòng nào trong bảng user chuẩn bị vào data warehouse có tuổi <=-1 thì đó là dữ liệu rác và phải loại dòng đó ra không được đưa vào data warehouse" ? Những hành động kiểu như tìm ra SurrogateKey tương ứng trong các bảng DIM trong Data Warehouse để điền vào các dữ liệu fact mới, những cái này được thực hiện khi load hay khi transform? Hiện giờ mình đang làm thử thì mình vừa load (INSERT INTO) (hiện giờ mình làm hoàn toàn bằng SQL Stored Procedure, vì mình chưa tự tin vào Spark Databricks) thì vừa transform CASE WHEN SELECT Staging trên cái lệnh insert into đó luôn. Cách làm này là đúng hay sai và nếu sai thì mình nên làm như thế nào mới là đúng nhất? Làm việc với raw data có phải là dùng Spark để đọc các file semi-structured data file như JSON, XML, hoặc unstructured data (như text file, dùng regular expression để parse), aggregate rồi ghi kết quả aggregate vào data warehouse, còn dữ liệu raw thì lưu giữ ở 1 cái Data Lake để khi cần query nâng cao phức tạp chi tiết thì chọc Spark vào query? Aggregate Data có phải là những thứ theo kiểu ví dụ. 1:05 AM | 2 1:15 AM | 1 1:40 AM | 3 2:25 AM | 3 2:35 AM | 1 3:01 AM | 1 Thì Aggregate thành 1:00~2:00 | 6 2:00~3:00 | 4 3:00~4:00 | 1 Mà nếu làm thế này thì théo bác nên nên tạo bảng tính sẵn ở Data Warehouse, hay là tận dụng semantic model (OLAP) để tính? Rất mong bác giải đáp các thắc mắc của mình ![]() |
#16
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Em background kinh tế ,mới học 1 khóa ngắn hạn Data Analyst, biết cơ bản SQL và Python.
Pro nào ở HN nhận fresher intern thì cíu vớt em với ![]() ![]() |
#17
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Quote:
- Transform cũng có thể hiểu là DW có structure khác với OTLP và các hệ thống khác, vì vậy cần "biến đổi" dữ liệu từ các nguồn nói trên và load đúng structure vào DW. - Theo đúng chuẩn thì việc clean/validate data phải nằm ở bước đầu tiên, từ lúc triển khai hệ thống chứ không phải ở bước triển khai DW hay BI. Nhưng trên thực tế các system đều như CC (đăc biệt là ở VN) nên mới sinh ra trò clean/validate ở đây. Bạn không giải quyết dứt điểm vấn đề trên core, không có Data Governance thì DW của bạn khác đ' gì cái máy dọn rác. Nếu bắt buộc phải dùng clean/validate thì nó xảy ra ở process Transform, vì việc của Load chỉ nên là Load. Nói thêm thì các Cty chuyên về BI ở EU, US thường không (hoặc rất ít khi) làm clean data, mà client phải chủ động làm việc này. Cũng chính vì thế mà các system ở VN thường ít/hầu như không có các giải pháp BI từ các thị trường trên. - Xử lý SurrogateKey / raw data thì tùy thuộc vào business. Trên BI không quan tâm raw data, cần thiết vào DW mà lấy. - Aggregate Data đơn giản là các dữ liệu đã được tính toán và tổng hợp từ trước. Ví dụ của bạn tạm chấp nhận được mặc dù nhìn nó buồn cười vl ![]() DW, BI... nặng về methodology. Trừ những ngành đặc thù đã có sẵn vài model chuẩn như Banking, Finance, Insurance, Medical... thì tùy bài toán, yêu cầu… từng người sẽ có exp và solution riêng nên khó chia sẻ mà cũng chẳng có đúng vs sai.
__________________
M.Eng MEBF CFA ACCA OCP MCSE CEPP PMP CDMP Last edited by Blanic; 29-08-2019 at 14:16. |
#18
|
||
|
||
Re: Page 2 - Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Bên mình thấy team data có xử dụng kafka nè.
__________________
Nick xin được |
#19
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Đội data warehouse big data ở bank thấy nghiên cứu mãi mà chưa ra sp gì
Gửi từ Xiaomi Redmi Note 7 bằng vozFApp |
#20
|
||
|
||
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.
Mấy ngày hôm nay mình rơi vào trạng thái cực kì bế tắc các bác à. Mình không biết mình có đang đi sai hướng không nữa, solution toàn hệ thống BI hiện giờ đụng vào đâu cũng có những vấn đề mà mình nghĩ mãi cũng giải quyết nổi. Công việc thì gần như mình làm 1 mình ko có support, tiền nghiên chạy thử dịch vụ cloud công ty cũng chẳng thèm cho luôn, nhưng lại đòi hỏi đủ mọi trò. Đang rất nản muốn kiếm 1 nơi khác có người giỏi có kinh nghiệm guide được mình và nghiêm túc muốn thực hiện những hệ thống kiểu này, nhưng giờ cũng cuối năm rồi đi đứng gì cũng khó.
![]() Một trong những vấn đề là: Mục tiêu của mình là xây dựng một hệ thống query thông tin chi tiết và aggregation dễ nhất có thể cho tất cả các thành phần từ có hiểu biết lẫn không hiểu biết đều có thể thực hiện được mà không cần có sự trợ giúp của người hiểu biết về data. Mình đang dùng công cụ Power BI nhưng.... 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.... Mình cảm thấy Power BI làm rất tốt những việc như aggregate data, nhưng để query thì rất có vấn đề. Vì cái hệ thống query của nó là tự động. Cardinality, filter propagation, auto-exists, empty row removal hoạt động rất khó hiểu, đến cả mình còn không xử lý nổi. Để có thể query thành công một bộ dữ liệu nào đó rồi visualize chúng lên table visualization, mình cảm thấy nó còn tốn sức hơn cả mình query trực tiếp bằng SQL nữa. Để có thể model một cái bộ bảng để có thể dùng những BI tool để query data, mình tốn vô cùng nhiều công sức. Nhưng tình trạng thường xuyên xảy ra sẽ là mình bịt chỗ này thì sẽ có chỗ đi ngược với lí thuyết xuất hiện. Mà nếu bịt các lỗ hổng về lí thuyết thiết kế thì lại không làm được việc mà mình mong muốn. ![]() ![]() Mình sợ ko biết là mình vì đang mắc một sai lầm rất nghiêm trọng nào đó trong thiết kế cốt lõi nên tình trạng trên mới xảy ra, hay chỉ đơn giản là mình đang sử dụng wrong tool for wrong job. ![]() Mình muốn hỏi các bạn rành về vấn đề này, cho mình hỏi là liệu những cái BI Tool như PowerBI, Tableau gì đó có thực sự là công cụ đúng để thực hiện những việc như query thông tin chi tiết như mình nói bên trên không. Hay là tốt nhất chỉ dùng nó để aggregate data thôi. Còn detail data thì tốt nhất nên tự dùng SQL để query. ![]() Đây là vấn đề thiết kế ở phần lõi, nếu làm sai hoàn toàn có thể sẽ phải đập bỏ cả solution để thiết kế lại từ đầu, thậm chí dẹp luôn dự án. Mình thì rất thận trọng nhưng bên trên thì họ chỉ muốn nhìn thấy kết quả gì đó, khiến mình vô cùng mệt mỏi. ![]() |
![]() |
Thread Tools | |
|
|