Apache Mesos

本文译自《 DevOps2.0的工具集（DevOps黑宝书）——打造自动化的持续交付流程》一书 ，转自译者CSDN博客，转载请注明出处。 译者的话： 你真的懂DevOps么？你知道怎么就持续集成持续部署又微服务了么，用时下流行的工具，实践DevOps怎么搞……跟着我，听老司机818 DevOps的那些事儿。 本文只是开个头儿…… 原著作者介绍： Viktor Farcic CloudBees资深顾问，熟悉多种编程语言，从最早的Pascal，Basic，ASP，C，C++，Perl，Python，ASP，NET，Visual Basic，C#，JavaScript等等。热衷于微服务、持续部署和测试驱动开发（TDD）。著有《Test-Driven Java Development》一书，该书由Packt出版。 DevOps理念 做小型的新项目感觉很棒，上一次我做这样的项目还是在2015年的夏天。虽然那个项目有不少问题，但做起来确实很高兴。因为在做这种小型而且相对来说比较新的项目产品时，我们可以按照自己的喜好选择技术手段、方法策略以及整体框架等。 我们能用微服务么？当然可以！我们能试试Polymer和GoLang么？必须的！无拘无束自由自在的做项目真的很爽。虽然我们或许会做错误的决定，而且这个决定可能会让我们的进度延缓一周，但起码不会像其他项目那样，一着不慎满盘皆输。简单来说

Spark 集群相关 <style> table td{ width: 15% } </style> <font face="微软雅黑"> 来源于官方, 可以理解为是官方译文, 外加一点自己的理解. 版本是2.4.4 本篇文章涉及到: 集群概述 master, worker, driver, executor的理解 打包提交,发布 Spark application standalone模式 SparkCluster 启动 及相关配置 资源, executor分配 开放网络端口 高可用(Zookeeper) 名词解释 Term（术语） Meaning（含义） Application 用户构建在 Spark 上的程序。由集群上的一个 driver 程序和多个 executor 组成。 Driver program 该进程运行应用的 main() 方法并且创建了 SparkContext。 Cluster manager 一个外部的用于获取集群上资源的服务。（例如，Standlone Manager，Mesos，YARN） Worker node 任何在集群中可以运行应用代码的节点。 Executor 一个为了在 worker 节点上的应用而启动的进程，它运行 task 并且将数据保持在内存中或者硬盘存储。每个应用有它自己的 Executor。 Task 一个将要被发送到

“ 微服务的概念最早在 2012 年提出，在 Martin Fowler 的大力推广下，微服务在 2014 年后得到了大力发展。 今天我们通过一组手绘图来梳理下微服务的核心架构。 图片来自 Pexels 什么是微服务？ 微服务 Microservices 之父，马丁.福勒，对微服务大概的概述如下： 就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。 但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。 每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。 另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。 可以使用不同的语言来编写服务，也可以使用不同的数据存储。 根据马丁.福勒的描述，我总结了以下几点： ①小服务 小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。

总结下近两年在云原生方向下的工作 一、Mesos SDK开发内部及外部项目，具体用法见 官方文档 二、Kubernetes KUDO Operator开发内部业务系统，具体用法见 官方文档 三、基于Docker CI/CD工作流； 四、CI SDK的内部业务系统开发，基于上基于Python 2.7，感觉后面如果升到Python 3.7，基础上得重构一版了； 五、Mesos/DCOS业务系统集群运维，客户提供各种虚拟机环境时不时的就重启或Crash了，所以混乱测试非常就有必要了，每天应该随机重启集群中的某一台机器； 六、Kubernetes业务系统集群运维。 来源： oschina 链接： https://my.oschina.net/u/4361003/blog/4722037

日前，D2iQ与先智数据宣布建立合作关系，双方将融合先智数据的高端AIOps解决方案Federator.ai与D2iQ Kubernetes云原生平台，帮助企业客户在基于Kubernetes的多云环境中优化资源和应用性能。 如今，许多企业正在将其应用程序工作负载和数据迁移到云端，且迁移的速度正在加快。D2iQ的全栈云原生解决方案和端到端服务支持可帮助世界各地各种规模和垂直行业的组织迁移到云。事实上，大约有三分之一的《财富》50强公司、北美十大银行中的一半以及全球前十二大电信提供商中的七家都在采用D2iQ的解决方案。 由于许多运行在云的应用具有高度动态的工作负载和不同的服务级别要求，企业客户需要创新的解决方案来提高其运营的成本效率，为每个应用规模化地管理其云资源，同时确保应用的性能和服务水平。 AIOps解决方案的领先提供商先智数据使用先进的机器学习技术提供Federator.ai解决方案，以帮助企业优化云资源和应用性能。通过Federator.ai，企业现在可以在云上执行有效的容量规划和资源优化，并以最佳性能自动扩展每个应用程序的资源规模。Federator.ai的使用可确保每个应用程序的云资源不会过度配置或不足。 双方的合作将为用户提供更具成本优势的Kubernetes云原生AIOps解决方案，通过机器学习，智能化协调企业在本地数据中心/云上的容器资源，合理规划资源利用

序言 搭建完了Rancher2.4.X,整理一下知识点,其中包括了K8S.方便后面我们玩.知识点当然是持续更新 K8S K8S是容器编排调度引擎.提供了如下的内容: 简化应用部署 提高硬件资源利用率 健康检查和自修复 自动扩容缩容 服务发现和负载均衡 K8S内部的元素( 从元素上看K8S是很复杂的 ) k8s集群由 Master节点 和 Node（Worker） 节点组成。 Master节点 Master节点指的是集群控制节点 ，管理和控制整个集群，基本上k8s的所有控制命令都发给它，它负责具体的执行过程。( 如下的机器上运行的程序都可以在Rancher起来后通过docker ps看到----cuiyaonan2000@163.com ) 在Master上主要运行着： Kubernetes Controller Manager（kube-controller-manager）： k8s中所有资源对象的自动化控制中心 ，维护管理集群的状态，比如故障检测，自动扩展，滚动更新等。 Kubernetes Scheduler（kube-scheduler）： 负责资源调度， 按照预定的调度策略将Pod调度到相应的机器上 。( 这里的POD即最小的工作单元) etcd：保存整个集群的状态 。----这个东西在Rancher2.5.1中一直报错~~~ Node节点

我们知道，大部分Spark计算都是在内存中完成的，所以Spark的瓶颈一般来自于集群(standalone, yarn, mesos, k8s)的资源紧张，CPU，网络带宽，内存。Spark的性能，想要它快，就得充分利用好系统资源，尤其是内存和CPU。有时候我们也需要做一些优化调整来减少内存占用，例如将小文件进行合并的操作。 一、问题现象 我们有一个15万条总数据量133MB的表，使用SELECT * FROM bi.dwd_tbl_conf_info全表查询耗时3min，另外一个500万条总数据量6.3G的表ods_tbl_conf_detail，查询耗时23秒。两张表均为列式存储的表。 大表查询快，而小表反而查询慢了，为什么会产生如此奇怪的现象呢？ 二、问题探询 数据量6.3G的表查询耗时23秒，反而数据量133MB的小表查询耗时3min，这非常奇怪。我们收集了对应的建表语句，发现两者没有太大的差异，大部分为String，两表的列数也相差不大。 CREATE TABLE IF NOT EXISTS `bi`.`dwd_tbl_conf_info` ( `corp_id` STRING COMMENT '', `dept_uuid` STRING COMMENT '', `user_id` STRING COMMENT '', `user_name` STRING COMMENT

原文链接: http://www.apachecn.org/bigdata/spark/268.html Apache Spark™ 是一个快速的, 用于海量数据处理的通用引擎. 官方网址: http://spark.apache.org 中文文档: http://spark.apachecn.org 花了大概两周左右的时间，在原来 Spark 2.0.2 中文文档 版本的基础上，终于迭代出该 Spark 2.2.0 中文文档 的版本了。 衷心感谢每一位贡献者，感谢 ApacheCN 让我们聚在一起奋斗，我们一直在努力 。。。 网址: http://spark.apachecn.org/docs/cn/2.2.0 github: https://github.com/apachecn/spark-doc-zh （如果觉得不错，请各位大佬们给个 star ） 贡献者: https://github.com/apachecn/spark-doc-zh#贡献者 建议反馈: https://github.com/apachecn/spark-doc-zh#联系方式 以下是 Spark 2.2.0 中文文档 的目录索引: Apache Spark 2.2.0 官方文档中文版 概述 编程指南 快速入门 Spark 编程指南 Spark Streaming 编程指南 DataFrames,

腾讯会议大规模扩容，快手春节红包流量洪峰：超大规模给云计算系统带来诸多挑战。如何管理海量节点并持续提升可扩展性？如何保证复杂工作流的稳定执行和故障自愈？如何提供高可用、高性能、低成本的计算能力？本文是腾讯云专家工程师李德铠在「云加社区沙龙online」的分享整理，为大家介绍腾讯会议大规模任务调度系统架构设计！ 点击视频，查看完整直播回放 疫情期间，很多企业受到了较大冲击，正常的复工生产无法进行。腾讯会议作为一款非常便捷的远程协作工具，成为了国内众多企业日常会议沟通交流的主要平台，这款产品从2019年12月26号正式推出，如何在这么短的时间内有效支撑起国内数以亿计用户的访问量呢？如何保障系统的稳定运行？ 下面为大家介绍，腾讯会议8天时间内完成100万核资源扩容背后的技术。 一、两个典型案例 首先介绍腾讯会议大规模扩容，下图所示为腾讯会议的架构图，左右两端的用户通过交换机连接到基站，然后接入腾讯云机房，首先会通过我们的调度中心，还有腾讯后台的接入层，接收到用户发起会议的请求。 拿到请求之后，再通过一些状态机的判断，帮用户加入到对应的会议室里面，然后再跟远端的朋友或同事建立一个音频媒体长链接，再通过混音和流控达到稳定的沟通服务。 今年对于腾讯会议是非常有突破的一年，它在春节期间快速崛起，成为了众多中小企业和学校复工复学必备的APP之一

Hadoop存在缺陷： 基于磁盘，无论是MapReduce还是YARN都是将数据从磁盘中加载出来，经过DAG，然后重新写回到磁盘中 计算过程的中间数据又需要写入到HDFS的临时文件 这些都使得Hadoop在大数据运算上表现太“慢”，Spark应运而生。 Spark的架构设计： ClusterManager负责分配资源，有点像YARN中ResourceManager那个角色，大管家握有所有的干活的资源，属于乙方的总包。 WorkerNode是可以干活的节点，听大管家ClusterManager差遣，是真正有资源干活的主。 Executor是在WorkerNode上起的一个进程，相当于一个包工头，负责准备Task环境和执行Task，负责内存和磁盘的使用。 Task是施工项目里的每一个具体的任务。 Driver是统管Task的产生与发送给Executor的，是甲方的司令员。 SparkContext是与ClusterManager打交道的，负责给钱申请资源的，是甲方的接口人。 整个互动流程是这样的： 1 甲方来了个项目，创建了SparkContext，SparkContext去找ClusterManager申请资源同时给出报价，需要多少CPU和内存等资源。ClusterManager去找WorkerNode并启动Excutor，并介绍Excutor给Driver认识。 2