网易数据基础平台建设

1 .网易数据基础平台建设 网易杭州研究院 蒋鸿翔 Designed by GOMI 

2 . 部门介绍 杭州研究院 — 数据科学中心 p 服务网易公司集团内部基础平台建设 定位 p 对外尝试输出成熟的商业化方案，赋能外部企业客户 p 浙江省网易大数据重点企业研究院 p 内部服务于电商、游戏、传媒、教育、金融等各个部门，平台数据 > 100PB 规模 p 对外向包括：传媒、金融、快递、农业等不同行业输出数据解决方案，帮助企业信息化转型 p 数据库产品：RDS、DDB、NTSDB p 大数据产品：网易猛犸、网易有数、网易哈勃 产品 

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

4 .我们不生产数据，我们只是数据平台的提供商 

5 .解决业务/用户在数据治理中的各种问题，让业务/用户能更高效地管理 自己的数据，进而产生更大的价值 Ø 现有功能流程整合，节省用户使用成本 Ø 新功能/平台不断调研，丰富平台功能 Ø 新平台功能、性能改造，从而满足用户大规模使用需求 Ø 根据业务实际需求，输出相应解决方案 http://note.youdao.com/noteshare?id=20de2248c5d6019a2f85093349ce3bd3 

6 .大纲 01 数据库技术 02 大数据技术 

7 .PART 01: 数 据 库 技 术 

8 . 数据库技术 InnoSQL NTSDB 

9 . InnoRocks：特点 应用特点 Ø 大数据量写入，底层LevelDB，基于LSM结构 Ø 高数据压缩，节省实例存储空间 Ø 结合DDB可以进行分布式扩展 

10 . InnoRocks：性能对比 写入对比 读取对比 

11 .InnoRocks：存储对比 300GB原始数据，分别导入到InnoDB(未 压缩)和InnoRocks后的存储容量对比， InnoDB为315GB左右，InnoRocks为50 ~ 60GB，存储容量是InnoDB的1/6 ~ 1/5 

12 . InnoRocks：场景 InnoRocks有较高的数据压缩比，数据写入能维持在一个比较低的延时， 不会随着外部压力的增加出现频繁波动，比较适合用于以下场景： Ø 大量数据写入场景，比如日志、订单等 Ø 需要高压缩以便存储更多的数据，InnoDB --> InnoRocks Ø 对写入延迟波动比较敏感，HBase --> InnoRocks Ø 相对较低的延迟要求(10 ~ 50ms)下替换缓存场景(延迟<5ms)，节省内存成本， Redis --> InnoRocks 

13 .NTSDB：架构 

14 .NTSDB：特点 

15 . NTSDB：场景 内部平台监控系统 

16 . NTSDB：场景 工业互联网方案 

17 . 技术交流 数据库知乎专栏 HBase & 时序博客 

18 .PART 02: 大 数 据 技 术 

19 . 大数据平台 大数据应用开发层 大数据开发套件(可视化IDE) 作业流开发 Azkaban 数据加工 数据集成 数据开发 任务运维 自助分析 数据管理 权限管理 Ranger 离线计算 流式计算 内存计算 数据计算 Hive Sloth Spark 多租户管理 统一资源管理与调度 资源管理 Yarn 元数据管理 分布式文件系统 分布式数据库 数据质量校验 数据存储 HDFS和Kudu HBase DQC 全量/非实时接入 实时/增量接入 秘钥管理 数据集成 Sqoop NDC和DataStream Kerberos 运维监控 结构化数据 半结构化数据 非结构化数据 数据源 如RDBMS备库 如JSON 如音频文件 Ambari 

20 . Impala Impala解决内部大数据量下的ad-hoc查询问题 

21 . Impala：架构 执行节点 状态同步服务 元数据服务 

22 .Impala：执行方式 

23 . Impala：高性能 Codegen 支持HDFS 算子下推 元数据缓存 MPP并行计算 技术，支持 本地读 (>,<,In List, LLVM，JIT (shortcircuit) runtime filter) 

24 . Impala：一般使用方式 适用场景 Ø 适用于做ad-hoc查询，尽量少做ETL工作 Ø 适用于不会经常进行元数据变更的场景 Ø 底层I/O资源充足更能体现性能 

25 . Impala：缺陷 Ø MPP结构，没有统一Master入口，负载均衡存在一定问题 Ø 在Hive或者Spark中进行数据变更，与Hive的元数据同步需要手动操作(refresh，invalidate) Ø 底层数据权限粒度控制不够 Ø 元数据缓存机制，在元数据量较大时，会对整个元数据服务造成影响 Ø 每个coordinator节点都能接收SQL，没有集中统一的SQL管理 

26 . Impala：改进 Ø 基于Zookeeper的Load Balance机制 Ø 管理服务器保存最近几天的SQL和执行过程，便于后续SQL审计，超时SQL自动kill Ø 底层权限代理功能，解决业务直接拷贝数据到HDFS上的权限问题 Ø 增加与Hive的元数据同步功能，Hive记录元数据变更，Impala拉取变更自动同步 Ø 元数据过滤功能：支持库级别正则过滤和表级别自定义过滤 Ø 集成ElasticSearch作为存储引擎，使用Impala进行SQL查询ES数据 遗留问题： Ø 元数据容量问题，过滤只能解决部分问题，需要解决元数据过大产生的各种问题 Ø 共享存储下I/O资源问题，Impala + Alluxio来缓解I/O，提升查询性能 

27 . Kudu Kudu用于解决离线数据实时性问题 

28 .Kudu：架构 

29 .Kudu：架构