#140 - Giải mã sự khác biệt giữa Artificial Intelligence, Machine Learning và Data Science

Sep 27, 2020

Vào ngày 27/09 vừa qua, tại văn phòng của LINE Technology Vietnam, Grokking TechTalk #38 - Languages, Technologies, Architectures - different components that make a high performance system - đã đã kết thúc tốt đẹp với sự tham gia của gần 100 kỹ sư.

Techtalk #38 đánh dấu lần đầu tiên Grokking tham gia tổ chức tại Hà Nội với sự hợp tác đến từ LINE Technology Vietnam. Hi vọng, trong thời gian tới sẽ có thêm nhiều Grokking Techtalk diễn ra tại Hà Nội.

Những bài viết hay

Giải mã sự khác biệt giữa Artificial Intelligence, Machine Learning và Data Science — pandaml.com

Những năm gần gần đây, những khái niệm về AI, Machine Learning hay Data Science trở nên thịnh hành và nhận được rất nhiều sự quan tâm. Với các bạn mới vào nghề hay các dev muốn tìm tòi về những lĩnh vực này, một trong những việc thiết yếu đầu tiên chính là hiểu rõ được về phạm vi và những sự khác biệt cơ bản.

Về khái niệm đơn thuần:

Trí tuệ nhân tạo (Artificial Intelligence – AI) là những hệ thống được con người tạo ra với mục tiêu để mô phỏng các chức năng nhận thức của con người, ví dụ như khả năng nghe, nhìn, tư duy và ra quyết định.
Học máy (Machine Learning – ML) là mảng nghiên cứu về kỹ thuật để giúp máy tính có khả năng tự học thay vì cần sự điều chỉnh bởi con người. Có thế nói ML là một phần của AI bên cạnh các công cụ, kỹ thuật khác.
Khoa học dữ liệu (Data Science – DS) là chuyên ngành về phân tích dữ liệu với mục tiêu hỗ trợ cho việc ra các quyết định trong nhiều lĩnh vực như nghiên cứu, sản xuất, kinh doanh,…

Bài viết gồm những phân tích chi tiết hơn bằng tiếng Việt của tác giả có lẽ sẽ mang lại cho các bạn một góc nhìn chính xác về những thuật ngữ đang càng ngày càng "hot" này. Từ đó có thể giúp các bạn chọn lựa cho mình một hướng đi đúng đắn hơn.

Persistent Disks and Replication — medium.com

Nếu bạn là người dùng các dịch vụ trên Cloud, bạn chắc hẳn đã thấy các tùy chọn lưu trữ độc đáo có thể có được như thế nào. Điều này thậm chí đúng với các đĩa mà bạn truy cập từ máy ảo . Vậy hãy cùng tìm hiểu về Persistent Disk và cơ chế replication của nó như thế nào nhé.

Disks as a services: Persistent Disk không phải là đĩa cục bộ được gắn vào máy vật lý. Persistent Disk là một dịch vụ và được gắn vào máy ảo của bạn dưới dạng thiết bị khối mạng. Khi bạn đọc hoặc ghi từ một Persistent Disk, dữ liệu sẽ được truyền qua mạng. Điều này mang lại một số lợi ích như quá trình thay đổi dũng lượng disk trở nên dễ dàng, việc gắn và tháo đĩa khỏi một máy ảo trở nên rất đơn giản, hay khả năng cung cấp high availability nhờ quá trình replication các đĩa.
Disk Latency: Người dùng thường thắc mắc về chi phí độ trễ khi có đĩa như một dịch vụ hơn là gắn trực tiếp vào máy. Bạn có thể sử dụng các benchmark tool để kiểm tra xem liệu yêu cầu của ứng dụng có được đáp ứng. Trong trường hợp bạn cần chạy một cache server hay cần xử lý một lượng lớn với các output trung gian, local SSDs có thể sẽ là sự lựa chọn tốt hơn với độ trễ thấp hơn.
Replication: Khi tạo đĩa mới, bạn có thể tùy ý chọn sao chép đĩa trong 1 region. Các đĩa liên tục được nhân rộng để có tính khả dụng cao hơn. Sự sao chép xảy ra giữa hai zones trong một region. Điều này giúp các đĩa có khả năng truy cập ổn định khi rất khó xảy ra lỗi trên toàn bộ một region so với zone.
Chuỗi Read/Write khi replication: Công việc này được thực hiện bởi disk driver trong máy ảo. Người dùng không phải can thiệp chi tiết quá trình replication được xử lý như thế nào.

Principles for Microservice Design: Think IDEALS, Rather than SOLID — www.infoq.com

Chúng ta thường phải tuân thủ SOLID principles trong thiết kế hướng đối tượng (OOD - Object-Oriented Design). SOLID vẫn đúng trong mô hình microservices tuy nhiên nó bao phủ hết các khía cạnh của microservices. Do đó, Paulo Merson - microservices trainer - đưa ra một số nguyên lý phù hợp hơn với tên gọi IDEALS:

Interface segregation: thay vì cố gắng đưa ra một API/Service contract chung cho tất cả các loại clients(mobile app, web app, desktop app...) khác nhau, chúng ta nên tách nhỏ thành nhiều contracts đáp ứng đúng và đủ cho từng loại client. Backend for Frontends (BFF) là một trong các giải pháp thường được áp dụng.
Deployability: khi đưa ra các quyết định quan trọng về thiết kế hay lựa chọn công nghệ, một yếu tố phải được quan tâm đó là khả năng triển khai bao gồm cơ sở hạ tầng (runtime infrastructure), khả năng mở rộng, CI/CD, hạn chế tối thiểu downtime khi nâng cấp phiên bản (Version), theo dõi tình trạng của các microservices
Event-Driven: ưu tiên sử dụng asynchonus (event message) thay cho synchronous (HTTP call) để nâng cao hiệu suất và khả năng mở rộng cũng như giảm sự phụ thuộc lẫn nhau giữa các services
Availability over Consistency: người dùng cuối coi trọng tính khả dụng (Availability) hơn là tính nhất quán dữ liệu(Consistency). Chúng ta có thể đạt được trạng thái nhất quán dữ liệu thông qua eventual consistency.
Loose-Coupling: một thay đổi nhỏ ở một service có thể dẫn đến một loạt các services khác phải thay đổi theo nếu chúng phụ thuộc lẫn nhau. Điều này rất tốn kém về thời gian và tiền bạc. Do đó, sự phụ thuộc lẫn nhau giữa các services phải được hạn chế ở mức tối thiểu.
Single Responsibility: một services không nên quá lớn cũng không nên quá nhỏ.

Góc database

Trong những công ty công nghệ lớn hàng đầu, việc đối mặt với các bài toán kinh doanh không ngừng thay đổi như số lượng người dùng tăng đột biến, mở rộng thêm lĩnh vực mới, tối ưu hoá chi phí, ... khiến cho đội ngũ kỹ sư cũng phải không ngừng tìm kiếm các kỹ thuật, công nghệ mới để đáp ứng. Những công nghệ như F1, BigData, Aurora, DynamoDB, ... đã dần hình thành, trước hết là để giải quyết các bài toán nội bộ của chính công ty, sau đó được mở rộng dần để trở thành một dịch vụ để cung cấp ra ngoài.

Trong mục Góc Database kỳ này, mời các bạn cùng tìm hiểu bài viết mô tả thiết kế của DynamoDB, một trong những key-value database đã được hình thành để giải quyết những bài toán nội bộ của Amazon một cách hiệu quả.

Theo các tác giả bài viết, DynamoDB được xây dựng ban đầu với một số giả định/yêu cầu như sau:

- Mô hình Query: hệ thống sẽ hướng đến việc đọc và lưu dữ liệu dạng key/value. Việc đọc/ghi cũng diễn ra trên các dòng dữ liệu độc lập và ít liên quan đến nhau.

- Hiệu quả: hệ thống được xây dựng sao cho các service sử dụng có thể thay đổi cấu hình cần thiết để đạt được độ trễ ngắn nhất có thể.

- Ít quan tâm tính bảo mật: hệ thống được xây dựng trên giả định là đây sẽ là hệ thống nội bộ của Amazon, không được sử dụng bên ngoài (giả định này hiện nay rõ ràng là không còn đúng nữa, nên nhiều thiết kế hẳn nhiên sẽ cần được thay đổi)

Dựa theo ngữ cảnh trên, các kỹ sư ở Amazon đã đưa ra các cân nhắc thiết kế quan trọng như:

- Lựa chọn khi nào thì sẽ xử lý conflict trong dữ liệu. Đối với các hệ dữ liệu phân tán trong đó dữ liệu được ghi thành nhiều phiên bản trên nhiều node khác nhau thì việc xảy ra conflict trong các phiên bản dữ liệu là không thể tránh khỏi. Nhiều hệ thống truyền thống (như elastic search) sẽ quyết định giải quyết conflict trong quá trình ghi dẫn đến độ availability của việc ghi thấp hơn. Đối với DynamoDB, các kỹ sư lại theo hướng tiếp cận là "always writeable" và xử lý conflict trong quá trình đọc.

- Lựa chọn tiếp theo là dành cho ai sẽ là người giải quyết conflict. Hai lựa chọn phổ biến là chính tầng quản lý dữ liệu (DynamoDB) hoặc tầng ứng dụng (application) sẽ giải quyết conflict. Trong tình huống của DynamoDB, các kỹ sư cung cấp các cơ chế để tầng ứng dụng có thể chọn chiến lược giải quyết conflict phù hợp, từ đó mang đến sự mềm dẻo hơn.

- Incremental scalability: Dynamo cần có thể scale thêm node mới (dần dần, mỗi lần thêm một node) mà không ảnh hưởng đến hệ thống.

- Symmetry: Các node trong hệ thống Dynamo cần phải có vai trò như nhau, không có node nào đóng vai trò quan trọng hơn node nào.

- Decentralization: Do đặc tính Symmetry, các thuật toán, kỹ thuật được sử dụng cũng phải mang tính chất phân tán, không lệ thuộc vào một trung tâm xử lý chính như mô hình master/slave.

- Heterogeneity: Hệ thống cần có đặc tính "heterogeneity", tức là việc phân tải ra các node phải có sự cân nhắc cấu hình của node tương ứng. Khi bổ sung thêm một node mạnh hơn 2-3 lần các node khác, thì lẽ dĩ nhiên chúng ta sẽ trông đợi node mạnh hơn xử lý nhiều công việc, nhận được nhiều tải hơn so với các node nhiều lại.

Mời các bạn đọc thêm bài viết gốc: link

Code & Tools

Tin tức

Kỳ thi Olympic Tin học quốc tế năm 2020 vừa kết thúc, Việt Nam xếp thứ 9 trong tổng số 87 đoàn tham dự.

Bốn thí sinh dự Olympic Tin học quốc tế (IOI) năm 2020 đều đoạt giải, trong đó Bùi Hồng Đức giành huy chương vàng, Vũ Hoàng Kiên (lớp 12) và Lê Quang Huy (lớp 11) của trường THPT chuyên Khoa học Tự nhiên giành huy chương bạc, Trần Quang Thành, lớp 12 trường THPT chuyên Đại học Sư phạm Hà Nội giành huy chương đồng. Chúc mừng đoàn Olympic Tin học Việt Nam.

Quotes

Knowing is not enough; We must apply. Willing is not enough; We must do.

- Bruce Lee