施乐开启了PC，被苹果摘了苹果。苹果开启了窗口，被微软抢了风头。 雅虎开启了搜索，被谷歌吃了大头， 谷歌开启了云计算，被亚马逊拿了头牌。 云计算的世界离不开谷歌的神，Jeff Dean。开源云计算的世界，离不开另一个神Doug Cutting。
听着神话，看着神作，想着神码，才能明白神的力量，享受神的眷恋！Jeff Dean和Google另外一个最高的级别11级的Sanjay Ghemawat早年一起搞了GFS, MapReduce, BigTable等等。 而Doug Cutting是Lucene, Nutch, Hadoop的发明人。 自从有了Hadoop （刚开始用的时候就叫Nutch File System，后来改名叫Hadoop了）, 开源大数据工具20年间大概有好几百种了， 能够大致了解一下核心的十几个，然后能搭起架子来就很不错了。 想着这些开启万亿生态的神还在帮老板打工，突然觉得知识还是不够值钱。
从数据说起
最近10年，当人们谈数据的时候， 数据的性质其实已经发生了巨大的变化， 就是传统的，整理好的表数据已经不再是主流。 而各种多媒体，传感器，或者时髦点的说法5G才能更适合搞定的数据才是主流了。可见数据变得复杂了。
但是另外一方面， 处理数据的架构， 人们正在抛弃Lambda架构，并且已经嫌弃Kappa架构。为什么呢？
1. Lambda架构中，批处理部分和流处理部分集成，让服务的流程变得异常复杂，稳定性较差， 维护变得困难。
2. Kappa架构， 抛弃了批处理部分， 让一切成为数据流， 结构简单，服务稳定。
但是，即便如此， Kappa架构在交互数据处理面前依然不够灵活。 打个比方， 你去吃自助：
Lambda架构：很多菜品，你可以拿到就吃（Real-time）。然而，部分菜品你需要定制一下， 然后等待后，再去取(Streaming)。 后来一发现，在定制等待的过程中，你看到别的好吃的，就先吃了。 情况变得复杂起来。
Kappa架构：如果餐馆规定，不能定制， 你只能吃准备好的菜，并且保证所有菜都到了就能拿。 你的决策就很简单，看到就拿，拿了就吃。
交互架构：Kappa架构下有个问题，你想把部分菜品的配料根据我之前已经吃的东西换一下。发现没法做到。 你其实需要有个厨师在面前， 谈话间，就把你想吃的东西配好，给你了。
如果把上门两个方面结合起来看，矛盾就大了。
一方面，数据变得异常复杂， 这是由人们产生数据的实际情况决定的。
另外一方面，数据处理架构变得尽量简单、实时、交互，这是来自服务质量提高的要求。
在这对矛盾下，就需要对资源的配置变得异常的灵活。
其实类似的逻辑在数据仓库(data warehouse)， 数据湖 (data lake), 数据虚拟化 (data virtualization) 上面上演。
早些年， 你看到的很多围绕数据仓库的服务，需要繁重的批处理流程：
近些年，巨大部分都变成了数据湖架构， 抛弃了批处理流程，引入了事件机制进行数据流处理。
而数据虚拟化，则进一步把数据按客户动态需求进行交互式的组织。
讲逻辑很简单，但是做起来很难很难，
资源调度
随着虚拟化技术，资源渐渐都是按容器进行编排了。 主流的Container Orchestration (OC) 工具包括Kubernetes， Mesos， Docker Compose， Docker Swarm， Rancher。 首先从市场份额来看，你已经知道应该选Kubernetes。
其实这场大战的核心是三家：Kubernetes (K8s, 8指代中间的八个字母ubernete；Kubernetes 本意是希腊语的舵手)， Mesos 和 Swarm。 因为Compose不够实战，对大规模集群不够友好。而Rancher自身并不提供底层OC能力，依然依赖核心3家。 另外Aurora， Marathon， DC/OS基本算是Mesos系列的。 同时也说明Mesos很强大的资源共享机制， 其实Mesos之上也可以跑K8s，所以有人也认为Mesos和K8s是共生关系。
相比Mesos， K8s在全局服务端口，虚拟IP网络方面有很强的优势。
其实从下图你可以看到， K8s在9大方面（app管理，容器安全，集群安全，QoS配置， 资源配额， 应用配置， 容器网络， 可定制化， 机器配置）都是可配置性最强的。
另外，在应用升级方面， K8S也会能力最强的。
容器CPU和内存分配方面也是最强的。
容器安全隔离方面也是最佳的。
1.K8s
Kubernetes的核心是Pod。 顾名思义，Pod是对一组Container的管理模式。 好比豆荚一样。
再来看寻址过程， 每个Pod有一个唯一的虚拟IP地址，换句话说，K8s用Pod来替换了物理的Node，成为虚拟的地址节点。 使得不同机器的资源可以很好的切分和隔离。
Pod作为基本的K8s的单元，K8s还有Namespace的概念， 一个直观的例子，如下：
基于Namespace，很容易实现相同命名的Object在不同Namespace下的部署。
其实K8s的Object都至少有4种属性：name，kind, spec，status, 前三个由用户在YAML配置中指定，status由系统管理。 例如，下面是一个Pod的YAML配置描述。
常见的Object大体分为两大类， Namespaced Object 和 Non-Namespaced Object
K8s上层控制大概可以分为4种类型： 控制器；服务； 存储；配置。大致就是，任务类型； 对外任务功能；任务数据；任务参数。
控制器：
无状态，有状态，后台控制器：Deployments（ReplicaSets）, StatefulSets, DaemonSets,
批处理和定期批处理：Jobs, and CronJobs
对外服务：Service
存储：
简单存储：Volumes
跨节点复杂存储：PersistentVolumes, PersistentVolume Claims
配置：ConfigMaps
除了这些基本概念， K8s也有非常多的工具集，有几个最好熟悉一下：
命令行：Kubectl，
集群部署：kubeadm, miniube(本地测试), kubespray (上云)
部署：Helm,
监控：dashboard, prometheus, cAdvisor, Kube-state-metrics
高可用：Istio， Linkerd
测试：kube-monkey
迁移工具：Kompose
即使有这些工具， K8s要想玩的好， 还是要在高可用性，和访问控制安全等方面下功夫。
高可用性
负载均衡、Service Mesh
异地多活
安全和访问控制
Role-Based Access Control(RBAC)
Attribute-Based Access Control (ABAC)
一句话， K8s玩的好， 不愁没饭吃！
Mesos
Mesos 本身是一个集群管理系统, 可以管理上万台机器。就单纯的把节点资源管理好， Mesos已经是非常成功的。
所以Mesos很多高级的技巧是如何结合各种应用完成集成部署， 例如Spark, Marathon等等。
Mesos是如此的成功，以至于很多软件都统一使用Mesos来进行管理节点资源，即便之前可能自己有资源管理的解决方案。
如果不是拥有Pod管理和强大的资源围绕Pod进行分配管理的K8s出现， Mesos可能就无敌的有点寂寞了。 如今Mesos也开始支持Pod，但是更成功的还是要看Mesos+Marathon，或者DC/OS (Datacenter Operating System)。
Marathon的管理界面：
DC/OS 是基于Mesos之上的强大的开源集成。
可以说DC/OS是集大成已有的开源世界，对标Google的K8s的杰作。 在这个框架下， Mesos仅仅对标了Kubelet。
由于K8s的学习曲线比较陡峭， 如果是Mesos从业者，可以先从DC/OS开始对标K8s的所有能力，然后掌握K8s。
说起管理资源来说， 最近5年发展最快的算是以GPU为代表的计算类型硬件了，包括
CPU ( Central Processing Unit),
GPU (Graphics Processing Unit),
TPU(Tensor Processing Unit),
DPU(Data Processing Unit),
NPU(Neural Network Processing Unit),
BPU(Brain Processing Unit)
等等。
算力硬件加速器
虽然各自XPU发展都很快，但是目前应用最广，尤其在大数据上最突出的还是GPU, TPU和DPU。
互联网造芯有3家代表：
Google的TPU（Tensor Processing Unit）
微软的DPU (DNN Processing Unit)
Baidu的XPU
简单来说， 数据中心的芯片算力和能量开销都比较大。DPU/TPU > FPGA > GPU > BPU。
目前Nvidia的BlueField-2x的DPU, 能达到60TOPS = 60, 000GOPS; 一个片子就可以取代125个CPU。
为什么会这样呢？其实跟计算单元的组织方式有关。CPU为了通用性就是只能实现标量计算， GPU可以实现向量计算， 而DPU/TPU往往可以实现Tensor的计算方式。
K8s运行各自硬件尝试提供产品的插件来进算力的调度。 现在就通用的GPU来说， AMD， Intel， NVIDIA都提供了K8s的插件。
在插件支持的前提下， K8s只需要在Pod的资源描述里面，描述需要的硬件加速器即可。
即便如此， 但是如果想要更为高效的使用好DPU, 如前面提到的Nvidia的BlureField， 那么就需要使用Remote Direct Memory Access (RDMA)技术，实现绕过操作系统Kernel的干预和无需内存拷贝的远程数据读写，从而实现高吞吐量。
RDMA目前主要有三种技术，
RoCE：RDMA over Converged Ethernet
RoCE v1
RoCE v2: v2 可以支持UDP方式的实现
InfiniBand
最新的技术， 性能最好，但是需要网卡支持，价格贵
iWARP
可以支持TCP方式，毕竟TCP比UDP可靠性好点。但是实现就变得复杂， 使用范围，和维护都比RoCE费力。
所以追求性价比，就用RoCE，追求性能就用InfiniBand。
RDMA相关的技术本身在Spark/Hadoop平台早就被广泛的考察了，但是到了K8s平台。 如果把RDMA的性能、安全隔离、控制访问监管做好。
所以我们再看一下这逻辑：
要做到DPU的高吞吐性能，就要绕过内核CPU进行通信
因而要虚拟化算力，DPU，必须实现好的网络的虚拟化
网络的虚拟化就离不开PCI插槽的虚拟化
单根 I/O 虚拟化 Single-Root IO Virtualization(SR-IOV)就是做这个事情的， 它把PCI的物理功能PF（Physical Function）, 可以虚拟化成虚拟功能VF （Virtual Function），然后穿透内存管理单元(memory management unit (MMU))，实现PCI设备的虚拟化，高效利用好主机通道适配器Host Channel Adapters (HCAs) ，也就是前面提到的支持InfiniBand, RoCE ，iWARP的设备。
当然SR-IOV并非唯一的这种虚拟化，还有例如virtual machine queue (VMQ), vRDMA等其他方式。
可以看到，如何将计算资源，网络资源，存储资源都按照Pod方式进行组织进行调用，并且能够实现访问安全等复杂的控制，将是未来的方向。
而Container Runtime Interface, CRI，Container Storage Interface, CSI和Container Network Interface, CNI就是对计算资源，网络资源，存储资源的抽象。 所以理解K8s 也可以通过CSI， CRI， CNI的角度去分析。
文件系统
说起分布式文件系统，开源的核心就是4款， Ceph, Gluster, Lustre, Swift.
如果按高扩展和高可用性来说， Ceph肯定是首选的。 尤其Lustre本身不具备容错能力，容易因错误导致服务不可用。 而Gluster虽然有容错，但是不够自动化。 Swift也不错，不过性能比Ceph还是差点。 但是Swift只适合对象存储，而且只提供Restful API访问接口，并发访问能力比Ceph差蛮多。Swift很多代码是Python写的，而其他3款都是C/C++的，后续就不讨论了。
单纯性能而言， 如果数据量不大的文件， 那么Lustre是最快的， Ceph很多时候是最慢的，Ceph复杂，在部分场景下， 性能也会急剧退化，例如扩容的时候。Gluster对大的顺序文件的读写速度是最好的， 例如视频数据。
就运维而言， Gluster相比难度小点， Ceph和Lustre都很复杂。
所以，如果就安全第一，性能第二，块存储的话， 那么Ceph还是第一选择。
Ceph
Ceph最成熟的是块存储RBD，文件存储FS还不稳定， Object存储也还可以。
Ceph的核心是CRUSH算法，尤其是CRUSH Map的功能强大。
其实CRUSH算法的，分为4层对象， 文件，对象，放置组（Placement Group, PG）和对象存储设备（Object Storage Device， OSD）。前两层基本采用Hash方式进行映射。 而放置组和存储设备之间是通过CRUSH方式进行映射的。
CRUSH – Controlled Replication Under Scalable Hashing， 对均匀的把PG分布到节点上去。
一旦扩容， Ceph就会进行在均衡，而这时候有可能速度变得很不稳定。
Lustre
Lustre的本质就是基于高速主干通信的网格文件系统， 主要分成4个高层模块： 管理MGT，元数据 MDT，对象存储OST和客户端Client。
但是为了加强基本的数据安全， 可以实现主备机制，并且支持IB网络提升访问速度。 对于企业用户可以支持存储区域智能光纤网络SAN Fabric。
不管是Ceph还是Lustre都源自大学研究， Ceph是University of California的博士Sage Weil的论文项目， Sage Weil研发了原型系统。
而Lustre是源自CMU的 员工Peter J. Braam的研究项目。 不管是Sage Weil还是Peter J. Braam他们成名世界就是因为开源项目。他们成名后，也迅速的成立了自己的公司，在他们的领域继续深挖。 现在越来越多的华人博士也以此为模范，开启博士毕业就成名之旅。
数据库
通常说，数据库已经包含SQL数据库和Non-SQL的数据库。 在大数据领域的两大标杆Jeff Dean的GFS和BigTable开启了一个时代， 其中Big Table就是Non-SQL的， 而到了Dremel又转向SQL-Like，最终Spanner又坚定了SQL方向。
对应到开源界，Doug Cutting的Hadoop开启了那个时代，但是开源的力量是庞大的，后续大爆炸来的更为猛烈。Hive作为SQL的代表就是那个大爆炸的最早一颗核弹。
Google后续的Colossus继续增强了GFS在master端meta-data的分片自动维护，并且采用了Reed-Solomon纠错编码，成为GFS2。Dataflow是依托Flume和Millwheel的集大成，正式开启了从Lambda走向Kappa架构的时代。
可以看到在K8s之前，Google在大数据面前的战略是只开放思想（论文），不开放代码，一片论文几乎可以影响世界，当然包括Google的股价。 到了K8s谷歌直接下场开放源码。
即便只看SQL的数据库也是多如牛毛， 要搞清楚这么多东西很难也没有必要。 很多开源产品都是跟谷歌不开源有一定关系， 例如Drill就是参考Google Dremel思想的。
Lambda时代的SQL大数据
如果我们把2014年作为Kappa架构开启的年代， 那么2014年之前诞生的很多SQL大数据库基本就是Lambda架构的思路。Kappa架构时代以流数据为核心， 例如上图的Flink项目，也有SQL数据库，但是目前还不够成熟。
个人挑选了4架Lambda DB马车：
经典Hive （Apache）：Hadoop上SQL DB的经典。
Spark SQL（Apache）： 是一个SQL解释层，后台计算由Spark的内存计算完成。
Impala （Cloudera）：针对多表链接查询做了很多优化的架构。
Presto （Facebook）：和Impala架构类似， 但是
首先，从与SQL的兼容性来说，Presto和Impala与SQL兼容性更好，更适合做前端BI的能力。
从性能上来说， 很多测试表明Impala在多表交叉查询的时候有优势， Spark要比Hive要快。Presto与Impala不相上下，部分场景下更有优势。 在实现语言上， 可能Impala是C++实现了核心代码有一定关系。
另外从支持的数据格式化上来说，这4种数据库都是支持列结构数据（ORC， Parquet），对行结构数据支持差(Avro)，一般而言，列结构方便数据压缩和数据读取，而行结构更适合数据写和修改。Impala和Spark最佳存储格式是Parquet，而Hive和Presto最佳是ORC文件结构。一般而言， Parquet的索引效率高于ORC，但是压缩率低于ORC。
Hive
早期Hive主要是SQL的引擎，后端有Hadoop的MR去执行。Map-Reduce执行效率比较低。
后来，Hive可以替换为Tez实现有向图DAG的执行流程， 提速很多。 同时也添加了Live Long And Process (LLAP)机制，进一步加速了计算。LLAP通过内存的缓存， 异步的预读机制进一步加速执行。
现在Hive的执行除了前面的SQL引擎之外就要经过Tez和LLAP层。
而一般HiveSQL的执行需要经过多层解析和优化，变成逻辑树和操作树，最终变成执行树。中间也可能，利用Apache Calcite对SQL查询进行优化后再执行。
Spark SQL
Spark目前除了可以接自己的SQL引擎外，也可以接入Hive on Spark。 只要SQL可以翻译成 abstract syntax tree (AST)，或者可以基于DataFrame的object操作，都可以由Spark后端进行分析运行。
Spark SQL核心还是提供了很好的数据表DataFrame和数据Dataset的封装，以及RDD的内存执行引擎。
而一个AST分析类似如下：
而对于Hive on Spark来说， 就是需要把Hive SQL最终转换成Spark的AST进行执行。
Impala
Impala核心只一个独立的执行引擎， 不依赖于Map-Reduce或者Tez的DAG执行。
并且核心的Executor是C++编写的。
第一步， 会有编译节点把SQL语法编译成本地的节点的执行计划。
第二步， 由转换成分布式的执行计划。
第三步，在不同节点上执行结果。
第4步，按照query fragments的反向路径，把结果进行反向传送回来。但是，我们也能清晰的看到， 在执行过程中， 这些节点之间要进行频繁的数据交换Exchange。
Impala执行的时候采用 Massively Parallel Processing, MPP架构。MPP架构对硬件的要求较高，尤其对于主干网络的性能要求很高。
通常MPP架构的数据有3种分布方式。
Presto
Presto核心能力就是把多源的数据，合并到一起进行查询。 它的基本架构由Coordinator和Worker节点组成。
其实就结构上而言， Presto和Impala很相似的， 都是Cordinator和Worker/Executor的结构， 在Cordinator里面都需要Planner对任务进行编排。 这种结构容易做成任务流的模式。 所有数据都是通过任务的方式分解执行，实现Memory to Memory (M2M)机制，而不用写回存储器，只需要在内容中执行。因此效率较高。
Presto全部Java实现，也是MPP架构， 具有非常灵活的外接数据和插件能力。 绝大部分主流的数据库数据都可以导入Presto而无需添加自己的代码。
总而言之， 如果后台做OLAP批处理，那么还是选择Hive最佳， 如果需要跑后台的大数据分析，那么SparkSQL更适合。 如果需要前台进行多个大数据库交叉查询，并且对速度要求更高，那么Impala更合适。 但是如果想做多源数据的聚合查询， 那么Presto更为灵活。 但是Impala和Presto都没有错误重启机制。
Non-SQL 数据库
常见的Non-SQL的数据库大致有4种， Key-Value和Column-based是最常见的两种。还有图数据库和文本数据库。
知名的数据库里面，
HBase 和 Cassandra是Column-Store类型的。
Couchbase，CouchDB， MongoDB， ElasticSearch是Document-Store类型的。
Redis, LevelDB是Key-Value类型的。
Neo4j, OrientDB 是Graph类型的。
对于Column方式的话， 需要理解Column Family和Super Column Family的组织形式。
举一个Column Family的例子：
再举一个，Super Column Framily的例子：
Document方式就比较简单了，一般用JSON文档的多，也有用BSON的。
Key-Valu就更简单了。
很多时候之间的映射关系是由Hash函数来管理的。
具体到表的组织方式上， 一般会有Key Space, Collection, Table等概念，需要注意。
大致能看到部分数据库都是何种语言实现的。 著名的开源Column-Store都是Java实现的。Document的各种语言都有。Key-Value的大部分是C语言实现的。而Graph的大部分也是Java实现的。
除了实现语言， 按通常性能来说， Graph 类型一般性能不好，而扩展性来说， Column类型和Key-Value类型的比较好。
通常对于关系数据库，要应用ACID理论，对应的Non-SQL是BASE理论，而对于分布式的系统还要考察CAP情况。
Replication和Sharding是分布数据库常用的两种技术。 而Sharding和Replication又分很多种的具体技术。
HBase
HBase 是基于Column类型的non-sql数据库。 组织为Table->Region->Column Families -> Stores结构。
举个例子如下， 要注意，这里Column Families是纵向划分的。
然后有Master Slave 模式进行管理， Client与Master之间通过Zookeeper进行协调。
这里能看到HBase和Cassandra在实现一致性（Consistency）的机制是不一致的。HBase核心是加锁保障了一致性的实现，这样使得部分情况下，可得性较差。HBase也有采用MVCC，是Lock+MVCC的组合优化。
数据库的并发控制一般实现有3种机制：
基于时间标签顺序，这种就是MVCC的思想
基于3阶段的优化并发控制
基于2阶段的锁
MVCC的核心就是写不要锁住读，读也不要锁住写，这样使得读变得非常高效。 怎么做到的呢，就是通过时间来控制多个版本。 对于写操作， 那么对于写之前的读来说， 现在写的数据的时间标签表示它还不可见。 因此尽管数据库有，但是时间控制看不到。
Cassandra
Cassandra也是Column类型的数据库， 以Keyspace->Column Family (Table) -> Partiption (Rows)-> Row -> Column的方式组织的。
举个例子如下， 要注意，这里的Column Family是横向划分的。
Cassandra的核心思想来自Google的 BigTable和Amazon的Dynamo.架构上是一个对等的P2P网络
在访问的时候，其实链接的节点会成为Coordinator节点。
基于Consistent Hashing来解决数据分布的问题， 就是把节点的IP地址空间和数据的空间通过相同的目标hash范围进行关联起来。
另外一个特性就是Virtual Node的设计。 没有虚节点的情况下， 环里面就是真实的节点，当实现3备份的时候，某个节点坏掉了，就只能利用另外3台机器来进行数据恢复。
在有虚节点的设计下， 那么每个真实的节点可能对应多余3个的虚节点。 这样恢复一个盘的数据，可以均匀的来自多个节点。而不是只有3个节点在忙。
由于是对等网络构建Cordinator进行通信， 节点之间的通信采用Gossip协议通信，这个是对等网络高效通信的常用方法。
Cassandra的这些特性使它成为很成功的Column数据库。但是和HBase有什么不一样呢？最大的不一样就是设计上追求的方向不一致。 前面提到CAP理论， 传统的SQL数据库是在CA， 而很多新型数据库都是CP或者AP的。其中HBase就是CP的， 而Cassandra就是AP的。
Redis数据库
Redis是追求CP的Key-Value数据库， 核心要点之一就是要求Client，Master和Slave由不同的节点扮演。
节点间也通过Gossip协议进行通信。
LevelDB
Leveldb 存储主要分为 SSTable（磁盘） 和 MemTable（内存，包括 MemTable 和 Immutable MemTable）
通过从内存到硬盘的逐层Load实现类似Cache的机制，进而提高读写效率。
而做到这种分层机制是基于LSM-Tree （Log-structured merge tree）实现的。
LSM-Tree使用过程就是隔一层写Delta数据，然后再Merge Sort写入再下一层。
为了加速查找速度，也会加上Bloom Filter去排除一些难以命中的块的读取。
其实LSM Tree在内存加速数据读写的云数据库里面都会使用。而传统的数据库基本采用B+树来进行索引。
NewSQL 数据库
NewSQL就是CP+ACID == P + ACID。 代表就是Google的Spanner系统。
当然还有很多的其他NewSQL数据库, 国内的TiDB也是非常的闪亮！
相比传统RDBM和NoSQL， NewSQL兼具了两者的优点。
下期，我们深入看几个NewSQL的例子。
小结：
至此，大致看了一下开源大数据平台的以下部分。 个人认为1）以算力为核心的的资源调度。2）以NewSQL为核心的在线运行。会是新的技术红利。
而具体到平台如何选择，还得根据实际需求，数据量，运维能力等去做选择。 尤其还有庞大的商业软件可以供选择。
至此， 我们大致讲述了22个核心概念：
Lambda vs Kappa架构
数据虚拟化
Pod资源管理
K8s控制类型和工具集
算力峰值TOPS
RDMA （RoCE, InfiniBand，iWARP）
SR-IOV
CSI，CRI，CNI
Ceph的CRUSH算法
Lustre的MGT, MDT, OST分层模型
ORC, Parquent, Avro文件格式
Hive的LLAP机制
Spark的SQL AST树分析
Impala的MPP架构
Presto的M2M机制
SQL Like OLAP vs Non-SQL vs NewSQL
ACID vs BASE vs CAP
HBase 的Column Family vs Cassandra的Column Family
HBase的MVCC
Cassandra的Consistent Hashing
Redis的Gossip协议
LevelDB的LSM Tree
希望能够帮助到你~~~