[hninja222]

Originally Posted by Robin Phan Persie

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.

À 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

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õ

[phamhuythang]

Originally Posted by hninja222

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

[ez-aqua]

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

[skyfront]

Originally Posted by hninja222

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

[amarifleur]

Originally Posted by ez-aqua

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.

[ez-aqua]

Originally Posted by amarifleur

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á)

Originally Posted by skyfront

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.

[bsevenshido]

Originally Posted by ez-aqua

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á)



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.

Em cũng đang tìm hiểu về data engineer cũng 2 năm exp dev Bác nghiên cứu mấy tháng nay rồi khai sáng cho em với

[Chief Bean]

Originally Posted by ez-aqua

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

Mấy cái này thím phải nắm chắc mỗi tech nó create ra để làm việc gì. Còn theo Kimball thì thím phải nắm được tech nào support triết lý đó.

Về Google Big Query và model append only thì có thể nói như này
- Storage is cheap meaning you can store as much as you want without worry about the cost. Các service như GCF,S3 offer cho bạn lưu hàng TB với giả rất rẻ.
- Google Bigquery là general purpose query engine. Nghĩa là nó kiểu query cho nhiều source khác nhau. Có thể dùng để query từ db, files, excel ....
- Qua hệ này thì không có dùng update vì đa số based trên file system. Thường bên hệ này thì phải suy nghĩ về snapshot/partition và overwrite/append. Tức là muốn update thì có snapshot/partition cái version cũ đi và tạo một version mới bằng cách copy/overwrite lên một version mới. Vì storage is cheap so we can do that.
- Data modeling trên hệ này thì theo kiểu big fact table, dimension table chỉ là làm ra để tạo ra fact. Và fact table thường rất wide tới 100-300 columns là chuyện thường. JOIN ở hệ này rất costy nên fact table là nơi đã join sẳn để user chỉ query từ đó ra xài.
- Qua hệ này thì tính cost khác hệ cũ. Hệ này tính cost gồm 2 yếu tố storage cost và query cost.
- Hệ này scale dễ hơn hệ cũ nhưng phải scale lớn mới thấy được impact + tốn nhiều tiền cỡ vài trăm ngàn $ đến vài triệu là bình thường.

[ez-aqua]

Originally Posted by Chief Bean

Mấy cái này thím phải nắm chắc mỗi tech nó create ra để làm việc gì. Còn theo Kimball thì thím phải nắm được tech nào support triết lý đó.

Về Google Big Query và model append only thì có thể nói như này
- Storage is cheap meaning you can store as much as you want without worry about the cost. Các service như GCF,S3 offer cho bạn lưu hàng TB với giả rất rẻ.
- Google Bigquery là general purpose query engine. Nghĩa là nó kiểu query cho nhiều source khác nhau. Có thể dùng để query từ db, files, excel ....
- Qua hệ này thì không có dùng update vì đa số based trên file system. Thường bên hệ này thì phải suy nghĩ về snapshot/partition và overwrite/append. Tức là muốn update thì có snapshot/partition cái version cũ đi và tạo một version mới bằng cách copy/overwrite lên một version mới. Vì storage is cheap so we can do that.
- Data modeling trên hệ này thì theo kiểu big fact table, dimension table chỉ là làm ra để tạo ra fact. Và fact table thường rất wide tới 100-300 columns là chuyện thường. JOIN ở hệ này rất costy nên fact table là nơi đã join sẳn để user chỉ query từ đó ra xài.
- Qua hệ này thì tính cost khác hệ cũ. Hệ này tính cost gồm 2 yếu tố storage cost và query cost.
- Hệ này scale dễ hơn hệ cũ nhưng phải scale lớn mới thấy được impact + tốn nhiều tiền cỡ vài trăm ngàn $ đến vài triệu là bình thường.

Như vậy, mình hiểu là như thế này, Google Big Query/Hive là nơi lưu những dữ liệu mà mình tổng hợp sẵn, join sẵn mọi thứ, thành một bảng phẳng rồi lưu trên đó. Khi có update xảy ra, mình sẽ phải tổng hợp lại version mới, vào xóa toàn bộ cái partition chứa dữ liệu cũ rồi append cái mới vào.

Ví dụ

Mình có 3 partition tháng 10, 11, 12

Tháng 10 và 11 đã chốt sổ nên sẽ không update nữa, nhưng tháng 12 là tháng đang diễn ra, vì vậy hàng ngày sẽ có những update mới cho những đơn hàng đang xử lý.
Thì hàng ngày mình sẽ phải chạy lại lệnh ETL của toàn bộ dữ liệu tháng 12 tính đến ngày hôm nay, để ra version mới cho cả những đơn hàng lập từ hôm trước có update mới, và những dòng mới chưa được extract từ trước, rồi vào GG BigQuery/Hive xóa toàn bộ partition chứa dữ liệu của tháng 12, rồi nhét lại dữ liệu của tháng 12 extract được hôm nay vào partition của tháng 12.

Lúc mình ETL thì mình join mọi thứ cần thiết vào, cào phẳng bảng fact để sau khi vào data warehouse rồi thì không phải join nữa.

Mình hiểu như vậy đúng không nhỉ?

Có một điều lạ là mình xem doc trên Google (mình chỉ lướt) thấy vẫn có SCD2, vẫn có DIM, Fact, vẫn có lệnh Merge. Hive cũng có loại bảng hỗ trợ update, hoặc có những work around với việc update SCD 2, chứ ko đến mức là cào phẳng bảng.

Mình làm đồ của Microsoft nhưng khá hứng thú với cái ý tưởng của Hive, dù chỉ mới sờ thử chơi cái Hive qua Hive Table trong Spark của Databricks.

Với cho mình hỏi là tổng hợp sơ data trước khi nhét data vào BigQuery/Hive ở đâu nhỉ, theo như hệ thống của mình thì mình đang cần làm Accumulating Snapshot cho các đơn hàng (VD Đơn hàng 1, Khách hàng, Người bán, Ngày nhận đơn, ai nhận đơn, ngày ship, ship bởi ai, ngày giao, ngày khiếu nại, ngày kết thúc....), với hệ thống bảng quan hệ chằng chịt, thì cái lệnh tổng hợp, join được thực hiện ở Source Data hay ở đâu nhỉ. Hiện giờ mình quyết định làm luôn trên source data cho lẹ (đang bị hối quá rồi), dùng sức mạnh của source để join, detect change chỉ cần có thay đổi ở 1 khâu là extract lại cả cái snapshot cho đơn hàng đó, có đủ dữ liệu rồi thì mang nó qua Spark/Data Warehouse transform, đã test và tạm thời không có vấn đề gì về performance, nhưng chẳng biết sau này sẽ trở thành quái quỷ gì luôn.


1355308