首先简单介绍一下网易杭州研究院情况简介，如下图所示：

我们公司主要从事平台技术开发和建设方面，工作的重点方向主要在解决用户在数据治理中的各种问题，让用户能更高效地管理自己的数据，进而产生更大的价值，比如如何整合现有功能流程，节省用户使用成本；增加新平台不断调研，丰富平台功能；新平台功能、性能改造，从而满足用户大规模使用需求；根据业务实际需求，输出相应解决方案等。今天分享的内容主要是从数据库内核到大数据平台底层技术开发，分享网易数据科学中心多年大数据建设经验。

1. 数据库技术

数据技术主要有InnoSQL和NTSDB，NTSDB是最近研发的新产品，预计明年将向外推荐此产品，InnoSQL属于MySQL分支方面的研究大概从2011年开始的，InnoSQL的主要目标是提供更好的性能以及高可用性，同时便于DBA的运维以及监控管理。

RocksDB是以树的形式组织数据的产品，MySQL有一个MyRocks产品，我们内部将其集成到InnoSQL分支上。这样做的原因是公司有很多业务，很多都是利用缓存保持其延迟，其规模会越来越大，这样就导致缓存、内存成本很高；其业务对延迟要求不是特别高，但要保持延迟稳定（小于50毫秒）。RocksDB能够很好地将缓存控制的很好，随着缓存越来越大，有的公司会将其放到HBase上，但是其延迟有时波动会很大，如小米HBase很强，但还是做了一个基于K-V模式的缓存处理，主要解决延迟波动问题。我们主要是基于开源产品来解决，如将RocksDB集成起来解决公司业务对延迟稳定的一些需求。InnoRocks由于是基于LSM，因此对写入支持非常好，后续有内部测试数据可以展示。还有就是LSM压缩比很高，网易一种是替换缓存，一种是普通数据库存储，目前还是用InnoDB存储，如果用InnoRocks存储会节省很多存储空间；还有一个就是结合DB做扩展，将其集成到公司内部。

上图是写入对比，是一个普通的写入测试，其主介质是递增型的，对于两个都是一个顺序读写过程；如果要完全对比还要测试RFID写入测试，这样能够明显反应RocksDB和InnoDB的差距。图中RocksDB写入性能比InnoDB要好，读取性能InnoDB性能比RocksDB。300GB原始数据，分别导入到Inno DB(未压缩)和Inno Rocks后的存储容量对比，Inno DB为315GB左右，Inno Rocks为50 ~ 60GB，存储容量是Inno DB的20%到30%。

InnoRock一般场景是替换InnoDB写入，因为其写入性能、压缩性能更好、成本也更低。另一方面能够解决InnoDB延迟不稳定，替换大量的缓存应用，只要其对相应时间没有特殊要求。

（1）大量数据写入场景，比如日志、订单等；

（2）需要高压缩以便存储更多的数据，Inno DB --> Inno Rocks；

（3）对写入延迟波动比较敏感，HBase --> Inno Rocks；

（4）相对较低的延迟要求(10 ~ 50ms)下替换缓存场景(延迟<5ms)，节省内存成本， Redis --> Inno Rocks。

InnoSQL是MySQL一个分支，同时还做了一个时序数据库。其不依赖第三方存储，重新做了一套。其架构也是列式存储，支持倒排索引等不同索引组织形式。对大型数据公司时序数据库集中在访问时通过什么去访问，我们提供SQL层给外部应用去访问，应用简单。

NTSDB特点有聚合运算相关算法，时序数据库相对于关系型数据库没有特别复杂的查询，最常见的使用类型是宽表使用，在此基础上做一些聚合算法、插值查询。

NTSDB应用场景很多，很多应用都可以基于时序数据库来做，最常见的就是监控系统，有一些外部应用也会对接监控系统。外部应用中，现在RIT比较火，时序是其中比较重要的一环，很多设备目前都需要联网，数据的产生都是以时间的形式产生，有的通过规则引擎处理存储在时序数据库中。

2. 大数据技术

我们大数据平台整合了一些开源社区的一些组件，内部进行一些产品化的改造和bug修复。最顶层是大数据接入层，作为大数据平台，业务平台很多数据来源于数据库，也有很大一部分来源于日志。通过NDC做全量数据导入，如有些数据在Oracle中，通过NDC导入，后续可以通过数据变更来进行同步，还有一个通过dataStream将日志数据录入大数据平台。数据存储层大都差不多，都用HDFS 存储，搭载一些HBase分布式存储；数据计算大都是离线计算平台，内存计算是基于Spark；数据加工和一般大数据平台都差不多，我们加入了自助分析、任务运维，后续会详细介绍。接下来介绍自助分析里面应用的一个插件Impala，以及分布式存储系统中的Kudu平台。

应用Impala目标是解决大数据量下的ad-hoc查询问题，ad-hoc是介于OITP和OIAP中间的一层，OITP是响应层很快，毫秒级；OIAP查询有时会耗时很久。ad-hoc定位与1分钟到几分钟，现在很多业务需要ad-hoc提供，如公司报表，有时需要实时计算，响应在5秒-1分钟延迟。

Impala架构特点就是每一个节点都是无状态节点，节点查询地位一样，查询无论发送到哪一个节点都可以生成查询计划、产生结果。查询打到哪一个节点就能生成执行计划，将对应的节点分配给对应的处理节点，将所有节点返回后做一个规则，然后做一个返回。基本所有的MPP架构都是类似。

选择Impala而不选择其他工具的原因：首先它有元数据缓存，好处是节点缓存元数据做查询时不用再去获取元数据，缺点就是元数据爆炸问题；再者就是Impala兼容Hive，元数据可以和Hive共享；同时还支持很多算子下推。Impala最好使用方式是通过Impala自己insert然后通过其自己去查，实际过程是通过Hive和Spark写入大数据平台，通过Impala来做查询。这种方式有些限制就是写入时Impala无法感知写入，还有在Hive更改元数据，Impala能读取数据但是无法动态感知，为了解决这个问题官方提供手动刷新操作。

Impala缺陷就是所有节点都是MPP结构，没有统一的Master入口，负载均衡不易控制。底层数据权限粒度控制不够，HDFS转HBase是以同级HBase身份访问，Impala访问底层需要以Impala身份访问。这种问题尤其在同一平台下分有很多业务时，用Hive写数据时，访问权限就会有问题，因此我们在内部权限访问方面做了改造。每个coordinator节点都能接收SQL，没有集中统一的SQL管理，如果挂掉所有历史信息都无法追踪。

我们基于Impala问题做了相应整改：

（1）首先是基于Zookeeper的Load Balance机制；

（2）管理服务解决SQL无法持续化问题，管理服务器保存最近几天的SQL和执行过程，便于后续SQL审计，超时SQL自动kill；

（3）管理权限将底层权限分的很细；

（4）元数据缓存问题，增加与Hive的元数据同步功能，Hive记录元数据变更，Impala拉取变更自动同步，这种只能缓解元数据爆炸问题。

遗留的问题就是元数据容量，过滤智能解决部分问题；还有一个就是底层IO问题，因为离线写入和Impala查询是同一份数据，如果写入吃掉很多IO，查询就会出现问题。离线本身对IO敏感很低。除此之外我们还引入了ES技术，公司ES业务也有很多，碰到问题就是ES在SQL支持方面不是很好，目前我们的Impala支持一些ES的查询。

Kudu用于解决离线数据实时性问题，HDFS存K-v数据，类似IOAP访问，Hive是来做离线分析的，Kudu就是想同时做这两件事情的背景下产生的。行为数据是在离线平台上，用户数据是实时在数据库中，如快递行业经常需要追踪快递的位置，离线平台就要经常做自助分析，需要将数据库中的状态实时同步到离线平台上去。目前做法就是数据库批量写入Hive表中，同时你的批量不能太小，容易产生很多小文件，这样可能造成数据实时性很差，一般是半小时到一小时的延迟。大部分业务可接受，但是对于对延迟敏感的业务可能不支持，Kudu就是解决半小时到一小时的数据实时性。

Kudu是一个存储平台，不依赖于任何第三方存储系统，目前更类似于数据库形式，Impala既能访问Hive中的数据，也能访问Kudu中的数据，这样的好处是两边的数据可以进行联合查询。Kudu现在也支持Spark，也可以直接通过API访问。上图是Kudu的结构划分到内部数据组织形式，Kudu支持Tablelet操作而HDFS不支持。前面的结构和HBase挺像，不同的是数据组织形式是不一样的，Kudu可以做一些分析性的业务查询。最主要的区别是数据存储格式不一样，Kudu是Column Family级别列存，先整个切一块然后再做列组形式。

Kudu跟HDFS相比性能还是有差距，Kudu由于需要支持update，在内存 & 磁盘上数据的存储采用Base + delta形式，Base记录基本的数据，delta记录修改的数据，所以数据读取时需要同时读取Base + delta两部分数据。

Kudu优化主要是：

（1）支持Kudu tablet的split；

（2）支持指定列的TTL功能；

（3）支持Kudu数据Runtime Filter功能；

（4）支持Kudu创建Bitmap索引。

我们主要是按照HBase进行优化，在有需要情况下优化，HBase有而Kudu没有就对照的做。

Impala里面对HDFS有一个Runtime Filter功能，Kudu表上没有，我们先分析下它到底有什么作用，是不是有性能上的改进，将其移植过来。Runtime Filter主要是用在大表和小表做关联时使用，在关联时做成hash表，绑定到所有大表节点上去，在大表扫数据时利用hash表做过滤，因此在底层扫描就已经过滤掉很多数据，就可以省略很多不必要的计算。上图是Kudu的是否有Runtime Filter的结果对比，可以看出减少了很多计算量，原先需要几秒，现在只需秒级显示结果。结果对比有了很大的改进，虽然还是有差距，目前也在改进，目标是和Impala相差不是很大。

还有一个场景就是在Kudu上做Bitmap索引，主要面向的业务是宽表的多维过滤，有些表的查询会依据后面的实例去确定查询，这种用Bitmap做比一个个找出来查询性能要优越很多。另一个好处就是group by，因为其要将相同类型合并到一列，主要是做hash或者排序，这种查询会很快，而不用做全局排序。Bitmap应用的限制就是数据离散性不能太好，dinstct count的值不能太多，向数据库中主键不适合做Bitmap，像省份等值比较少的适合做Bitmap。

应用后用TPC-H中的一张表测试，Bitmap主要应用多维场景过滤，从一列过滤、两列过滤、到五维过滤整个表现很好，性能提升有十几倍提升。如果数据从数据库导入大数据平台离线分析其实时性比较慢，主要局限小文件以及导入批量大小问题,利用Kudu就不用考虑，可以直接通过Kudu实现数据变更导入大数据支持实时联查。而且可以实时同步Oracle和MySQL数据到Kudu中，进行联查就可以了，如果没有就需要同步查询可能需要半小时才能返回结果。

作者介绍：

蒋鸿翔，2011年加入网易，网易数据科学中心首席架构师。《MySQL内核：InnoDB存储引擎卷1》作者之一，网易数据库内核和数据仓库平台负责人，长期从事数据库内核技术和大数据平台底层技术开发，主导网易数据库内核整体技术方案和大数据平台先进技术调研和实现，先后主导了内部MySQL分支InnoSQL、HBase、自研时序数据库、自研实时数据仓库等各种不同的平台，具有丰富的数据库内核和大数据平台相关经验。

本文来自蒋鸿翔在 DataFun 社区的演讲，由 DataFun 编辑整理。

创作场景

网易数据基础平台建设经验谈