Apache Spark

1、前言 项目有个需求，需要把一些没用影响业务逻辑的http请求改成异步请求，httpclient在4.0后提供新的api CloseableHttpAsyncClient可以使用，记录下使用过程。 2、网络调用类型 （1）传统BIO（Blocking IO） 同步阻塞式IO，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。 （2）NIO(Not-Blocking IO) NIO：同步非阻塞式IO，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。 (3)AIO(NIO.2) 异步非阻塞式IO，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理。 3、CloseableHttpAsyncClient CloseableHttpAsyncClient是apache在4.0后提供AIO操作的api，基本使用如下 1）pom.xml引用如下 <dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId>

RDD vs DataFrames vs DataSet 在SparkSQL中Spark为我们提供了两个新的抽象，分别是DataFrame和DataSet。他们和RDD有什么区别呢？首先从版本的产生上来看： RDD (Spark1.0) —> Dataframe(Spark1.3) —> Dataset(Spark1.6) 如果同样的数据都给到这三个数据结构，他们分别计算之后，都会给出相同的结果。不同是的他们的执行效率和执行方式。 在后期的Spark版本中，DataSet会逐步取代RDD和DataFrame成为唯一的API接口。 RDD RDD是一个懒执行的不可变的可以支持Lambda表达式的并行数据集合。 RDD的最大好处就是简单，API的人性化程度很高。 RDD的劣势是性能限制，它是一个JVM驻内存对象，这也就决定了存在GC的限制和数据增加时Java序列化成本的升高。 Dataframe 与RDD类似，DataFrame也是一个分布式数据容器。然而DataFrame更像传统数据库的二维表格，除了数据以外，还记录数据的结构信息，即schema。同时，与Hive类似，DataFrame也支持嵌套数据类型（struct、array和map）。从API易用性的角度上看，DataFrame API提供的是一套高层的关系操作，比函数式的RDD API要更加友好，门槛更低

本文转载自公众号“读芯术”(ID：AI_Discovery)。 机器学习(ML)被称为技术债务的高利率信用卡。对于特定的业务问题，使用适用的模型会相对容易一些，但是要使该模型在可伸缩的生产环境中运行，并能够处理不断变化的混乱数据语义和关系，以及以可靠的自动化方式演进模式，则完全是另一回事。 对于机器学习生产系统而言，只有5%的实际代码是模型本身。将一组机器学习解决方案转变为端到端的机器学习平台的，是一种运用了加速建模、自动化部署和确保生产中的可伸缩性和可靠性的技术的架构。 笔者此前讲过lean D/MLOps，数据和机器学习操作，因为没有数据的机器学习操作是没有意义的，所以端到端机器学习平台需要进行整体构建。CI/CD基金会启动了一个MLOps特别兴趣小组(SIG)。其端到端机器学习平台确定的步骤如下图所示： 不过，其中掩盖了一些不太重要的细节。例如，服务可能需要不同的技术取决于它是否是实时完成的。可伸缩的解决方案通常将模型放在一个负载均衡器后的服务集群的多个机器上的容器内运行。因此，上述图表中的单个框并不意味着实际平台的单个步骤、容器或组件。 这并不是对图中步骤进行批评，而是一个警示：看似简单的事情在实践中可能并不那么容易。 图表中没有模型(配置)管理。可以考虑诸如版本控制、实验管理、运行时统计、用于培训、测试和验证数据集的数据沿袭跟踪，从头开始或从模型快照、超参数值

1. 迁移背景介绍 目前我们的图数据库数据量为 顶点 20 亿，边 200 亿的规模。在迁移之前我们使用的 AgensGraph 数据库 一个主库四个备库，机器的配置都比较高，256G 内存 SSD 的磁盘，单机数据量为 3T左右。 在数据量比较小的情况下 AgensGraph 表现非常稳定优异，我们之前一主一备的情况下支撑了很长一段时间。 但随着公司业务的急速发展，图越来越大，占用的磁盘越来越多，对应的查询量也越来越大，随之这种方案的问题就暴露出来了 单机的磁盘空间不够，按理说可以一直添加磁盘，但现实情况有很多限制 AgensGraph 不是分布式结构，每次查询都需要单机处理，单台机器的处理能力总是有上限的，导致查询耗时增加 随着查询量的增加，机器磁盘，网络 IO 出现瓶颈。按理说可以通过增加备库来解决，但备库要求高导致成本增高，并且数据冗余严重 由于上面的原因导致 AgensGraph 没办法继续支撑业务高速发展带来的性能要求。AgensGraph 底层基于 PostgreSQL 数据库使它在小数据量的情况下非常的稳定并且查询响应非常的迅速，在此感谢 AgensGraph 陪我们度过业务快速成长阶段。 为了寻找新的图数据库我们把目光投向了接受度和知名度都比较高的 JanusGraph。当然还有收费的图数据库 TigerGraph，暂时不做考虑 在此贴一张我们图的应用场景

前言 本文致力于从架构原理、集群部署、性能优化与使用技巧等方面，阐述在如何基于HBase构建容纳大规模数据、支撑高并发、毫秒响应、稳定高效的OLTP实时系统 。 一、架构原理 1.1 基本架构 从上层往下可以看到HBase架构中的角色分配为： Client——>Zookeeper——>HMaster——>RegionServer——>HDFS Client Client是执行查询、写入等对HBase表数据进行增删改查的 使用方 ，可以是使用HBase Client API编写的程序， 也可以是其他开发好的HBase客户端应用。 Zookeeper Zookeeper同HDFS一样， HBase使用Zookeeper作为集群协调与管理系统 。 在HBase中其主要的功能与职责为： 存储整个集群 HMaster 与 RegionServer 的运行状态 实现 HMaster的故障恢复 与 自动切换 为Client提供 元数据表 的 存储信息 HMaster、RegionServer启动之后，将会在Zookeeper上注册并创建节点（ /hbasae/master 与 /hbase/rs/* ），同时 Zookeeper 通过 Heartbeat的心跳机制 来 维护与监控节点状态 ，一旦节点 丢失心跳 ，则认为 该节点宕机 或者下线，将 清除该 节点 在Zookeeper中的注册信息。

数据只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。面对海量的数据和复杂的计算，阿里巴巴的数据计算层包括两大体系： 数据存储及计算平台（离线计算平台MaxCompute和实时计算平台StreamCompute）、数据整合及管理体系（OneData） 。 阿里数据研发岗位的工作大致可以概括为： 了解需求→模型设计→ETL开发→测试→发布上线→日常运维→任务下线 。与传统的数据仓库开发（ETL）相比，阿里数据研发有如下几个特点： 业务变更频繁——业务发展非常快，业务需求多且变更频繁； 需要快速交付——业务驱动，需要快速给出结果； 频繁发布上线——迭代周期以天为单位，每天需要发布数次； 运维任务多——在集团公共层平均每个开发人员负责上百多个任务； 系统环境复杂——阿里平台系统多为自研，且为了保证业务的发展，平台系统的迭代速度较快，平台的稳定性压力较大。 通过统一的计算平台（MaxCompute）、统一的开发平台、统一的数据模型规范和统一的数据研发规范，可以在一定程度上解决数据研发的痛点。 本文主要介绍MaxCompute和阿里巴巴内部基于MaxCompute的大数据开发套件，并对在数据开发过程中经常遇到的问题和相关解决方案进行介绍。 1、统一计算平台

Spark缓存 之 Collect Cache Persist 三者都有汇聚数据，拉取数据存储的作用，mark一下各自的作用。 Collect: /** * Return an array that contains all of the elements in this RDD. * * @note This method should only be used if the resulting array is expected to be small, as * all the data is loaded into the driver's memory. */ def collect(): Array[T] = withScope { val results = sc.runJob(this, (iter: Iterator[T]) => iter.toArray) Array.concat(results: _*) } collect操作将RDD中所有元素转换为Array，一般多用于本地local模式下测试输出使用；集群模式下不推荐使用，正如源码所说，collect操作应该用于数组预期比较小的情况，因为这里数据会加载到dirver端内存中，本地测试时影响不大，但是集群模式下，如果dirver端内存申请太小就很容易oom。 Cache: /** * Persist

框架 Apache Hadoop：分布式处理架构，结合了 MapReduce(并行处理)、YARN(作业调度)和HDFS(分布式文件系统); Tigon：高吞吐量实时流处理框架。 分布式编程 AddThis Hydra ：最初在AddThis上开发的分布式数据处理和存储系统; AMPLab SIMR：用在Hadoop MapReduce v1上运行Spark; Apache Beam：为统一的模型以及一套用于定义和执行数据处理工作流的特定SDK语言; Apache Crunch：一个简单的Java API，用于执行在普通的MapReduce实现时比较单调的连接、数据聚合等任务; Apache DataFu：由LinkedIn开发的针对Hadoop and 和Pig的用户定义的函数集合; Apache Flink：具有高性能的执行时间和自动程序优化; Apache Gora：内存中的数据模型和持久性框架; Apache Hama：BSP(整体同步并行)计算框架; Apache MapReduce ：在集群上使用并行、分布式算法处理大数据集的编程模型; Apache Pig ：Hadoop中，用于处理数据分析程序的高级查询语言; Apache REEF ：用来简化和统一低层大数据系统的保留性评估执行框架; Apache S4 ：S4中流处理与实现的框架; Apache Spark

数据湖分析Data Lake Analytics是阿里云数据库自研的云原生数据湖分析系统，目前已有数千企业在使用，是阿里云 库、仓、湖战略高地之一 !!! 现紧急 招聘 【 数据湖平台工程师】 产品链接：https://www.aliyun.com/product/datalakeanalytics !!! 如果想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共帐号： iteblog_hadoop 团队内部拥有多位Apache PMC&Committer，在国内外拥有良好的影响力，加入后您将与国内最顶尖的大数据、数据库领域专家一起工作，打造世界一流的数据湖分析服务能力!!! 业界趋势 ：数据湖是比大数据关注更多的词汇，未来5年数据湖同比以50%在高速发展。在全球多家云厂商，阿里云 数据湖分析 Data Lake Analytics 处于领先地位 !!! 岗位职责 负责产品云化，打造Serverless弹性多租户平台能力 负责平台的资源调度、高并发连接、多租户管理、安全、计量、被集成 等研发 负责商业化输出研发，包括公有云、集团、专有云、混合云等多种形态 生产问题的定位解决，系统性能的调优改进，业务需求的分析落地。 工作地可以open to 杭州， 深圳，北京 职位要求 熟悉JAVA，较好的架构意识、性能意识、清晰的代码能力 有平台相关经验

　　说起陶瓷，人们第一时间想到的可能就是景德镇。中国是世界上最早制成陶器与瓷器的国家之一，不仅起步早，生产规模与造型工艺等也都一直领先于世界，长期备受赞誉。而 “China” 既是在称呼中国，也代表着瓷器。 　　可以说陶瓷的发明，是人类原始社会跨入到新石器时代的一个重要标志，而中国陶瓷的生产距今已有近一万两千年的悠久历史。人们所俗称的“五大名窑”——官窑、汝窑、哥窑、定窑和钧窑，指的便是人们在一个特别搭建的建筑中通过生火加热，将粘土烧制成型的过程；烧制的温度、材料、手法等不同，则会带来不同样式效果的瓷器。 　　所以在某种意义上，陶瓷的制备是一种 “火” 的艺术。 　　随着科技与工艺的不断发展，陶瓷已不再局限于人们通常认知的生活器皿，而是得到了广泛应用。其在结构设计、电子通信、生物医疗等领域有着重要作用，尤其在固态电池和燃料电池领域的应用前景更为可观。不过，因为传统工艺在 “火力” 上的限制，烧制时间通常要数十小时，这让研究人员无法对原材料、特征性能等进行快速检测与迭代。 　　但近日， 美国马里兰大学胡良兵教授的研究团队克服了传统烧结工艺的制约，发明出一种超快速的陶瓷高温烧结工艺 （ultrafast high-temperature sintering，UHS），将这项有着上万年历史的工艺时间缩短为 10 余秒，这既满足现代陶瓷的需求，又能推动新材料的创新发现。该研究登上了 5