x

  • Tạo bởi Tạo bởi LQDuy
  • Start date Start date
Nên viết theo series chứ rời rạc vậy khó. Tao ủng hộ mày viết
 
edges15:
Nên viết theo series chứ rời rạc vậy khó. Tao ủng hộ mày viết
Bấm để mở rộng...
Giờ em viết theo kiểu tìm ý kiến phản biện. Viết theo kiến thức đã học rồi.

Tìm ý kiến, bài toán câu hỏi của các newbie, hoặc người đi làm rồi.

Chứ viết kiểu đó giống viết sách đi bán quá.
 
LQDuy:
Giờ em viết theo kiểu tìm ý kiến phản biện. Viết theo kiến thức đã học rồi.

Tìm ý kiến, bài toán câu hỏi của các newbie, hoặc người đi làm rồi.

Chứ viết kiểu đó giống viết sách đi bán quá.
Bấm để mở rộng...
Viết cũng là một cách để hệ thống hoá kiến thức của mình. Chưa kể ở senior level kĩ năng writing rất cần thiết
 
Mẹ cứ đụng vô mấy cái tài liệu này là t hoa mắt buồn ngủ nhỉ. Thôi sục cái đi ngủ cho ấm
 
LQDuy:
Chia sẻ kinh nghiệm đi anh.
Bấm để mở rộng...
Mình học DS nhưng muốn code hơn nên dần chuyển sang DE
Học thì JAVA + PY (PY thì phổ biến hiện giờ rồi, còn java vì học để dùng vào hệ sinh thái apache có spark, ...), thêm được thì scala tương tự như java
Thành thạo SQL
DWH Modeling (dim, fact, star schema, snow flake schema,...) : Đọc quyển Kimball's Dimensional Data Modeling
Tool Processing Data: Spark, Pandas
Db: Mysql, Mongodb
Hệ điều hành; Ubuntu ,..
 
Đang vừa học vừa viết à mài, có đang theo roadmap nào ko? Đọc sách nào or xem course nào cho t xin cái tên :misdoubt:
 
LQDuy:

Data warehouse​

  • Các dữ liệu hoạt động của doanh nghiệp: sản phẩm, bán hàng, mua hàng, tài khoản, hàng,.. được lưu trữ trong CSDL(thường là CSDL quan hệ)
  • Các truy vấn trên dữ liệu: select, insert, update, delete
  • Các báo cáo truy vấn trực tiếp vào dữ liệu hoạt động thông qua chuỗi các câu truy vấn
  • Chuỗi các câu truy vấn có thể lưu trữ ngay ở CSDL dưới dạng Store Procedure
==========================================================================

Vấn đề:
  • Các câu truy vấn để kết xuất báo cáo thường phải lấy dữ liệu trên nhiều bảng, tổng hợp dữ liệu trên nhiều bản ghi
  • Truy vấn trực tiếp trên dữ liệu vận hành
  • Doanh nghiệp sử dụng nhiều phần mềm khác nhau
Giải pháp:
  • Tạo CSDL lưu trữ lại kết quả của từng báo cáo
  • Truy vấn trên csdl mới này
DataWarehouse
  • Kho dữ liệu của một tổ chức
  • Được thiết kế đặc biệt cho việc lập báo cáo và phân tích
  • Dữ liệu được tổng hợp từ nhiều nguồn và được đưa vào DWH
Cấu trúc DW:
  • Data Sources: Các dữ liệu phục vụ hoạt động hàng ngày của doanh nghiệp như thông tin sản phẩm, bán hàng, tài khoản
  • Staging Area: Chứa các bản copy của dữ liệu được tải vào từ dữ liệu hoạt động
  • DataWarehouse: Bao gồm dữ liệu thô đã được làm sạch, dữ liệu tổng hợp**, siêu dữ liệu*
  • DataMart: Chứa dữ liệu được tổ chức theo mục tiêu của một phòng ban
  • Users: Lập báo cáo, xử lý và phân tích
*: Metadata: lưu trữ thông tin hoạt động của DWH như là dữ liệu lấy từ nguồn nào, thời gian bao giờ, thực hiện trong bao lâu, các bước, có thể gặp lỗi thì gặp lỗi gì -> Giúp mình cải thiện hệ thống, tăng tốc độ truy vấn, dễ dàng nắm tổng quan về thông tin dữ liệu DWH.
**: Summarydata: Lưu dữ liệu tổ hợp, dẫn xuất l(được tính toán tổ hợp từ dữ liệu nguồn)

Kiến trúc:​

  • Kiến trúc 2 tầng(hướng chức năng)
  • Kiến trúc 3 tầng(hướng dữ liệu)
Kiến trúc 2 tầng: Client - Server
2 kiểu loại này:
  • Thin Client: Server có nhiệm vụ xử lý dữ liệu, client chỉ hiển thị kết quả
  • Fat Client: Server chỉ cung cấp dữ liệu, các phép toán thực hiện trên client
Kiến trúc 3 tầng
  • Tầng 1: Dữ liệu thô đến lúc làm sạch
  • Tầng 2: Dữ liệu được tổ chức, tổng hợp phục vụ phân tích, báo cáo
  • Tầng 3: Công cụ báo cáo phân tích
Các tính chất của DataWarehouse:
  • Tính nguyên tử: Dữ liệu phải là tối gọn(tối ưu gọn gàng) nhất
  • Tinh nhất quán: Chỉ lấy những dữ liệu có ích(cùng chủ đề)
  • Tính cô lập: Dữ liệu không bị chồng chéo lên nhau
  • Tính bền vững: Dữ liệu không thể thêm, xóa hay sửa(cố định)

Nguyên lý thiết kế Datawarehouse:​

  • Hướng chủ đề: Loại bỏ các dữ liệu không hữu ích cho quá trình phân tích
  • Tính toàn vẹn : Tích hợp dữ liệu từ nhiều nguồn khác nhau vào một định dạng thống nhất
  • Tính bất biến: Dữ liệu phải thống nhất theo thời gian(hạn chế tối đa sửa, xóa) -> Phân tích thay đổi theo thời gian
  • Giá trị lịch sử: Cung cấp dữ liệu tại các thời điểm khác nhau của một thông tin

Cấu trúc datawarehouse:​

Báo cáo có điểm gì chung: các tiêu chí đánh giá, trên tiêu chí đánh giá phải định lượng theo từng tiêu chí.
  • Dimension: Các bảng chứa dữ liệu về các tiêu chí đánh giá
  • Fact/Measure: Các bảng chứa dữ liệu định lượng cho các tiêu chí

Mô hình hóa Datawarehouse​

Các lược đồ:
  • Ngôi sao - Star Schema
  • Bông tuyết - Snowflake Schema
  • Thiên hà - Galaxy Schema

Các kiểu mô hình của DataWarehouse:​

#Star Schema
  • Trung tâm mô hình là bảng Fact, xung quanh là các bảng Dim. Bảng Fact chứa khóa ngoại của các bảng Dim.
#SnowFlake Schema
  • "Một bảng" Fact là trung tâm, bao quanh là các bảng Dim, nhưng Dim có tính phân cấp.
  • Bảng (Dim) Dealer phân cấp ra 2 bảng (Dim) Location và Country
  • Bảng Product được phân cấp ra thêm bảng Variant - Biến-thể
#So sánh Star Schema và SnowFlake
  • SnowFlake Schema: Thông tin lưu ở 3 bảng phân cấp
  • Star Schema: Một bảng duy nhất lưu toàn bộ thông tin
  • Khi lấy báo cáo trên đầu SP: Tổng hợp chỉ lấy theo chiều SP, khi lấy theo nhóm SP thì nó phải tổng hợp trên cả bảng nhóm (Group) và bảng Product
Star Schema
  • Dim table không phân cấp, tất cả thông tin được lưu trữ ở 1 bảng
  • Cải tiến hiệu năng truy vấn với các dữ liệu thường sử dụng (truy suất nhanh, chỉ cần join trên 1 tầng)
  • Ít bảng và cấu trúc đơn giản
  • Xử lý truy vấn đơn giản trên khía cạnh sử dụng join
  • Trong 1 số trường hợp có sự dư thừa lớn
SnowFlake Schema
  • Dim table phân cấp (số bảng cần quản lý nhiều hơn)
  • Kích thước Dim table nhỏ (do dữ liệu được phân rã ra)
  • Dễ bảo trì, tránh dư thừa
  • Cho phép các truy vấn phức tạp với các chiều phức tạp, nhiều mức phân lớp (khi truy vấn lấy Product thì chỉ cần thao tác trên bảng Product, ko gây dư thừa dữ liệu như Star 1 bảng lưu trữ toàn bộ dữ liệu)
  • Số lớn các bảng cần được quản lý
  • Truy vấn có thể cần kết nối nhiều bảng
Galaxy Schema
  • Nhìn nhận trên nhiều báo cáo, các báo cáo có những chiều, các yếu tố tiêu chí đánh giá chung, thì nó sẽ dùng chung các Dim table
  • Galaxy Schema mô tả nhiều báo cáo khác nhau dùng chung các bảng tiêu chí
Bấm để mở rộng...
viết nhiều quá, lên linkedin copy vài cái hình vào đây cho dễ hiểu nào
viết thêm 1 cái dự án trình bày ra cho dễ hiểu nào viết kia chung chung quá
 
aaaaaaaaaaaaaaaaaaa:
viết nhiều quá, lên linkedin copy vài cái hình vào đây cho dễ hiểu nào
viết thêm 1 cái dự án trình bày ra cho dễ hiểu nào viết kia chung chung quá
Bấm để mở rộng...
Lười viết quá anh do chẳng ai quan tâm mấy, mà cái này giờ cạnh tranh khốc liệt quá.
 
Mcopns:
Chịu mày ơi. Cái này chỗ tao có thằng làm chuyên. Tao muốn tự làm mấy cái theo ý còn suýt bị ăn đánh=))
Bấm để mở rộng...
Anh làm phân tích thì Domain nào vậy ạ.
 
LQDuy:
Anh làm phân tích thì Domain nào vậy ạ.
Bấm để mở rộng...
Anh làm mô phỏng ko làm phân tích em ạ.
Hiện tại mô hình của anh chỉ có 16 tham số. Đưa vào hệ vi phân để mô phỏng tạo ra dữ liệu để phân tích.
 
Đăng nhập hoặc Ghi danh để trả lời
Top