Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data. - Page 4 - vozForums
vozForums
Go Back   vozForums > Học tập và công việc > Ngành CNTT > Phát triển Phần mềm
Reply
 
Thread Tools
  #31  
Old 15-10-2019, 14:41
hninja222 hninja222 is offline
K.I.A
 
Join Date: 12-2010
Posts: 2,735
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by Robin Phan Persie View Post
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
Mấy bác dùng Tool tự động là gì nhỉ. Dùng để làm cái gì vậy bác (Ví dụ như tool tự động analytic aggregation engine, semantic model, visualization)

VD như bên Microsoft nó có thể coi là có bộ 3: Power Query + Power Pivot + Power View là extension cho Excel để chuyên làm Analytic. 3 thằng này tách ra khỏi Excel gộp chung lại thì thành Power BI, thằng Power Pivot dùng để modeling dữ liệu, làm analytic engine + semantic layer, dùng in memory aggregate data nhanh như điện xẹt, đứng 1 mình trên cloud thì thành Azure Analysis Services. Analysis services import Data từ Data Warehouse lên in-memory columnar storage của nó. Power View thì là nhận kết quả phân tích từ engine nội tại hoặc trên cloud (live connection lên Analysis Service) về rồi vẽ ra các thể loại đồ thị.

Mình ko biết nếu là stack của Google hay Amazon thì thế nào. Mìnhxem thì thấy hình như Amazon Redshift nó có quảng cáo (xem quảng cáo thôi chứ mình ko làm trực tiếp nên ko rõ) là có 1 cái in-memory analytic gì đó, ko biết nó có giống cái M$ Analysis Services ko. Còn Google Big Query thì mình xem tìm mãi nhưng ko thấy nói gì về in-memory analytic cả.

Còn nếu ko dùng tool trên thì thành ra thế nào nhỉ, viết các lệnh SQL thủ công để drill xuống các fact à bác. Nếu là cách này thì mình thấy với mình sẽ rất sướng do mình chủ động mọi thứ, lại ko phải học ba cái DAX với filter propagation quái quỷ của Analysis Services, nhưng sẽ khó để expose ra cho dân không biết kĩ thuật biết dùng được. Mà đây cũng là một đặc điểm được bên trên mong đợi ở cái hệ thống này.

À nếu được bác cho mình chút ý kiến của bác về cái vấn đề này nhé bác.

Quote:
À 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:47.
Reply With Quote
  #32  
Old 15-10-2019, 17:51
Robin Phan Persie Robin Phan Persie is offline
Senior Member
 
Join Date: 05-2013
Posts: 207
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by hninja222 View Post
Mấy bác dùng Tool tự động là gì nhỉ. Dùng để làm cái gì vậy bác (Ví dụ như tool tự động analytic aggregation engine, semantic model, visualization)
...
Đội đấy dùng tool của SAP đưa trong flows nên bị chậm, cũng có thể đội đó chưa tối ưu được nên mình k rõ
Reply With Quote
  #33  
Old 16-10-2019, 15:37
phamhuythang phamhuythang is offline
Senior Member
 
Join Date: 04-2007
Posts: 387
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by hninja222 View Post
Ừ, 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.
Về cơ bản data mà DB master replicate sang DB slave là transaction logs và đương nhiên Kafka connector cũng sẽ ghi nhận được các log này, tương tự như log của web app.
DB slave được dùng để tổng hợp report đó bạn.
Reply With Quote
  #34  
Old 06-11-2019, 11:52
ez-aqua ez-aqua is offline
Junior Member
 
Join Date: 11-2013
Posts: 6
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Mình là chủ topic đây. Acc kia mình bị ban rồi nên mình dùng acc này.

Mình mới nhận ra một điều là không biết phương pháp thiết kế của các Data Warehouse ở Việt Nam hiện nay là gì. Hiện tại mình đang làm theo phương pháp Star-Schema bottom up của Kimball, dùng stack của Microsoft để làm.

Nhưng gần đây mình cảm thấy chột dạ khi mình nghe nói rằng là Google Big Query (Đối trọng của Azure Data Warehouse trong cloud của Google) dùng kiểu gì mà "append only", rồi nested data nữa. Mà nếu append only thì chắc chắn những kĩ thuật chủ chốt của Kimball Approach dimensional modeling như SCD Type 2, Accumulating Snapshot... sẽ không bao giờ thực hiện được (Vì nó dựa vào update). Vậy đối với những data warehouse dùng Google Big Query họ sẽ thiết kế data ware house kiểu quái nào.

Rồi Amazon Redshift nghe bảo cũng sẽ có khác biệt gì đó mà đọc ở đâu đó nó nói không phù hợp lắm với dimensional modeling.

Như vậy bọn này sẽ dùng thiết kế như thế nào nhỉ. Bill Inmon Top Down EDW chăng? Thực sự mình phải nói là cái EDW mình chỉ nghe trong truyền thuyết chứ chưa biết nó thiết kế theo kiểu quái nào. Stack của Microsoft thì có cái data warehouse mẫu AdventureWorkDW với các doc về dimensional modeling rất rõ ràng rồi chứ Inmon Top down EDW trông tròn méo thế nào mình không biết luôn.

Hay là nó thiết kế theo kiểu Data Vault không biết. Giờ mình đang phải xem Data Vault nó là cái gì.

Chưa kể còn Hive. Lúc đầu mình tưởng Hive nó chỉ là cái context để gõ lệnh SQL trong Spark, sau đó mới biết nó là cái kiểu Data Warehouse. Không biết 1 cái data warehouse mà làm bằng Hive nó sẽ trông giống thế quái nào luôn.
1355308
Reply With Quote
  #35  
Old 18-11-2019, 16:30
skyfront's Avatar
skyfront skyfront is offline
Senior Member
 
Join Date: 11-2006
Location: ............
Posts: 128
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by hninja222 View Post
Mấy ngày hôm nay mình rơi vào trạng thái
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.

^
Bác trình bày rối quá, với yêu cầu như này thì Power Bi là khả quan, nhưng mà bác nên chơi với Power Query để làm "sạch" dữ liệu rồi mới chuyển vào data model, cơ mà thằng này dùng M language để tạo query, lại phải học thêm 1 ngôn ngữ nữa, cơ mà bảo khá giống SQL
mình cũng đang tìm hiểu power bi, múa rìu qua mắt thợ lấy kinh nghiệm chút
Reply With Quote
  #36  
Old Yesterday, 21:39
amarifleur amarifleur is offline
Senior Member
 
Join Date: 07-2013
Location: Thiên đường
Posts: 1,202
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by ez-aqua View Post
Mình là chủ topic đây. Acc kia mình bị ban rồi nên mình dùng acc này.

Mình mới nhận ra một điều là không biết phương pháp thiết kế của các Data Warehouse ở Việt Nam hiện nay là gì. Hiện tại mình đang làm theo phương pháp Star-Schema bottom up của Kimball, dùng stack của Microsoft để làm.

Nhưng gần đây mình cảm thấy chột dạ khi mình nghe nói rằng là Google Big Query (Đối trọng của Azure Data Warehouse trong cloud của Google) dùng kiểu gì mà "append only", rồi nested data nữa. Mà nếu append only thì chắc chắn những kĩ thuật chủ chốt của Kimball Approach dimensional modeling như SCD Type 2, Accumulating Snapshot... sẽ không bao giờ thực hiện được (Vì nó dựa vào update). Vậy đối với những data warehouse dùng Google Big Query họ sẽ thiết kế data ware house kiểu quái nào.

Rồi Amazon Redshift nghe bảo cũng sẽ có khác biệt gì đó mà đọc ở đâu đó nó nói không phù hợp lắm với dimensional modeling.

Như vậy bọn này sẽ dùng thiết kế như thế nào nhỉ. Bill Inmon Top Down EDW chăng? Thực sự mình phải nói là cái EDW mình chỉ nghe trong truyền thuyết chứ chưa biết nó thiết kế theo kiểu quái nào. Stack của Microsoft thì có cái data warehouse mẫu AdventureWorkDW với các doc về dimensional modeling rất rõ ràng rồi chứ Inmon Top down EDW trông tròn méo thế nào mình không biết luôn.

Hay là nó thiết kế theo kiểu Data Vault không biết. Giờ mình đang phải xem Data Vault nó là cái gì.

Chưa kể còn Hive. Lúc đầu mình tưởng Hive nó chỉ là cái context để gõ lệnh SQL trong Spark, sau đó mới biết nó là cái kiểu Data Warehouse. Không biết 1 cái data warehouse mà làm bằng Hive nó sẽ trông giống thế quái nào luôn.
1355308
Lên quora, stackoverflow, reddit xem thử , để làm DW thì đi sâu cũng rất ít, ở VN nhu cầu cũng không nhiều và chỉ tập trung ở các Big Corp.
Reply With Quote
  #37  
Old Yesterday, 22:36
ez-aqua ez-aqua is offline
Junior Member
 
Join Date: 11-2013
Posts: 6
Re: Hướng đi nào cho Data Engineer, BI, Data Warehouse, Big Data.

Quote:
Originally Posted by amarifleur View Post
Lên quora, stackoverflow, reddit xem thử , để làm DW thì đi sâu cũng rất ít, ở VN nhu cầu cũng không nhiều và chỉ tập trung ở các Big Corp.
Có lẽ hết năm nay mình sẽ nghỉ. Thấy Itviec tuyển Data Engineer cũng không quá hiếm. Hiện tại mình thấy chẳng có tương lai gì cả. Một vòng xoáy hỗn độn giữa làm ra kết quả ngay (Theo mong muốn của bên trên) và thiết kế căn cơ, dữ liệu ở grain atomic.

Vấn đề chưa hẳn quan trọng là nhân lực và trình độ của người làm, mà vấn đề ở đây là sự hợp tác và thấu hiểu rất kém của các bên liên quan. Ai đời thằng data engineer lại phải trả lời cho đám business biết cần dữ liệu gì, dữ liệu này có ý nghĩa gì. Khi hỏi mấy cái dữ liệu này mày lấy từ đâu, clean như thế nào thì bị nói là "hỏi vấn đề vớ vẩn". Hôm sau demo dữ liệu bị lủng lỗ vì không clean thì lại hỏi tại sao lại như thế.

Hiện giờ để ra kết quả cho người ta xem, mình đang phải làm những biện pháp hết sức tạm bợ, grain to đến tận... tháng. Làm theo kết quả người khác muốn thấy, cào phẳng bảng hết ra cho lẹ éo cần DIM FACT quái gì luôn.

Hôm trước team mình đưa ra 2 lựa chon, một là thiết kế modern data warehouse đúng theo mô hình modern data warehouse của Microsoft, 2 là làm virtual table (SQL View - nói tóm lại là 1 chùm select được đóng gói trong 1 cái view) ngay trên database backup của công ty thì bên trên đã chọn giải pháp thứ 2, đơn giản là vì nó sẽ thấy kết quả nhanh nhất.

Tóm lại thì sau khi chọn xong thì mình không còn động lực làm việc nữa. Giờ thì mình đợi năm sau là chuồn. Giờ thì ngồi nghịch Spark Streaming + Event Hub thôi. (Event Hub cho nhanh chứ nếu chơi Kafka thì phải mở cả 1 cái cluster HDInsights thì nặng nề quá)

Quote:
Originally Posted by skyfront View Post
Bác trình bày rối quá, với yêu cầu như này thì Power Bi là khả quan, nhưng mà bác nên chơi với Power Query để làm "sạch" dữ liệu rồi mới chuyển vào data model, cơ mà thằng này dùng M language để tạo query, lại phải học thêm 1 ngôn ngữ nữa, cơ mà bảo khá giống SQL
mình cũng đang tìm hiểu power bi, múa rìu qua mắt thợ lấy kinh nghiệm chút
Mình đồng ý và mình nhớ là mình có viết ở đâu đó trong topic này trước đây rằng nói cho cùng thì Power BI 1 mình nó cũng có thể bao trọn gói được toàn bộ giải pháp BI/Reporting. Vấn đề ở đây là scale.

VD như để host đc 1 cái dataset cực lớn thì bạn không thể host trên Power BI app.powerbi.com (Mình nhớ chỉ cho tối đa 250MB), tabular model thì data được host trên ram, sức mạnh xử lý cũng không. Mình không dám chắc nhưng Power BI cloud thuần chắc sẽ không bao giờ có những thứ như partition (data mà lớn mà không có partition thì khi refresh cứ gọi là đã ), perspective... và quan trọng nhất là centralized semantic model như Analysis Services. (những thứ khó nhất như table relationship, filter propagation, calculated table, calculated column, measure... được engineer lo hết và được host trên cloud, người dùng chỉ việc live connection vô cloud rồi vẽ report.)

Để nuôi được con Analysis Service này, thì lại cần 1 con data warehouse chứa dữ liệu đã được integrate sẵn, clean sẵn, restructure sẵn để nuôi nó...

Để integrate, để clean, để restructure thì sẽ lại quay về với các giải pháp extract transform load. Tùy vào kiểu dữ liệu, độ lớn vv... để xem dùng giải pháp gì để làm. VD nếu dữ liệu nhỏ cấu trúc bình thường thì load vào data warehouse rồi dùng stored procedure transform. Nhưng gặp dữ liệu lớn, semi structure/unstructured thì sẽ bắt đầu phải tìm đến big data cluster như Hadoop, Spark. Gặp stream real time thì sẽ phải tìm đến Spark Streaming, Storm... 1355308

Nói tóm lại thì đi một vòng thì rồi cũng sẽ không sớm thì muộn trở về như cũ thôi.

Last edited by ez-aqua; Yesterday at 23:01.
Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +7. The time now is 12:17.
Chịu trách nhiệm nội dung: Bạch Thành Trung © 2019 Công ty TNHH Thật Vi Diệu
ĐC tầng 4, số 6-8 Đường D2, Bình Thạnh, Hồ Chí Minh, Việt Nam - SĐT 0981323799 - MST 0313906593
Giấy phép thiết lập MXH số 334/GP-BTTTT, Ký ngày: 19/08/2019