Cơ sở hạ tầng dữ liệu tại Airbnb

Bởi James Mayfield , Krishna Puttaswamy , Swaroop Jagadish và Kevin Long

Phần 1: Triết lý đằng sau cơ sở hạ tầng dữ liệu của chúng tôi

Tại Airbnb, chúng tôi thúc đẩy văn hóa thông tin dữ liệu và sử dụng dữ liệu làm đầu vào quan trọng để đưa ra quyết định. Theo dõi các chỉ số, xác thực giả thuyết thông qua thử nghiệm, xây dựng mô hình học máy và khai thác để có thông tin chi tiết sâu sắc về doanh nghiệp đều rất quan trọng đối với việc di chuyển nhanh và thông minh của chúng ta.

Sau nhiều bước phát triển, giờ đây chúng tôi cảm thấy rằng cơ sở hạ tầng dữ liệu của chúng tôi ổn định, đáng tin cậy và có thể mở rộng, vì vậy đây có vẻ như là một cơ hội tốt để chia sẻ kinh nghiệm của chúng tôi với cộng đồng. Trong vài tuần tới, chúng tôi sẽ phát hành một loạt các bài đăng trên blog nêu bật các phần của kiến ​​trúc phân tán và bộ công cụ của chúng tôi. Bởi vì những người đóng góp nguồn mở đã cung cấp nhiều hệ thống cơ bản mà chúng tôi sử dụng hàng ngày, điều đó khiến chúng tôi rất vui khi đóng góp lại không chỉ các dự án hữu ích trong các kho lưu trữ GitHub công khai mà còn để mô tả những điều chúng tôi đã học được trong suốt quá trình.

Một số triết lý không chính thức đã xuất hiện trong thời gian chúng tôi làm việc trên cơ sở hạ tầng dữ liệu:

• Nhìn vào thế giới nguồn mở: có rất nhiều tài nguyên tốt cho cơ sở hạ tầng dữ liệu trong cộng đồng nguồn mở và chúng tôi cố gắng áp dụng những hệ thống đó. Hơn nữa, nếu chúng ta tự xây dựng một thứ gì đó hữu ích và khả thi để trao lại nó cho cộng đồng, chúng ta sẽ đáp lại.
• Ưu tiên các thành phần và phương pháp tiêu chuẩn : Đôi khi việc phát minh ra một phần cơ sở hạ tầng hoàn toàn mới là hợp lý, nhưng thường thì đây không phải là cách sử dụng tốt các nguồn lực. Có trực giác về thời điểm xây dựng một giải pháp duy nhất và khi nào áp dụng một giải pháp hiện có là điều quan trọng, và trực giác đó phải tính đúng chi phí tiềm ẩn của việc bảo trì và hỗ trợ.
• Đảm bảo nó có thể mở rộng quy mô: chúng tôi nhận thấy rằng dữ liệu không phát triển tuyến tính với doanh nghiệp, nhưng phát triển siêu tuyến tính khi các nhân viên kỹ thuật bắt đầu xây dựng sản phẩm mới và ghi lại các hoạt động mới dựa trên sự phát triển của doanh nghiệp.
• Giải quyết các vấn đề thực tế bằng cách lắng nghe đồng nghiệp của bạn: đồng cảm với những người dùng dữ liệu xung quanh công ty là một phần quan trọng trong việc thông báo lộ trình của chúng tôi. Để tuân theo câu thần chú của Henry Ford, chúng ta phải cân bằng giữa việc tạo ra những con ngựa nhanh hơn và chế tạo ô tô - nhưng trước tiên hãy lắng nghe khách hàng của bạn.
• Để lại một số khoảng trống: chúng tôi đăng ký tài nguyên quá mức cho các cụm của chúng tôi để thúc đẩy văn hóa khám phá không giới hạn. Các nhóm cơ sở hạ tầng rất dễ bị cuốn vào sự phấn khích của việc tối đa hóa nguồn lực quá sớm, nhưng giả thuyết của chúng tôi là một cơ hội kinh doanh mới được tìm thấy trong nhà kho sẽ nhiều hơn bù đắp những máy móc thừa đó.

Đây là một sơ đồ đơn giản cho thấy các thành phần chính của cơ sở hạ tầng của chúng tôi.

Dữ liệu nguồn được đưa vào hệ thống của chúng tôi từ hai kênh chính: thiết bị đo trong mã nguồn gửi các sự kiện qua Kafka và kết xuất cơ sở dữ liệu sản xuất được lấy bằng cách sử dụng khôi phục điểm trong thời gian AWS trên RDS, sau đó được phân phối qua Sqoop .

Dữ liệu nguồn này chứa dữ liệu sự kiện hoạt động của người dùng và ảnh chụp nhanh thứ nguyên sau đó được gửi vào cụm Gold nơi chúng tôi lưu trữ dữ liệu và bắt đầu chạy các công việc trích xuất, chuyển đổi và tải của chúng tôi. Trong bước này, chúng tôi áp dụng logic nghiệp vụ, lập bảng tóm tắt và thực hiện kiểm tra chất lượng dữ liệu.

Trong sơ đồ trên, có hai cụm riêng biệt cho “Vàng” và “Bạc” mà chúng tôi sẽ mô tả chi tiết hơn ở phần sau của bài đăng này. Lý do cấp cao cho sự tách biệt là để đảm bảo sự cô lập của các tài nguyên máy tính và lưu trữ và nó cung cấp các đảm bảo khôi phục sau thảm họa nếu từng có sự cố mất điện. Kiến trúc này cung cấp một môi trường Vàng nơi các công việc quan trọng nhất có thể chạy với sự đảm bảo nghiêm ngặt và các thỏa thuận mức dịch vụ, không bị ảnh hưởng bởi bất kỳ sự can thiệp nào do các truy vấn đặc biệt sử dụng nhiều tài nguyên. Chúng tôi cũng coi Silver cluster là một môi trường sản xuất, nhưng nới lỏng các đảm bảo được thực hiện và chấp nhận sự bùng nổ của các truy vấn sử dụng nhiều tài nguyên.

Lưu ý rằng bằng cách có hai cụm, chúng ta có được sức mạnh của sự cô lập, nhưng nó phải trả giá bằng cách quản lý sao chép dữ liệu khối lượng lớn và duy trì tính đồng bộ giữa các hệ thống động. Vàng là nguồn chân lý của chúng tôi và chúng tôi sao chép từng bit dữ liệu từ Vàng xuống Bạc. Dữ liệu được tạo ra trên cụm Silver không được sao chép trở lại Gold, và vì vậy bạn có thể coi đây là một sơ đồ sao chép một chiều khiến cụm Silver như một tập hợp siêu của mọi thứ. Bởi vì phần lớn phân tích và báo cáo của chúng tôi xảy ra từ cụm Silver, điều quan trọng là khi dữ liệu mới chuyển sang Gold, chúng tôi sẽ sao chép nó trên Silver càng sớm càng tốt để giữ cho tất cả các công việc của người dùng hoạt động không bị chậm trễ. Nghiêm trọng hơn, nếu chúng tôi cập nhật một phần dữ liệu đã có từ trước trên cụm Vàng, chúng tôi phải được cảnh báo về bản cập nhật đó và truyền tải thay đổi xuống cả Bạc. Vấn đề tối ưu hóa sao chép này không có giải pháp tốt trong mã nguồn mở, vì vậy chúng tôi đã xây dựng một bộ công cụ mới mà chúng tôi sẽ mô tả chi tiết hơn trong một bài đăng sắp tới.

Chúng tôi đã rất nỗ lực để xử lý HDFS và chính xác hơn là coi các bảng được quản lý bởi Hive, là nguồn trung tâm và nơi chứa dữ liệu của chúng tôi. Chất lượng và sự tỉnh táo của kho phụ thuộc vào dữ liệu là bất biến và tất cả các nguồn gốc của dữ liệu đều có thể tái tạo - sử dụng bảng Hive được phân vùng thực sự quan trọng cho mục tiêu này. Hơn nữa, chúng tôi không khuyến khích sự gia tăng của các hệ thống dữ liệu khác nhau và không muốn duy trì cơ sở hạ tầng riêng biệt nằm giữa dữ liệu nguồn và báo cáo người dùng cuối của chúng tôi. Theo kinh nghiệm của chúng tôi, các hệ thống trung gian này làm xáo trộn các nguồn sự thật, tăng gánh nặng cho việc quản lý ETL và gây khó khăn cho việc truy tìm nguồn gốc của một số liệu trên bảng điều khiển theo cách trở lại dữ liệu nguồn mà nó được lấy từ đó. Chúng tôi không chạy Oracle, Teradata, Vertica, Redshift, v.v. và thay vào đó sử dụng Presto cho hầu hết các truy vấn đặc biệt trên các bảng được quản lý bởi Hive. Chúng tôi hy vọng sẽ liên kết trực tiếp Presto với cài đặt Tableau của chúng tôi trong tương lai gần.

Một số điều khác cần lưu ý trong sơ đồ bao gồm Airpal , một công cụ thực thi truy vấn dựa trên web được hỗ trợ bởi Presto mà chúng tôi đã xây dựng và có nguồn mở. Đây là giao diện chính của chúng tôi để người dùng chạy các truy vấn SQL đặc biệt đối với kho hàng và hơn 1/3 tổng số nhân viên đã chạy các truy vấn bằng công cụ này. Lập lịch công việc diễn ra thông qua Airflow , một nền tảng để tạo lập trình, lập lịch và theo dõi các đường ống dữ liệu có thể chạy các công việc trên Hive, Presto, Spark, MySQL, v.v. - lưu ý rằng chúng tôi chia sẻ Airflow một cách hợp lý giữa các cụm, nhưng về mặt vật lý thì các công việc của Airflow chạy trên các nhóm cụm, máy móc và công nhân thích hợp .. Chúng tôi đã xây dựng Luồng khí và mở nguồn cung cấp đó. Cụm Spark là một công cụ xử lý khác được các kỹ sư và nhà khoa học dữ liệu làm việc trên máy học rất ưa chuộng và rất hữu ích cho việc xử lý luồng. Bạn có thể xem thêm các nỗ lực ML của chúng tôi trong bài đăng Aerosolve . S3 là một hệ thống lưu trữ riêng biệt, nơi chúng ta có thể gỡ bỏ dữ liệu từ HDFS để lưu trữ lâu dài với giá rẻ. Các bảng được quản lý bởi Hive có thể thay đổi bộ nhớ của chúng và trỏ tới các tệp S3 để duy trì các mẫu truy cập dễ dàng và quản lý siêu dữ liệu.

Phần 3: Cái nhìn chi tiết về sự tiến hóa của cụm Hadoop của chúng tôi

Năm nay, chúng tôi đã thực hiện một cuộc di chuyển đáng kể để chuyển từ một nhóm các cụm có cấu trúc kém gọi là “Pinky và Brain” sang hệ thống “Gold và Silver” được mô tả ở trên. Để đặt một số bối cảnh cho quy mô, hai năm trước, chúng tôi đã chuyển từ Amazon EMR sang một tập hợp các phiên bản EC2 chạy HDFS với 300 terabyte dữ liệu. Ngày nay, chúng tôi có hai cụm HDFS riêng biệt với 11 petabyte dữ liệu và chúng tôi cũng lưu trữ nhiều petabyte dữ liệu trong S3. Với nền tảng đó, đây là những vấn đề chính và chúng tôi đã làm gì để giải quyết chúng:

A) Chạy một Hadoop duy nhất trên kiến ​​trúc Mesos

Một số kỹ sư Airbnb ban đầu rất quan tâm đến một phần của cơ sở hạ tầng được gọi là Mesos, được thiết lập để triển khai một cấu hình duy nhất trên nhiều máy chủ. Chúng tôi đã xây dựng một cụm máy c3.8xlarge duy nhất trong AWS, mỗi máy được hỗ trợ bởi 3TB EBS và chạy tất cả Hadoop, Hive, Presto, Chronos và Marathon trên Mesos.

Để rõ ràng hơn, nhiều công ty sử dụng Mesos để tạo ra hiệu quả lớn và thực hiện các giải pháp mới để quản lý các bộ máy lớn chạy cơ sở hạ tầng quan trọng. Tuy nhiên, nhóm nhỏ của chúng tôi quyết định chạy một triển khai tiêu chuẩn hơn, phổ biến hơn sẽ giảm thời gian chúng tôi dành cho các hoạt động và gỡ lỗi.

Hadoop về các vấn đề của Mesos:

• Rất ít khả năng hiển thị các công việc đang chạy và tệp nhật ký
• Rất ít khả năng hiển thị về tình trạng cụm
• Hadoop trên Mesos chỉ có thể chạy MR1
• Các vấn đề về hiệu suất do tranh chấp trình theo dõi tác vụ
• Cụm đang được sử dụng
• Tải hoạt động cao và lý luận khó khăn về hệ thống
• Thiếu tích hợp với Kerberos để bảo mật

B) Đọc và ghi từ xa

Bằng cách lưu trữ tất cả dữ liệu HDFS của chúng tôi trong các ổ EBS (lưu trữ khối đàn hồi) được gắn kết, chúng tôi đã gửi rất nhiều dữ liệu qua mạng Amazon EC2 công cộng để chạy các truy vấn. Hadoop được xây dựng cho phần cứng hàng hóa và mong muốn đọc và ghi cục bộ trên các đĩa quay, vì vậy đây là một thiết kế không phù hợp.

Hơn nữa về bản chất từ ​​xa của việc đọc và ghi, chúng tôi đã chọn không chính xác để phân chia bộ nhớ dữ liệu của mình thành ba vùng khả dụng riêng biệt, trong một vùng duy nhất, trong AWS. Hơn nữa, mỗi vùng khả dụng được chỉ định là “giá đỡ” riêng của nó, do đó 3 bản sao được lưu trữ trên các giá đỡ khác nhau, do đó việc đọc và ghi từ xa được diễn ra liên tục. Đây lại là một lỗi thiết kế dẫn đến việc truyền dữ liệu chậm và các bản sao từ xa xảy ra bất cứ lúc nào máy bị mất hoặc một khối bị hỏng.

Giải pháp: có các phiên bản chuyên dụng sử dụng bộ nhớ cục bộ và chạy trong một vùng khả dụng duy nhất mà không có EBS đã khắc phục các vấn đề này.

C) Khối lượng công việc không đồng nhất trên các máy đồng nhất

Nhìn vào khối lượng công việc của chúng tôi, chúng tôi thấy rằng có những yêu cầu riêng biệt đối với các thành phần kiến ​​trúc của chúng tôi. Máy Hive / Hadoop / HDFS của chúng tôi yêu cầu rất nhiều dung lượng lưu trữ, nhưng không cần nhiều RAM hoặc CPU. Presto và Spark khát bộ nhớ và sức mạnh xử lý, nhưng không cần nhiều dung lượng lưu trữ. Chạy các phiên bản c3.8xlarge được hỗ trợ bởi 3TB EBS được chứng minh là rất tốn kém vì dung lượng lưu trữ là yếu tố hạn chế của chúng tôi.

Giải pháp: Khi chúng tôi di chuyển khỏi kiến ​​trúc Mesos, chúng tôi có thể chọn các loại máy khác nhau để chạy các cụm khác nhau, ví dụ: sử dụng các phiên bản r3.8xlarge để chạy Spark. Amazon tình cờ phát hành các phiên bản “D-series” thế hệ mới của họ vào thời điểm chúng tôi đang đánh giá một sự thay đổi, điều này khiến sự chuyển đổi thậm chí còn đáng mong đợi hơn từ góc độ chi phí. Việc chuyển từ 3TB dung lượng lưu trữ từ xa cho mỗi nút trên máy c3.8xlarge sang 48TB dung lượng lưu trữ cục bộ trên các máy d2.8xlarge rất hấp dẫn và sẽ giúp chúng ta tiết kiệm hàng triệu đô la trong ba năm tới.

D) Liên kết HDFS

Chúng tôi đã chạy một cụm HDFS được liên kết với Pinky và Brain nơi dữ liệu được lưu trữ trong các nhóm khối vật lý được chia sẻ nhưng các bộ ánh xạ và bộ giảm thiểu được phân lập trên mỗi cụm logic. Điều này dẫn đến trải nghiệm người dùng cuối tuyệt vời trong đó bất kỳ phần dữ liệu nào có thể được truy cập bằng truy vấn Pinky hoặc truy vấn Brain, nhưng rất tiếc, chúng tôi nhận thấy rằng liên kết không được hỗ trợ rộng rãi và được các chuyên gia coi là thử nghiệm và không đáng tin cậy.

Độ phân giải: chuyển sang một tập hợp các nút HDFS hoàn toàn khác biệt và không chạy liên kết, đã cho chúng tôi sự cô lập thực sự của các cụm ở cấp máy, điều này cũng cung cấp phạm vi phục hồi thảm họa tốt hơn.

E) Giám sát hệ thống là một gánh nặng

Một trong những vấn đề nghiêm trọng nhất của việc có một hệ thống cơ sở hạ tầng duy nhất là buộc phải tạo ra giám sát và cảnh báo tùy chỉnh cho cụm. Hadoop, Hive và HDFS là những hệ thống phức tạp, dễ gặp lỗi trên nhiều nút bấm và mặt số của chúng. Cố gắng dự đoán tất cả các trạng thái thất bại và đặt ngưỡng máy nhắn tin hợp lý tỏ ra khá khó khăn và chúng tôi cũng cảm thấy rằng chúng tôi đang giải quyết một vấn đề đã được giải quyết.

Giải pháp: chúng tôi đã ký hợp đồng hỗ trợ với Cloudera để có được kiến ​​thức từ chuyên môn của họ trong việc kiến ​​trúc và vận hành các hệ thống lớn này, và quan trọng nhất là giảm gánh nặng bảo trì của chúng tôi bằng cách sử dụng công cụ Cloudera Manager. Việc liên kết nó với các công thức Chef của chúng tôi đã giảm bớt đáng kể gánh nặng giám sát và cảnh báo và chúng tôi vui mừng thông báo rằng chúng tôi dành rất ít thời gian cho việc bảo trì và cảnh báo hệ thống.

Phần kết luận

Sau khi đánh giá tất cả các lỗi và sự kém hiệu quả với thiết lập cụm cũ của chúng tôi, chúng tôi bắt đầu giải quyết những vấn đề này một cách có hệ thống. Đó là một quá trình dài để di chuyển hàng petabyte dữ liệu và hàng trăm công việc của người dùng mà không làm gián đoạn dịch vụ cho các đồng nghiệp của chúng tôi; chúng tôi sẽ viết một bài mới về chủ đề đó một mình và phát hành một số công cụ của chúng tôi cho cộng đồng nguồn mở.

Hiện tại, quá trình di chuyển đã hoàn tất, chúng tôi đã giảm đáng kể số lượng sự cố và ngừng hoạt động trong nền tảng của mình. Không khó để hình dung số lỗi và số vấn đề mà chúng tôi đã xử lý khi chạy ngăn xếp tùy chỉnh của mình trên các nền tảng chưa trưởng thành, nhưng hệ thống hiện đã hoạt động tốt và phần lớn ổn định. Lợi ích khác là khi chúng tôi thuê các kỹ sư mới tham gia vào nhóm, việc giới thiệu được sắp xếp hợp lý vì các hệ thống đã quen thuộc với những gì các công ty khác đã áp dụng.

Cuối cùng, bởi vì chúng tôi có cơ hội kiến ​​trúc mọi thứ mới mẻ trong thiết lập Vàng và Bạc mới, chúng tôi có cơ hội xoay quanh tất cả các phiên bản mới và thêm vai trò IAM để quản lý bảo mật theo cách hợp lý. Điều này có nghĩa là một lớp kiểm soát truy cập lành mạnh hơn nhiều trên đầu cụm và tích hợp với cách chúng tôi quản lý tất cả các máy của mình.

Thực tế là chúng tôi có thể cắt giảm đáng kể chi phí và đồng thời tăng hiệu suất thật tuyệt vời. Dưới đây là một vài số liệu thống kê:

• Đọc / ghi đĩa được cải thiện từ 70–150MB / giây lên 400+ MB / giây
• Hive công việc nhanh hơn ~ 2 lần trong thời gian CPU và đồng hồ treo tường
• Mạng có thể được bão hòa hoàn toàn trên máy của chúng tôi, khi có thể
• Thông lượng đọc tốt hơn ~ 3 lần
• Thông lượng ghi tốt hơn ~ 2 lần
• Chi phí giảm 70%

Xin gửi lời cảm ơn sâu sắc tới đội ngũ kỹ sư đã xây dựng nền tảng cơ sở hạ tầng dữ liệu ban đầu tại Airbnb và những người đã và đang làm việc đều đặn để cải thiện và ổn định hệ thống. Tôi rất vui khi viết bài đăng trên blog này nhưng công lao thực sự thuộc về Nick Barrow-Williams, Greg Brandt, Dan Davydov, Wensheng Hua, Swaroop Jagadish, Andy Kramolisch, Kevin Long, Jingwei Lu, Will Moss, Krishna Puttaswamy, Liyin Tang, Paul Yang, Hongbo Zeng và Jason Zhang.

Xem tất cả các dự án mã nguồn mở của chúng tôi tại airbnb.io và theo dõi chúng tôi trên Twitter: @AirbnbEng + @AirbnbData