阿里云互联网中间件：让企业实现业务云化持续创新|学习笔记
开发者学堂课程【上云须知 - 全面了解阿里云能为你做什么：阿里云互联网中间件：让企业实现业务云化持续创新】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/381/detail/4772阿里云互联网中间件：让企业实现业务云化持续创新让企业实现业务云化持续创新经过阿里巴巴多年真实场景洗礼的阿里云互联网中间件正式推出，阿里云互联网中间件通过成熟稳定的企业互联网架构平台，高效开发应用程序，无缝实现应用和终端通信，数据存储无限水平扩展，让您的企业轻松面对众多的不确定任务需求，海量并发的用户访问，纵横交错的系统架构，实现业务员化持续创新。阿里云互联网中间件由企业级分布式应用服务以 Darth 分布式关系型数据库服务，BRTS 消息队列 MQ，业务实时监控服务 arms，云服务总线 CSB 这五剑客组成。阿里云 EDAS 基于应用为中心的中间件 pass 平台，为您轻松构建并托管分布式应用，采用分布式服务框架，脱离出相似业务逻辑并单独部署，您只需借助 RPC 框架进行服务的远程调用，EDAS 每天可处理 3000 亿次调用服务，生成万亿条业务调用链，同时拥有完善的健全体系，为您每一次服务调用保驾护航。EDAS 的自动压测通过容量规划，让您从容应对流量高峰，同时对 CPU 内存和负载实时监控，您只需要轻松勾选并能实现对应用的秒级扩容和缩容，更拥有强大的鹰眼监控系统，为您分析每一次系统调用，消息发送和数据库访问，精准发现您系统的瓶颈和隐患，同时针对服务的 qps 响应时间和出错率进行全方位的监控。EDAS 自主研发拥有多项专利的分布式事务服务 TXT，支持大多数关系型数据库，消息等多种事务源和 EDAS 服务调用。在保证 ACID 原则下，长分布式事务性能提升10倍。曾经的单机数据库瓶颈造成的各种问题，让企业苦不堪言。D2DS 将多个单机数据库集成管理起来，以分布式集群方式提供服务，并行处理数据库请求。每天可帮您处理 800 至 1000 亿次数据库请求，DRDS 按需在线平滑扩缩容，只需要动动鼠标选择自己需要的配置即可，而且 DRDS 存储集群节点达 200+，峰值 qps 达 150 万+。同时实现应用透明的读写分离，做到业务零代码改动。全面兼容 MySQL 协议和语法，具备全生命周期的数据库运维管控能力。在双十一狂欢的同时，您是否想过如何在瞬间海量交易请求的冲击之下，保持平台各个电影消息畅通，MQ就是解决的秘方。它实现分布式计算场景中所有异步解耦功能，像一个万能变压器，不管前端多大电流输入，后端出来都是平稳的流量。MQ 更支持消息海量推进，单 Tokyo 就可容纳 100+ 亿条信息。平衡利用处理得到缓冲，确保系统不崩溃。经过双十一严苛场景验证，支持每天流转几千亿条消息，您只需钻研用户需求而不用担心暴涨的应用请求对系统的冲击。随着您的企业的业务增长，数据也将剧增，如何实时处理数据满足您企业业务监控，arms 在业务实时监控领域绝对是你梦寐以求的神器，它经历多年打磨，每秒处理的业务数据值超过 15 GB，后台数据结果每秒峰值写入超过 5 GB，谁说进入新的互联网技术就要彻底抛弃企业原有的以及第三方的系统，CSB 基于高可用分布式集群技术构建的服务 API 开放平台，贴心帮您融合内外新旧系统，兼具服务化 API 的组织和安全管控。与此同时 CSB 支持多实例的级联服务链路，让您从容应对更为复杂的网络结构和隔离策略。阿里云互联网中间件产品，经过阿里内部近10年使用和沉淀，支撑了整个阿里巴巴99% 以上的大规模应用。采用阿里云互联网中间件后，中石化90 天快速搭建了工业品采购平台 100 克，实现了从 0 到 1 的蜕变。近一年累计成交 137 亿。芒果 TV4 四十天完成跨年晚会互动系统构建。互联网+让企业更贴近用户，阿里云互联网中间件配合你的步伐洞，察用户的需求让您轻松拥抱云计算，快速实现业务尝鲜和资源配置效率最大化。
阿里云 MaxCompute：轻松玩转大数据|学习笔记
开发者学堂课程【上云须知 - 全面了解阿里云能为你做什么：?阿里云 MaxCompute：轻松玩转大数据】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/381/detail/4769阿里云 MaxCompute：轻松玩转大数据阿里云 MaxComputeMaxCompute 是一种全新的大数据计算服务。它能提供快速完全托管的 PB 级仓库解决方案，让你不用花费大量成本建数据中心，就能分析处理高达 PB 级的海量数据。?MaxCompute 独创地底层存储技术，采用电压缩存储格式，超强的 5 倍的压缩能力，大大的提高了数据压缩比，提升了磁盘 IO 性能，节省了用户成本。除此之外，MaxCompute 的计算能力表现也更加强劲。2015 年 10 月的 Sort Benchmark 排序竞赛中，MaxCompute 只用 377 秒完成 100 TB 的数据排序，打破了四项世界纪录。区别于 Hadoop 等开源软件，MaxCompute 是一种全新分布式数据存储计算引擎，所有功能以 ALL in ONE BOX 方式提供服务，您不仅可以在上面做基本的数据导入、导出、SQL 查询、ETL 处理，还可以使用机器学习算法来建模，做高级数据分析，丰富的用户接口让你轻松与 ECS、RDS、分析型数据库以及其他 BI 报表工具等配合使用完成 BI 分析。更加神奇的是，从商业智能分析到广告个性化推荐，再到基因测序和好莱坞级别电影动画渲染，这些 MaxCompute 都能帮你搞定。MaxCompute 不仅在计算性能上突出，服务上也更加专业。专业的服务器就是兼容开放。MaxCompute 多种计算模型于一身，支持 SQL、MapReduce、Graph 以及 MPI 迭代类算法，并与开源的大数据处理软件编程接口高度兼容，用户不用再烦心修改程序，所有应用都可轻松的从 Hadoop 迁移到 MaxCompute上。专业的服务就是开箱即用。使用 Hadoop 等开源软件需要手工配置、升级集群，针对不同组件时还要解决版本兼容的问题，运维更是魅力还费心。Max compute 帮你搞定这一切。他开箱即用，拥有集成化的操作界面，你不必关心集群搭建、配置和运维工作，仅需简单点击鼠标，几步操作，就可以在MaxCompute 中上传数据，分析数据并得到分析结果。专业的服务就是安全可靠。Max compute 是首家通过国 内 CSA -STAR 和ISO27001 两项国际云安全认证的产品。 在各个环节都采用了国际上最先进的数据安全管理标准，完善的认证和鉴权解决方案，真正做到让你自主可控，体验金融级可靠性。多族谱机制保证用户数据隔离，同时采三重备份，读写请求鉴权、应用沙箱、系统沙箱等多层次数据存储和访问安全机制保障用户数据安全。灵活的数据授权可以让组织中多名数据分析师协同工作，并且每人仅能访问自己权限许可内的数据，在保障数据安全的前提下，最大化工作效率。计算大，性能好，服务专业，价格如何呢？使用开源的 Hadoop、Spark 等软件，前提是你要拥有一个专业的运维团队和维护人员。开源人才难招，更别提招人成本上的投入。现在有了 MaxCompute，企业不用为了 Hadoop 人才难觅而发愁，先帮你省下一个运维团队。此外，MaxCompute按量付费，成本更低。它凭借更高效的计算及存储能力。能够降低企业 2 0% 至 30% 的采购成本性能，性能却能提升 2.5 倍。从 2010 年开始，Max compute 支撑起阿里巴巴集团所有大数据分析挖掘业务，经过长时间的数据业务场景下锤炼，帮用户彩票了无数的坑，让大数据计算真正产品化。因为 MaxCompute，墨迹天气在数据分析和运维成本上省下了 70% 的 开支，华大基因每千人基因的测序时间从几个月到一天完成。马上加入 MaxCompute，开启你的大数据之旅吧。
微服务场景下数据抽取与统计（3）
数据仓库建模方法在数据仓库建模领域有两种主流的建模方法，一种是Inmon提出的依托于OLTP数据库，采用自上而下的建模方法，先对企业级数据仓库进行总体设计，在数据仓库基础之上，根据业务部门的不同需求构建数据集市。另一种是Kimball提出的维度建模，采用自下而上的建模方法，先构建数据集市，然后将多个数据集市整合成一个数据仓库。目前，这两种建模方法在学术界和工业界都得到了广泛认可，并且在生产环境中已经被大规模应用。这两种建模方法没有好坏之分，用户可以根据公司目前所处阶段、业务复杂度、公司规模等条件选择合适的建模方法。当公司处于早期阶段，公司规模较小，业务发展速度非常快，有可能需要经常调整业务方向。针对这种情况，可以选择使用Kimball的维度建模法，快速地搭建数据仓库，及时响应业务需求。当公司处于稳定阶段，公司属于大中型规模，业务发展稳定，并且已经有了一定的数据积累。针对这种情况，可以选择Inmon的建模方法，从上到下系统地规划设计，这种方法的开发周期比较长，但是一旦搭建成功，后期维护将非常方便。数据抽取、转换和加载在构建数据仓库的过程中，需要将各分散数据源中的数据整合在一起，不同数据源的数据格式、字段描述、存储方式等信息各不相同，有些数据中还存在大量的脏数据。数据仓库要求必须是干净的、规范的、一致性的数据才可以被加载到数据仓库中。所以原始数据源的数据要经过抽取、清洗转换之后才会被加载到数据仓库中，这个数据被加工处理的过程称为ETL。ETL是抽取（Extract）、转换（Transformation）、加载（Load）的简称，目的是将企业中分散、不规范、不一致的数据整合到一起，为后续的统计分析工作提供准确的数据支撑。ETL不只发生在数据加载进数据仓库之前，在数据仓库各层之间也会涉及ETL。ETL在数据仓库中起着非常重要的作用，决定了最终分析结果的准确性。在构建数据仓库的过程中，ETL会耗费大量的时间，有些公司会专门设置ETL工程师的岗位专门从事ETL工作。数据统计数据从业务系统经过ETL进入数据仓库，为后续的数据统计工作提供基础数据。数据工程师基于数据仓库进行数据处理和统计分析工作，最终的统计结果会被导入BI系统为决策者提供数据依据。整个数据处理和统计流程如图9-4所示。数据统计分析的过程是基于数据仓库中进行的，公司决策者使用的BI系统与数据仓库是两套系统，那么就会涉及统计结果在两个系统之间的传输问题。解决这个问题有三种常用方法。（1）将统计结果保存到TXT、CSV等数据文件中，然后使用关系型数据库的数据导入工具将数据文件导入BI系统可以访问的关系型数据库表中。（2）将统计结果保存到数据仓库应用层的数据表中，搭建中间数据服务系统，该系统通过JDBC/ODBC访问应用层数据表中的数据，BI系统通过中间数据服务系统获取相关数据。（3）如果数据仓库是基于Hadoop/Hive构建的，那么可以将统计结果保存到HDFS的指定目录中，通过Sqoop等工具将存储在HDFS中的结果数据导入BI系统的关系型数据库表中。数据仓库工具HiveHive是一款基于Hadoop的数据仓库解决方案。Hive最初是由Facebook开发的，后来贡献给Apache软件基金会，将其命名为Apache Hive并作为一个独立开源项目。Hive不是一个关系型数据库，不提供数据存储服务，真正的数据存储在Hadoop的分布式文件系统HDFS中。Hive主要负责元数据管理，把研发工程师或数据分析师熟悉的SQL语句转换为Hadoop的分布式处理程序MapReduce，然后将MapReduce程序调度到Hadoop中运行，对存储在HDFS上的大规模数据进行分析处理。虽然Hive不是一个关系型数据库，但是Hive支持类似关系型数据库中的数据库、表、视图等概念。对于熟悉数据库的用户来说学习成本非常低，可以像操作关系型数据一样使用Hive。Hive提供了一种类SQL的查询语言HiveSQL，它的语法与MySQL的语法非常相似，熟悉MySQL的用户可以非常快速地掌握HiveSQL。HiveSQL内置了很多常用的运算符和函数，能够满足日常的大部分工作需求。对于HiveSQL中没有提供的函数或用户需要处理的一些个性化需求，可以通过用户自定义函数UDF或用户自定义聚合函数UDAF进行扩展实现。Hive的架构如图9-5所示。?Hive允许用户通过三种方式访问Hive，分别如下：（1）通过命令行接口（CLI）交互式地访问Hive，这种方式简单方便。（2）为了方便用户使用不同编程语言开发的程序访问Hive，Hive提供了跨语言Thrift服务，在程序中通过JDBC或ODBC直接访问Hive。（3）Hive提供了可视化操作工具HWI，用户可以更加直观地通过试图界面访问Hive。ETL作业调度ETL过程会调度大量的作业，在项目初期业务比较简单的阶段，一种比较经典的调度方式是通过Linux系统的crontab调度作业脚本执行调度的，在Linux系统中，用户可以通过编辑crontab文件设置需要定时执行的作业。crontab文件中的一行就是一个待执行的作业，Linux系统通过后台服务进程crond定期检查crontab文件中是否有要执行的任务，从而实现定时自动执行某个任务。例9-3每天凌晨1点15分执行数据抽取脚本sqoop_import_consumer_address_df.sh，作业执行过程中产生的日志输出到sqoop_import_consumer_address_df.log日志文件中。?使用crontab定时执行作业的优点是操作简单，适合在简单地业务场景下使用。缺点也很明显，在复杂的业务场景下通常需要调度大量的作业，有些作业需要并行执行，有些作业需要前后依赖执行，需要编写大量的脚本控制各个作业的执行流程，需要工程师投入大量的精力维护这些脚本，作业的监控管理也非常不方便。在复杂的业务场景下，通常会选择使用操作更加灵活、功能更加强大、方便监控管理的开源调度系统或公司内部自研的调度系统进行自动化调度。这种调度方式不但可以周期性地并行执行各种作业，还可以设置复杂的作业之间的依赖关系。工程师可以对作业整个运行流程进行监管，当作业运行失败时会立即向管理员发送报警信息，如果配置了重试机制，那么调度器针对失败的作业还会重新调度执行。常用的开源工作流调度系统有Apache Oozie、Azkaban等。
从 GFS 失败的架构设计来看一致性的重要性（1）
作者简介 陈东明，饿了么北京技术中心架构组负责人，负责饿了么的产品线架构设计以及饿了么基础架 构研发工作。曾任百度架构师，负责百度即时通讯产品的架构设计。具有丰富的大规模系统构 建和基础架构的研发经验，善于复杂业务需求下的大并发、分布式系统设计和持续优化。作者微信公众号dongming_cdm，欢迎关注。GFS(Google File System)是Google公司开发的一款分布式文件系统。在2003年，Google 发表一篇论文详细描述了GFS的架构。GFS，MapReduce，Bigt able并称为Google的三架? ?，推动了Google的高速发展。其他互联公司和开源领域纷纷模仿，构建自己的系统。可以 这么说，GFS，MapReduce，Bigt able引领了互联网公司的分布式技术的发展。但GFS架构设 计并不是一个完美的架构设计，它有诸多方面的问题，一致性的欠缺就是其中的一个问题。本文探讨一下GFS架构设计、分析其在一致性方面的设计不足，并且看一下一致性对分布式系统 的重要性。我们从GFS的接口设计说起。接口GFS采用了人们非常熟悉的接口，但是被没有实现如POSIX的标准接口。通常的一些操作包 括:create, delete, open, close, read, write, record append等。create,delete,open,close 和POSIX的接口类似，这里就不强调说了。这里详细讲述一下write, record append提供的语意。write操作可以将任意?度len的数据写入到任意指定文件的位置off setrecord append操作可以原子的将len<=16MB的数据写入到指定文件的末尾之所以GFS设计这个接口，是因为record append不是简单的offset等于文件末尾的write操作。 record append是具有原子特性的操作，本文后面会详细解释这个原子特性。write和record append操作都允许多个客户端并发操作。架构GFS架构如下图。(摘自GFS的论文)主要的架构部件有GFS client, GFS master, GFS chunkserver。一个GFS集群包括:一个 master，多个chunkserver，集群可以被多个GFS client访问。GFS客户端(GFS client)是运行在应用(Application)进程里的代码，通常以SDK形式 存在。GFS中的文件被分割成固定大小的块(chunk)，每个块的?度是固定64MB。GFS chunkserver把这些chunk存储在本地的Linux文件系统中，也就是本地磁盘中。通常每个 chunck会被保存3个副本(replica)。一个chunkserver会保存多个块，每个块都会有一个 标识叫做块柄(chunk handle)GFS 主(mast er)维护文件系统的元数据(met adat a)，包括名字空间(namespace， 也就是常规文件系统的中的文件树)，访问控制信息，每个文件有哪些chunk构成，chunk 存储在哪个chunkserver上，也就是位置(locat ion)。在这样的架构下，文件的读写基本过程简化、抽象成如下的过程:写流程1.client 向mast er发送creat e请求，请求包含文件路径和文件名。mast er根据文件路径和文件 名，在名字空间里创建一个对象代表这个文件。2.client 向3个chunkserver发送要写入到文件中的数据，每个chunkserver收到数据后，将数据 写入到本地的文件系统中，写入成功后，发请求给mast er告知mast er一个chunk写入成功， 与此同时告知client 写入成功。3.mast er收到chunkserver写入成功后，记录这个chunk与机器之间的对应关系，也就是chunk 的位置。4.client 确认3个chunkserver都写成功后，本次写入成功。这个写流程是一个高度简化抽象的流程，实际的写流程是一个非常复杂的流程，要考虑到写入 类型(即，是随机写还是尾部追加)，还要考虑并发写入，后面我们继续详细的描述写流程， 解释GFS是如何处理不同的写入类型和并发写入的。读流程1.应用发起读操作，指定文件路径，偏移量(off set )2.client 根据固定的chunk大小(也即64MB)，计算出数据在第几个chunk上，也就是chunk索 引号(index)3.client 向mast er发送一个请求，包括文件名和索引号，mast er返回3个副本在哪3台机器上， 也就是副本位置(location of replica)。4.client 向其中一个副本的机器发送请求，请求包换块柄和字节的读取范围。?5.chunkserver根据块柄和读取范围从本地的文件系统读取数据返回给client这个读流程未做太多的简化和抽象，但实际的读流程还会做一些优化，这些优化和本文主题关 系不大就不展开了。
阿里云网络增强型云服务器计算型、通用型和内存型有什么区别？
?
阿里云服务器计算型、通用型和内存型之间的区别
阿里云网络增强型云服务器计算型、通用型和内存型网络增强型云服务器的详细区别可以对比：ECS云服务器实例规格族官方详解 - 阿里云，官方有详细的对比说明：
相同之处CPU处理器：2.5 GHz主频的Intel Xeon E5-2682 v4（Broadwell）或Platinum 8163（Skylake），计算性能稳定无论是计算型、通用型还是内存型网络增强云服务器，都是使用相同的CPU型号；都具有超高网络PPS收发包能力；都具有网络延迟低的特性。
不同之处计算型、通用型和内存型之间的区别主要在于CPU和内存之间的配比，顾名思义计算型更倾向于CPU，通用型是CPU和内存之间的平衡，内存型更侧重于内存，三者的CPU和内存之间的配比参考下方：网络增强型云服务器
计算型
通用型
内存型
CPU和内存比
1:2
1:4
1:8
规格代码
sn1ne
sn2ne
se1ne
适用场景
高网络包收发场景，如视频弹幕、电信业务转发等Web前端服务器大型多人在线游戏（MMO）前端数据分析、批量计算、视频编码高性能科学和工程应用
高网络包收发场景，如视频弹幕、电信业务转发等各种类型和规模的企业级应用中小型数据库系统、缓存、搜索集群数据分析和计算计算集群、依赖内存的数据处理
高网络包收发场景，如视频弹幕、电信业务转发等高性能数据库、内存数据库数据分析与挖掘、分布式内存缓存Hadoop、Spark群集以及其他企业大内存需求应用
综上，计算型、通用型和内存型网络增强型云服务器都是使用同种规格的CPU型号，都具有超低的网络延迟和高性能的网络收发包能力；区别在于三者之间的CPU和内存比，计算型CPU和内存比为1:2，通用型CPU和内存比为1:4，内存型CPU和内存比为1:8，三者的适用场景也不同。详细参考：ECS实例规格族 - 阿里云，阿里云ECS实例根据不同的使用场景分为多种实例规格，用户按照实际使用场景选择。
?
?
一文快速了解ClickHouse 战斗民族的开源搜索引擎（超详细解读+快速入门）
@[toc]引言?大家好,我是ChinaManor,直译过来就是中国码农的意思,俺希望自己能成为国家复兴道路的铺路人,大数据领域的耕耘者,一个平凡而不平庸的人。一文快速搞懂系列讲究快速入门掌握一个新的大数据组件,帮助新手了解大数据技术,以下是系列文章:文章传送门:[一文快速搞懂Kudu到底是什么](https://blog.csdn.net/xianyu120/article/details/117261771)一文快速了解Elastic Search 开源搜索引擎（技术选型+启动命令）[一文快速搞懂系列__一文快速搞懂SuperSet[实战案例]](https://blog.csdn.net/xianyu120/article/details/117882205)这是一文快速搞懂系列的第三篇:一文快速了解ClickHouse 战斗民族的开源搜索引擎（超详细解读+快速入门）1.技术选型__弱水三千只取一瓢饮目前市面上主流的开源OLAP引擎包含不限于：Hive、Presto、Kylin、Impala、SparkSQL、Druid、Clickhouse、Greeplum等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。总结：上面给出了常用的一些OLAP引擎，各自有各自的特点，将其分组：Hive，Impala - 基于SQL on Hadoop； Presto和Spark SQL类似 - 基于内存解析SQL生成执行计划；Kylin - 用空间换时间，预计算； Druid - 一个支持数据的实时摄入； ClickHouse - OLAP领域的HBase，单表查询性能优势巨大； Greenpulm - OLAP领域的PostgreSQL；2. ClickHouse 的保姆级入 门ClickHouse是一个面向列的数据库管理系统（DBMS），用于在线分析处理查询（OLAP）。 ClickHouse官网：https://clickhouse.tech/ClickHouse中文社区：http://www.clickhouse.com.cn/2.1ClickHouse 概 述1.ClickHouse是俄罗斯的Yandex于2016年开源的面向OLAP列式数据库管理系统（DBMS）2.ClickHouse采用 C++ 语言开发，以卓越的查询性能著称，在基准测试中超过了目前很多主流的列式数据库3.ClickHouse集群的每台服务器每秒能处理数亿到十亿多行和数十千兆字节的数据4.ClickHouse会充分利用所有可用的硬件，以尽可能快地处理每个查询 5．单个查询（解压缩后，仅使用的列）的峰值处理性能超过每秒2TB 6．允许使用类SQL查询实时生成分析数据报告，具有速度快、线性可扩展、硬件高效、容错、功能丰富、高度可靠、简单易用和支持跨数据中心部署等特性，号称在内存数据库领域是最快的7.ClickHouse提供了丰富的数据类型、数据库引擎和表引擎，它所存储的表类似于关系型数据库中的表，默认情况下使用结构化方式在节点本地存储表的数据，同时支持多种数据压缩方式8.ClickHouse独立于Hadoop生态系统，不依赖Hadoop的HDFS，但可以扩展HDFS进行数据查询，ClickHouse还支持查询Kafka和MySQL中的数据9.ClickHouse目前已经在很多大型企业中得到了充分的生产验证，其在存储PB级别的数据规模时仍能很好的提供稳健的实时OLAP服务。简单的说ClickHouse作为分析型数据库，三大特点：一是跑分快， 二是功能多 ，三是文艺范。2.1.1ClickHouse 发展历程2.1.2ClickHouse 特 性真正面向列的DBMS、支持压缩 支持普通硬盘存储、支持多核并行处理支持SQL、支持矢量引擎、支持实时数据更新支持索引、支持在线查询 支持近似计算、支持数据辅助和数据完整性2.1.3ClickHouse 优 势高性能、线性可扩展、硬件高效容错、高度可靠、简单易用ClickHouse存储数据是面向列进行存储，类似ORC和Parquet及Kudu数据库存储数据方式。与行存将每一行的数据连续存储不同，列存将每一列的数据连续存储。针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。由于I/O的降低，这将帮助更多的数据被系统缓存。例如，查询?统计每个广告平台的记录数量?需要读取?广告平台ID?这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。2.1.4ClickHouse 劣 势缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据；没有完整的事务支持不支持二级索引有限的SQL支持，join实现与众不同不支持窗口功能元数据管理需要人工干预维护2.1.5ClickHouse 基准测试2.2ClickHouse 应用场景绝大多数请求都是用于读访问的，数据只是添加到数据库，没有必要修改数据需要以大批量（大于1000行）进行更新，而不是单行更新；或者根本没有更新操作读取数据时，会从数据库中提取出大量的行，但只用到一小部分列表很“宽”，即表中包含大量的列查询频率相对较低（通常每台服务器每秒查询数百次或更少）对于简单查询，允许大约50毫秒的延迟列的值是比较小的数值和短字符串（例如，每个URL只有60个字节）在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）不需要事务，数据一致性要求较低每次查询中只会查询一个大表。除了一个大表，其余都是小表查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存大小2.3ClickHouse 使用案例ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用。 电信行业用于存储数据和统计数据使用我国的中国电信G网数据分析应用采用ClickHouse作为数据存储引擎，主要存储网络基站设备数据、监控设备和骨干网等数据，这些数据日的增量500亿条左右，约700GB。并进行相应的分析处理，最终提供BI应用、数据挖掘等系统使用。 新浪微博用于用户行为数据记录和分析工作新浪微博APP监控系统采用ClickHouse作为数据存储引擎，使用Kafka存储实时产生的消息， Python消费数据存储到ClickHouse中，然后Superset连接ClickHouse作为可视化工作台。同时还使用Hangout消费Kafka的数据到ElasticSearch中，然后使用Kibana进行问题跟踪和问题排查。 RTB网络广告Geniee是日本的一家广告公司，使用ClickHouse作为其RTB实时竞价服务的数据存储引擎。 商业智能今日头条最早使用ClickHouse的是用户行为分析系统。该系统在使用 ClickHouse之前，engine（引擎）层已经有两个迭代。尝试过Spark全内存方案还有一些其他的方案，都存在很多问题。主要因为产品需要比较强的交互能力，页面拖拽的方式能够给分析师展示不同的指标，查询模式比较多变，并且有一些查询的DSL 描述，也不好用现成的SQL去表示，这就需要engine有比较好的定制能力。行为分析系统的表可以打成一个大的宽表形式，join的形式相对少一点。系统的数据量比较大， 因为产品要支持头条所有APP的用户行为分析，包含头条全量和抖音全量数据，用户的上报日志分析，面临不少技术挑战。在使用ClickHouse做一些简单的POC测试工作后，综合来看ClickHouse的性能、功能和产品质量来说效果不错，因为开发ClickHouse的公司使用的场景实际上跟头条用户分析是比较类似的，因此有一定的借鉴意义。目前头条 ClickHouse 集群的规模大概有几千个节点，最大的集群规模可能有1200个节点，这是一个单集群的最大集群节点数。数据总量大概是几十PB，日增数据100TB，落地到ClickHouse的日增数据总量大概是它的3倍，原始数据也就 300T 左右，大多数查询的响应时间是在几秒钟。从交互式的用户体验来说，一般希望把所有的响应控制在 30 秒之内返回，ClickHouse基本上能够满足大部分要求。覆盖的用户场景包括产品分析师做精细化运营，开发人员定位问题，也有少量的广告类客户。2.4ClickHouse 快速入门2.4.1安 装 ClickHouse安装官方文档：https://clickhouse.tech/#quick-startRPM方式安装：https://github.com/Altinity/clickhouse-rpm-install 离线下载安装：https://packagecloud.io/Altinity/clickhouseDocker 容器安装：https://hub.docker.com/r/yandex/clickhouse-server/操作步骤 说明1 安装yum-utils工具包yum install yum-utils -y2 添加ClickHouse的yum源yum-config-manager --add-repo https://repo.yandex.ru/clickhouse/rpm/stable/x86_643 安装ClickHouse的服务端和客户端yum install -y clickhouse-server clickhouse-client如果安装时出现warning: rpmts_HdrFromFdno: Header V4 RSA/SHA1 Signature, keyID e0c56bd4: NOKEY错误导致无法安装，需要在安装命令中添加—nogpgcheck来解决。yum install -y clickhouse-server clickhouse-client --nogpgcheck4 关于安装的说明默认的配置文件路径是：/etc/clickhouse-server/默认的日志文件路径是：/var/log/clickhouse-server/clickhouse的server配置，在/etc/clickhouse-server/config.xml及user.xml，前者是clickhouse 的系统配置，包括日志，服务部署ip，zk等配置。后者是当前节点服务的配置，包括用户名密码， 内存大小限制等。服务配置：config.xml用户配置：users.xml5 启动服务前端服务启动：`clickhouse-server start`后台服务启动：systemctl start clickhouse-server6 查看ClickHouse的版本信息clickhouse-client -m --host node2.itcast.cn --port 9999 --user root --password 123456
select version();
2.4.2命令行 clickhouse-clientClickHouse安装包中提供了clickhouse-client工具，这个客户端在运行shell环境中，使用TCP 方式连接clickhouse-server服务。要运行该客户端工具可以选择使用交互式与非交互式（批量）两种模式：使用非交互式查询时需要指定--query参数；在交互模式下则需要注意是否使用—mutiline参数来开启多行模式。clickhouse-client提供了很多参数可供使用，常用的参数如下表：参数 介绍--host,-h 服务端的 host 名称, 默认是 'localhost'。 您可以选择使用 host 名称或者 IPv4 或IPv6 地址。--port 连接服务端的端口，默认值9000--user,-u 访问的用户名，默认default--password 访问用户的密码，默认空字符串--query,-q 非交互模式下的查询语句--database,-d 连接的数据库，默认是default--multiline,-m 使用多行模式，在多行模式下，回车键仅表示换行。默认不使用多行模式。--multiquery,-n 使用”,”分割的多个查询，仅在非交互模式下有效--format, -f 使用指定格式化输出结果--vertical, -E 使用垂直格式输出，即每个值使用一行显示--time, -t 打印查询时间到stderr中--stacktrace 如果出现异常，会打印堆栈跟踪信息--config-file 使用指定配置文件--use_client_time_zone 使用服务端时区quit,exit 表示退出客户端Ctrl+D,Ctrl+C 表示退出客户端登录命令：clickhouse-client -m --host node2.itcast.cn --port 9999 --user root --password 123456航班数据集：https://yadi.sk/d/pOZxpa42sDdgm2.4.3导入样例数据操作步骤 说明1 编写下载航班数据脚本创建名为 clickhouse-example-data-download.sh 的脚本文件
vim clickhouse-example-data-download.sh
for s in `seq 2017 2020` do
for m in `seq 1 12` do
wget https://transtats.bts.gov/PREZIP/On_Time_Reporting_Carrier_On_Time_Performance_1987_present_${s}_${m}.zip
done
done2 下载航班数据chmod +x clickhouse-example-data-download.sh?./clickhouse-example-data-download.sh3 创建ontime表CREATE TABLE `ontime` (
`Year` UInt16,
`Quarter` UInt8,
`Month` UInt8,
`DayofMonth` UInt8,
`DayOfWeek` UInt8,
`FlightDate` Date,
`UniqueCarrier` FixedString(7),
`AirlineID` Int32,
`Carrier` FixedString(2),
`TailNum` String,
`FlightNum` String,
`OriginAirportID` Int32,
`OriginAirportSeqID` Int32,
`OriginCityMarketID` Int32,
`Origin` FixedString(5),
`OriginCityName` String,
`OriginState` FixedString(2),
`OriginStateFips` String,
`OriginStateName` String,
`OriginWac` Int32,
`DestAirportID` Int32,
`DestAirportSeqID` Int32,
`DestCityMarketID` Int32,
`Dest` FixedString(5),
`DestCityName` String,
`DestState` FixedString(2),
`DestStateFips` String,
`DestStateName` String,
`DestWac` Int32,
`CRSDepTime` Int32,
`DepTime` Int32,
`DepDelay` Int32,
`DepDelayMinutes` Int32,
`DepDel15` Int32,
`DepartureDelayGroups` String,
`DepTimeBlk` String,
`TaxiOut` Int32,
`WheelsOff` Int32,
`WheelsOn` Int32,
`TaxiIn` Int32,
`CRSArrTime` Int32,
`ArrTime` Int32,
`ArrDelay` Int32,
`ArrDelayMinutes` Int32,
`ArrDel15` Int32,
`ArrivalDelayGroups` Int32,
`ArrTimeBlk` String,
`Cancelled` UInt8,
`CancellationCode` FixedString(1),
`Diverted` UInt8,
`CRSElapsedTime` Int32,
`ActualElapsedTime` Int32,
`AirTime` Int32,
`Flights` Int32,
`Distance` Int32,
`DistanceGroup` UInt8,
`CarrierDelay` Int32,
`WeatherDelay` Int32,
`NASDelay` Int32,
`SecurityDelay` Int32,
`LateAircraftDelay` Int32,
`FirstDepTime` String,
`TotalAddGTime` String,
`LongestAddGTime` String,
`DivAirportLandings` String,
`DivReachedDest` String,
`DivActualElapsedTime` String,
`DivArrDelay` String,
`DivDistance` String,
`Div1Airport` String,
`Div1AirportID` Int32,
`Div1AirportSeqID` Int32,
`Div1WheelsOn` String,
`Div1TotalGTime` String,
`Div1LongestGTime` String,
`Div1WheelsOff` String,
`Div1TailNum` String,
`Div2Airport` String,
`Div2AirportID` Int32,
`Div2AirportSeqID` Int32,
`Div2WheelsOn` String,
`Div2TotalGTime` String,
`Div2LongestGTime` String,
`Div2WheelsOff` String,
`Div2TailNum` String,
`Div3Airport` String,
`Div3AirportID` Int32,
`Div3AirportSeqID` Int32,
`Div3WheelsOn` String,
`Div3TotalGTime` String,
`Div3LongestGTime` String,
`Div3WheelsOff` String,
`Div3TailNum` String,
`Div4Airport` String,
`Div4AirportID` Int32,
`Div4AirportSeqID` Int32,
`Div4WheelsOn` String,
`Div4TotalGTime` String,
`Div4LongestGTime` String,
`Div4WheelsOff` String,
`Div4TailNum` String,
`Div5Airport` String,
`Div5AirportID` Int32,
`Div5AirportSeqID` Int32,
`Div5WheelsOn` String,
`Div5TotalGTime` String,
`Div5LongestGTime` String,
`Div5WheelsOff` String,
`Div5TailNum` String
) ENGINE = MergeTree(FlightDate, (Year, FlightDate), 8192)4 导入数据创建名为 import.sh 的脚本文件
vim import.shfor i in *.zip; do echo $i; unzip -cq $i '*.csv' | sed 's/\.00//g' | clickhouse-client
--host=node2.itcast.cn --port 9999
--user root
--password 123456
--query="INSERT INTO db_ontime.ontime FORMAT CSVWithNames"; done chmod +x import.sh ./import.sh2.4.4简单查询查询总条数select count(1) from ontime;查询从2017年到2020年每天的航班数SELECT DayOfWeek, count(1) AS c FROM ontime WHERE Year>=2017 AND Year<=2020 GROUP BY DayOfWeek ORDER BY c DESC;查询从2017年到2020年每周延误超过10分钟的航班数。SELECT DayOfWeek, count(1) AS c FROM ontime WHERE Year>=2017 AND Year<=2020 GROUP BY DayOfWeek ORDER BY c DESC;总结 以上便是ClickHouse快速入门篇，愿你读过之后有自己的收获,如果有收获不妨一键三连一下~
阿里巴巴数据库分库分表的实践（3）
此时就出现了我们所说的全表扫描。此时我们来解释一下这里“事务边界”的定义，所谓的事务边界即是指单个SQL语句在后端数据库上同时执行的数量，上面示例中就是事务边界大的典型示例，即一条SQL语句同时被推送到后端所有数据库中运行。事务边界的数量越大，会给系统带来以下弊端：系统的锁冲突概率越高。如果事务边界大的SQL请求比较多，在一次SQL请求处理过程中自然对于后端的数据库操作的数据库记录覆盖比较广，当有多个类似的SQL请求并行执行时，则出现数据锁造成的资源访问互斥的概率会大大增加。系统越难以扩展。如果有大量的SQL请求都是这样全表扫描，或者从极端角度说明这个问题，如果每一次的SQL请求都需要全表扫描执行，你会发现整个平台的数据库连接数量是取决于后端单个数据库的连接能力，也就意味着整个数据库的能力是无法通过增加后端数据库实例来扩展的。所以如果有大量的全表扫描的SQL请求对于系统的扩展能力会带来不小的影响。整体性能越低。对于性能，这里想强调的是对系统整体性能的影响，而不是单次SQL的性能。应用发送获取买家test1订单列表SQL的请求（如图5-8步骤①）时，分布式数据层会并行的将这条SQL语句推送（如图5-8步骤②）到后端8台数据库上运行，因为订单数据进行了平均的拆分，单个数据库订单表的数据量大小都使得数据库处于最佳性能表现的状态，所以意味着每一个数据库返回的计算结果都是在一个可期望的时间内（比如100毫秒），将结果返回到分布式数据层（如图5-8步骤③），分布式数据层将从各个数据库返回来的结果在内存中进行聚合或排序等操作（如图5-8步骤④），最后返回订单列表给应用（如图5-8步骤⑤）。图5-8DRDS对需全表扫描操作的SQL请求处理流程整个SQL执行的过程包含了5个步骤，仔细看看，你会发现一次带分库分表键执行的SQL过程也会经历这5个步骤，区别只是在②③步骤是并行的方式同时跟多个后端数据库进行交互，但在时间上带来的影响几乎是毫秒级的；而第④个步骤是可能造成差异的一个点，如果像示例中一个用户的订单信息可能最多几千条，对于几千条数据的内存聚合操作，处理时间也是毫秒级的，所以这样一次全表扫描的操作，用户的体验是完全无感知的，跟访问单机数据库的体验是没有差异的。但如果在第④个步骤中确实遇到对大数据量（比如几十万、几百万条数据）的聚合、排序、分组等计算时，则会占用较大的内存和CPU计算资源，如果这样类型的SQL请求比较频繁的话，就会给分布式数据层带来较大的资源占用，从而导致整体分布式服务的处理性能受到影响。很多人对于全表扫描会有一些误解，甚至认为出现全表扫描对于系统来说是完全不能接受的。其实全表扫描在真实的业务场景中很难完全避免（也可以做到完全避免，但会带来其他方面的问题，后面会有说明），对于在分布式数据层的内存中进行数据量不大的聚合这类的SQL请求，如果不是高并发同时请求的情况下，比如对订单进行复杂的条件检索，如图5-9所示，就一定需要采用全表扫描的方式，将查询语句同时推送到后端的数据库中才能实现该场景的要求，但因为调用不会特别频繁，而且计算的数据量不会太大，所以整体不会给数据库整体性能带来太大的影响。图5-9 订单搜索是典型的多条件查询场景如果是高并发情况下同时请求的话，为了数据库整体的扩展能力，则要考虑下面描述的异构索引手段来避免这样的情况发生。对于在内存中要进行大数据量聚合操作和计算的SQL请求，如果这类SQL的不是大量并发或频繁调用的话，平台本身的性能影响也不会太大，如果这类SQL请求有并发或频繁访问的要求，则要考虑采用其他的平台来满足这一类场景的要求，比如Hadoop这类做大数据量离线分析的产品，如果应用对请求的实时性要求比较高，则可采用如内存数据库或HBase这类平台，这一部分的内容不在本书中讨论。4.异构索引表尽量降低全表扫描频率还是基于订单数据的分库分表场景，按照订单ID取模虽然很好地满足了订单数据均匀地保存在后端数据库中，但在买家查看自己订单的业务场景中，就出现了全表扫描的情况，而且买家查看自己订单的请求是非常频繁的，必然给数据库带来扩展或性能的问题，有违“尽量减少事务边界”这一原则。其实这类场景还有很多，比如卖家要查看与自己店铺相关的订单信息，同样也会出现上述所说的大量进行全表扫描的SQL请求。针对这类场景问题，最常用的是采用“异构索引表”的方式解决，即采用异步机制将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。本质上这是互联网公司很多时候都采用的一个解决思路：“拿空间换时间”。也就是应用在创建或更新一条按照订单ID为分库分表键的订单数据时，也会再保存一份按照买家ID为分库分表键的订单索引数据，如图5-10所示，其结果就是同一买家的所有订单索引表都保存在同一数据库中，这就是给订单创建了异构索引表。图5-10 订单异构索引表
DDD 不够好用，你需要学习如何进行弹性软件系统设计
关键要点 当今的分布式系统环境必须采用弹性软件设计。关键挑战不在于编码，而在于“外围”。做好分布式其实很难，大多数人都严重低估了它的难度。恰当的功能设计是构建健壮的分布式系统的关键，但人们却知之甚少。在公司中引入弹性软件设计的主要挑战是如何建立意识和可持续性。 写这篇文章的起因是我在 2018 年GOTO 柏林大会上所做的演讲，我在演讲中分享了在进行弹性软件设计时会面临哪些挑战。我将简要地介绍弹性软件设计的“why”和“what”，中间部分是我近年来经常遇到的挑战，最后，我添加了一些关于如何在组织中实现弹性软件设计的最佳实践。阅读完本文之后，希望你能够更好地了解弹性软件设计所面临的挑战，并知道如何解决这些问题。 弹性软件设计（Resilient Software Design，简称 RSD）是一个无法用一两句话解释清楚的概念——有时候很难向习惯于“电梯游说”（在很短时间内说清楚一个问题）的人解释这个概念。尽管如此，我仍然试着尽可能简短地解释我所知道的 RSD，一个是“why”，一个是“what”。 让我先从“why”开始。通常，我们试图通过系统来实现某种商业价值：赚钱或者让客户满意。显然，只有当系统在生产环境中看用时，我们才有可能实现这一价值。这一直以来都是这样的。 但是，现在有所不同的是，几乎每个系统都是分布式的。系统之间相互通信，并且系统本身也可能被分成几个部分，而这些部分进一步被拆分，并以此类推。微服务、移动计算和物联网的发展使得协作系统之间的连接变得更加复杂，将这些系统的开发提升到新的水平。 系统及其部件之间相互交互所需的远程通信会引入一些故障模式，这些故障模式只存在于跨进程边界的情况，不会在进程内部出现。如果我们忽略它们的存在，这些故障模式，例如非响应性、等待时间、不完整或无序消息将在应用程序级别上引起所有类型的非预期故障。换句话说，如果你需要一个健壮高可用的系统，就不应该忽略分布式所带来的影响。 这让我想到了 RSD 的“what”：我倾向于将弹性软件设计定义为“在理想情况下，如果发生意外故障（由分布式的非确定性行为造成的），用户根本不会注意到，或者用户至少可以继续使用应用程序已定义范围的部分功能（即服务的优雅降级）”。 请注意定义中的“已定义”一词。这意味着，计划在发生意外情况时该做些什么，这个与你通常在不采用弹性软件设计时遇到的意外系统行为有很大不同。 我的旅程通常从在代码级别设计和实现弹性开始。但随着时间的推移，我意识到，在代码层面实现弹性是最容易的部分，实际的挑战其实是在其他方面。 虽然在事后看来，这并不足为奇（大型项目的问题从来都不是在编码层面），但我不得不承认，我刚开始还是感到有些奇怪。你只有长期接触这个问题，才有可能清楚地了解这些挑战。因此，我在“弹性软件设计的 7 个任务”演讲中分享了我的一些经验，其中每个“任务”代表了我遇到过的一个挑战。以下是从我的演讲中挑选出来的挑战。 了解 RSD 的“业务案例”。作为一名软件工程师，如果你尝试开发新的东西，通常会被问及相关的业务案例是什么。虽然这是一个无可厚非的问题，但如果被应用在 RSD 上，就会导致方向跑偏，因为 RSD 不是为了赚钱，而是为了不损失钱。尽管如此，定义弹性预算仍然是有必要的，你可以看一下如果系统变得不可用会有哪些即时的损失，以及由于累积效应（例如感到厌烦的客户会增加你的流失率）导致的更频繁的不可用性造成的长期损失。通过这种方式，我们可以将 RSD 嵌入到一个理智的经济框架中。了解分布式系统的非确定性行为及其后果。问题是分布式系统不仅难以驾驭，而且难以理解。远程通信为系统行为添加了概率性因素。不幸的是，我们的大脑无法轻易地处理概率性行为。此外，几乎所有的 IT 教育或培训都是以进程内交互为前提，在这些环境中，我们面临的是确定性的行为，导致大多数人对分布式不甚了解。我也不知道有哪些简单的分布式解决方案（我其实认为不存在这样的解决方案）。也许在我们的 IT 教育中添加更多与分布式系统相关的教材可能会有所帮助。数以百计的计算机科学论文已经清楚地告诉我们，进程内的东西一旦变成分布式的，即使再简单也会变得很难，甚至是不可能的。但并不是所有人会去阅读这些资料。然后有些人说，我们应该将远程通信问题留给基础设施去解决，让应用工程师不受干扰。过去的很多分布式框架都遵循了这一理念——事实证明，这只适用于非常小的系统，总体来说并不是可行的解决方案……避免“100％可用”的陷阱。这与上一个挑战有关，但影响范围要小得多。由于典型的确定性思维，人们（无论是 IT 人员还是非 IT 人员）都倾向于假设他们连接的所有系统的可用性都可以达到 100％。你可以在需求、设计和代码方面看到这种隐含的假设。并不是人们有不良意图，也不是他们粗心大意，只是他们忘记了一些东西。在分布式系统中，问题不在于系统是否会发生故障，而是会在什么时候发生故障。可用性始终会小于 1（或者说小于 100％）。因此，我们需要小心 100％可用性的陷阱，并检查我们的要求、设计和代码，避免掉入这个陷阱。建立 OpsDev 反馈闭环。在很多公司，我们仍然看到开发和运维之间存在巨大的屏障，甚至已经触及 C 级人员。造成这种局面有一定的原因，同时也给 RSD 带来了一个大问题。弹性需要在应用程序层面实现，也即在开发中。但是，你只能通过运维来衡量实际的弹性效果。此外，在运维中，你会检测到需要由开发来处理的应用程序缺陷。但是如果你在 Dev 和 Ops 之间有一堵大墙，就会破坏这个重要的反馈闭环。开发人员盲目地实施他们的弹性举措，而运维发现的问题却得不到修复。因此，无论你是使用 DevOps 或 SRE 等既定方法，还是使用自定义的方法，都需要建立反馈闭环。正确的功能设计。如果分布式功能在设计方式上出了问题，那么即使再好的弹性措施也无法帮你构建出健壮的系统。问题出在这里：假设你在服务之间创建了紧密的功能依赖（“强耦合”）。如果被依赖的服务变得不可用，那么所有依赖这个服务的服务也将变得不可用，因为这些服务需要借助被依赖服务的业务逻辑来完成自己的任务。遗憾的是，我们学到的几乎所有与设计系统相关的技术，即如何划分功能，都会导致强耦合，因为它们侧重于进程内设计，而进程内设计的可用性不受这种耦合性的影响。因此，我们需要重新学习分布式系统的功能设计，重点是降低功能耦合——这与进程内的低耦合不同。我将在下一节深入探讨这个主题。了解应该使用哪些模式以及如何合理地组合它们。在你学习完自考新模式后，总想着去用它们。问题是，使用弹性模式是要付出代价的。它们通常会增加实现和运维成本。更重要的是，它们增加了解决方案的复杂性，而复杂性是健壮性的敌人。解决方案越复杂，就越难以理解，意外故障给健壮性带来不利影响的可能性也就越大。因此，关键在于不要使用太多的模式，而是要在弹性和复杂性之间找到一个平衡点。不要因为技术的更新换代每几年就淘汰积累起来的社区知识。这不是 RSD 特有的，它适用于整个 IT 行业。作为一个社区，我们倾向于每隔几年就将集体智慧淘汰，然后从头开始。我们倾向于忽视我们已经知道的东西，然后寻找下一个被炒作起来的银弹，以此来解决我们的问题，而不是像其他工程学科一样建立和维护经过验证的知识体系。同样，这不仅限于 RSD，但我们现在可以观察它们，因为大多数 RSD 概念不是新东西，其中一些已经存在了几十年了。说实话，我也不知道该如何解决这个问题。因此，我能够想到的最好的事情是提醒人们要注意这个问题，并希望如果有足够多的人意识到这一点，最终将成长为一个真正的工程学科。 当然，还有其他更多的挑战，但从我的角度来看，这些是最应该引起我们注意的。 根据我的经验，理解分布式系统以及如何进行好的功能设计是创建健壮应用程序的最大障碍。因此，让我们更深入地探讨这两个主题。 理解分布式故障模式的含义是非常困难的。单进程系统中一些很简单的事情到了分布式系统中有会变得非常困难，甚至是不可能的，而且基础设施无法为应用程序隐藏掉所有这些影响。另一方面，大多数（如果不是全部）大学和大学后的 IT 教育都是基于本地计算。此外，试图掌握分布的非确定性影响对我们的大脑来说并不是一件容易的事。 根据我的经验，IT 领域之外的大多数人几乎不可能真正理解分布式，因为他们把计算机理解为“可以完成人类布置的任务的机器”，教会他们有关分布式计算的概念和所面临的挑战需要很长时间——我们通常没有那么多时间。 但其实对大多数开发人员来说也是非常困难的。开发人员在面对不可用的分布式系统时，他们通常也会不知所措。由于他们的 IT 教育完全忽略了分布式系统，他们甚至会避免处理与分布式有关的问题。这导致在设计和实现系统时忽略了分布式的影响，而这反过来让系统变得既脆弱又慢。 我之前说过，我不知道这个问题有什么简单的解决方案，我其实认为并不存在所谓的简单的解决方案。我能做的就是建议在我们的 IT 教育（大学期间和大学之后）中增加更多有关分布式系统设计的课程，因为我们的系统环境变得越来越分散，我们需要更好地了解设计和编码的实际效果。 另一个巨大的阻碍是功能设计。如果功能传播的方式是错误的，最终只会得到一个脆弱的系统。举个简单的例子：服务 A 接收外部请求，为响应该请求，它需要来自服务 B 的一些信息，这也就是所谓的在服务之间传播功能。如果服务 B 被关闭，服务 A 就无法响应外部请求。 这就是所谓的级联故障。弹性软件设计的主要任务之一是避免级联故障。通常，你可以使用简单的超时检测机制或断路器来检测服务 B 是否已关闭，然后回退使用服务 A 的备份计划。但由于功能在服务之间传播，不可能有备份计划，即断路器只会让级联故障可见，不会提供任何绕过它的方法。 这只是其中的一个例子，类似的情况还有很多。如果你将通常的“设计最佳实践”应用于分布式系统，通常会出现这类问题。在给定的示例中，服务 B 是“可重用服务”。可重用性是单进程的理想属性，但它也会带来非常强的耦合性，在跨进程的环境中表现出非预期的特性。 在过去，如果我们的功能设计出现错误，到最后系统会变得难以维护——这已经够糟糕的了。但是，在分布式系统中，糟糕的功能设计在运行时就会体现出脆弱性、不可靠和性能问题，这个更糟糕。问题是大多数有关如何做出“正确设计”的建议只适用于进程内设计。如果将这些建议应用在分布式系统上，大多数都无法正常工作。 我从过去的经历中学到的是，我们需要重新学习如何设计系统，即如何在分布式环境中传播功能。 然后，大多数人会提到领域驱动设计（或简称“DDD”），但根据我的经验，这也不是灵丹妙药。不要误会我的意思，实际上，DDD 为更好的设计提供了很多非常好的建议。但是当谈到分布式系统的设计时，单靠 DDD 是不够的，它还缺少了一些额外的建议。好的方面是：据我所知，人们正在尝试扩展 DDD 的原始思想，加入分布式系统因素。因此，我对这一领域的未来发展非常期待。 如果你想将 RSD 引入到你自己的公司，你可能会要求制定一个可以达到最佳效果的计划。根据我的经验，并不存在完美的计划。我的建议是实现通用的“意识—能力—可持续性”模式。 首先，了解为什么需要 RSD 以及如何将其传达给不参与软件开发的人员。这涉及理解和接受分布式系统的不可用性（包括避免“100％可用性”陷阱）和弹性软件设计的业务案例。此外，你还需要学习如何在不使用深奥的 IT 知识的情况下将其传达给人们。即使你知道需要通过 RSD 来构建健壮的系统，但却不能与你的经理或你的企业主讨论它，并帮助他们更好地理解这个主题，然后做出正确的决策，那么这一切将无济于事。 获得知识可能是最容易的部分。同时，还可以找到一些有关这个主题的资源和培训——只需要注意与分布式系统或微服务相关的会议的研讨会部分，或者从阅读文末参考部分提供的两本书开始。当然，你需要在工作中应用它们。再强调一下，做出正确的功能设计是一项艰巨的任务，但弹性模式本身相对容易学习和应用。 要建立可持续性，首先需要一个有效的 OpsDev 反馈循环。如果没有这种循环，任何弹性倡议都将注定失败，因为你的弹性度量在实践中缺少了反馈。 此外，你可能希望建立混沌工程计划。混沌工程不仅有助于揭示系统缺陷，它还通过持续、可控的学习（了解系统的健壮性并进一步提高系统健壮性）帮你实现可持续的弹性。 “混沌工程”这个词有点容易被误解，它不是为了制造混乱，而是为了避免混乱。在混沌工程中，你可以设计受控的实验，以便更好地了解系统的实际健壮性以及需要做出哪些额外的弹性措施。混沌工程师总是小心翼翼地控制实验潜在的影响范围，并在执行实验之前与所有受影响的人进行沟通。 它从一个假设开始，例如“如果我们切断与此服务器的连接，将发生自动故障转移，最终用户不会察觉到任何差异”。然后，与受影响的开发人员和运营人员讨论该假设。假设是有效的吗？我们怎么测试它呢？我们如何衡量正确性？如果我们错了，怎样才能以安全的方式停止实验？ 在讨论和定义好所有内容之后，就可以进行实验。根据试验结果，可能需要定义（RSD）度量。除了帮你找出应用程序中之前未被发现的问题之外，混沌工程也会显著提高你对系统的信心——这是一种很好的感觉。 总的来说，在今天的分布式系统环境中，RSD 是一个必选项。虽然学习如何设计和实现弹性模式相对容易，但 RSD 所面临的实际挑战通常不在于编码方面。 分布式系统本身的复杂性和分布式系统的功能设计让实现可持续的弹性变得更加困难。同时，Ops 和 Dev 之间缺少反馈循环、过于复杂的弹性设计，或者缺乏对 RSD 业务案例的理解，等等，通常都会带来阻碍。不过，了解挑战是成功掌握它们的第一步…… 参考 “Release It！”第 2 版，作者 Michael T. Nygard，Pragmatic Bookshelf 于 2018 年出版“Patterns for Fault Tolerant Software”，作者 Robert S. Hanmer，Wiley 于 2007 年出版
征文投稿丨使用轻量应用服务器部署Hadoop云集群
编者按：本文来自轻量应用服务器征文活动用户投稿，已获得作者（昵称Maynor大数据）授权发布。由于我在工作学习中经常需要使用到Hadoop集群，而本地Hadoop有启动速度慢、操作麻烦和占用内存等痛点。最近在和粉丝的交流中，一位提到的伪分布式部署Hadoop的概念启发了我。正好领取的服务器还没开始用，何不用来部署云集群？以下为具体的部署过程，我选择的是Hadoop3.x的伪分布式部署方法。1、领取轻量应用服务器阿里云的产品活动还是很给力的，遇到像双11这样的大促活动，甚至可以做到免费获得服务器。如果你是学生，买轻量应用服务器还是很便宜的，只需要9元/月， 也可以参与阿里云开发者成长计划。2、服务器选择和配置这里选择的是轻量应用服务器，系统镜像和应用镜像不需要改变，保持默认值就行（WordPress, CentOS 7.3）。这里需要设置root权限和密码设置成功后通过本地terminal（MAC）或者cmd（Windows）来构建ssh：ssh root@****然后输入之前设置的root的权限密码（注意：这里的密码是不会有任何显示的）若出现上图的情况，需要清理一下之前的key：ssh-keygen -R XX.XX.XX.XX然后再次用ssh连接，然后yes，到此我们进入到了阿里云的服务器。3、配置java环境首先下载java的jdk：wget https://download.java.net/openjdk/jdk8u41/ri/openjdk-8u41-b04-linux-x64-14_jan_2020.tar.gz然后解压：tar -zxvf openjdk-8u41-b04-linux-x64-14_jan_2020.tar.gz移动位置并且配置java路径：mv java-se-8u41-ri/ /usr/java8
echo 'export JAVA_HOME=/usr/java8' >> /etc/profile
echo 'export PATH=$PATH:$JAVA_HOME/bin' >> /etc/profile
source /etc/profile检查是否安装成功：java -version若安装成功会出现如下结果：4、进行Hadoop的安装这个是清华的镜像源，国内的小伙伴下载比较快：# 借助清华源下载Hadoop
wget https://mirrors.tuna.tsinghua.edu.cn/apache/hadoop/common/hadoop-3.2.2/hadoop-3.2.2.tar.gz按照惯例解压：tar -zxvf hadoop-3.2.2.tar.gz -C /opt/
mv /opt/hadoop-3.2.2 /opt/hadoop配置地址：echo 'export HADOOP_HOME=/opt/hadoop/' >> /etc/profile
echo 'export PATH=$PATH:$HADOOP_HOME/bin' >> /etc/profile
echo 'export PATH=$PATH:$HADOOP_HOME/sbin' >> /etc/profile
source /etc/profile配置yarn和hadoop：echo "export JAVA_HOME=/usr/java8" >> /opt/hadoop/etc/hadoop/yarn-env.sh
echo "export JAVA_HOME=/usr/java8" >> /opt/hadoop/etc/hadoop/hadoop-env.sh查看Hadoop 安装情况：hadoop version若出现下图情况，则说明安装成功。5、利用vim来操作core-site 和 hdfs-site输入以下命令：vim /opt/hadoop/etc/hadoop/core-site.xml进入vim环境，如下图示：按下i（insert）修改光标移动至configuration之间，复制如下的信息：<property>
<name>hadoop.tmp.dir</name>
<value>file:/opt/hadoop/tmp</value>
<description>location to store temporary files</description>
</property>
<property>
<name>fs.defaultFS</name>
<value>hdfs://localhost:9000</value>
</property>然后按下esc，停止修改，然后打":wq"（实际无“”）退出vim修改。同理，操作hdfs-site输入命令行：vim /opt/hadoop/etc/hadoop/hdfs-site.xml移动光标，复制以下信息：<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:/opt/hadoop/tmp/dfs/name</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:/opt/hadoop/tmp/dfs/data</value>
</property>配置master和slave连接，运行如下指令，并且一直回车，直至出现如下图：ssh-keygen -t rsa运行如下代码：cd .ssh
cat id_rsa.pub >> authorized_keys启动Hadoop：hadoop namenode -format
start-dfs.sh
start-yarn.sh踩坑提醒：ERROR: but there is no YARN_NODEMANAGER_USER defined. Aborting operation这里踩了一个小坑，出现如上面的错误提示，解决方案参考：https://blog.csdn.net/ystyaoshengting/article/details/103026872查看是否配置成功：jps配置成功图如下：6、配置防火墙端口接下来需要开启你在阿里云的防火墙端口，才可以在浏览器上访问，否则你怎么弄都是访问不到。最后你就可以在浏览器输入XX.XX.XX.XX：9870 或者XX.XX.XX.XX:8088来在浏览器上访问你的Hadoop，效果图如下：以上就是使用Hadoop3.x的伪分布式部署方法，利用轻量应用服务器部署云集群的全过程，希望对你有所帮助。点击我要投稿，查看全新升级的轻量应用服务器征文活动，奖励提升，每月都可以投稿。
