[RPG29]

Originally Posted by hninja222

Cho mình hỏi về cái Kafka 1 chút. Theo như mình hiểu thì cái Kafka này nó giống như 1 tòa soạn báo vậy, nhà báo (producer) đăng bài vào 1 mục (topic) và bạn đọc (consumer) sẽ check theo interval để để đọc báo (poll)....

Vậy thì cái Kafka này có gì khác với một cái database thông thường nhỉ. Người cần viết viết vào 1 cái DB nào đó, rồi người đọc kết nối vào DB đó để đọc? Khác nhau ở distributed computing chăng?

____________________

Chỗ học bài bản thì mình nghĩ không có đâu, ở đại học không biết thời bây giờ hoặc trường khác thế nào chứ bên mình (1 trường hạng xoàng ở SG) thì ngay cả ngành hệ thống thông tin đi chăng nữa thì cũng chủ yếu học về DB cho các hệ thống xử lý online thôi chứ không có Warehouse.

Mà mình nghĩ chứ thực ra thì được đào tạo cử nhân, kĩ sư khoa học máy tính đã có thể gọi là bài bản rồi, tuy ko đc đào tạo trực tiếp nhưng mindset thì đều ổn cả. Chứ Ralph Kimball (có thể coi là cha đẻ của Data Warehouse) thì bắt đầu cũng từ kĩ sư điện thôi.

Còn chứng chỉ ngoài thì mình thấy có Exam 70-767 của Microsoft, nhưng cái exam này có dạy ở VN không thì mình không chắc.

Đúng rồi bác, có thể xem Kafka như một cái logging database/append-only database, mỗi topic có thể xem như là một cái table chứa các event theo thứ tự. Cơ bản là Kafka nó được thiết kế cho việc này nên throughput nó rât cao

Không có ai hướng dẫn bài bản nên tự bơi hơi mệt

[_sharp_]

Originally Posted by CloneBayernVsChelsea

cty mình đang tuyển dataware house senior upto 3k min 4 năm kinh nghiệm mà ko ra đây nè.

Làm về domain gì vậy thím?

Originally Posted by hninja222

...Chưa kể nữa là stack của mình là stack của Microsoft, hàng mình xài khả năng lớn là Azure Data Warehouse trong khi ở VN mình toàn thấy AWS Redshift với Google Big Query....

....
Trong khi mình cảm thấy nếu muốn đi xa trong ngành này thì Kafka và Spark là bắt buộc, khi mà các thiết bị IOT sau này phát triển sẽ stream event liên tục và người ta có nhu cầu phân tích cái luồng dữ liệu khổng lồ đó.

"AWS Redshift với Google Big Query" chỉ là 1 phần nhỏ thôi.
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.

[KhangBKIT]

BI dùng tool gì thế thím? PowerBI hả?

[cuvip1412]

bookmark

[hninja222]

Originally Posted by RPG29

Đúng rồi bác, có thể xem Kafka như một cái logging database/append-only database, mỗi topic có thể xem như là một cái table chứa các event theo thứ tự. Cơ bản là Kafka nó được thiết kế cho việc này nên throughput nó rât cao

Không có ai hướng dẫn bài bản nên tự bơi hơi mệt

Mình cũng thấy mệt nhưng sau một thời gian dài học đủ mọi thứ trò theo kiểu tự bơi quen rồi. Nói chung mình ngại nhất là không có người cứng để hỏi, sai đến 1, 2 năm sau mới biết mình sai. Và khi học xong xuất sơn ra thì không có chỗ dùng hoặc muốn tìm học tiếp thì quá cao so với cấp bán chuyên nhưng lại ko có điều kiện vào cấp chuyên nghiệp. (Ví dụ học ngoại ngữ ko phổ biến như Nhật/Hàn/Tàu, ra ngoài học nâng cao thì ko có lớp, muốn học thì chỉ có nước vào... đại học học.)

Originally Posted by _sharp_

"AWS Redshift với Google Big Query" chỉ là 1 phần nhỏ thôi.
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.

Mình cũng đâu có quan tâm lắm 3 cái chém gió đâu, chỉ là mình xem mấy tin tuyển dụng Data Engineer thì hầu hết đều có đề cập đến Kafka thôi.

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

[thanhmk7]

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

[Blanic]

Originally Posted by hninja222

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

Ngắn gọn thì bác hiểu đúng gần hết rồi.

- 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.

[thanhnhock]

Bên mình thấy team data có xử dụng kafka nè.

[NguoiChienBinhBatTu]

Độ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

[hninja222]

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. Ví dụ như là query across giữa các data mart, (những câu hỏi kiểu tìm ra thông tin chi tiết hóa đơn và thông tin đặt hàng của hóa đơn đó thỏa mãn 1 điều kiện nào đó) nếu query bằng SQL trực tiếp ở Data Warehouse thông qua degenerate dimension thì dễ rồi, nhưng lên Power BI thì bắt buộc phải thiết lập quan hệ giữa 2 bảng (lúc này máy nó nhận là quan hệ nhiều nhiều -> sai lí thuyết, nhưng ít nhất là vẫn dùng được). Nhưng mấy hôm nay mình phát hiện là nếu mình muốn mang cái tabular model đó deploy lên cloud (Analysis Services) thì chắc chắn sẽ chết vì Tabular Model của Analysis Service không hỗ trợ many-to-many cardinality.

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.