本文是 5月 26日大数据杂谈微信群分享，达观主题月第四个议题的内容整理。大数据系统的应用领域
首先回顾一下历史。
从中我们可以看到一些趋势，在大数据生态发展的过程中，大数据系统的管理系统，大数据系统的安全，易用性，机器学习不断的补充到生态系统中来并不断完善。
早期是 google一家独有。2003 gfs paper发表的时候，google的集群规模就达到上千台，遥遥领先。
之后是大家都知道的历史，doug cutting在为他的lucene分布式化的时候看到了 google的这篇论文，并把它实现出来，后来被 yahoo收编，得到一个机会和环境把hadoop孵化出来。
随着互联网的兴旺发展，许多互联网公司也逐渐开始把 hadoop变成内部大数据处理系统的不二之选。随着大数据概念的火爆，使得开始是行业领头羊的巨头在玩的东西逐渐被有机会普及到传统领域。
现在不断能够听说新的大数据项目冒出来。
hadoop零基础的同学会有一个模糊的认识，会把 hadoop当初数据库，尤其是在使用 hive和 impala的时候，会在清醒和迷糊之间徘徊一段时间。
即使是领域内的同学，也会持有一个观点，没有海量数据，搞什么大数据?我个人愿意把大数据系统这样定义：大数据系统是在大数据的时代背景下，由一个朴素的应用需求催生出的系统，在大数据的浪潮中，被赋予的不同的期待，逐渐成长起来的尚处于青少年期的生态。
总之，我是想说，这是有门槛的。
好处自然很多，横向扩展的能力、机器学习的能力、图计算、流式计算，许许多多的应用场景令人浮想联翩。
门槛也有很多，1)开源系统，大家知道开源系统如果你不把里里外外全部了然于心，使用的时候碰到的麻烦应该是有所体会的。2)它还在快速的成长，很多功能可能还没有，或者是 bug很多，传统行业（在这里我指除 it之外的行业）应该是使用商业软件居多。
但毫无疑问这个领域正在蓬勃发展。底层数据类型和格式非常广的兼容性，计算模型的丰富和对于机器学习模型的支持。
那么什么样的领域需要大数据系统？
海量数据：例如 it企业数据非常杂：传统企业需要有新的数据处理模型的支持：ai和实时运营决策公司（目前还很超前）。
例如下面这个场景：
5年以上的老公司跨国业务，数据需要到母公司汇总分析数据链条很长，不同的业务会产生数据，数据应用和数据分析没有分开积累了历史数据，还在继续产生不知道如何分析的历史数据积累了一些问题，这些问题可以在数据中找到答案行业竞争激烈，管理层很着急。。。
那么问题来了：
搭建这个平台会遇到哪些困难？要一个什么样的数据平台？如何做数据管理和数据流程管理?多久才能带来价值？
这些问题先暂且放一放。
我们先看看这个问题，那么多的大数据系统的服务，如何能统一管理呢？这里的管理是指：
初始化安装配置文件修改发布服务启动停止查看分布式的日志服务升级添加新的服务系统调优监控到服务内部不同 web应用的导航集群元数据管理
还有在公有云和私有云提供创建实例接口的情况下，如何实现一键部署呢？下面以cloudera的产品为例，讲一下这些是如何设计实现的。分布式系统的管理系统
先来看一下，如果修改一个没有管理系统辅助的社区版的 hadoop系统的配置文件，它的复杂度是这样的。
而事实上早期的集群维护的确就是这么做的，即使你用脚本把配置文件推送到其他节点，并且用脚本拉回日志检查的话，还是非常不方便。
下面来看看cloudera manager是怎么来解决这个问题的。
cloudera manager可以通过 rpm手工安装。cloudera agent可以通过 cloudera manager的界面添加。
cloudera manager通过 cloudera-scm-server来中央控制整个集群的搭建、维护和监控。每台机器上的管理工作交给 cloudera-scm-agent。
cloudera-scm-agent借助开源项目 supervisord来实现每台机器的进程管理。supervisord的好处是在单台机器上实现对进程的集中管理。cloudera-scm-agent通过接受 cloudera-scm-server的指令，调用 supervisord的接口来进行控制本机上所有的进程和查询本机上所有进程的状态。
clouderamanager把新改动与线上环境配置进行对比，如果发现有配置更新，提示用户更新服务配置或者部署客户端配置。
在更新服务配置的同时通过命令调用 cloudera agent，cloudera agent调用 supervirsord的接口，重启各个服务器上的进程。在重启完毕以后，cloudera manager监控管理服务，通过调用服务接口检测服务是否成功启动，显示服务的状态，如果发现服务没有成功启动，用户可以通过检测结果判断服务失败的原因。
cloudera rpm安装包中，还提供了监控的服务包。cloudera manager管理界面上可以启动 cloudera的管理服务。其中有两个监控服务，一个是 host monitor，其作用是接受 agent上报来的节点数据，如磁盘使用情况，cpu capacity，cpu用量，内存的大小和内存的用量，机器负载等。service monitor则是一个服务健康检测服务，会定期的执行各种不同的检测，把数据汇总到 web界面供管理员查看。
同时cloudera manager提供统一入口的日志查询 gui，以一个搜索接口加过滤器的方式帮助用户排查原因。
在有共有云服务的环境下，可以通过一个描述文件安装整套 cloudera manager，cloudera agent以及大数据服务。
cloudera director通过调用云服务 api创建集群所需要的实例。
通过云服务 api得到地址信息，进而用 ssh远程命令调用安装 cloudera manager和 cloudera agent，并且启动 cloudera manager和cloudera agent服务。
通过调用 cloudera manager的 rest服务 api，进行大数据服务的安装，部署和配置。
一些我了解的情况如下：
cloudera自己有自己的代码仓库，它的各种服务的代码版本与社区发布的版本不一致。具体多大程度上不一致很难知晓。部分应该是由于license的原因，像 sparkr没有集成到 cloudera版本的 spark中去，应该是 license的原因。社区的大数据服务需要 cloudera进行定制才能集成到 cloudera的管理平台上，支持的大数据服务的种类有限。cloudera上面的服务版本更新还是比较慢的。
再来看看大数据系统在底层技术上是如何实现多租户的？数据平台多租户的实现
对于hadoop平台而言，多租户是最大的难点之一。大数据系统最大的一个问题是资源浪费，早期单用户，单任务。多租户的目标可以有效的充分利用资源。多租户的资源分配依赖于两个技术：资源隔离，调度算法，在操作系统层面和服务层面（yarn）都可以做资源隔离。
yarn在服务层面做资源隔离的是 jvm。yarn的 node manager响应 resourcemanager的请求创建的 container，其实就是一个 jvm。通过 jvm的参数来设置资源的大小，这个资源包括内存和 cpu。mr2可以对于 map和 reducer的 jvm大小分别做定义。spark的对应的 jvm叫 executor，大小都是一样的。还有一类 yarn的框架需求也需要用到 jvm，那就是 application master，同样也是 jvm。这其实就是 yarn的核心功能，在 yarn的层面之上的应用框架，无外乎是通过 yarn和 hdfs来分发应用程序逻辑，申请资源，把具体的应用层的框架逻辑注入到 jvm中，而最后用户的业务逻辑再注入到应用层的框架逻辑之中。
应用层框架譬如就是 mr2和 spark，用户逻辑就是你的ｊａｒ包
操作系统层linux用cgroups做静态资源隔离。2006年 google工程师在创建 cgroups这个特性的时候，本来的名字不是 cgroups，而是进程容器，这也是这个特性的本意，就是在 linux内核级别创建一个容器的概念，使得这些进程只竞争容器内部的资源。容器内的应用不会收到容器外的应用对于操作系统资源，cpu、内存、网络 io、句柄的侵占，运行出现问题。cgroups同时也是 docker的底层技术，docker在 cgroups的基础之上，实现了更加广泛和易用的接口，和建立的一个广泛的生态。
hadoop的这些服务中，也广泛的应用 cgroup来对服务资源做静态隔离。
只有革命性的底层技术，才能带来上层应用的突飞猛进。不过 cgroup是 2007年就有了第一个版本，而 docker是 2013年才出第一个版本，中间间隔了 6年。
对于内存、cpu等资源，hadoop主要用的就是这两种资源隔离的方式。其实想想这两种方法仍然挺朴素的，我也相信，底层一定会有更好的技术来支持资源隔离。调度算法
然后再讲讲调度算法。
在yarn之前，操作系统、数据库都要用到调度算法，所以调度算法在工程领域有很多学术论文可以参考。
下面只是简单以公平调度为例看一下大概是怎么回事。
根据上面的图示，公平调度是在不同的 pool之间，首先满足最小需求阈值，当实际需求低于最小需求阈值时，以实际需求为准。而实际需求高于最小保证的用量时，仅仅满足最小用量，在整个请求者的最小用量得到满足之后，再进行第二轮分配。第二轮分配以一个“迫切度”来做指标，即实际需求和已满足的资源差额除以实际需求，需求最为迫切的分配剩余的资源。
以上策略是在不同池子中的竞争算法。在同一个池子中，按照时间片轮转的方式为不同用户分配资源。多租户环境的安全性实现
再讲讲多租户环境的安全性实现。
安全性话题很大，先挑 3个点讲一下：
authenticationauthorzation服务层面的 impersonation和 delegation
首先讲第一个点 authentication。
什么是 authentication呢？authentication就是如何证明你是你？可以叫身份验证。
最常见的用户单一服务环境，用的是 simpleauthentication，就是简单身份验证，方法是用户名加密码的方式。以一个网站服务为例，
那这种验证方式，网络功能逻辑和身份验证是两个非常解耦的功能，在一个多服务或者是海量服务的环境下，是有严重的效率问题的。看下图。
有n个服务，就会有 n套用户信息系统。用户就得记住 n套密码。而 ldap的用户密码验证把验证密码的逻辑后移了，委托给了 ldap服务。使得多套密码验证只需要一个用户名和密码。
现在的系统有很多微服务，服务之间的解耦调用，服务和服务之间也需要做身份认证。当请求认证身份的主体由一个“人”变成一个服务的时候应该怎么办呢？怎么防止恶意的服务程序来伪装成一个另一个服务的客户端非法请求数据呢？当海量服务相互调用的时候，采用名称和密码的方式显然是不可行的，所以 kerberos使用秘钥。
服务在 kdc上认证，访问其他服务是通过向 kdc申请 ticket的方法。秘钥采用非对称加密，秘钥信息不会通过网络传播。kdc不知道 client和服务之间通信的秘钥，服务也不知道 client和 kdc之间的秘钥。客户的秘钥不会经过服务。
以上是多租户的认证方式。权限控制
再讲权限控制，在通信层的 sasl的实现方式 gssapi，在底层支持了 impersonation，如下图。
impernation也就是说，前端服务连接到后端服务，前端服务根据他本身登录用户的不同，伪装成 login user在后端服务上执行任务。这样做的好处是，便于做权限控制，也便于审计用户的行为。在一个安全性要求比较高的平台上，要注意集成到平台上的前端服务是否支持这个特性，否则这个层面上恶意用户可以绕开权限控制。
还有一种方式叫 delegation，代理的方式。譬如 rstudio在连接 spark的时候就是采用的这种方式。
rstudio的用户委托 rstudio在与 spark的每个用户 session建立之前，先到服务器登录用户的 home目录地下做认证，拿到 ticket，然后到后端服务上执行任务。
企业办公系统，windows是不二之选，而其他用户认证和信息都是在微软的 active directory里面的。 active directory集成了 ldap和 kerberos的实现。所以多租户的大数据系统的会跟 ad集成来为企业用户提供 single sign on。
权限管理
再讲一下多租户的权限管理，以apachesentry为例。
apachesentry是一个开放性的服务，通过实现 sentry的接口可以为新的分布式服务增加权限控制的功能。目前 hive，impala，hbase等都可以用 sentry进行权限控制。
看一下，ad和 sentry的概念图，其中重叠部分是 group。
sentry通过为 ad里面的 group做 role的映射来赋予权限。当你企业的权限模型定义完备之后，那么只需要在 ad里面操作 user和 group的关系来为用户赋予权限了，这是非常简单的 windows配置。
sentry通过一个接口协议为所有的服务提供权限定义和权限校验。
hive是一个 mr或者 spark处理引擎的 sql解释接口，那么用户可能绕开 hive的权限直接去 hdfs上访问数据。hdfs的 name node上的 sentry插件解决了这个问题。
name node上的 sentry的插件会去把 hive的权限控制语转换成 hdfs层面的 acl。hdfs层面的 acl和 linux的类似的，都是扩展了简单的 posix用户权限管理。acl跟 linux上的 acl原理一致，都是基于 posix权限管理的补充。企业级数据平台的实践
数据平台需要有哪些参与者？用户类型。
现在对于软件开发生命周期都有比较成熟的系统和工具。源代码管理工具，软件开发版本特性 bug管理，开发环境和可持续交付与集成的测试框架和自动化部署。
数据管理和数据开发比较欠缺一个行业的标准流程。数据管理包括对于数据的权限控制和内容管理。在一个多租户的环境下，经年累月平台上会出现越来越多的数据，不知道 owner是谁，也没有数据的版本，长�...