BTL: NHẬP MÔN CÔNG NGHỆ PHẦN MỀM - Quản lý thu phí, đóng góp ( HUST)

1.1. Mô tả yêu cầu bài toán Bài toán quản lý thu phí, đóng góp (yêu cầu nghiệp vụ số 2)  Hàng năm tổ dân phố thực hiện thu một số khoản phí và đóng góp của các hộ gia đình, công việc này do cán bộ kế toán phụ trách. Khoản phí vệ sinh là bắt buộc với tất cả các hộ gia đình, mỗi năm thu 1 lần với định mức 6.000VNĐ / 1 tháng / 1 nhân khẩu.  Cán bộ kế toán sẽ lập danh sách các hộ gia đình và số nhân khẩu tương ứng, sau đó đến từng nhà thu phí và ghi nhận số tiền nộp. Đối với các khoản đóng góp thì không quy định số tiền mà phụ thuộc vào từng hộ, các khoản đóng góp này được thu theo từng đợt của các cuộc vận động như: “Ủng hộ ngày thương binhliệt sỹ 27/07”, “Ủng hộ ngày tết thiếu nhi”, “Ủng hộ vì người nghèo”, “Trợ giúp đồng bào bị ảnh hưởng bão lụt”,…  Cán bộ kế toán cũng cần thống kê tổng số tiền đã thu trong mỗi đợt, tổng số hộ đã nộp và có thể xem chi tiết mỗi hộ đã nộp những khoản tiền nào

GIỚI THIỆU ĐỀ TÀI

Đặt vấn đề

Trong giai đoạn hiện nay, thị trường chứng khoán Việt Nam ngày càng thu hút được nhiều nhà đầu tư quan tâm Khác với việc đầu tư bất động sản hay đầu tư một số lĩnh vực khác, đầu tư chứng khoán có thể giúp cho nhà đầu tư kiếm lời ngay lập tức, không cần phải cần thời gian quá lâu hay số vốn khá nhiều Chính vì vậy, nó thu hút được số lượng người trẻ tham gia ngày càng nhiều Những người trẻ này hầu hết không phải lúc nào cũng luôn luôn chú ý đến tình trạng chứng khoán, biến động thị trường ngay lập tức Họ cũng không thể thường xuyên có mặt ở các Sở giao dịch chứng khoán để theo dõi các thông tin được, mà chỉ theo dõi biến động, tham gia đầu tư khi rảnh rỗi.

Ngoài ra, không phải ai cũng có thể để đầu tư một cách hợp lý, mà nhiều khi chỉ theo cảm tính, hay nghe theo chỉ dẫn của những người môi giới chứng khoán.

Với việc đầu tư như vậy, kèm theo việc tỉ lệ lớn những người tham gia chỉ muốn sinh lời nhanh, đầu tư ngắn hạn dẫn đến xác suất đầu tư rủi do, thua lỗ khá lớn. Để có những quyết định đúng đắn, nhà đầu tư cần tìm hiểu và phân tích, lựa chọn các công cụ hỗ trợ hiệu quả Phân tích kỹ thuật là một phương pháp đánh giá thiết yếu, hữu ích, được chứng minh tính hiệu quả rõ rệt trong thực tiễn Phương pháp này cung cấp các chỉ báo kỹ thuật (hay còn gọi là chỉ báo), là các đại lượng được tính toán dựa trên dữ liệu lịch sử giá chứng khoán Bằng các số liệu này, theo dõi các ngưỡng của nó, người dùng có thể có phán đoán tốt hơn trong việc quyết định đầu tư, dự đoán xu hướng chứng khoán tương lai, xác định thời điểm nên giao dịch,giảm tỉ lệ rủi do Một số chỉ báo chứng khoán thông dụng mà nhà đầu tư nên chú ý như MA, EMA, SO, Đồng thời, nhà đầu tư cũng muốn tự thiết lập các chỉ báo,và các cảnh báo liên quan, để kịp thời can thiệp.

Mục tiêu và phạm vi đề tài

Với vần đề trên, việc tồn tại một hệ thống xử lý dữ liệu chứng khoán, cung cấp cho người dùng các số liệu chỉ báo, thiết lập các chỉ báo cho riêng mình, hay cảnh báo chứng khoán định kỳ là rất cần thiết Dựa vào nhu cầu trên, tôi đã khảo sát, tìm hiểu các hệ thống xử lý dữ liệu chứng khoán tiêu biểu, được nhiều người dùng nhất như SSI iBoard 1 (thuộc công ty cổ phần chứng khoán SSI) , TCInvest 2 (thuộc Công ty Cổ phần Chứng khoán Kỹ Thương TCB) , VNDIRECT 3 (thuộc Công

1 https://iboard.ssi.com.vn/

2 https://tcinvest.tcbs.com.vn/

3 https://www.vndirect.com.vn/ ty Cổ phần Chứng khoán VNDIRECT) Các hệ thống này cung cấp giao diện bắt mắt, trực quan hóa bằng các biểu đồ, với số liệu thị trường chứng khoán biến động không ngừng theo thời gian Ngoài ra, các hệ thống trên đều do các công ty chứng khoán phát triển nên cho phép người dùng có thể giao dịch chứng khoán, đặt lệnh mua bán ngay trên hệ thống sau khi định danh tài khoản Tuy nhiên, các hệ thống cũng có một số hạn chế về mặt cung cấp chỉ báo tài chính: các chỉ báo có sẵn, mặc định trên hệ thống, người dùng không thể định nghĩa, thiết lập các chỉ báo theo ý muốn của riêng bản thân mình Các hệ thống trên cũng cung cấp quá nhiều thông tin khác với mật độ cao, màu sắc quá nổi bật khiến người dùng bị rối mắt.

Dựa trên những đặc điểm trên, tôi quyết định xây dựng một hệ thống có chức năng thu thập dữ liệu lịch sử giá chứng khoán định kỳ theo ngày, và tính toán một số chỉ báo nhất định Hệ thống cũng tính toán các chỉ báo cá nhân do người dùng tự định nghĩa theo ý muốn của bản thân, đưa ra các cảnh báo hằng ngày liên quan đến các chỉ báo đó, để giúp nhà đầu tư đưa ra quyết định kịp thời Ngoài ra, hệ thống cũng cung cấp một tính năng phụ: một chatbot thông qua telegram, để giúp người dùng tương tác với hệ thống dễ dàng.

Định hướng giải pháp

Với mục tiêu và phạm vi đã trình bày ở phần 1.2 trên, tôi định hướng giải pháp phát triển hệ thống trên như sau:

Dữ liệu lịch sử chứng khoán sẽ được thu thập định kỳ hằng ngày và lưu trữ lâu dài vào cơ sở dữ liệu Hệ thống sẽ lấy dữ liệu để tính toán một số chỉ báo mặc định của hệ thống Ngoài ra, hệ thống cho phép người dùng tự định nghĩa chỉ báo, nên cũng tính tóan định kỳ chỉ báo người dùng hằng ngày theo định nghĩa người dùng cung cấp Hệ thống kiểm tra các điều kiện nhận cảnh báo chứng khoán người dùng thiết lập dựa trên những số liệu chỉ báo đã tính toán/dữ liệu giá, xem có vượt ngưỡng cảnh báo hay không, và xuất ra cảnh báo nếu có Hệ thống cũng cung cấp người dùng tính năng xem chỉ báo.

Với những định hướng trên, tôi sử dụng Python để đọc và xử lý dữ liệu, tính toán Đối với lưu trữ, tôi sử dụng cơ sở dữ liệu PostgreSQL [1] và tiện ích mở rộng (extensions) của nó: Timescaledb [2] Công nghệ Apache Kafka [3] phụ trợ cho việc dịch chuyển dữ liệu Hệ thống lập lịch xử lý định kỳ với Airflow [4] Để hệ thống chạy, hoạt động ổn định, tôi sử dụng một số công nghệ đóng gói và triển khai ứng dụng như Docker [5], Kubernetes [6] và Helm [7] Với chatbot, tôi sử dụng thư viện python-telegram-bot để xây dựng.

Với định hướng và giải pháp như trên, hệ thống được xây dựng với các tính năng tính toán chỉ báo, thêm mới chỉ báo theo người dùng định nghĩa, đưa ra các cảnh báo chứng khoán, cho phép xem dữ liệu chứng khoán Chatbot giúp người dùng tương tác với hệ thống một cách trực quan, dễ dàng hơn Đồ án đã đáp ứng được những mục tiêu đề ra.

Bố cục đồ án

Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau:

Chương 2 trình bày về khảo sát và phân tích các yêu cầu của hệ thống Tại phần này, đồ án trình bày tổng quan thị trường chứng khoán Việt Nam nói chung, các sản phẩm xử lý dữ liệu chứng khoán đã có và tổng quan sơ đồ thiết kế toàn bộ hệ thống.

Trong chương 3, tôi giới thiệu về các công nghệ được sử dụng trong quá trình xây dựng đồ án trên.

Trong chương 4, tôi sẽ trình bày về cách thiết kế chi tiết, xây dựng các chức năng đã đề cập của hệ thống Mục này bao gồm các thiết kế lớp, thiết kế cơ sở dữ liệu, luồng xử lý của hệ thống, Mục này trình bày chi tiết về cách sử dụng một số công nghệ đề cập ở chương 3.

Cuối cùng, ở chương 5 tôi sẽ trình bày về thực nghiệm và đánh giá trong quá trình xây dựng, triển khai thực tế hệ thống Chương này trình bày về kết quả xây dựng ứng dụng, quá trình đóng gói và triển khai hệ thống với Docker, Kubernetes,Helm, kiểm thử các chức năng của hệ thống.

KHẢO SÁT VÀ PHÂN TÍCH YÊU CẦU

Hiện trạng tình trạng thị trường chứng khoán Việt Nam

Chứng khoán là một loại bằng chứng xác thực quyền sở hữu cũng như lợi ích hợp pháp của người nắm giữ chứng khoán đối với một phần tài sản hay phần vốn của tổ chức phát hành chứng khoán Chứng khoán là tài sản bao gồm cổ phiếu, chứng chỉ quỹ, chứng khoán phái sinh, trái phiếu, chứng quyền, chứng quyền có bảo đảm, quyền mua cổ phần, chứng chỉ lưu ký.

Thị trường chứng khoánlà một phần của hệ thống tài chính trong đó các công ty cổ phần, tổ chức tài chính và cá nhân có thể mua và bán các chứng khoán như cổ phiếu, trái phiếu và các công cụ tài chính khác Thị trường chứng khoán cung cấp cho các doanh nghiệp một nguồn tài trợ trọng yếu để mở rộng hoạt động kinh doanh, đầu tư vào công nghệ và nghiên cứu phát triển Đây cũng là một kênh quan trọng để các nhà đầu tư có thể đầu tư và kiếm lợi nhuận từ các hoạt động giao dịch trên thị trường chứng khoán Có 2 loại thị trường chứng khoán: thị trường chứng khoán sơ cấp và thị trường chứng khoán thứ cấp Thị trường sơ cấp là nơi cổ phiếu lần đầu tiên được phát hành từ công ty để thu hút các nguồn vốn đầu tư từ thị trường chứng khoán, ví dụ như các đợt IPO, ra mắt công chúng lần đầu, Người mua trên thị trường sơ cấp đa phần là các tổ chức lớn hay quỹ đầu tư Thị trường chứng khoán thứ cấp là thị trường giao dịch, trao đổi các loại chứng khoán đã được phát hành trên thị trường sơ cấp Người mua tại thị trường sơ cấp sẽ tiến hành mua bán lại với các nhà đầu tư khác Khi người mới tham gia vào thị trường chứng khoán và đặt lệnh giao dịch thì đó chính là thị trường thứ cấp.

Có 4 thành phần tham gia vào thị trường chứng khoán:

-Nhà phát hành chứng khoán: là những tổ chức thực hiện huy động vốn thông qua thị trường chứng khoán, bao gồm chính phủ, chính quyền địa phương, các công ty.

-Nhà đầu tư chứng khoán: là những người cung cấp vốn cho thị trường chứng khoán Họ thực hiện việc mua và bán chứng khoán trên thị trường chứng khoán với mục tiêu thu được lợi nhuận Nhà đầu tư chứng khoán gồm nhà đầu tư cá nhân và nhà đầu tư có tổ chức.

- Các công ty chứng khoán: Những công ty chứng khoán hay người môi giới trung gian đóng vai trò quan trọng trên thị trường Họ thực hiện nhiệm vụ trung gian, môi giới mua-bán chứng khoán như một định chế tài chính trên thị trường.

Ngoài ra các công ty chứng khoán cũng tư vấn và cung cấp một số dịch vụ khác hỗ trợ doanh nghiệp cũng như nhà đầu tư trên thị trường chứng khoán.

- Cơ quan quản lý: Cơ quan quản lý là chủ thể đảm bảo cho thị trường hoạt động theo đúng quy định nhà nước.

Phân tích kỹ thuậtlà phương pháp được sử dụng để giúp nhà đầu tư đánh giá, quyết định thời điểm đầu tư hay giữ lại giá cổ phiếu trên thị trường Phương pháp này tập trung phân tích các dữ liệu thu thập được từ lịch sử giao dịch, cụ thể là giá và khối lượng Có nhiều loại công cụ được sử dụng trong phân tích kỹ thuật, trong đó các chỉ báo kỹ thuật (hay còn gọi là chỉ báo) là loại công cụ được áp dụng phổ biến và đã chứng minh được hiệu quả trong thực tiễn đầu tư.Chỉ báolà các giá trị được tính toán để đo đạc sự biến động của giá chứng khoán, xác định xu hướng, tìm kiếm các điểm mua vào hoặc bán ra Dựa vào giá trị các loại chỉ báo, nhà đầu tư có thể phán đoán tốt hơn trong giao dịch chứng khoán, đánh giá cơ hội đầu tư và đưa ra các quyết định đầu tư sáng suốt.

Ngoài ra, còn một số khái niệm thông dụng khác:

Cổ phiếu: là loại chứng khoán phổ biến nhất trong thị trường chứng khoán Nó là loại chứng khoán, được phát hành dưới dạng chứng chỉ, xác nhận quyền và lợi ích của nhà đầu tư khi tham gia vào hoạt động kinh doanh của công ty Người nắm giữ cổ phiếu trở thành cổ đông và đồng thời là một trong những chủ sở hữu của công ty phát hành.

Lịch sử giá chứng khoán: bảng thống kê gồm giá, khối lượng và một số thông tin khác của các mã chứng khoán phát sinh giao dịch trong quá khứ theo ngày.

Vùng quá mua: là vùng dữ liệu mà tại đó giá chứng khoán giao dịch lớn hơn định giá thật của nó Điều này xảy ra khi số lượng mua vào nhiều làm đẩy giá cao hơn so với giá trị của chứng khoán.

Vùng quá bán: là vùng dữ liệu mà tại đó giá chứng khoán giao dịch thấp hơn định giá thật của nó Điều này xảy ra khi số lượng mua vào ít làm hạ mức giá so với giá trị của chứng khoán.

2.1.2 Các thông tin cơ bản về một số loại chỉ báo chứng khoán phổ biến

Trong mục này, đồ án trình bày một số thông tin cơ bản của các loại chỉ báo phổ biến, thường được các nhà đầu tư sử dụng để phân tích, đánh giá trong đầu tư chứng khoán Ta sử dụng một số quy ước như sau:

O i : giá mở cửa của ngày giao dịch thứi C i : giá đóng cửa của ngày giao dịch thứi H i : giá cao nhất trong ngày của ngày giao dịch thứi L i : giá thấp nhất trong ngày của ngày giao dịch thứi V i : số lượng cổ phiếu giao dịch của ngày giao dịch thứi ndicator i: giá trị của chỉ báo indicator của ngày giao dịch thứi min{x 1 , , x n }: giá trị nhỏ nhất trong dãyx 1, ,x n max{x 1 , , x n }: giá trị lớn nhất trong dãyx 1 , ,x n Dưới đây là một số các chỉ báo phổ biến:

1 Chỉ báo Moving Average (MA):

• Vai trò: Đường trung bình động MA – Moving Average [8] là đường trung bình của chuỗi giá cả trên thị trường của cổ phiếu trong một khoảng thời gian nhất định Đây là một chỉ báo kỹ thuật được sử dụng trên thị trường tài chứng khoán Đường MA thường dùng để theo dõi sự vận động của giá cổ phiếu theo các xu hướng tăng, giảm hay bình ổn dựa vào dữ liệu giá ở quá khứ. Đường MA thường lấy một số mốc phổ biến như 10, 14, 20,

Chỉ báo MA được dùng để xác định xu hướng giá cổ phiếu sẽ tiếp tục hay đảo chiều ngược lại, từ đó tạo ra các tín hiệu giúp nhà đầu tư nhận biết được thời điểm thích hợp để đưa ra quyết định mua vào và bán ra.

MA được sử dụng phổ biến, nó phản ánh tâm lý của nhà đầu tư tại ngưỡng hỗ trợ và kháng cự khá sát thực tế.

Tổng quan hệ thống

Hệ thống thu thập và xử lý dữ liệu giá chứng khoán đáp ứng một số yêu cầu chức năng sau:

Thu thập dữ liệu của tất cả các công ty phát hành chứng khoán từ sàn giao dịch, và lưu trữ vào cơ sở dư liệu Hệ thống thực hiện lập lịch và thực hiện các tính toán hằng ngày để tính giá trị chỉ báo, rồi lưu trữ vào cơ sở dữ liệu Ngoài ra, hệ thống cho phép người dùng tự định nghĩa chỉ báo chứng khoán, tính toán và lưu trữ định kỳ chỉ báo chứng khoán đó Tiếp đến, người dùng có thể thiết lập các cảnh báo chứng khoán hằng ngày với các chỉ báo/dữ liệu trên hệ thống Cuối cùng, hệ thống cung cấp chatbot telegram cho phép người dùng tương tác với hệ thống, và gửi cảnh báo nếu có thông qua giao diện.

2.2.2 Yêu cầu phi chức năng

Hệ thống có yêu cầu phi chức năng như sau: Dữ liệu phải được thu thâp, lưu trữ đầy đủ và không mất mát dữ liệu Hệ thống cần phản hồi nhanh với yêu cầu người dùng, hoạt động ổn định Giao diện chatbot telegram phải rõ ràng, bố cục dễ hiểu, hướng dẫn chi tiết cách sử dụng.

Dựa vào những yêu cầu chức năng và phi chức năng trên, hệ thống được thiết kế như sau:

Hình 2.1: Biểu đồ tổng quan hệ thống

Biểu đồ trên thể hiện luồng hoạt động của hệ thống cũng như các thành phần trong hệ thống.

Luồng thu thập và lưu trữ dữ liệu thực hiện thu thập dữ liệu của tất cả các mã cổ phiếu của các công ty niêm yết trên sàn chứng khoán từ API công khai của TCBS.

Sau đó, dữ liệu được đẩy vào Kafka, rồi được tiêu thụ bằng cách lưu trữ lâu dài trong cơ sở dữ liệu PostgreSQL, timescaledb Luồng này được lập lịch chạy hằng ngày, sau khi phiên giao dịch kết thúc bởi Airflow.

Luồng tính toán chỉ báo và gửi thông báo: luồng này được lập lịch chạy hằng ngày bởi Airflow Luồng này thực hiện tính toán chỉ báo cho cả chỉ báo mặc định hệ thống và chỉ báo người dùng tự định nghĩa Trình xử lý chỉ báo sẽ lấy dữ liệu cần thiết từ PostgreSQL, timescaledb, tính toán giá trị chỉ báo Kế tiếp sẽ kiểm tra các điều kiện nhận cảnh báo xem có vượt ngưỡng hay không, và gửi cảnh báo đến Kafka nếu có Một consumer được chạy để lấy dữ liệu từ Kafka và gửi cảnh báo đến người dùng.

Luồng xử lý yêu cầu của người dùng: Người dùng tương tác với hệ thống thông qua Telegram chatbot Tùy vào yêu cầu người dùng, trình xử lý chatbot sẽ truy cập vào cơ sở dữ liệu, lưu trữ/trả về kết quả cần thiết cho người dSùng, hoặc sẽ sinh Airflow DAG mới nếu người dùng muốn tạo chỉ báo cá nhân.

Toàn bộ hệ thống được triển khai với Kubernetes.

Dưới đây làbiểu đồ ca sử dụng của một số chức năng chính trong hệ thống:

Hình 2.2: Biểu đồ ca sử dụng một số chức năng chính của hệ thống

Tác nhân timer (trình lập lịch) sẽ thực hiện các ca sử dụng thu thập và lưu trữ dữ liệu, tính toán chỉ báo, kiểm tra cảnh báo Tác nhân người dùng thực hiện ca sử dụng tạo chỉ báo cá nhân, tạo cảnh báo Ca sử dụng kiểm tra cảnh báo trả kết quả cho tác nhân người dùng.

Dưới đây là đặc tả 2 ca sử dụng (use case) quan trọng: tạo chỉ báo cá nhân và tạo cảnh báo: Đặc tả ca sử dụng tạo chỉ báo cá nhân

Bảng 2.1: Đặc tả ca sử dụng tạo chỉ báo cá nhân

Mã use case UC01 Tên use case Tạo chỉ báo cá nhân

Luồng sự kiện chính (thành công)

STT Thực hiện bởi Hành động

1 Người dùng Yêu cầu tạo chỉ báo cá nhân

2 Người dùng Nhập thông tin của chỉ báo, hàm tính toán chỉ báo

3 Hệ thống Kiểm tra dữ liệu đầu vào và lưu trữ vào cơ sở dữ liệu

4 Hệ thống Sinh lớp con định nghĩa trình tính toán chỉ báo vừa tạo

5 Hệ thống Thông báo cho người dùng tạo chỉ báo thành công

Luồng sự kiện thay thế

STT Thực hiện bởi Hành động

3.a Hệ thống Thông báo lỗi nếu dữ liệu đầu vào chưa hợp lệ

Hậu điều kiện Không Đặc tả ca sử dụng tạo cảnh báo

Bảng 2.2: Đặc tả ca sử dụng tạo cảnh báo

Mã use case UC02 Tên use case Tạo cảnh báo

STT Thực hiện bởi Hành động

1 Người dùng Yêu cầu tạo cảnh báo

Nhập thông tin của cảnh báo, bao gồm mã cổ phiếu, loại chỉ báo, loại ngưỡng và giá trị ngưỡng

3 Hệ thống Kiểm tra dữ liệu đầu vào và lưu trữ vào cơ sở dữ liệu

Nếu thiết lập cảnh báo cho chỉ báo người dùng tự định nghĩa, hệ thống tạo DAG/thêm task vào DAG Task trong DAG thực hiện tính toán giá trị chỉ báo cho mã cổ phiếu vừa được thiết lập cảnh báo.

5 Hệ thống Thông báo cho người dùng tạo cảnh báo thành công

Luồng sự kiện thay thế

STT Thực hiện bởi Hành động

3.a Hệ thống Thông báo lỗi nếu dữ liệu đầu vào chưa hợp lệ

CÔNG NGHỆ SỬ DỤNG

Công nghệ streaming dữ liệu: Apache Kafka

Apache Kafka [3] là công nghệ được sử dụng trong quá trình thu thập dữ liệu, lưu trữ message trung gian trong quá trình gửi cảnh báo đã trình bày trong mục 2.2.3.

Apache Kafka là một nền tảng phát trực tuyến (streaming) dòng dữ liệu dưới dạng tin nhắn (message), chủ yếu được áp dụng trong hệ thống phân tán Mỗi tin nhắn trong Kafka là một bản ghi dữ liệu Kafka được tối ưu hóa để nhập và chuyển đổi dữ liệu phát trực tuyến theo thời gian thực.

Kafka nhận dữ liệu từ nguồn và lưu trữ tạm thời nó Người sử dụng dữ liệu có thể lấy dữ liệu từ Kafka và xử lý chúng Thông qua Kafka, quá trình gửi dữ liệu và quá trình nhận/sử dụng dữ liệu được tách riêng biệt với nhau Người dùng có thể sử dụng dữ liệu bất cứ lúc nào mà người dùng muốn, không cần phải nhận và xử lý dữ liệu ngay khi nguồn gửi dữ liệu.

Một trong những khái niệm thông dụng thường gặp trong Kafka là topic, broker, producer, consumer.

Topic (chủ đề), là tập hợp một nhóm tin nhắn Mỗi chủ đề được chia thành nhiều phân vùng (partition) khác nhau Khi nguồn gửi tin nhắn hoặc sự kiện vào một chủ đề Kafka cụ thể, chủ đề sẽ lần lượt thêm các tin nhắn vào vị trí cuối cùng của các phân vùng Vì vậy, trong cùng một phân vùng, các tin nhắn đằng trước luôn có thời gian xuất hiện (thời gian được gửi đến Kafka) sớm hơn các tin nhắn sau Bằng cách tạo chủ đề Kafka, người dùng có thể thực hiện phân tách hợp lý giữa các tin nhắn.

Mỗi chủ đề tương đồng với khái niệm về bảng trong cơ sở dữ liệu Mỗi tin nhắn trong chủ đề tương đồng với khái niệm về các dòng trong cơ sở dữ liệu Chỉ khác là chủ đề không có lược đồ dữ liệu(schema), trong khi đó bảng thì có Trong ApacheKafka, ta có thể tạo bất kỳ số lượng chủ đề nào dựa trên các trường hợp sử dụng của mình Tuy nhiên, mỗi chủ đề phải có một tên duy nhất và có thể nhận dạng để phân biệt nó với các chủ đề khác trong cụm Kafka.

Broker (nhà môi giới), là thành phần để lưu trữ dữ liệu gửi đến Kafka Mỗi broker tương ứng với một máy tính vật lý/máy ảo Trong môi trường phân tán, kafka được triển khai duới dạng một cụm gồm nhiều broker Dữ liệu trong Kafka được lưu trữ dư thừa, lặp lại với một số lần nhất định và được lưu trữ phân tán trong các broker Khi một vài broker bị lỗi, chết, dữ liệu đảm bảo không bị mất đi mà vẫn có thể lấy từ các broker đang hoạt động để khôi phục lại.

Hình 3.1: Kiến trúc của Kafka

Source: https://developerexperience.io/articles/kafka

Producer(người sản xuất) là thành phần gửi dữ liệu từ nguồn bên ngoài đến Kafka Khi gửi dữ liệu, người sản xuất cần chỉ định rõ topic muốn gửi đến, không cần quan tâm dữ liệu sẽ được gửi đến phân vùng nào Tuy nhiên, nếu muốn, người sản xuất vẫn có thể chỉ định phân vùng muốn gửi, bằng cách chỉ rõ phân vùng.

Hoặc người sản xuất cũng có thể gửi kèm dữ liệu với một trường khóa, tin nhắn nào có khóa trùng nhau sẽ được lưu chung vào một phân vùng.

Consumer (người tiêu dùng) là thành phần sử dụng dữ liệu từ Kafka Consumer đọc dữ liệu từ Kafka, và xử lý nó Để đọc được dữ liệu từ Kafka, consumer phải theo dõi topic cụ thể Nó có thể tùy chọn số lượng dữ liệu cần đọc thông qua offset.

Offset là số thứ tự của tin nhắn trong phân vùng Số thứ tự tăng là số tăng dần,và consumer có thể quyết định đọc dữ liệu từ số thứ tự nào, từ lúc bắt đầu, hay đọc từ vị trí hiện tại, Khi consumer đọc và xử lý dữ liệu từ Kafka, mỗi tin nhắn,consumer đều thực hiện commit offset - tức là gửi offset vị trí đang đọc hiện tại cho Kafka để Kafka lưu lại Khi consumer đột ngột bị lỗi, sau khi khắc phục sự cố và chạy lại, dựa vào offset đã gửi lên hệ thống, consumer vẫn có thể biết được những tin nhắn nào chưa được xử lý trong thời gian consumer lỗi để xử lý tiếp.

Công nghệ lập lịch tính toán: Apache Airflow

Apache Airflow [4] là công cụ dùng để lập lịch, lên kế hoạch chạy các tác vụ(task) trong toàn bộ đồ án.

Apache Airflow là nền tảng cho phép người dùng tạo, lên lịch và giám sát quy trình công việc Với giao diện trực quan hóa thứ tự các tác vụ, công việc, Airflow hữu ích cho việc kiến trúc và sắp xếp các đường dẫn dữ liệu phức tạp cũng như khởi chạy tác vụ.

Airflow là một công cụ dễ sử dụng: người dùng có thể thiết kế luồng công việc thông qua việc lập trình Python Với cú pháp đơn giản, những người không quen với Python cũng có thể sử dụng một cách nhanh chóng Airflow cung cấp rất nhiều plugin để kết nối tới và thực thi các tác vụ bởi các ứng dụng bên ngoài.

Một số các khái niệm cơ bản trong Airflow:

DAG: là một đồ thị có hướng, biểu diễn quy trình thực thi các tác vụ nhỏ trong một công việc nhất định Nó là tập hợp các tác vụ cần thực hiện cho công việc, và các mối liên hệ phụ thuộc giữa các tác vụ đó Mỗi node trong đồ thị DAG đại diện cho một tác vụ cụ thể, và đường nối từ node này đến node khác thể hiện thứ tự thực hiện của các node đó Ví dụ: đường nối giữa 2 node A và B, có chiều từ A đến B thể hiện tác vụ A sẽ được thực hiện trước tác vụ B trong hệ thống.

Task(tác vụ): đây là đơn vị công việc nhỏ nhất trong Airflow Nó là một tác vụ cần thực hiện trong quy trình công việc, được thể hiện dưới dạng node trong DAG.

DAG và task trong Airflow định nghĩa về tác vụ, và thứ tự thực hiện các tác vụ đó trong công việc Nó mô tả về luồng và các tác vụ trong công việc Khi một DAG được chạy, DAG instance và task instance được tạo ra - là trạng thái động của DAG và task, sẽ chứa thêm các thông tin về trạng thái, thời gian, kết quả thực thi,

Dưới đây là kiến trúc và luồng hoạt động của Airflow:

Hình 3.2: Kiến trúc và luồng hoạt động của Airflow

Source: https://www.altexsoft.com/blog/apache-airflow-pros-cons/

Các thành phần chính của Airflow gồm webserver, scheduler, worker và execu- tor, metadata database.

Người dùng định nghĩa các luồng công việc dưới dạng các DAG file và đặt chúng vào DAG folder.

Scheduler là thành phần lập lịch của hệ thống Nó đọc các tệp trong thư mục DAG, rồi lên lịch cho các task trong DAG: thực thi với thời điểm nào, thực thi theo thứ tự nào, Scheduler gửi lịch chạy đến executor.

Executor là thành phần điều phối thực thi của Airflow Scheduler không chạy bất cứ tác vụ nào mà gửi nó cho executor Executor cũng không chạy tác vụ, nhưng gán tác vụ cho ”nhân viên” để ”nhân viên” của nó trực tiếp thực hiện Executor hoạt động như một người trung gian, điều phối công việc, phân chia tài nguyên sao cho Airflow hoạt động hiệu quả nhất.

Worker là thành phần trực tiếp gọi và xử lý các task Nó trực tiếp sử dụng tài nguyên của Airflow để tính toán.

Metadata database là siêu dữ liệu của Airflow Nó lưu trữ thông tin về trạng thái thực thi các tác vụ, các DAG hiện đang có,

Webserverlà thành phần để hiển thị giao diện trực quan các tác vụ, DAG cho người dùng.

Công nghệ sinh dữ liệu theo mẫu: Jinja2

Jinja2 [9] là một thư viện của Python - cung cấp chức năng sinh tệp dựa theo mẫu có sẵn Trong đồ án này, một trong những chức năng quan trọng nhất là lập lịch, tính toán chỉ báo người dùng tự định nghĩa Để làm được điều đó, cần phải sinh ra các lớp, các file DAG chứa tác vụ mới để thực thi jinja2 được sử dụng trong đồ án này để hoàn thành công việc trên Một số công cụ khác có chức năng tương tự có thể tham khảo thêm/thay thế như Diajango, Mako.

Hình 3.3: Quá trình sinh tệp từ mẫu của jinja2

Jinja2 tách cấu trúc của tệp văn bản thành 2 phần: phần dữ liệu thay đổi và phần dữ liệu cố định Đối với phần dữ liệu cố định, nó chứa những dòng văn bản với những khoảng trống nhất định được đánh dấu lại Mỗi khi muốn sinh một tệp dữ liệu mới, ta chỉ cần thay đổi phần dữ liệu, phần cố định giữ nguyên, jinja2 sẽ điền,thay thế dữ liệu vào các trường đang khuyết của phần cố định để tạo ra một tệp văn bản hoàn chỉnh.

Cơ sở dữ liệu: PostgreSQL và tiện ích mở rộng TimescaleDB

Trong đồ án này, cơ sở dữ liệu dùng để lưu trữ dữ liệu là PostgreSQL [1], được cài thêm kèm với tiện ích mở rộng (extension) của nó là TimescaleDB [2] để tối ưu hóa truy vấn cho những dữ liệu dạng chuỗi thời gian(time series).

PostgreSQL là hệ thống cơ sở dữ liệu quan hệ mã nguồn mở, một trong những cơ sở dữ liệu sử dụng phổ biến nhất hiện nay Với ưu điểm chạy ổn định, ít khi cần phải bảo trì, cộng đồng hỗ trợ mạnh mẽ, Postgres thu hút được lượng lớn người sử dụng.

TimescaleDB là một công cụ mở rộng của PostgreSQL, được tối ưu hóa cho những dữ liệu dạng time series Nó sử dụng lại cấu trúc lưu trữ của PostgreSQL, nhưng có nâng cấp thêm, từ đó không những tận dụng được tính dễ sử dụng, ổn định của PostgreSQL mà còn tăng tốc độ truy vấn.

TimescaleDB sử dụnghypertable được xây dựng thêm trên nền các bảng Post- greSQL thông thường Hypertable là bảng PostgreSQL được phân vùng theo thời gian thành nhiều phần khác nhau Các phần này được trừu tượng hóa thành một bảng lớn, gọi là hypertable Khi thực hiện các câu truy vấn với các bảng chứa trường dữ liệu thời gian tương tự như truy vấn trên PostgreSQL thông thường, nhưng thực chất là truy vấn trên hypertable.

Mỗi hypertable được tạo thành từ tập hợp các bảng con gọi làchunk Mỗi chunk tương ứng với một khoảng thời gian và chỉ được chứa dữ liệu trong khoảng thời gian đó Ngoài ra, còn có thể phân vùng bảng theo một số trường dữ liệu khác ngoài thời gian Khi đó, hypertable được chia thành các chunk theo thời gian, bên trong mỗi chunk được phân vùng theo các trường dữ liệu khác [10]

Bằng vào việc mỗi chunk chỉ chứa một khoảng thời gian xác định, khi truy vấn với điều kiện thời gian, có thể nhanh chóng xác định được trường dữ liệu cần tìm ở chunk nào.

Hình 3.4: Cấu trúc bảng Hypertable[10]

Trong hình trên, dữ liệu được phân vùng thành các chunk Mỗi chunk tương ứng với 1 ngày(Tham số chunk_time_interval có giá trị 1) Khi cần truy vấn, timescaledb sẽ biết được ngay dữ liệu ngày này nằm ở chunk nào, từ đó tăng tốc độ truy vấn Ta có thể tùy chỉnh khoảng thời gian để phân vùng dữ liệu thành các chunk.

Biểu đồ dưới đây so sánh tốc độ chèn dữ liệu vào bảng của PostgreSQL vàTimescaleDB Khi kích cỡ bảng trong PostgreSQL càng tăng, tốc độ chèn dữ liệu vào bảng càng chậm Trong khi đó, kích cỡ chèn dữ liệu của timescaledb không thay đổi nhiều.

Hình 3.5: So sánh tốc độ chèn dữ liệu của PostgreSQL và Timescaledb [11]

Ngoài ra, timescaledb cũng có tốc độ nhanh hơn gấp nhiều lần so với cơ sở dữ liệu influxdb - một cơ sở dữ liệu NoSQL phổ biến thường được dùng nhất cho dữ liệu time series.

Công nghệ tạo chatbot telegram: python-telegram-bot

Phần 3.5 này trình bày về python-telegram-bot, một thư viện được sử dụng để làm chatbot telegram Trong phạm vi đồ án này, chatbot giúp cho người dùng tương tác với hệ thống để xem số liệu chứng khoán, đặt cảnh báo, định nghĩa chỉ báo mới,

Thư viện python-telegram-bot được xây dựng từ API chính thức được cung cấp bởi telegram Ngoài việc bao gồm các API thuần túy, thư viện này còn có một số lớp cấp cao để giúp việc phát triển bot trở nên dễ dàng và đơn giản Các lớp này được chứa trong module telegram.ext.

Thông qua việc sử dụng các phương thức CommandHandler (dùng để lọc và xử lý các câu lệnh người dùng), MessageHandler (lọc và xử lý tin nhắn thông thường),ConversationHandler (dùng để tạo và xử lý một cuộc hội thoại trong ngữ cảnh nhất định), thư viện trên giúp người dùng dễ dàng tạo một chatbot telegram đơn giản.

Công nghệ đóng gói và triển khai ứng dụng: Docker, Kubernetes, Helm

Trong phần 3.6 này, đồ án sẽ trình bày về công nghệ đóng gói và triển khai ứng dụng: Docker, Kubernetes và Helm.

Docker [5] là một công nghệ cho phép xây dựng, chạy, thử nghiệm và triển khai các ứng dụng phân tán Nó sử dụng ảo hóa cấp hệ điều hành để chạy phân tán các ứng dụng, dưới dạng vùng chứa (container) Docker đóng gói một ứng dụng, các công cụ hệ thống cần thiết và các thành phần phụ thuộc,thư viện của nó trong một vùng chứa ảo có thể chạy trên bất kỳ máy tính nào.

Một số khái niệm cơ bản, thường gặp trong Docker là:

Image: Một gói chứa ứng dụng người dùng, các thành phần phụ thuộc và tất cả những gì khác cần thiết để ứng dụng có thể hoạt động Tuy nhiên, image có tính bất biến, chỉ là các mẫu, chỉ đọc (read-only)

Container: Là phiên bản chạy trong thời gian thực của image - hoạt động trong thời gian thực, dữ liệu, trạng thái, có thể thay đổi được. registry: Đây là kho lưu trữ image Khi xây dựng xong ứng dụng, có thể gửi image ứng dụng đến registry để lưu trữ Dockerhub là kho lưu trữ công khai của cộng đồng, tất cả mọi người đều có thể đẩy image đến Dockerhub và dùng image của nhau Ngoài ra, còn có các kho lưu trữ riêng tư (private registry) mà chỉ có người tạo hoặc người được chia sẻ mới được sử dụng image.

Kubernetes[12] là một nền tảng điều phốicontainer(vùng chứa), tự động hóa nhiều quy trình thủ công liên quan đến việc triển khai, quản lý và thay đổi quy mô các ứng dụng được chứa trong container Kubernetes được sử dụng khi cần quản lý và triển khai một hệ thống phức tạp với nhiều container hoặc microservices.

Container là một trong những giải pháp để đóng gói và chạy các ứng dụng.

Chúng cho phép dễ dàng để đóng gói và triển khai các dịch vụ, sử dụng tài nguyên hiệu quả và rất nhẹ trong quá trình chạy Tuy nhiên, trong môi trường sản xuất, việc quản lý container rất khó khăn, bởi cần quản lý các container chạy các ứng dụng và đảm bảo rằng không ngừng hoạt động.

Nếu một container gặp sự cố, thì một container khác cần phải khởi động ngay Số lượng có thể lên tới hàng trăm, thậm chí hàng nghìn container theo thời gian Những container này cần được triển khai, theo dõi sát tình trạng hoạt động Sẽ rất khó để làm tất cả mọi thứ trên một cách thủ công.

Kubernetes cung cấp một hệ thống quản lý các container chạy phân tán,đáp ứng được yêu cầu nêu trên Nó có thể khởi động lại khi container gặp sự cố, mở rộng quy mô và chuyển đổi dự phòng cho ứng dụng,

Hình 3.6: Kiến trúc của Kubernetes

Source: https://www.linkedin.com/pulse/kubernetes-architecture-installation-roli-singh

Trên hình là kiến trúc tổng quan hệ thống Kubernetes.

Master, hay còn gọi là Control Panel, là thành phần giám sát, quản lý toàn cụm Kubernetes Master chứa các thành phầnAPI Server,scheduler, controller manager API server giao tiếp với toàn bộ hệ thống Người dùng cuối/các thành phần khác của hệ thống tương tác với API server để thực hiện các yêu cầu.Scheduler chịu trách nhiệm lên lịch cho các Pod trong worker node.Controller manager liên tục theo dõi trạng thái thực tế và mong muốn của các đối tượng, và thực thi các công việc để đảm bảo hai trạng thái trùng nhau.

Worker Node là thành phần trực tiếp đảm bảo việc thực thi công việc.

Mỗi node có thể là một máy ảo hoặc vật lý, tùy thuộc vào cụm Mỗi node được quản lý bởi master và chứa các dịch vụ cần thiết để chạy Pod.kube- proxy là thành phần nằm trong các worker node, chịu trách nhiệm liên quan đến kết nối mạng của các node, giúp kết nối với nhau, kết nối bên ngoài kubelet là thành phần quản lý chung trong worker node, và chịu trách nhiệm giao tiếp với master node Nó trực tiếp thực hiện các công việc tạo, cập nhật, xóa, pod trên worker node. etcdlà cơ sở dữ liệu của Kubernetes, lưu trữ mọi thông tin của cụm, như trạng thái pod, số lượng pod,

Podlà đơn vị triển khai nhỏ nhất trong Kubernetes Kubernetes quản lý các container qua pod Nó là một nhóm gồm một hoặc nhiều container đang chạy một ứng dụng Pod được lưu trữ và khởi tạo, chạy tại các node trong cụm Kubernetes Khi một pod bị ngừng hoạt động, Kubernetes sẽ khởi động lại pod đó trên cùng một node, hoặc một node khác trong cụm.

Ngoài ra, còn một số khái niệm thông dụng khác:

Persistent volume là phần không gian lưu trữ dữ liệu trong cụm, được cấp phát với mục đích lưu trữ dữ liệu bên trong các Pod Khi các Pod gặp sự cố, dựa vào Persistent Volume claim, sau khi khởi động lại các Pod vẫn có đầy đủ dữ liệu như trước khi gặp sự cố.

Persistent volume claimlà yêu cầu sử dụng không gian lưu trữ ( yêu cầu persistent volume)

Service là tập hợp một số cách thức cấu hình mạng Nó hỗ trợ cho việc giao tiếp, điều hướng giữa các Pod với nhau Một số service nổi bật như NodePort cho phép truy cập cổng của pod thông qua cổng máy ngoài, LoadBalancer điều hướng các yêu cầu người dùng đến một nhóm Pod sao cho cân bằng giữa chúng, namespace là một thành phần logic để phân chia các nhóm tài nguyên thành các vùng khác nhau, từ đó tăng hiệu quả trong việc quản lý tài nguyên

Helm [7] là một trình quản lý gói và công cụ quản lý ứng dụng cho Ku- bernetes Helm đóng gói cách triển khai ứng dụng lại thành duy nhất một thành phần gọi là chart Điều này giúp cho người triển khai ứng dụng không cần phải chạy từng tệp một, mà chỉ cần chạy một lần duy nhất.

Mỗi lần triển khai ứng dụng, người dùng có thể có những cấu hình khác nhau Việc truy cập vào từng tệp để sửa rất tốn thời gian Helm đã giải quyết việc trên bằng cách tách biệt tệp triển khai ứng dụng thành 2 phần: phần template (khuôn mẫu) và phần dữ liệu Phần template là mẫu để triển khai ứng dụng, với những chỗ cấu hình quan trọng được để trống Người sử dụng có thể điền các cấu hình này vào phần dữ liệu, Helm sẽ kết hợp phần template và phần dữ liệu để triển khai ứng dụng.

THIẾT KẾ HỆ THỐNG

Thu thập và lưu trữ dữ liệu giá chứng khoán

Dữ liệu được sử dụng cho đồ án này là dữ liệu giá cổ phiếu trên thị trường chứng khoán Việt Nam của 1610 công ty đang niêm yết trên sàn giao dịch Dữ liệu được thu thập bằng cách sử dụng API được cung cấp công khai bởi công ty cổ phần chứng khoán kỹ thương Techcom Securities – TCBS định kỳ hằng ngày.

Việc thu thập dữ liệu gồm 2 phần:

Thu thập thông tin công ty, trong đó chứa mã cổ phiếu các công ty đang niêm yết trên sàn chứng khoán Sau khi thực hiện xong bước này, ta được kết quả là file dữ liệu companies.csv gồm thông tin của 1610 công ty đang có trên sàn chứng khoán Sau đó, dữ liệu sẽ được đẩy vào cơ sở dữ liệu Postgres và lưu trữ.

Hình 4.1: Thông tin công ty được lưu trữ trong cơ sở dữ liệu

Thu thập định kỳ giá chứng khoán hằng ngày của các mã cổ phiếu có được ở bước trước Dữ liệu được thu thập 1 ngày 1 lần vào lúc 15h15 từ thứ 2 đến thứ6 hằng tuần - sau khi các phiên giao dịch chứng khoán kết thúc Bằng cách duyệt lần lượt danh sách các mã cổ phiếu thu thập được ở bước trước và gọiAPI dữ liệu giá chứng khoán của TCBS, ứng với mỗi mã cổ phiếu, ta thu thập được 1 bản ghi Tiếp đến, dữ liệu được lần lượt đẩy vào một topic của Kafka tên là stock Tại Kafka, dữ liệu sẽ được tiêu thụ: lưu trữ vào cơ sở dữ liệu, xử lý,

Hình 4.2: Log ghi dữ liệu vào Kafka

Dữ liệu được đọc từ Kafka và lưu trữ lâu dài tại cơ sở dữ liệu PostgreSQL, TimescaleDB Mỗi bản ghi dữ liệu gồm 7 trường: symbol (mã cổ phiếu), time (ngày giao dịch), open (giá chứng khoán lúc mở cửa), close (giá chứng khoán lúc cuối ngày), high (giá chứng khoán tại thời điểm giá cao nhất trong ngày), low (giá chứng khoán tại thời điểm giá thấp nhất trong ngày), volume (số lượng cổ phiếu được giao dịch trong phiên ngày hôm đó), sẽ được lưu trữ vào bảng stock trong cơ sở dữ liệu.

4.2 Tính toán các chỉ báo

Trong phạm vi đồ án này, có 2 loại chỉ báo được tính toán hằng ngày: chỉ báo được cung cấp sẵn, và chỉ báo được người dùng tự định nghĩa để tạo cảnh báo. Ở mục này, đồ án sẽ trình bày chi tiết việc thiết kế chức năng tính toán chỉ báo của thị trường chứng khoán, cho cả 2 loại chỉ báo được nêu trên.

4.2.1 Thiết kế luồng tính tóan chỉ báo

Dữ liệu được được đọc từ cơ sở dữ liệu PostgreSQL Sau khi tính toán kết quả các chỉ báo, dữ liệu các chỉ báo sẽ được lưu vào các bảng trong PostgreSQL.

Dưới đây là sơ đồ luồng tính toán chỉ báo:

Hình 4.3: Sơ đồ luồng tính toán chỉ báo

4.2.2 Biểu đồ lớp trình tính toán chỉ báo

Biểu đồ lớp trình tính toán chỉ báo được thiết kế như sau:

Hình 4.4: Sơ đồ gói trình tính toán chỉ báo

Cả trình tính toán chỉ báo được hệ thống cung cấp sẵn hay trình tính toán chỉ báo cho người dùng tự định nghĩa đều được kế thừa abstract class Indicator Trong đó, các lớp trình tính toán chỉ báo do hệ thống cung cấp được đặt tên theo định dạng TenChiBao + Indicator, các lớp tính toán chỉ báo do người dùng định nghĩa được đặt tên theo định dạng tenchibao + userid + Indicator.

4.2.3 Đặc tả lớp Indicator và các lớp con

Lớp Indicator là lớp trừu tượng định nghĩa trình tính toán chỉ báo, được thiết kế như hình sau:

Hình 4.5: Sơ đồ lớp trình tính toán chỉ báo

Các thuộc tính của lớp Indicator:

• database_connection: Thuộc tính database_connection là instance của lớp Post- gresConnection Lớp này được xây dựng với mục đích thuận tiện hơn cho việc kết nối tới PostgresSQL Nó cung cấp con trỏ, connection đến cơ sở dữ liệu, các phương thức để truy vấn, commit và đóng kết nối tới cơ sở dữ liệu Dưới đây là sơ đồ lớp PostgresConnection:

Hình 4.6: Sơ đồ lớp PostgresConection

• user_id: Thuộc tính user_id là id định danh người tạo chỉ báo Mỗi id định danh một người dùng duy nhất Đối với chỉ báo được hệ thống cung cấp sẵn, user_id được khởi tạo là chuỗi rỗng.

• indicator_name: Thuộc tính này định danh tên chỉ báo Người dùng khác nhau có thể đặt tên chỉ báo trùng nhau, nhưng một người dùng không được định nghĩa hai chỉ báo có trùng tên nhau.

Các phương thức của lớp Indicator:

• get_inputs(symbol: String): Phương thức này dùng để lấy những dữ liệu cần thiết để tính toán chỉ báo của ngày hiện tại Đầu vào là mã cổ phiếu Đầu ra của phương thức là danh sách 2 DataFrame dùng để tính toán chỉ báo: dataframe chứa dữ liệu giá chứng khoán cần lấy, và dataframe chứa dữ liệu chỉ báo khác/chỉ báo của chính nó nhưng thuộc về những ngày trước. Đối với chỉ báo mới người dùng tự định nghĩa, khi định nghĩa chỉ báo, người dùng sẽ cần phải nhập thông tin dữ liệu cần lấy để tính toán chỉ báo, hàm tính chỉ báo Định nghĩa chỉ báo sẽ được lưu trữ vào trong cơ sở dữ liệu Hàm get_inputs sẽ đọc trong cơ sở dữ liệu thông tin định nghĩa chỉ báo (gồm các trường, các bảng dữ liệu cần đọc để lấy dữ liệu), sau đấy sẽ lần lượt truy vấn vào các bảng dữ liệu cần đọc trên để trả kết quả về Đối với chỉ báo hệ thống cung cấp, để tăng hiệu năng tính toán, tránh việc rẽ nhánh nhiều trong hàm get_inputs, hàm này sẽ được ghi đè lại.

• compute(ticker_data: DataFrame, indicator_data: DataFrame): phương thức này là phương thức trừu tượng (abstract class) Phương thức này tính toán để trả về giá trị của chỉ báo ngày hôm nay cho một mã cổ phiếu duy nhất Đầu vào gồm 2 DataFrame được trả về từ phương thức get_inputs(symbol: String) ở trên, trong đó dataframe ticker_data là dữ liệu lịch sử giá chứng khoán, indicator_data là dữ liệu chỉ báo khác/chỉ báo của chính indicator được định nghĩa nhưng của những ngày trước Do một chỉ báo có thể có nhiều tham số khác nhau, đầu ra là danh sách các số thực (List) giá trị của chỉ báo của ngày hiện tại.

• save_data(result: List, symbol: String): Phương thức này dùng để lưu trữ các giá trị chỉ báo tính toán được của ngày hiện tại vào trong cơ sở dữ liệu Sau khi tính toán xong ở phương thức compute, kết quả cần được lưu trữ Đầu vào gồm trường result là danh sách giá trị của chỉ báo, symbol là mã cổ phiếu ứng với kết quả chỉ báo được tính toán ở trên.

• compute_symbol(symbol: String): Phương thức này tổng hợp lại tất cả quá trình để tính toán chỉ báo cho một mã chứng khoán cụ thể Nó gọi get_inputs để lấy dữ liệu, truyền dữ liệu vào compute để tính toán và lưu kết quả trả về bằng phương thức save_data. Đối với các trình tính toán chỉ báo hệ thống cung cấp sẵn: Các chỉ báo này sẽ được tính toán mỗi ngày cho tất cả các mã cổ phiếu trên thị trường Để tăng hiệu năng, tránh rẽ nhánh nhiều, hầu hết các phương thức lớp Indicator sẽ được ghi đè lại, trừ phương thức compute_symbol Đồng thời sẽ định nghĩa thêm phương thức compute_all() tính toán giá trị chỉ báo cho tất cả các mã cổ phiếu Nó lặp qua tất cả các mã chứng khoán, với mỗi mã chứng khoán sẽ gọi phương thức compute_symbol ở lớp cha. Đối với trình tính toán chỉ báo người dùng tự định nghĩa: người dùng chỉ cần ghi đè lại duy nhất phương thức compute Tất cả phương thức khác hệ thống định nghĩa sẵn từ lớp cha.

4.2.4 Thiết kế cơ sở dữ liệu

Dưới đây là cơ sở dữ liệu cho chức năng tính toán chỉ báo Trong đó:

• Bảng companies chứa dữ liệu các công ty niêm yết trên sàn chứng khoán Nó gồm các trường symbol: mã cổ phiếu, name: tên công ty, industry: tên ngành kinh doanh của công ty

Lập lịch thu thập và tính toán dữ liệu

Do ứng dụng thu thập dữ liệu hằng ngày sau phiên giao dịch, xử lý dữ liệu và gửi cảnh báo đến cho người dùng định kỳ nên việc lập lịch cho ứng dụng là không thể thiếu Các thành phần cần lập lịch bao gồm:

• Thành phần thu thập dữ liệu bằng API của TCBS: thành phần này được lập lịch chạy định kỳ vào lúc 15h15 hằng ngày, sau khi phiên giao dịch kết thúc để thu thập dữ liệu của tất cả các mã chứng khoán về.

• Thành phần lưu trữ dữ liệu và tính toán các chỉ báo được hệ thống cung cấp sẵn: thành phần này được khởi chạy sau khi dữ liệu thu thập về Nó đọc dữ liệu từ kafka và lưu trữ vào cơ sở dữ liệu PostgreSQL, TimescaleDB Sau đó, các trình tính toán chỉ báo các chỉ báo định kì được chạy và lưu kết quả chỉ báo theo ngày vào cơ sở dữ liệu.

• Thành phần tính toán các chỉ báo người dùng tự định nghĩa: Thành phần này được thực hiện sau khi các chỉ báo mặc định của hệ thống được tính và lưu trữ xong Khi đó, chỉ báo của người dùng có thể lấy dữ liệu giá phiên giao dịch hằng ngày, hoặc chỉ báo mặc định của hệ thống để làm dữ liệu đầu vào tính toán.

• Thành phần cảnh báo chứng khoán: Thành phần này được làm rõ ở các mục sau Sau khi các thành phần ở trên được chạy xong, hệ thống sẽ kiểm tra những mã cổ phiếu người dùng quan tâm xem giá trị hôm nay có vượt mức báo động hay không Nếu có, hệ thống sẽ gửi cảnh báo đến người dùng.

Các thành phần cần lập lịch trên được lên lịch bởi Airflow Để lập lịch với Airflow, ta cần tạo DAG và các task (tác vụ) trong DAG.

Căn cứ vào thời gian chạy, ta có thể chia việc lập lịch thành 3 DAG, xử lý các công việc sau:

• DAG thu thập dữ liệu dữ liệu từ API của TCBS và gửi dữ liệu vào Kafka

• DAG đọc dữ liệu từ Kafka và lưu vào cơ sở dữ liệu, tính toán các chỉ báo mặc định của hệ thống và lưu trữ nó vào cơ sở dữ liệu, gửi thông báo cho những người dùng đặt cảnh báo cho dữ liệu giá chứng khoán và chỉ báo mặc định của hệ thống.

• DAG tính toán các chỉ báo người dùng tự định nghĩa, gửi cảnh báo của các chỉ báo này cho người dùng DAG này sẽ được trình bày cụ thể hơn ở mục 4.4.2.

Dưới đây là các bước triển khai DAG đọc dữ liệu từ Kafka và lưu vào cơ sở dữ liệu, tính toán các chỉ báo mặc định và gửi thông báo Các DAG khác triển khai tương tự:

Sau khi khai báo thư viện, khởi tạo các tham số mặc định, cần khai báo một object DAG với các thiết lập về thời gian lập lịch Tham số start_date trong de- fault_argsthể hiện ngày bắt đầu chạy dag Tham sốschedule_interval là biểu thức cron, khai báo rằng DAG sẽ được chạy vào 8h15 múi giờ GMT (tương ứng với15h15 múi giờ +07 - giờ Việt Nam), vào thứ hai đến thứ sáu hằng tuần.

Hình 4.8: DAG lưu trữ dữ liệu và tính toán các tác vụ mặc định

Sau khi định nghĩa DAG, cần tạo các task cho DAG Các task này gọi và thực thi các hàm python Ví dụ task2_a gọi hàm calculate_MA, hàm này sẽ tính chỉ báo EMA:

Hình 4.9: Khai báo task gọi đến hàm calculate_EMA

Như ở trên, hàm calculate_EMA tạo 1 thể hiện (instance) của lớp EMAIndica- tor và truyền các tham số để khởi tạo vào Instance này sẽ gọi đến phương thức compute_all để tính toán giá trị chỉ báo EMA cho tất cả các mã cổ phiếu, lưu vào cơ sở dữ liệu Cuối cùng thiết lập thứ tự thời gian giữa các task trong DAG:

Hình 4.10: Thứ tự thực thi các task trong DAG

Với thứ tự được định nghĩa ở trên, trên, sau khi task1 (save_history_data_to_db) được chạy xong, các task2_a, task2_b, task2_c (tương ứng với calculate_MA, cal- culate_EMA, calculate_SO) được thực thi đồng thời Sau khi cả 3 task chạy xong, task3 send_notification sẽ được gọi.

Tác vụ save_history_data_to_db sẽ gọi hàm thực thi việc lưu dữ liệu giá hằng ngày vào PostgreSQL Các tác vụ khác như calculate_EMA, calculate_MA, cal- culate_SO sẽ tính toán chỉ báo EMA, MA, SO Tác vụ send_notification gửi cảnh báo đến người dùng nếu giá trị cổ phiếu vượt ngưỡng cảnh báo.

Hình 4.11: Trình tự tính toán các task trong Dag

Chức năng tính toán các chỉ báo do người dùng tạo

Ở phần 4.2 đã trình bày việc thiết kế các luồng tính toán chỉ báo, sơ đồ lớp tính toán chỉ báo cho cả chỉ báo mặc định của hệ thống và chỉ báo nguời dùng tự định nghĩa Ở mục này sẽ trình bày chi tiết hơn về chức năng tính toán chỉ báo do người dùng tạo Mục này trình bày dữ liệu đầu vào người dùng khi định nghĩa chỉ báo và việc tự động sinh lớp con kế thừa lớp Indicator nêu ở mục 4.2.2, tự động tạo dag tính toán.

4.4.1 Dữ liệu đầu vào của người dùng

Khi tạo một chỉ báo mới, người dùng cần khai báo các trường dữ liệu sau:

• indicator_name: String: Tên của chỉ báo

• stock_features: String: Trường dữ liệu lịch sử giao dịch chứng khoán cần lấy.

Có thể nhập nhiều trường, ngăn cách nhau bởi dấu phẩy Ví dụ close, volume

• input_period: String: Chỉ định các ngày cần lấy dữ liệu giá chứng khoán Ví dụ ”0-7, 10, 11” thể hiện cần lấy dữ liệu dữ liệu từ ngày hôm nay đến 7 ngày về trước, ngày thứ 10 và ngày thứ 11 trong quá khứ kể từ ngày hôm nay.

• ref_indicator: String: Tên của chỉ báo cần lấy dữ liệu Nó có thể tham chiếu đến các chỉ báo mặc định có sẵn của hệ thống (ema, ma, so), hoặc tham chiếu đến chính chỉ báo đang khai báo từ thời điểm hiện tại trở về trước Ví dụ: so

• ref_indicator_features: String: Các trường dữ liệu cần lấy của chỉ báo ref_indicator trên, ngăn cách nhau bởi dấu phẩy Một loại chỉ báo có thể lấy nhiều trường.

• ref_indicator_period: String: Chỉ định các ngày cần lấy dữ liệu của chỉ báo ref_indicator Ví dụ: ”1-3” thể hiện cần lấy dữ liệu của chỉ báo 3 ngày trước.

• output: String Chỉ định các trường đầu ra của chỉ báo đang định nghĩa, ngăn cách nhau bởi dấu phẩy Ví dụ chỉ báo đang định nghĩa là ema, output là

”ema12, ema26’ thể hiện chỉ báo đang định nghĩa sau khi tính xong có 2 tham số: ema12 và ema26

• function: Hàm python thể hiện công thức tính toán của chỉ báo vào thời điểm ngày hiện tại Tham số truyền vào của hàm mặc định là ticker_data:

DataFrame, indicator_data: DataFrame - là dữ liệu lịch sử giao dịch và dữ liệu chỉ báo cần lấy, thông tin được khai báo ở các trường ở trên Dữ liệu đầu ra của hàm này là danh sách các số thực (List), tương ứng với các giá trị khai báo ở output.

Hình 4.12: Dữ liệu đầu vào người dùng

Ví dụ thông tin đầu vào người dùng cần nhập khi tự định nghĩa chỉ báo EMA.

Hình 4.13: Dữ liệu đầu vào người dùng: Hàm python tính giá trị chỉ báo

Dữ liệu định nghĩa chỉ báo trên được lưu vào cơ sở dữ liệu tại bảng indicator, trình bày ở mục 4.2.4.

4.4.2 Sinh lớp chỉ báo và tạo DAG tính toán Ở mục 4.4.1 trên đã trình bày về dữ liệu đầu vào người dùng trong chức năng người dùng tự định nghĩa chỉ báo mới Dữ liệu tính chỉ báo trên chỉ bao gồm thông tin định nghĩa chỉ báo Khi người dùng tạo một chỉ báo mới, hệ thống sẽ sinh ra lớp con kế thừa lớp Indicator theo biểu đồ lớp hình 4.4 Khi người dùng đặt điều kiện nhận cảnh báo cho một mã cổ phiếu với chỉ báo trên, hệ thống sẽ tạo/cập nhật DAG và task, mỗi task trong DAG ứng với một mã cổ phiếu người dùng quan tâm.

Khi người dùng gỡ bỏ một điều kiện nhận cảnh báo cho một mã cổ phiếu với chỉ báo trên, hệ thống sẽ cập nhật lại DAG để gỡ bỏ task Để làm được điều này, hệ thống sử dụng công cụ jinja2 - một thư viện của Python Jinja2 là một template engine, đã được giới thiệu cụ thể ở chương 3 Để sử dụng Jinja2, cần tạo sẵn các mẫu (template) Mẫu này có một phần nội dung cố định, một phần nội dung là các biến, người dùng có thể điền giá trị cho các biến này để sinh ra các tệp theo mẫu.

Cụ thể các bước như sau:

• Tạo lớp tính toán chỉ báo người dùng định nghĩa, kế thừa lớp Indicator:

Theo trình bày ở mục 4.2.2, một chỉ báo mới do người hệ thống sẽ tạo một lớp kế thừa lớp Indicator ban đầu Lớp này sẽ chỉ ghi đè duy nhất lại phương thức compute, và sử dụng lại tất cả các phương thức còn lại ở lớp cha Phương thức này nhận đầu vào là 2 DataFrame ticker_data và indicator_data, ứng với dữ liệu lịch sử chứng khoán và dữ liệu chỉ báo cần tệp chiếu đến để tính toán cho chỉ báo đang định nghĩa Như vậy, file template của lớp con sẽ được tạo như sau:

Hình 4.14: Khuôn mẫu (template) định nghĩa chỉ báo mới

Trong đó indicator_name là tên chỉ báo, định dạng chữ thường user_id là định danh của người dùng, mỗi user_id tương ứng với một người dùng duy nhất. function là hàm của chỉ báo bỏ đi dòng đầu tiên, được lưu trữ trong cơ sở dữ liệu.

Class trên sẽ được cập nhật vào một file với tên là user + user_id được lưu trong package indicators File này sẽ chứa tất cả các indicator do người dùng có định danh user_id định nghĩa File này ban đầu được tạo chỉ gồm có import thư viện, sẽ được thêm nội dung mỗi khi người dùng tạo chỉ báo mới Dưới đây là hình ảnh file này của người dùng có định danh 5249785884:

Hình 4.15: Nội dung tệp user5249785884 ban đầu

Hình 4.16: Nội dung tệp user5249785884 sau khi người dùng tạo một chỉ báo mới

• Tạo mới/thêm task vào file DAG:Tất cả các task tính toán của tất cả các chỉ báo người dùng tự định nghĩa được thực hiện chung trong một file DAG. dag_id được khai báo là user_id, định danh cho một người dùng duy nhất.

Việc đặt tên user_id đảm bảo tính duy nhất, không trùng lặp của dag_id mà Airflow yêu cầu.

DAG được khởi tạo ban đầu bởi template jinja2, chứa một tác vụ: send_notification.

Tác vụ này sẽ gọi khởi tạo một instance (thể hiện) của lớp SendNotification, được trình bày chi tiết ở mục 4.5.3 Instance gọi phương thức check_condition_ for_user_id để kiểm tra các điều kiện nhận cảnh báo xem có vượt ngưỡng cảnh báo hay không, nếu có sẽ gửi cảnh báo đến người dùng Khi người dùng đặt các điều kiện nhận cảnh báo các mã chứng khoán cho chỉ báo người dùng tự định nghĩa, các task mới thực thi công việc tính toán sẽ được thêm vào Sau khi tất cả các task tính toán được thực thi xong, task send_notification sẽ được thực thi. Để cập nhật lại DAG mỗi khi thêm điều kiện nhận cảnh báo mới, hệ thống sẽ thêm mới các task tính toán và thứ tự tính toán vào cuối file DAG Khi đó, DAG sẽ được tự động cập nhật.

Hình 4.18: Template task mới và thứ tự tính toán trong DAG

Hình 4.19: Task tính toán chỉ báo rs cho mã chứng khoán BIDV được thêm vào DAG

DAG sẽ được tự động cập nhật, lên lịch chạy với thứ tự: các task tính toán chạy trước, sau khi tất cả tính toán chạy xong sẽ thực thi task gửi thông báo send_notification

Hình 4.20: DAG được tự động cập nhật

Chức năng cảnh báo chứng khoán

Ở mục 4.5 này, đồ án sẽ trình bày cách xây dựng chức năng cảnh báo chứng khoán cho người dùng Sau khi người dùng thiết lập các điều kiện nhận cảnh báo, hệ thống sẽ gửi thông báo về cho người dùng định kỳ hằng ngày (nếu có) Chatbot Telegram được xây dựng đễ hỗ trợ người dùng tương tác với hệ thống để sử dụng chức năng cảnh báo chứng khoán trên Đồng thời, người dùng cũng có thể thông qua chatbot để xem dữ liệu, tạo chỉ báo, Cách xây dựng chatbot Telegram được triển khai tại phụ lục A.

4.5.1 Thiết kế cơ sở dữ liệu Để thực hiện việc cảnh báo cho người dùng về các mã cảnh báo vượt ngưỡng/thấp hơn ngưỡng, ta thêm vào bảng warning cơ sở dữ liệu đã trình bày ở hình 4.7.

Bảng warning là bảng chứa các cảnh báo người dùng Bảng này chứa các trường:

• user_id: định danh người dùng

• indicator_name: tên loại chỉ báo muốn thiết lập cảnh báo Ví dụ "ema", "so",

Trong trường hợp muốn thiết lập cảnh báo cho giá đóng cửa/số lượng cổ phiếu, trường này có giá trị "stock"

• indicator_features: tên của trường dữ liệu cuả chỉ báo muốn thiết lập cảnh báo.

Ví dụ "ema12", "ema26", "k", "d", Trong trường hợp người dùng muốn thiết lập cảnh báo cho giá đóng cửa/số lượng cổ phiếu, giá trị của trường này là

• threshold_type: loại cảnh báo muốn chọn, có thể là GREATER hoặc LOWER. Đối với GREATER, hệ thống sẽ gửi cảnh báo khi giá trị hôm nay lớn hơn giá trị ngưỡng LOWER ngược lại.

• threshold_value: giá trị ngưỡng cảnh báo.

Dưới đây là cơ sở dữ liệu của toàn bộ hệ thống trong đồ án này:

Hình 4.22: Cơ sở dữ liệu toàn bộ hệ thống

4.5.2 Thiết kế luồng cảnh báo chứng khoán Ở trên, tôi đã trình bày về thiết kế cơ sở dữ liệu lưu trữ cảnh báo Trong mục 4.5.2 này, tôi trình bày về chi tiết luồng thực thi quá trình cảnh báo chứng khoán.

Có 2 luồng cảnh báo chứng khoán: luồng xử lý cảnh báo cho chỉ báo người dùng tự định nghĩa, và luồng xử lý cảnh báo cho chỉ báo của người dùng tự định nghĩa/cảnh báo về dữ liệu lịch sử giao dịch chứng khoán.

- Dưới đây là luồng xử lý cảnh báo cho chỉ báo người dùng tự định nghĩa:

Hình 4.23: Luồng cảnh báo của chỉ báo người dùng tự định nghĩa

Sau khi người dùng đã tương tác với hệ thống để định nghĩa chỉ báo mới, người dùng có thể thiết lập những cảnh báo cho những mã cổ phiếu cụ thể cho chỉ báo trên Quá trình xử lý những cảnh báo người dùng đối với chỉ báo tự định nghĩa như sau:

(1) Người dùng tương tác với chatbot để thiết lập cảnh báo cho những mã cổ phiếu cụ thể.

(2) Trình xử lý chatbot lưu trữ những thiết lập về cảnh báo vào cơ sở dữ liệu.

(3) Trình xử lý chatbot tạo DAG để Airflow lập lịch tính toán giá trị chỉ báo.

(4) Airflow lấy dữ liệu để tính toán (5) Airflow lưu trữ dữ liệu chỉ báo của người dùng vào cơ sở dữ liệu

(6) Dữ liệu cảnh báo được lấy ra để kiểm tra xem có đạt ngưỡng báo động hay không.

(7) Nếu có cảnh báo, cảnh báo người dùng sẽ được gửi đến Kafka.

(8) Consumer của Kafka tiêu thụ gửi cảnh báo cho người dùng thông qua trình xử lý chatbot

(9) Trình xử lý chatbot gửi cảnh báo cho người dùng.

- Đối với chỉ báo mặc định của hệ thống/dữ liệu lịch sử giá chứng khoán, khi người dùng thiết lập những cảnh báo cho mã cổ phiếu cụ thể liên quan đến những dữ liệu trên, hệ thống sẽ trực tiếp lấy dữ liệu từ Postgres chứ không cần phải sinh DAG tính toán mới để tính toán Quá trình xử lý cảnh báo đó như sau:

Hình 4.24: Luồng cảnh báo cho chỉ báo mặc định của hệ thống/dữ liệu lịch sử giá chứng khoán

Luồng cảnh báo này gần như tương tự với luồng cảnh báo cho chỉ báo người dùng tự định nghĩa, chỉ khác là dữ liệu chỉ báo của hệ thống/dữ liệu lịch sử giá chứng khoán đẫ được tính toán sẵn trước đó/được crawl trước đó, không cần sinhDAG mới để tính toán lại.

4.5.3 Sơ đồ lớp SendNotification Ở phần này, tôi trình bày về thiết kế sơ đồ lớp SendNotification - lớp này cung cấp một số phương thức để kiểm tra điều kiện cảnh báo của người dùng, gửi dữ liệu cảnh báo tới Kafka, tiêu thụ dữ liệu cảnh báo từ Kafka để gửi đến người dùng.

Hình 4.25: Biểu đồ lớp Send Notification

Các phương thức trong lớp SendNotification gồm:

- send_to_kafka(user_id: String, symbol: String, type: String, threshold_type:

String, value: float): phương thức này sẽ gửi dữ liệu cảnh báo tới topic alert của Kafka Đầu vào gồm user_id định danh người dùng, symbol, type, threshold_type là thông tin liên quan đến chỉ báo đã thiết lập, value là giá trị chỉ báo hôm nay.

- check_condiction_for_user_id(user_id: String): Phương thức này dùng để kiểm tra điều kiện cảnh báo cho chỉ báo người dùng tự định nghĩa Đầu vào là user_id định danh người dùng Phương thức này sẽ truy cập vào cơ sở dữ liệu để đọc các cảnh báo của chỉ báo người dùng user_id tự định nghĩa, kiểm tra xem có vượt ngưỡng hay không Nếu có, nó sẽ gửi cảnh báo tới kafka thông qua phương thức send_to_kafka ở trên.

- check_condiction_for_all(): Phương thức này dùng để kiểm tra điều kiện cảnh báo cho tất cả chỉ báo mặc định của hệ thống/cảnh báo thiết lập dựa trên lịch sử giao dịch chứng khoán Nó sẽ đọc dữ liệu cảnh báo và dữ liệu chỉ báo/lịch sử giao dịch hôm nay để kiểm tra, nếu có cảnh báo thì gửi đến kafka thông qua phương thức send_to_kafka.

- send_alert(): đọc dữ liệu cảnh báo từ topic alert của Kafka, và gửi cảnh báo cho người dùng.

Với những thiết kế đã nêu trên, ta có thể xây dựng một hệ thống đáp ứng được các yêu cầu đã đề ra.

THỰC NGHIỆM VÀ ĐÁNH GIÁ

Kết quả xây dựng hệ thống

Chức năng thu thập và lưu trữ dữ liệu của hệ thống hoạt động ổn định Dữ liệu chứng khoán được thu thập, lưu trữ định kỳ hằng ngày Khi luồng lưu trữ dữ liệu bị tắt và bật lại sau một thời gian, dữ liệu đã thu thập được trong thời gian luồng lưu trữ dữ liệu bị tắt vẫn được lưu trữ đầy đủ, không cần thu thập (crawl) lại Khi luồng thu thập dữ liệu bị tắt, luồng lưu trữ dữ liệu chờ trong một khoảng thời gian timeout.

Hình 5.1: Dữ liệu được thu thập và ghi vào cơ sở dữ liệu theo ngày

Dữ liệu được phân vùng theo thời gian vào các chunk trong timescaledb, mỗi chunk nhận dữ liệu trong khoảng thời gian 7 ngày Tại mỗi chunk, dữ liệu tiếp tục được phân vùng theo mã chứng khoán và thời gian Khi truy vấn, dựa vào trường thời gian, timescaledb xác định được ngay lập tức dữ liệu lưu trữ ở chunk nào Các truy vấn được sử dụng nhiều nhất trong hệ thống là truy vấn theo mã chứng khoán trong khoảng thời gian nhất định Với việc phân vùng theo mã chứng khoán và thời gian bên trong mỗi chunk làm tốc độ tăng đáng kể.

Hình 5.2: Dữ liệu được lưu vào các chunk trong timescaledb

5.1.2 Kết quả xây dựng chức năng tính toán chỉ báo Ở trong phần 4.2 và 4.4, đồ án đã trình bày thiết kế tính toán chỉ báo, cho cả chỉ báo của người dùng tự định nghĩa và chỉ báo mặc định của hệ thống Ở mục 5.1.2 này, đồ án trình bày kết quả việc xây dựng chức năng tính toán chỉ báo: về kết quả triển khai mã nguồn, kết quả quá trình tính toán chỉ báo.

Dưới đây là mã nguồn triển khai lớp Indicator:

Hình 5.3: Mã nguồn lớp Indicator

Phương thức compute_symbol của lớp Indicator sẽ gọi lần lượt các phương thức get_inputs, compute, save_data để thực hiện quá trình tính toán Kết quả quá trình này là giá trị chỉ báo của người dùng cho mã cổ phiếu symbol ngày hôm nay được tính ra và lưu vào cơ sở dữ liệu. Đối với chỉ báo mặc định của hệ thống, chỉ báo này sẽ được tính toán cho toàn bộ 1610 mã cổ phiếu Vì vậy, để tăng hiệu suất tính toán, tránh rẽ nhánh câu lệnh nhiều, các phương thức của lớp Indicator được ghi đè lại hầu hết.

Có 3 chỉ báo mặc định của hệ thống: EMA, MA, SO Việc tính toán chỉ báo mặc định hoạt động ổn định.

Hình 5.4: Trình tính toán lưu trữ chỉ báo mặc định vào cơ sở dữ liệu Đối với chỉ báo người dùng định nghĩa, người dùng cần nhập thông tin định nghĩa chỉ báo, bao gồm các trường dữ liệu cần lấy, thời gian cần lấy và công thức tính toán Hệ thống sẽ dựa vào dữ liệu trên để tự động sinh ra một lớp con của Indicator, chỉ ghi đè lại duy nhất phương thức compute - công thức tính toán.

Ví dụ về chỉ báo RSI do người dùng tự định nghĩa:

Hình 5.5: Dữ liệu đầu vào người dùng

Hình 5.6: Dữ liệu đầu vào người dùng: Hàm compute

Class chỉ báo được hệ thống sinh ra:

Hình 5.7: Lớp tính chỉ báo được hệ thống tự động sinh ra

Kết quả được tính hàng ngày và lưu trữ lâu dài trong cơ sở dữ liệu.

Hình 5.8: Chỉ báo RSI của người dùng định nghĩa được lưu trữ trong cơ sở dữ liệu

5.1.3 Kết quả xây dựng chức năng lập lịch hệ thống

Dựa vào thiết kế xây dựng chức năng lập lịch ở mục 4.3.2, tôi đã hoàn thành việc lập lịch, gồm các DAG sau: DAG thu thập dữ liệu; DAG lưu trữ, xử lý chỉ báo mặc định của hệ thống và xuất ra cảnh báo; DAG tính toán chỉ báo người dùng và xuất ra cảnh báo; DAG tiêu thụ (consumer) cảnh báo từ Kafka và gửi đến người dùng.

Hình 5.9: Các DAG được lên lịch

Hình 5.10: DAG người dùng có user_id 5249785884

Hệ thống có tính năng thêm task (tác vụ) mới vào DAG, gỡ bỏ task mới trong DAG của chỉ báo người dùng tự định nghĩa.

5.1.4 Kết quả xây dựng chức năng cảnh báo người dùng

Với thiết kế ở mục 4.5, chức năng cảnh báo người dùng được xây dựng hoàn chỉnh Với các điều kiện nhận cảnh báo của người dùng, hệ thống sẽ lưu trữ vào cơ sở dữ liệu Hệ thống sẽ kiểm tra điều kiện nhận cảnh báo định kỳ hằng ngày sau khi tính toán xong, và gửi cảnh báo đến topic alert trong Kafka Một luồng tiêu thụ (consumer) trong Kafka sẽ đọc và gửi cảnh báo đến người dùng qua chatbot Telegram.

Hình 5.11: Các cảnh báo đã thiết lập

Hình 5.12: Cảnh báo được gửi đến cho người dùng qua Telegram

Ngoài các kết qủa trên, đồ án có trình bày kết quảxây dựng chatbot Telegram ở phụ lục A.

Triển khai ứng dung

Phần 5.2 này trình bày về quá trình triển khai ứng dụng trong thực tế Hệ thống sử dụng Docker để đóng gói ứng dụng, dùng trình quản lý gói Helm để triển khai ứng dụng trên Kubernetes.

Các ứng dụng được triển khai bao gồm: trình lập lịch tính toán và xử lý dữ liệu Airflow, cơ sở dữ liệu PostgreSQL - Timescaledb, công nghệ streaming dữ liệu Apache Kafka.

Hệ thống được triển khai trên máy tính cá nhân Môi trường Kubernetes được xây dựng bằng Minikube [13].

Có rất nhiều tổ chức cung cấp gói cài đặt helm chart cho Airflow Đồ án này sử dụng chart do chính Apache Airflow cung cấp, phiên bản 1.10.0 [14]

Các docker images sử dụng cho chart gồm postgres:12, redis:7-bullseye, và docker image của Airflow Image của Airflow được dựng lại, cài thêm một số thư viện cần thiết nhưjinja2,psycopg2,

Dưới đây là chi tiết các bước triển khai:

1 Thêm repo của Apache Airflow: helm repo add apache-airflow https://airflow.apache. org

2 Tải chart airflow từ repo: helm pull apache-airflow/airflow

3 Sau khi giải nén, thực hiện chỉnh sửa cấu hình như ở dưới.

4 Thực hiện cài đặt chart: helm namespace airflow install airflow-chart apache-airflow/airflow

Thành phần Airflow sau khi cài xong gồm 2 deployment, 3 statefulset, và các service, persistent volume, persistent volume claim Các deploy triển khai các thành phần scheduler, webserver, các statefulsets triển khai các thành phầnpost- greSQL,redis,worker.

Hình 5.13: Các thành phần của Airflow được triển khai

Một số cấu hình của Airflow như sau: images: airflow: repository: apache/airflow tag: v1 workers: persistence: size: 1Gi redis: persistence: size: 500Mi postgresql: image: tag: "12" dags: persistence: enabled: true size: 1Gi accessMode: ReadWriteMany existingClaim: airflow-dags-nfs-pv-claim

Các tham số có ý nghĩa như sau: images.airflow.repository và images.airflow.tag lần lượt chỉ định tên của docker image và phiên bản Docker image dùng để triển khai là docker image tôi xây dựng từ image phiên bản apache/airflow:2.5.3-python3.8, kèm theo một số thư viện và một số thư mục. postgresql.image.taglà phiên bản postgresql sử dụng trong triển khai Image với tag trên sẽ được docker tải xuống. workers.persistence.size,redis.persistence.sizevàdags.persistence.sizelần lượt là dung lượng của persistent volume claim yêu cầu cho workers, redis và dag. dags.accessModechỉ định quyền truy cập persistent volume claim. dags.existingClaimchỉ định tên của persistent Volume Claim đã được tạo sẵn từ trước, gắn liền với thư mục dags.

Trong thành phần PostgreSQL của Airflow, cấu hình tệp values.yaml với các thông số sau: image: repository: postgres tag: 12 primary: persistence: size: 1Gi volumePermissions: enabled: ’true’

Trong đó: image.repositoryvàimage.tagthể hiện tên của image và phiên bản image sử dụng. primary.persistence.size thể hiện kích cỡ persistent volume claim cần yêu cầu để lưu trữ PostgreSQL. volumePermissions.enabled được đặt là ”true” để chaỵ lệnh cấp các quyền đọc, ghi, thực thi cần thiết đối với volume lưu trữ.

5.2.2 Triển khai PostgreSQL và Timescaledb Để triển khai PostgreSQL và tiện ích mở rộng của nó - Timescaledb, đồ án này sử dụng helm chart được cung cấp sẵn bởi công ty Timescale [15] Docker image được sử dụng là timescale/timescaledb-ha:pg14.6-ts2.9.1-p1- đóng gói cả PostgreSQL và Timescaledb thành một ứng dụng.

Dưới đây là chi tiết các bước triển khai:

1 Thêm repo của timescale: helm repo add timescale ’https://charts.time scale.com/’

2 Tải xuống chart timescaledb-single: helm pull timescale/timescaledb-single

3 Giải nén và chỉnh sửa cấu hình.

4 Thực hiện cài đặt: helm -n timescaledb install timescaledb timescaledb- single/

Sau khi triển khai xong, một pod chạy cơ sở dữ liệu postgresql và timescaledb được quản lý bởi statefulsets.

Hình 5.14: Cơ sở dữ liệu chạy PostgreSQL và Timescaledb được triển khai

Trong đó, tệp values.yaml được cấu hình như sau: services: primary: type: NodePort nodePort: 31432 replicaCount: 1 persistentVolumes: data: size: 1Gi wal: size: 1Gi

Cấu hình trên chỉ định loại service dùng để truy cập vào cơ sở dữ liệu là NodePort, với số cổng là 31432 Số pod triển khai cho cơ sở dữ liệu là 1 Dung lượng lưu trữ cho persistent volumes được cấu hình 1Gi cho mỗi vùng.

5.2.3 Triển khai Apache Kafka Đối với Kafka, tôi sử dụng Kafka Raft - phiên bản Kafka sử dụng thuật toán đồng thuận Raft để bầu cử Khác với phiên bản thông thường, phiên bản này không cần dùng Zookeeper để quản lý metadata, giúp cho tăng hiệu suất của Kafka.

Tôi triển khai ứng dụng Kafka trên 1 pod, quản lý bởi statefulsets Cấu hình của Kafka được trình bày ở phần phụ lục B.

Hình 5.15: Kafka được triển khai

Dưới đây là một số kịch bản kiểm thử cho một số chức năng của hệ thống: thu thập dữ liệu, thiết lập cảnh báo, tính toán chỉ báo, thêm mới chỉ báo, tính khả dụng của hệ thống.

5.3.1 Kiểm thử chức năng thu thập dữ liệu

1.1 Tắt DAG thực hiện lưu trữ dữ liệu

- Bật DAG thực hiện việc thu thập dữ liệu - Tắt DAG lưu trữ dữ liệu ,chỉ được bật lại sau khi DAG thu thập dữ liệu chạy được một thời gian/chạy xong

Dữ liệu được lưu trữ đầy đủ vào cơ sở dữ liệu,không bị mất, kể cả những dữ liệu thu thập được tại thời điểm consumer bị tắt.

Dữ liệu được lưu trữ đầy đủ vào cơ sở dữ liệu,không bị mất, kể cả những dữ liệu thu thập được tại thời điểm consumer bị tắt.

1.2 DAG thu thập dữ liệu bị tắt

DAG thực hiện công việc thu thập dữ liệu bị tắt

DAG lưu trữ và tính toán chỉ báo chờ đợi trong khoảng thời gian timeout

DAG lưu trữ và tính toán chỉ báo chờ đợi trong khoảng thời gian timeout

5.3.2 Kiểm thử chức năng thiết lập cảnh báo

2.1 Thêm cảnh báo cho chỉ báo/mã chứng khoán không tồn tại tồn tại

Thêm cảnh báo với tên chỉ báo/mã chứng khoán chưa tồn tại trong hệ thống Đưa ra thông báo rằng chỉ báo/mã chứng khoán chưa tồn tại trong hệ thống

Thông báo rằng chỉ báo/mã chứng khoán chưa tồn tại trong hệ thống

2.2 Thêm cảnh báo với loại ngưỡng nhập vào không phải là GREATER hoặc

Thêm cảnh báo với loại ngưỡng nhập vào không phải là GREATER hoặc LOWER Đưa ra thông báo rằng nhập sai loại ngưỡng Đưa ra thông báo nhập sai lọai ngưỡng

2.3 Thêm cảnh báo với ngưỡng giá trị không phải là số

Nhập ngưỡng cảnh báo là chuỗi có kí tự chữ cái Đưa ra thông báo dữ liệu nhập sai, cần phải là số

Thông báo dữ liệu nhập sai, cần phải là số

2.4 Thêm cảnh báo với tên chỉ báo và mã cổ phiếu đã được thiết lập ở cảnh báo khác, nhưng khác loại ngưỡng

Thêm cảnh báo mới: cảnh báo có mã cổ phiếu và tên chỉ báo đó đã được thiết lập trước đó, nhưng khác loại ngưỡng.

Chấp nhận cảnh báo, không thêm lại task tính toán chỉ báo cho mã cổ phiếu đó vào DAG

Chấp nhận cảnh báo, không thêm lại task tính toán chỉ báo cho mã cổ phiếu đó vào DAG

2.5 Thêm cảnh báo với tên chỉ báo và mã cổ phiếu chưa được thiết lập cảnh báo

Thêm một chỉ báo mới, với tên chỉ báo và mã cổ phiếu chưa được thiết lập cho bất kỳ cảnh báo nào trước đó, kể cả cùng hay khác loại ngưỡng

DAG được cập nhật lại: task mới được thêm vào DAG

Task mới được thêm vào DAG

Xóa một cảnh báo đã thiết lập

Cập nhật lại DAG: DAG đã gỡ bỏ task tính toán cho cảnh báo trên

Task tính toán cho cảnh báo trên đã bị gỡ bỏ khỏi DAG