Bài viết chuyên sâu

Khi nào bạn cần Database, khi nào bạn cần Data warehouse.

Khi nào bạn cần Database, khi nào bạn cần Data warehouse.

by Admin Dathoc -
Number of replies: 0

#koolj_dataengineering

Vài ý kiến nhỏ làm rõ: Khi nào bạn cần Database, khi nào bạn cần Data warehouse.

Vì là dân DA, nên bắt buộc khi khách hàng đòi hỏi, chúng ta cần chuẩn bị những logic về cấu trúc dữ liệu đang định lưu, định lấy để làm tốt nhất bài toán phân tích ý nghĩa từ dữ liệu cho khách hàng.

Đối tượng phù hợp bài viết: các bạn làm da, dân business, dân làm de, ds.

Nếu bạn vào Guru, hay AWS knowledge hoặc Microsoft SQL knowledge thì nhanh lắm. Xong ở đây mình xin tiếp cận hơn trong ...đời thực với kinh nghiệm xào nấu dữ liệu ở VN, và các startup nho nhỏ đang le lói sờ vào ... nhiều dữ liệu, mà định nghĩa ra. Cho nên có có thể khác so với gì bạn học ở Đức, ở Pháp. Vậy nếu khác chỗ nào các bạn cho thêm tham khảo nhé. Thanks.
.
.
.
Trong các quan tâm của các bạn làm business, ví dụ các bạn bán hàng, các bạn tổ chức ra một nhóm startup, tạo sản phẩm... các công ty vừa cho tới... các tập đoàn lớn, tổng cty: một quan tâm nói chung muốn làm rõ nhất là: bây giờ các nhu cầu (của con người) đang mong muốn cái gì, tiền trong dân cư đang nhàn rỗi lúc nào, đang tích tụ bao nhiêu, khối lượng? giá trị? Làm sao để biết ở đâu cần cái gì để bán cái đấy? Phục vụ mục tiêu thương mại. Rồi các bài toán dự báo về xu thế, đặc tính phục vụ nghiên cứu khoa học.

Vậy những nhu cầu trên về data ... làm thế nào check được, làm thế nào tổng kết ra được? thông thường đa phần họ thường làm theo thói quen, tập quán. Hay học những người dày dặn lâu năm kinh nghiệm. Số còn lại thì sẽ dùng những kinh nghiệm kỹ thuật CNTT để thu thập, rà soát, gom các dữ liệu qua internet, mạng xã hội, hoá đơn chi tiêu, thống kê cuộc gọi, thống kê số lần đi lại, quãng đường hay đi lại... in/out tiền trong tài khoản,...hiện tượng, hành động, hình ảnh, âm thanh... đánh giá các mối quan hệ trong xã hội.. rồi áp dụng thuật toán, rạo mô hình để mong đợi cá dữ liệu trong tương lai sẽ dự đoán ra một ý nghĩa, hay là để tạo nên những ý nghĩa từ dữ liệu đó.
.
.
.
Câu hỏi đặt ra ở đây là: Vậy bạn dùng loại cơ sở nào, logic nào để quản lý dữ liệu; bạn dùng phương cách nào để lưu và phân tích dữ liệu bạn đang định có, đinh lấy. Mà nó phải đảm bảo nhanh, xử lý song song, xử lý lượng dữ liệu lớn, xử lý lượng dữ liệu đa dạng: cả cấu trúc bảng và phi cấu trúc bảng.

Công việc đó đòi hỏi phải định nghĩa rõ: bạn định dùng dữ liệu làm gì??? Tức là nên focus vào business bạn cần làm với data.
.
.
.
Vậy có chung một số loại yêu cầu như sau:
- Loại yêu cầu nhóm 1: Ah, anh ơi, em chỉ cần lưu bản ghi sản phẩm gồm ảnh, tên, đơn mua hàng, lưu lại để sau này tracking dữ liệu mua bán, quản lý hàng hoá ra vào.
- Loại yêu cầu nhóm 2: Em cần việc làm phân tích cho tổ chức: xu thế mua hàng của các loại mặt hàng, xu thế người dùng view và xem họ view cái gì mật độ thế nào; xu thế sản lượng bán hàng, và mong muốn ước tính cho tương lai sẽ nhập, bán cái gì? Câu hỏi tiếp:
+ Dữ liệu e ra vào hàng ngày nhiều ko?
+ Có bao nhiêu loại báo cáo em cần? các khía cạnh đặc tính từ dữ liệu e cần trong báo cáo? (thông thường các boss ko nói đc cái này, vậy mình nên
- Loại yêu cầu nhóm 3: Em cần chuyển đổi giao tiếp qua lại data cho 100k - 1 triệu đầu cuối, mà e cần tốc độ phải nhanh, tức thời bên kia gửi bên này nhận. Timeout không quá 0,05 mili giây. Kiểu game online. Tra cứu phản hồi bot trợ giúp online. 1 triệu thiết bị IoT kết nối với nhau.
.
.
.
1. Deal với Loại yêu cầu nhóm 1, đơn giản là một Database. Tức là phục vụ:
OLTP - việc lưu chuyển data trực tuyến- nhanh nhất có thể kiểu xem view, lưu trữ hàng cột quan hệ rõ ràng, report đơn giản tính chất thống kê thứ hạng, cao thấp

Thiết kế cơ bản: cứ theo đúng 3 chuẩn RDBMS là ra. Xong cần lưu ý dạng này:
- Nó sẽ có vấn đề khi dữ liệu lớn làm OLTP, khi cái phần mềm điều hành nó không quản lý tốt. Như các bạn biết CSDL chỉ là hàng cột thôi. Xong cái Hệ quản trị nó mới là vấn đề. Ở đây một số DB chưa gỡ đc nút thắt là:
+ Bể dữ liệu hàng đợi session quản lý ko tốt
+ Data được lưu rất giống object đời sống thực. Dẫn tới cồng kềnh. Khó gom lại nhanh sắp xếp nó để tính toán một cách song song
+ Xử lý data thì đưa lên RAM và hạ xuống HDD nên bị latency nhiều.
+ Chỉ xếp hàng rồi ghi vào DB, ko thể song song ghi vào
+ Xong đc cái I/O disk rất nhanh. Xong nhanh chỉ là cái móng tay với các hệ sau này..ko cần disk.
+ Đối với bạn lập trình: tập trung vào lệnh UPDATE, INSERT, SELECT, DELETE... vì là crud nên cần thế
+ Chính vì thế nó làm rất tốt kiểu hàng đợi và lần lượt ghi vào. Nếu chạy một DB kiểu này bạn giám sát bằng cách bật CPU monitor lên, khi đó bạn sẽ chỉ thấy 1 session cpu xử lý cho DB của bạn. Ko hiệu quả khi chúng ta cần song song nhiều tác vụ.

Ví dụ cụ thể: cái bàn, quyển sách, bạn Tuấn
- Thiết kế table các trường dữ liệu như: id đồ vật, tên loại, chất liệu, màu sắc, id chủ sở hữu; id người, tên người

Vậy nó rất phụ thuộc vào cấu trúc kiến trúc bạn dựng các quan hệ các bảng dữ liệu... để nhanh nhất có thể truy vấn...tức đây là vấn đề nội tại của RDBMS. Ko vưọt ra được sức mạnh các hệ tiếp theo.
.
.
.
2. Deal với Loại yêu cầu nhóm 2, cao cấp hơn, là Data warehouse - bạn cứ tạm hiểu nó là một dạng lưu trữ data sẵn sàng cho việc phân tích đọc ghi gồm nhiều bản ghi 1 lúc, nhiều nơi một lúc, truy vấn cùng 1 query xong, nơi tự động cho bạn ngay những bảng dữ liệu đã bao gồm sẵn những logic bạn yêu cầu phân tích. Nơi lưu trữ những data đã được kèm sẵn các logic tổng hợp từ các bảng data khác.. Tức là phục vụ: OLAP - việc phân tích data trực tuyến
- Vì đa phần chạy trên thủ tục tự dựng, và sắp xếp xử lý song song, nhưng cần các hệ quản trị tương đương, nên chỉ một số DB mới hỗ trợ tạo Datawarehouse: Oracle, MSSQL, MariaDB, CouchBase, Hadoop, Spark Dataframe, Snowflake, AWS Redshift, Redis, MongoDB, AngroDB
+ Lúc này cái hệ quản trị DB cần cho phép xử lý song song
+ Cần cho phép xử lý trên RAM nhiều hơn sau một chu kỳ rồi lưu xuống disk.
+ Đa phần dev sẽ sủ dụng SELECT thôi, hoặc MAP/REDUCE
+ Phân mảnh nhóm xử lý, cùng một chuỗi dữ liệu được copy ra nhiều nơi. Băm nhỏ để xử lý song song, truy vấn song song
+ Data được lưu thiên về nhóm khía cạnh của data, chứ không phải thực thể đời sống thực. Nên dễ gom theo khía cạnh. Dễ gọi tổng hợp.
+ Điển hình là các dimension table (các bảng chi tiết về khía cạnh liên quan của chủ thể cần tính toán phân tích) cho một fact table (chủ thể cần phân tích)
+ Nhiều index được lồng nhau cho nhiều khía cạnh của data. Dẫn tới lọc và truy vấn nhanh
+ Có nhiều kiểu tiến hành xử lý làm sạch, làm mịn dữ liệu: Bạn E trước, rồi L, rồi T. Hoặc là bạn E truớc rồi T rồi L. Xong nó cần đủ layer để

Ví dụ cụ thể 1: cái bàn, quyển sách, bạn Tuấn. Song business là: Hãy phân tích lượng bán và lý do tại sao doanh thu chậm
- Thiết kế fact table: id đồ vật, id gian hàng bán, id nhà cung cấp, giá bán, số lượng bán, mã khuyến mại, id đợt khuyến mại, id thời tiết theo ngày, id ngày tháng, id đợt bệnh dịch, id bệnh dịch;
- Thiết kế 1 dimension table: id kho, địa chỉ kho, thời gian nhập hàng, thời gian giao hàng
- Thiết kế 2 dimension table: id thời tiết, nội dung sự kiện thời tiết, độ ảnh hưởng, thiệt hại xung quanh

Ví dụ cụ thể 2: cái bàn, quyển sách, bạn Tuấn. Song business là: Hãy phân tích lượng bán và lý do tại sao ngưòi dùng bàn, và sách nhà ta hay bị.. cúm Covid19
- Như trên, xong thêm layer1 xử lý các thời gian mua và bán, rồi chuyển thành 0 hoặc 1 nếu mua hoặc bán khác nhau
- Chuyển tiếp đặt giá trị 2,3 để tạo ra một bảng chỉ có: 0,1,2,3 để tiện... Bên BI dùng thuật toán để tính toán.

Ví dụ cụ thể 3: dữ liệu cái bàn, quyển sách ... của em lớn lắm. Cứ mỗi ngày có vài trăm GB. Sợ SQL ko load nổi.
- OK yên tâm e, e cần tiếp cận tới dạng lưu trữ phân tán, và tính toán nhanh trên tổng hợp ram và cpu của nhiều máy tính gộp lại: Hadoop là một gợi ý. Vậy khi đó:
- Cái hệ quản trị database lúc này là: Spark hoặc Impala
- Cái nơi lưu và thiết kế DB nên là: parquet, kudu

.
.
.
3. Deal với Loại yêu cầu nhóm 3:
Một loại đặc trưng nhất là cần: tốc độ nhanh phục vụ IoT, rồi lưu trữ đọc ghi cấp tốc OLTP.. phục vụ bài toán game real-time, xe tự hành, hỗ trợ cấp báo sensor phản ứng nhanh nhạy
- Kiến trúc tương tự như (1)
- Cơ bản sô 1 để bỏ qua cũng như cho phép các cổng và giao thức giữa các máy với nhauđể giảm bớt cản trở: p2p, sock. Dễ gây rủi ro bị backdoor hay highjack xong đạt đc tốc độ cao băng thông.
- Cơ bản số 2 là: Sử dụng tất cả các DB xử lý trên cache, in-memory, onthefly. Do vậy nó chỉ phù hợp cho với những công cụ, bài toán, nghiệp vụ ... đơn giản, không có tính bảo mật: db cho ai bot, db cho share thông tin sức khoẻ, db cho địa danh, đường phố tra cứu, db cho nội dung và tên tin tức, thời sự, ... nội dung sách vở online, db xử lý clip trực tuyến livestream.
- Tiếp đến một số business dựa vào tính chất OLTP nhanh của DB dạng cache, in-mem, để làm các nghiệp vụ có kèm giao thức bảo mật. Cũng ko sao, coi như một phần kém đi tốc độ. Xong đổi lại sẽ gặp rủi ro dữ liệu mất mát nếu RAM bị hỏng bị lỗi gối bộ nhớ, xử lý tắc....dẫn tới lại lây lan gây cản trở xử lý. Gây mất mát dữ liệu, khi dữ liệu chưa kịp lưu xuống HDD.
- Vậy cần là xử lý RAM/cache xong cần backup thường xuyên

Ví dụ cụ thể: cái bàn, quyển sách... thay bằng DB trên ram/cache như (1) xong bạn sẽ thấy tốc độ khác chẳn.

Mời fans góp ý thêm.
-----------------------------
Học livestream, dài hạn 1-2-3 tháng, học ngắn hạn 5 buổi, xin qua dathoc.net/botreg, detail: dathoc.net/cms