itec - qua trinh phat trien he thong bigdata

1

Quá trình phát triển của hệ thống BigData @

niconicoBùi Hồng Hà

http://bit.ly/itec-bigdata-event

2

Nội dung• Giới thiệu bản thân• Giới thiệu qua về nicovideo• Quá trình phát triển hệ thống bigdata (hệ thống X)

• Bối cảnh lịch sử - quá trình phát triển• Thiết kế dữ liệu

• Một số bài học thu được

3

Giới thiệu bản thân• Bùi Hồng Hà• Kỹ sư hệ thống (infrastructure engineer)• Dwango (2012 – 2016)

• Thiết kế vận hành Nicovideo (và các dịch vụ nhỏ khác)• Thiết kế - xây dựng - vận hành hệ thống X

• Sở thích• Đọc sách• Viết lách http://kipalog.com/users/BuiHongHa/mypage

5

Giới thiệu về niconico• Ra đời năm 2006• “Youtube” Nhật Bản.• Website rank 8 toàn Nhật Bản. Alexa rank: 78• Quy mô người dùng

• 55 triệu người dùng đăng ký• 2.5 triệu người dùng trả tiền

• Mô hình kinh doanh • Subscription• 5$ / tháng

• Tổng số dịch vụ: ~ 50

6

Nicovideo

7

Truyền hình trực tiếp

8

Tranh ảnh – truyện tranh

9

Kênh giao lưu

10

Công nghệ nicovideo (2006 ~ 2014)• Kiến trúc monolithic• LAMP (Linux – Apache – Mysql – PHP)• Máy chủ on-premises

• 4000 – 5000 máy chủ• 3 datacenters

11

Công nghệ nicovideo (2014 ~ 2016)• Kiến trúc

• Chuyển từ monolithic sang hướng dịch vụ (service oriented)

• Công nghệ• PHP Scala• MySQL MariaDB• Apache / Varnish -> nginx

• Máy chủ• On-premises-> Cloud (Amazon / Azure)

12

Quá trình thiết kế và phát triển của hệ thống X

13

Tại sao bài nói này lại về quá trình?• Không có kiến thức tổng quan

• Chia sẻ case-studies

• Phân tích sự việc dựa trên ngữ cảnh• Không có hệ thống ”lởm”• “Those who do not learn history are doomed to repeat it”

• Quyết định của người thiết kế hệ thống là bài học vô giá

14

BigData là gì?

15

Định nghĩa của Gartner• Đặc điểm dữ liệu

• High-volume• High-velocity• High-variety

• Hệ thống: cần hệ thống xử lý dữ liệu mang tính đột phá• Khả năng phân tích thông tin

• Hỗ trợ quá trình ra quyết định• Tự động hoá quy trình

16

Hệ thống X để làm gì?• Xu hướng bigdata

• 2011 – 2012 buzzword• Các cty công nghệ Nhật trong giai đoạn này đều xây dựng hadoop cluster

• Nhu cầu phân tích dữ liệu của chính công ty• Thời gian người dùng xem 1 video là bao lâu?• Nhóm người dùng (độ tuổi, vùng miền, sở thích, thiết bị)• Thông tin thanh toán

• Người dùng của hệ thống X?• Nhân viên kế hoạch• Nhân viên kinh doanh

19

Lược sử• 2012: 10 nodes

• 4T * 10 ~ 40TiB

• cuối 2013: 24 nodes tính toán • CPU Intel Xeon 12 cores (HT), 8T * 24 ~ 192TiB

• 2014: 48 nodes• Intel Xeon 24 cores (HT), 10T (1*10) * 48 nodes ~ 480TiB

• 2015: 96 nodes• ToR (Top of Rack) 10G• Xeon 24 cores (HT), 30T (3T * 10) * 48 nodes• 1.9PB

20

2012 - 2013

21

Bối cảnh năm 2012 - 2013• BigData buzzword

• I keep saying that the sexy job in the next 10 years will be statisticians – Hal Varian

• Hadoop release (2011)

• BigData là lĩnh vực hoàn toàn mới• Chưa có công ty ở Nhật nào triển khai chưa có knowhow• Tài liệu không có nhiều

22

Vấn đề năm 2012 - 2013• Xem con số ở đâu?

• Bộ phận kinh doanh / kế hoạch không có nguồn số liệu

• SRE là người đảm nhận trích xuất dữ liệu• Không phải nhiệm vụ• Dùng các tools: sed / awk / grep / count / SQL... Chạy trực tiếp trên máy chủ

ảnh hưởng trực tiếp đến dịch vụ• Không đảm bảo được tính chính xác của con số

23

Giải pháp của năm 2012 - 2013• Xây dựng “data warehouse” riêng phục vụ cho việc phân tích dữ liệu• Start small

• Không tính đến high-availability• Front không tính đến tính phát triển. • Không dùng tool opensource

24

Kiến trúc năm 2012 - 2013• 1 batch server

• Storage gắn ngoài RAID-5 15T• 1 front server chuyên compile pig ra

Java jar.• Chạy webapp tự viết (CakePHP)• User dùng web interface để

chạy job• 1T storage• 30 users

• 10 nodes tính toán• 8T * 10 ~ 80TiB• CDH2

26

2014 (Năm ít biến động)

27

Bối cảnh năm 2014• Kỳ vọng ngày càng tăng cao

• 1 dịch vụ nhiều loại log gây áp lực lên dung lượng storage• Thời gian chạy job đòi hỏi ngắn lại đòi hỏi nâng cấp cluster

• Hợp đồng với datacenter kết thúc

28

Các vấn đề của năm 2014• Dự toán eo hẹp

• Các máy tính đời 2012 hết hạn bảo hành cần thay mới• Log tích luỹ trong hơn 3 năm (360T / 480T)

• Số lượng máy chủ nhiều (1 máy * 10 đĩa cứng SATA * 48 máy == 480)• Hỏng đĩa cứng trở thành việc hàng tuần• Khi đĩa cứng hỏng máy ngừng phục vụ dịch vụ số lượng cores không đủ• Network / CPU bắt đầu trở thành bottleneck của hệ thống

29

Kiến trúc năm 2014• 48 nodes tính toán

• 10TiB * 48 ~ 480TiB• 12 cores * 48 = 576 cores• CDH5.3

• Provision tools• Chef• Một phần các cài đặt tại OS

layer được thực hiện ở PXE kickstart

• Vấn đề CRC

32

2015 – 2016 (Đột phá)

33

Bối cảnh 2015 - 2016• Hầu hết các log file đều đã được lưu trữ trên hệ thống X

• Đến lúc cải tiến và nâng cấp hệ thống• Knowhow việc nâng cấp vận hành hệ thống

• Stream processing• Công nghệ container trở thành tâm điểm

• docker

• Cloud computing

34

Vấn đề gặp phải• Tính sẵn sàng của hệ thống chưa được cải thiện• Stream processing là công nghệ hoàn toàn mới• Docker là công nghệ mới• Các dịch vụ mới bắt đầu được triển khai trên cloud

36

Giải quyết 1: sử dụng lxc containerContainer là công nghệ không mới.

Chi tiết: http://kipalog.com/tags/LXC

38

Giải quyết 2: sử dụng đĩa cứng 3T• Tránh việc nâng cấp hệ thống qua từng năm

• Việc xin kinh phí rất phiền phức• Quá trình nâng cấp và mở rộng tốn rất nhiều cost.

• Tránh dùng công nghệ cũ• Đĩa cứng 3T dần trở nên phổ biến. • 1 máy chủ có thời gian khấu hao là 5 năm dùng công nghệ cũ trong 5 năm

39

Giải quyết 3: thêm streaming layer• Streaming layer được phát triển mang tính thử nghiệm• Streaming layer dùng fluentd

• Fluentd do người Nhật phát triển• “Người người nhà nhà” dùng fluentd knowhow có nhiều• Cấu hình và sử dụng đơn giản

40

Kiến trúc hệ thống 2015 - 2016

42

Các vấn đề còn tồn đọng• Vấn đề của streaming layer

• Fluentd không được thiết kế để phục hồi khi có sự cố• Fluentd không đáp ứng đủ hiệu năng• Fluentd không được thiết kế để routing log qua internet• Không join được với master data

• Vấn đề batch• SPOF ở batch server• Thiếu cơ chế quản lý job batch

• Vấn đề của lxc• Vấn đề về chuẩn hoá kiểu dữ liệu

43

Star-Schema trong Data warehouse

** The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling

44

Thiết kế schema• Dữ liệu như access log là dữ liệu “thô”

• Không có schema• Gây khó khăn trong việc phân tích

• Sử dụng storage như kudu để tăng tốc

45

Bài học cá nhân• The management question, therefore, is not whether to build a

pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow. – Fred Brooks

• Nguyên tắc 40% cho các hệ thống đang phát triển• Thiết kế để hệ thống phát triển

• Không có SPOF• Có phương án phục hồi khi gặp sự cố

• Định kỳ viết ra knowhow của mình và chia sẻ cho mọi người

46

Tương lai của BigData?

47

I asked Doug that question

48

He said he doesn’t know …

49

Một số nguồn tài liệu• https://amplab.cs.berkeley.edu/• https://databricks.com/blog• Hadoop / Spark Mailing list• https://dancres.github.io/Pages/• Gartner / McKinsey / … Reports

50

Cảm ơn các bạn đã lắng nghe !