网易大数据平台架构实践分享！

随着网易云音乐、新闻、考拉、严选等互联网业务的快速发展，网易开始加速大数据平台建设，以提高数据获取速度，提升数据分析效率，更快发挥数据价值。 本次演讲主要分享网易如何围绕和改造开源技术，以产品化思维打造网易自己的大数据平台， 也会分享一下网易在大数据平台构建和支撑互联网业务过程中面临的技术挑战，以及我们在调度、安全、元数据管理、spark多租户、SQL流计算、高性能查询引擎等关键技术环节的实践经验。 最后会介绍一下，网易大数据平台未来的技术路线规划。

分享大纲：

1、大数据平台概述

2、Sloth：实时计算

3、Kudu：实时更新存储

4、Kyuubi：Spark 多租户

5、未来规划

正文：

2008年之前，网易一直在使用传统数据库软件，随着数据量的增大逐渐过渡到Hadoop平台。2009年，网易发现单独的Hadoop平台不足以满足内部数据量的需求，便开始着手研发相关工具。2014年之后，随着网易云音乐和网易考拉等业务的发展，网易原有工具也无法支撑庞大的数据使用诉求，网易开始进入平台化阶段，推出网易猛犸和网易有数两款产品。

网易猛犸是面向网易集团内部的大数据平台软件，网易有数是企业级智能可视化分析平台。网易之所以推出这两款产品，是因为单纯维护Hadoop并不能满足数据使用诉求，我认为最核心的原因是大数据系统难以使用，以下是一个典型的数据处理流程：

数据从Kafka出发，通过Flink处理同时写入HDFS和HBase。HDFS的数据经过Spark进一步处理最终将汇总数据返回HDFS，传递给BI软件进行展示或者为线上数据提供支持。如果将大数据系统与数据库内核做对比，我们发现Kafka其实类似于数据库中的Redo log，Hbase/ES代表一个索引，经过进一步汇总最终形成物化视图HDFS Parquet。

表和索引通过Kafka日志保证一致，相当于将组件重新组成类数据库内核的样子让各组件配合工作，保证系统的稳定性和性能。整体来看，这件事情比较复杂，一番折腾下来，我们认为大数据系统还是比较难用的，需要花费大量精力组装搭配，虽然这也证明了大数据系统比较灵活，但确实进入门槛较高。

我们考虑要做一个大数据平台，就需要先搞清楚我们的需求是什么。我认为主要有以下四点：

一是可提供大数据的基础能力;

二是在基础之上提高使用效率，所谓的使用是指用户在我们的大数据平台上开发数据业务，包括数据仓库、数据可视化、推荐业务等的使用效率，这是大数据平台的核心价值;

三是提升管理效率，运营一个大数据平台会涉及到各方面的管理，比如升级、扩容、技术支持的代价等，我们需要提升管理效率进而降低成本。

四是多租户安全，大数据平台服务于整个公司，公司内部多条业务线都会使用，多租户安全是必备功能。

在这些需求之下，网易大数据最终的整体架构如下：

整个平台主要有四大特点：

一是统一元数据服务，Hive、Spark、Impala、HBase等元数据打通，也就是平台上任意一张表既可用Hive查询，也可用Spark、Impala来查，不需要在不同系统之间做元数据的同步。

二是流计算服务，我们用SQL作为开发方式，完全与离线SQL兼容。

三是数据安全与权限，Spark、Hive、Impala、HDFS等组件的权限自动同步。从Spark、Hive、Impala进来的请求，权限都可以得到控制，无论是通过表接口来访问还是通过底层HDFS来访问，权限都不会有任何泄露。

此外，我们也做列级权限控制以及角色访问控制。在我们的平台中，我们会为网易的每个用户发放kerberos Key，我们采用kerberos认证，权限可控制到个人级别，每个人的所有操作都会有审计。此外，我们提供一站式开发IDE，我们的客户在IDE上进行数据开发，我们也提供一站式部署业务监控体系。

在技术方面，我们的思路是满足大致平台需求从大数据平台的需求出发，采取自研和开源相结合的方式，在底层基础组件方面以开源为主，在其上进行增强和改进。

在一些相关工具上，我们以自研来满足用户需求，我们做的事情主要包括Kafka服务化，我们把Kafka做成云服务的方式，在日志收集方面做了Data Stream系统，主要功能是把日志收集到大数据平台并转成Hive表。我们也做了数据库同步工具，完成数据库到数据库，数据库到大数据系统之间的同步。

在Spark方面，我们做了多租户和高可用。，引用我们引入开源项目Kudu解决数据实时性实施方面的问题。，并我们针对kudu在上面做了很多优化。，采用Ranger作为统一权限控制中心，但Ranger性能有限，处理不了大量表和用户场景，所以，我们不得不扩展Ranger，优化其性能使其可以支撑更多表和数据。

接下来，我会分几个技术点介绍大数据方面的工作。首先，我先介绍一下Kudu，这是我们解决数据实时性的工具，Kudu的定位介于HBase和HDFS中间。我们认为，虽然HBase具备随机访问和更新能力，但它的数据查询分析能力较差。HDFS的查询分析和scan扫描性能较好，但它的数据实时性较差且更新能力不强。

Kudu兼具了二者的优点，扫描查询性能较好且同时也有更新和随机访问的能力。如果将Kudu和HBase对比，它们同时是KV系统，最不同的地方有以下几个方面：

一是Kudu采用Raft多副本协议，而HBase通过HDFS来做复制，这样的好处是Kudu的可用性会好一些。此外，在数据分区方面分析上，HBase支持用Ranger分区，Kudu采用用Ranger、Hash组合分区。在使用HBase的过程中，我们经常会遇到数据热点问题，所以设计schema时，通常不得不在Hbase会在key里加入一些随机哈希值，而，这就是Kudu组合分区则能有效的优势，不用担心数据热点问题。

此外，在数据格式上，HBase在ColumnFamily内部采用属于行存格式。在HBase内，我们很难设置很多ColumnFamily，因为会影响性能，每个ColumnFamily都会带上主键组件，这会导致数据冗余和变大，而Kudu的数据通过RowGroup形式组织，完全是列存结构，所以扫描性能会比较好。

（编辑：湘西站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!