2024网易数据基础平台建设方案

此产品，InnoSQLMySQL2011InnoSQL目标是提供更好的性能以及高可用性，同时便于DBA的运维以及监控管理。RocksDBMySQLMyRocks成到InnoSQL分支上。这样做的原因是公司有很多业务，很多都是利用缓存保持其延迟，保持延迟稳定（小于50毫秒）。RocksDB能够很好地将缓存控制的很好，随着缓存越来HBaseHBase但还是做了一个基于K-V模式的缓存处理，主要解决延迟波动问题。我们主要是基于开源RocksDBInnoRocksLSMLSM用InnoRocks存储会节省很多存储空间；还有一个就是结合DB做扩展，将其集成到公司RFIDRocksDBInnoDBRocksDBInnoDBInnoDBRocksDB。Inno315GB左右，InnoRocks为50~60GB，存储容量是InnoDB2030%。InnoRockInnoDBInnoDB需要高压缩以便存储更多的数据，InnoDBInno对写入延迟波动比较敏感，HBaseInno相对较低的延迟要求(10~50ms)下替换缓存场景(延迟<5ms)，节省内存成本，Redis-->InnoRocks。InnoSQL是MySQL一个分支，同时还做了一个时序数据库。其不依赖第三方存储，重新数据库集中在访问时通过什么去访问，我们提供SQL层给外部应用去访问，应用简单。NTSDBbug分来源于日志。通过NDC做全量数据导入，如有些数据在Oracle中，通过NDC导入，后续可以通过数据变更来进行同步，还有一个通过dataStream将日志数据录入大数据平HDFS存储，搭载一些HBaseSpark；数据加工和一般大数据平台都差不多，我们加入了自助分析、任务运维，后续会详细介绍。接下来介绍自助分析里面应用的一个插件Impala，以及分布式存储系统中的Kudu平台。秒-1分钟延迟。Impala的MPP架构都是类似。选择Impala而不选择其他工具的原因：首先它有元数据缓存，好处是节点缓存元数据做查询时不用再去获取元数据，缺点就是元数据爆炸问题；再者就是Impala兼容Hive，元数HiveImpalaImpalainsertHive和SparkImpalaImpala能读取数据但是无法动态感知，为了解决这个问题官方提供手动刷新操作。ImpalaMPPMaster底层数据权限粒度控制不够，HDFS转HBase是以同级HBase身份访问，Impala访问底层需要以Impala身份访问。这种问题尤其在同一平台下分有很多业务时，用Hive写数据时，访问权限就会有问题，因此我们在内部权限访问方面做了改造。每个coordinator节点都能接收SQL，没有集中统一的SQL管理，如果挂掉所有历史信息都无法追踪。ZookeeperLoadBalanceSQLSQL和执行过程，便于后续SQL审计，超时SQL自动kill；Hive，Hive变更，Impala拉取变更自动同步，这种只能缓解元数据爆炸问题。线写入和Impala查询是同一份数据，如果写入吃掉很多IO，查询就会出现问题。离线本ES在SQL支持方面不是很好，目前我们的Impala支持一些ES的查询。HiveKudu就是解决半小时到一小时的数据实时性。KuduImpala既能访问Hive中的数据，也能访问Kudu中的数据，这样的好处是两边的数据可以进行联合查询。KuduSparkAPIKudu不同的是数据组织形式是不一样的，Kudu可以做一些分析性的业务查询。最主要的区别是数据存储格式不一样，Kudu是ColumnFamily级别列存，先整个切一块然后再做列组形KuduHDFSKuduupdate，在内存&磁盘上数BasedeltaBasedelta据读取时需要同时读取Base+delta两部分数据。KudutabletKuduRuntimeFilterImpalaHDFSRuntimeFilter，KuduhashKuduRuntimeFilter进，目标是和Impala相差不是很大。Bitmapgroupby，hash序，这种查询会很快，而不用做全局排序。Bitmapdinstctcount的值不能太多，向数据库中主键不适合做Bitmap，像省份等值比较少的适合做Bitmap。应用后用TPC-H中的一张表测试，Bitmap主要应用多维场景过滤，从