Xin chào, Habr! Đăng ký cho một luồng khóa học mới hiện đang mở tại OTUS . Để chuẩn bị cho khóa học bắt đầu, theo truyền thống, chúng tôi đã chuẩn bị một bản dịch các tài liệu thú vị cho bạn.
Mỗi ngày, hơn một trăm triệu người truy cập Twitter để tìm hiểu chuyện gì đang xảy ra trên thế giới và thảo luận về nó. Mỗi tweet và mọi hành động khác của người dùng đều tạo ra một sự kiện có sẵn để phân tích dữ liệu nội bộ của Twitter. Hàng trăm nhân viên phân tích và trực quan hóa dữ liệu này, đồng thời cải thiện trải nghiệm của họ là ưu tiên hàng đầu của nhóm Nền tảng dữ liệu Twitter.
Chúng tôi tin rằng người dùng có nhiều kỹ năng kỹ thuật sẽ có thể khám phá dữ liệu và có quyền truy cập vào các công cụ phân tích và trực quan hóa dựa trên SQL hoạt động tốt. Điều này sẽ cho phép một nhóm người dùng hoàn toàn mới ít kỹ thuật hơn, bao gồm các nhà phân tích dữ liệu và quản lý sản phẩm, trích xuất thông tin chi tiết từ dữ liệu, cho phép họ hiểu và sử dụng tốt hơn các khả năng của Twitter. Đây là cách chúng tôi dân chủ hóa việc phân tích dữ liệu trên Twitter.
Khi các công cụ và khả năng phân tích dữ liệu nội bộ của chúng tôi được cải thiện, chúng tôi cũng thấy Twitter được cải thiện. Tuy nhiên, vẫn còn chỗ để cải thiện. Các công cụ hiện tại như Scalding yêu cầu kinh nghiệm lập trình. Các công cụ phân tích dựa trên SQL như Presto và Vertica có vấn đề về hiệu suất trên quy mô lớn. Chúng tôi cũng gặp vấn đề về phân phối dữ liệu trên nhiều hệ thống mà không có quyền truy cập liên tục vào dữ liệu đó.
Năm ngoái chúng tôi đã công bố , trong đó chúng tôi chuyển các phần của chúng tôi trên Nền tảng đám mây của Google (GCP). Chúng tôi đã kết luận rằng các công cụ của Google Cloud có thể giúp chúng tôi thực hiện các sáng kiến dân chủ hóa hoạt động phân tích, trực quan hóa và học máy trên Twitter:
- : kho dữ liệu doanh nghiệp dựa trên công cụ SQL , nổi tiếng với tốc độ, sự đơn giản và khả năng đối phó với .
- công cụ trực quan hóa dữ liệu lớn với các tính năng cộng tác giống như Google Docs.
Trong bài viết này, bạn sẽ tìm hiểu về trải nghiệm của chúng tôi với những công cụ này: những gì chúng tôi đã làm, những gì chúng tôi đã học được và những gì chúng tôi sẽ làm tiếp theo. Bây giờ chúng ta sẽ tập trung vào phân tích hàng loạt và phân tích tương tác. Chúng ta sẽ thảo luận về phân tích thời gian thực trong bài viết tiếp theo.
Lịch sử của các kho dữ liệu Twitter
Trước khi đi sâu vào BigQuery, bạn nên kể lại ngắn gọn lịch sử lưu trữ dữ liệu của Twitter. Năm 2011, phân tích dữ liệu Twitter đã được thực hiện ở Vertica và Hadoop. Chúng tôi đã sử dụng Pig để tạo các công việc MapReduce Hadoop. Vào năm 2012, chúng tôi đã thay thế Pig bằng Scalding, có API Scala với các lợi ích như khả năng tạo các quy trình phức tạp và dễ dàng thử nghiệm. Tuy nhiên, đối với nhiều nhà phân tích dữ liệu và người quản lý sản phẩm, những người cảm thấy thoải mái hơn khi làm việc với SQL, đó là một chặng đường học tập khá dốc. Khoảng năm 2016, chúng tôi bắt đầu sử dụng Presto làm giao diện SQL cho dữ liệu Hadoop. Spark cung cấp giao diện Python, khiến nó trở thành một lựa chọn tốt cho khoa học dữ liệu và học máy đặc biệt.
Kể từ năm 2018, chúng tôi đã sử dụng các công cụ sau để phân tích và trực quan hóa dữ liệu:
- Cán cho băng tải sản xuất
- Scalding và Spark để phân tích dữ liệu đặc biệt và học máy
- Vertica và Presto để phân tích SQL tương tác và đặc biệt
- Druid để truy cập có độ tương tác thấp, khám phá và độ trễ thấp vào các số liệu chuỗi thời gian
- Tableau, Zeppelin và Pivot để trực quan hóa dữ liệu
Chúng tôi nhận thấy rằng mặc dù những công cụ này cung cấp những khả năng rất mạnh mẽ nhưng chúng tôi gặp khó khăn trong việc cung cấp những khả năng này cho nhiều đối tượng hơn trên Twitter. Bằng cách mở rộng nền tảng của chúng tôi với Google Cloud, chúng tôi đang tập trung vào việc đơn giản hóa các công cụ phân tích của mình cho toàn bộ Twitter.
Kho dữ liệu BigQuery của Google
Một số nhóm tại Twitter đã kết hợp BigQuery vào một số quy trình sản xuất của họ. Sử dụng kiến thức chuyên môn của họ, chúng tôi bắt đầu đánh giá khả năng của BigQuery cho tất cả các trường hợp sử dụng Twitter. Mục tiêu của chúng tôi là cung cấp BigQuery cho toàn bộ công ty, đồng thời chuẩn hóa và hỗ trợ nó trong bộ công cụ Nền tảng dữ liệu. Điều này thật khó khăn vì nhiều lý do. Chúng tôi cần phát triển cơ sở hạ tầng để xử lý khối lượng lớn dữ liệu một cách đáng tin cậy, hỗ trợ quản lý dữ liệu trên toàn công ty, đảm bảo kiểm soát quyền truy cập phù hợp và đảm bảo quyền riêng tư của khách hàng. Chúng tôi cũng phải tạo ra các hệ thống phân bổ, giám sát và bồi hoàn tài nguyên để các nhóm có thể sử dụng BigQuery một cách hiệu quả.
Vào tháng 2018 năm 250, chúng tôi đã phát hành bản phát hành alpha toàn công ty của BigQuery và Data Studio. Chúng tôi đã cung cấp cho nhân viên Twitter một số bảng tính được sử dụng thường xuyên nhất với dữ liệu cá nhân đã được làm sạch. BigQuery đã được hơn 8 người dùng từ nhiều nhóm khác nhau bao gồm kỹ thuật, tài chính và tiếp thị sử dụng. Gần đây nhất, họ đang chạy khoảng 100k yêu cầu, xử lý khoảng XNUMX PB mỗi tháng, chưa tính các yêu cầu đã lên lịch. Sau khi nhận được phản hồi rất tích cực, chúng tôi quyết định tiếp tục và cung cấp BigQuery làm tài nguyên chính để tương tác với dữ liệu trên Twitter.
Đây là sơ đồ cấp cao về kiến trúc kho dữ liệu Google BigQuery của chúng tôi.
Chúng tôi sao chép dữ liệu từ các cụm Hadoop tại chỗ sang Google Cloud Storage (GCS) bằng công cụ Cloud Replicator nội bộ. Sau đó, chúng tôi sử dụng Apache Airflow để tạo các đường dẫn sử dụng "» để tải dữ liệu từ GCS vào BigQuery. Chúng tôi sử dụng Presto để truy vấn bộ dữ liệu Parquet hoặc Thrift-LZO trong GCS. BQ Blaster là một công cụ Scalding nội bộ để tải bộ dữ liệu HDFS Vertica và Thrift-LZO vào BigQuery.
Trong các phần sau, chúng tôi thảo luận về cách tiếp cận và chuyên môn của chúng tôi trong các lĩnh vực dễ sử dụng, hiệu suất, quản lý dữ liệu, tình trạng hệ thống và chi phí.
Dễ sử dụng
Chúng tôi nhận thấy rằng người dùng dễ dàng bắt đầu với BigQuery vì nó không yêu cầu cài đặt phần mềm và người dùng có thể truy cập nó thông qua giao diện web trực quan. Tuy nhiên, người dùng cần làm quen với một số tính năng và khái niệm của GCP, bao gồm các tài nguyên như dự án, bộ dữ liệu và bảng. Chúng tôi đã phát triển các tài liệu giáo dục và hướng dẫn để giúp người dùng bắt đầu. Với kiến thức cơ bản đã đạt được, người dùng thấy dễ dàng điều hướng các tập dữ liệu, xem lược đồ và dữ liệu bảng, chạy các truy vấn đơn giản và trực quan hóa kết quả trong Data Studio.
Mục tiêu của chúng tôi khi nhập dữ liệu vào BigQuery là cho phép tải liền mạch các bộ dữ liệu HDFS hoặc GCS chỉ bằng một cú nhấp chuột. Chúng tôi coi (được quản lý bởi Airflow) nhưng không thể sử dụng nó do mô hình bảo mật Chia sẻ hạn chế miền của chúng tôi (xem thêm về điều này trong phần Quản lý dữ liệu bên dưới). Chúng tôi đã thử nghiệm sử dụng Dịch vụ truyền dữ liệu của Google (DTS) để điều phối khối lượng công việc BigQuery. Mặc dù DTS được thiết lập nhanh chóng nhưng nó không linh hoạt trong việc xây dựng các quy trình có sự phụ thuộc. Đối với bản phát hành alpha, chúng tôi đã xây dựng khung Apache Airflow của riêng mình trong GCE và đang chuẩn bị chạy nó trong sản xuất cũng như có thể hỗ trợ nhiều nguồn dữ liệu hơn như Vertica.
Để chuyển đổi dữ liệu thành BigQuery, người dùng tạo các đường dẫn dữ liệu SQL đơn giản bằng cách sử dụng các truy vấn được lên lịch. Đối với các quy trình nhiều giai đoạn phức tạp có phần phụ thuộc, chúng tôi dự định sử dụng khung Airflow hoặc Cloud Composer của riêng mình cùng với .
Năng suất
BigQuery được thiết kế cho các truy vấn SQL có mục đích chung xử lý lượng lớn dữ liệu. Nó không dành cho các truy vấn có độ trễ thấp, thông lượng cao theo yêu cầu của cơ sở dữ liệu giao dịch hoặc để thực hiện phân tích chuỗi thời gian có độ trễ thấp . Đối với các truy vấn phân tích tương tác, người dùng của chúng tôi mong đợi thời gian phản hồi dưới một phút. Chúng tôi phải thiết kế việc sử dụng BigQuery để đáp ứng những kỳ vọng này. Để cung cấp hiệu suất có thể dự đoán cho người dùng, chúng tôi đã tận dụng chức năng BigQuery, có sẵn cho khách hàng trên cơ sở tính phí cố định, cho phép chủ sở hữu dự án đặt trước các vị trí tối thiểu cho truy vấn của họ. BigQuery là một đơn vị sức mạnh tính toán cần thiết để thực hiện các truy vấn SQL.
Chúng tôi đã phân tích hơn 800 truy vấn xử lý mỗi truy vấn khoảng 1 TB dữ liệu và nhận thấy rằng thời gian thực hiện trung bình là 30 giây. Chúng tôi cũng biết được rằng hiệu suất phụ thuộc rất nhiều vào việc sử dụng vị trí của chúng tôi trong các dự án và nhiệm vụ khác nhau. Chúng tôi phải phân định rõ ràng nguồn dự trữ sản xuất và vị trí đặc biệt của mình để duy trì hiệu suất cho các trường hợp sử dụng sản xuất và phân tích trực tuyến. Điều này ảnh hưởng lớn đến thiết kế của chúng tôi đối với việc đặt trước vị trí và phân cấp dự án.
Chúng ta sẽ nói về quản lý dữ liệu, chức năng và chi phí của hệ thống trong những ngày tới trong phần thứ hai của bản dịch, nhưng bây giờ chúng tôi mời mọi người cùng tham khảo. , trong thời gian đó, bạn sẽ có thể tìm hiểu chi tiết về khóa học cũng như đặt câu hỏi với chuyên gia của chúng tôi - Egor Mateshuk (Kỹ sư dữ liệu cấp cao, MaximaTelecom).
Đọc thêm:
Nguồn: www.habr.com