NewSQL：从NoSQL到NewSQL

前言

其实本来是预想本文发表在18年年末，作为18年最后一弹，也是对之前工作、学习一些见解的总结。但是由于仪式感不敌拖延症，所以文章变成了19年新年第一弹，可惜未能在元旦完成，自我执行力还是要检讨下。（纯文字，没有什么图，不好意思）
NoSQL源自2009年，当时在美国三藩市举办的一次Meetup提到的“Open Source, Distributed, Non Relational Database”为NoSQL提供了较为精炼的描述。
以HBase为首的NoSQL数据库，通过分布式实现大数据量存储和高吞吐，同时为了方便插入、查找，采用了非关系型数据模型（数据结构）表示数据组织形式，这样通过弱化对ACID和复杂关联查询的支持，获得更加简化的或者针对某一场景更加专业的模型，从而能够更高效地读写。这样的缺点在于容易出现大面积的冗余、维护麻烦，而不再支持SQL接口也让很多开发人员在入门时感到吃力，对于RDBMS中的代码平移到Hadoop也是十分麻烦。
Hadoop能够轻松解决千万级别以上数据量的批处理需求，同时数台几万块的小型机便可组装组网成集群，相较于RDBMS，对于企业来说既能解决数据库处理能力的瓶颈又能节省成本（相较于Oracle几百万、上千万的专用机器和软件服务），何乐而不为？

计算方式

由于硬件发展的瓶颈期，分布式计算需要在批处理和流处理中做出取舍，开发人员和架构师根据不同的应用场景，来确定技术选型、架构设计。
为何批处理和流处理要分开使用？大数据源起谷歌的三驾马车：Google FS，MapReduce,BigTable（分别解决存储管理、计算能力、数据模型（数据结构）的问题）。起初的关注点在于如何在海量数据中快速、准确搜索、读取文件，突出的是批处理能力。理论上来说，能够处理上亿行数据的大数据框架应该能轻松应对瞬时只有一条记录占用CPU的实时处理需求。
但事实并不与愿同。按批处理经验设计的处理逻辑，使得Hadoop这第一代大数据处理框架在处理实时数据流总是会做出过多无谓的展开、预处理，实质上，实时流处理只需做增量计算即可。
从极限的思想来说，流处理应该是批处理的时间消耗分解为无穷小，但非数据处理占用的CPU时间因此反而超过了单一一条记录处理的时间，预处理中对数据重新排列和分割对于瞬时只用单条数据的实时流处理来说变得多余。一个常量级的时间复杂度加上一个无穷小的时间复杂度，无论数据分解做得多么好、数据块分割得多么科学、程序执行的频率极可能地提高：从一天一次到一个小时一次，再到半小时、十五分钟、五分钟。。。。。都不能改变其处理效率低下的问题，这也是我一直以来认为用hive来模拟Storm、Spark实时流的工作是很无谓的，尽管在用户使用感知上区别不大。因为这相当于一道数学题常量级加无穷小，数据分割得再好，都只是在提高无穷小的阶而已，真正决定结果大小的常量级永远不变，因为这个常数是框架决定的。
所以需要另起炉灶开发一套新的实时流处理框架：Storm、Spark等。这里需要说下以Spark为代表的以内存式计算为技术特点的第三代大数据引擎。得益于内存技术的发展和工业化大规模生产，终于来到了内存式计算时代，冯诺依曼结构计算机体系中的痼疾——高I/O带来的带宽瓶颈和高时延以及CPU有效时间占比较小的问题得到有效改善。这样的特性使得批处理和流处理得到兼容：将所有需要计算的数据尽可能地加载到内存，减少磁盘读写次数。免去了工程师针对两种应用场景做过多的兼容测试与ETL，前者是会导致环境错误影响计算，后者则会因时序变化而导致数据不一致。
天下分久必合。工具再多，不如一步到位吸引。

存储

说到ETL，笔者认为这是个推动NoSQL到NewSQL的痛点，但也可能是个意外，谁也没想到“毫无技术含量”的ETL会如此麻烦，主要是因为NoSQL不再关注数据一致性的维护，然后越来越多人或团队寄希望于在ETL过程中完成一致性的检测和纠错，且确保实时传送，结果导致ETL过程越来越臃肿、链条越来越曲折、时延越来越大（或者说总是要在实时性和一致性之间做出取舍）。未来总体趋势，个人认为是要“干掉”纯同步的ETL，让批处理、实时流处理与分布式共享存储结合来替代之，以当下的技术水平来看，即将计算引擎当作通道，或者说是让通道或者接口更加智能、具有计算和缓存能力。
从数据的角度来看，所有的处理程序、工具都是上述的通道，即便是传统的RDBMS也是如此。数据在流通中产生价值或反映客观业务，通道将价值呈现给人。
但在NewSQL出现之前，由于计算力的差异，批处理与实时流处理分开执行，使得存在不同的数据存储形式（位置），使得ETL无处不在。我认为，ETL的问题真正在于，各种“通道”的介入数据流传的过程中，必然导致ETL环节的不断增加，形成了一个有向有环图，容易产生冲突。
技术选型的不同，额外产生数据结构适配、转换的问题；异地存储存在元数据管理的问题。工程师们需要让通道更智能，于是出现了能够保留多个时序版本、能缓存中间数据、能够快速处理、能约定数据格式的通道，比如KaFKa、RocketMQ、ActiveMQ等。
还有一种在架构上更为简洁的方式，那就是无论是Spark、Hive、Flink，只要能够兼容识别HDFS，就让这些框架、引擎共享同一个分布式文件系统（存储共享、存储管理共享）。这也符合现金存储架构发展，如同SDS（软件定义存储）一般，把不同结构、异地的存储视作分布式存储的不同节点，通过软件（存储管理系统）实现节点间通信、外部访问，外部用户使用时，和一个大容量、支持多种格式存储服务器没有两样。云技术的发展，使得不同渠道的数据能够集合成更大体量的集合，剩下的是解决好数据主权的问题。
人是群体动物，小到小组团体、大到国家，越来越多的人在一个抽象的概念下集合到一起才能发挥更大的作用、处理更大体量的问题。软件、存储亦如是，抽象化是趋势，所谓分久必合。

模型（数据结构）

大部分NoSQL在设计之初，由于遵循“non-relational”原则，数据校验、处理代码更多的嵌入到应用程序中，且未提供更通用的SQL接口支持。
Hive提供了SQL接口支持，使得用户能够通过使用SQL语言访问HDFS数据，前提是HDFS数据文件在Hive中被映射成表。这一设计使之与RDBMS数据仓库的操作区别不大，使Hive更具迁移性。但与RDBMS的SQL编译方式不同，SQL语言在hive中最终会被翻译成MapReduce程序和执行计划进行。因此Hive继承了Hadoop在批处理方面的优点，但在少量数据的计算、流计算中效率低下。
早期KaFKa未提供SQL接口支持，其待消费队列中的数据好像黑盒子一样，不能查阅。但出现故障时，只能对队列中数据做全备份后再做处理，但是处理好之后，不好做数据核对以确认是否有数据遗漏。目前Kafka版本已经加入了SQL接口的支持。
由于SQL的通用性，越来越多NoSQL开始支持SQL查询/插入。但能够使用SQL的NoSQL不一定等同于NewSQL。原因在于这些NoSQL在数据模型上依旧是非关系型的，依然存在越来越复杂的元数据管理问题。
数据模型的抽象要使之能对不同数据尽可能地包容，对外展示时能够让用户通过相同的方式访问之。

NewSQL

NewSQL应是RDBMS中的数据模型（关系型、符合ACID）和NoSQL中的计算框架、分布式存储、开源特定的结合产物。目前关于NewSQL是否从属于NoSQL仍有争议，但SQL化或者准确来说是relational化是趋势。NewSQL中的典型代表有Google Spanner和国内的TiDB。
至此大致可以梳理出，大数据处理技术，从一开始追求硬件的综合和运算（排列组合）速度的极限，经过计算框架的一代又一代发展、存储技术的发展，到最终SQL（关系型）模型的回归。早期大数据BigTable模型还是显得比较简陋，NewSQL中重新引入关系型模型使得数据更加容易处理，这当然也是由于数据压缩技术的发展所推动，体现的是技术自底向上不断抽象的结果。此时，不管NoSQL还是NewSQL，如果还在沿用“non-relational”的定义可能已经不大使用，也有观点认为应该是“Not-Only-SQL”，虽然有自圆其说的嫌疑，但总结很到位。
可以说NewSQL是在大数据KV存储的基础上，实现了关系型数据模型，并将元数据和其他表数据放到了一起管理，免去了割裂开来管理的麻烦。因为做了ACID限制，故在大规模数据处理的速度上还是有所放缓，但仍比RDBMS性能好。
大多NewSQL数据库都对其内部的机制、部件做了解耦，上述提到的将业务数据和元数据的管理机构统一为一个便是其中之一例子。
实时流和批处理的统一，促进了数据库对OLTP和OLAP两种需求的同时满足、尽可能地覆盖此二者的应用场景。
End

原文可以关注公众号：