Apache Spark

简介： Jindo 是阿里云基于 Apache Spark / Apache Hadoop 在云上定制的分布式计算和存储引擎 为什么要构建数据湖 大数据时代早期，Apache HDFS 是构建具有海量存储能力数据仓库的首选方案。随着云计算、大数据、AI 等技术的发展，所有云厂商都在不断完善自家的对象存储，来更好地适配 Apache Hadoop/Spark 大数据以及各种 AI 生态。由于对象存储有海量、安全、低成本、高可靠、易集成等优势，各种 IoT 设备、网站数据都把各种形式的原始文件存储在对象存储上，利用对象存储增强和拓展大数据 AI 也成为了业界共识，Apache Hadoop 社区也推出了原生的对象存储“Ozone”。从 HDFS 到对象存储，从数据仓库到数据湖，把所有的数据都放在一个统一的存储中，也可以更加高效地进行分析和处理。 对于云上的客户来说，如何构建自己的数据湖，早期的技术选型非常重要，随着数据量的不断增加，后续进行架构升级和数据迁移的成本也会增加。在云上使用 HDFS 构建大规模存储系统，已经暴露出来不少问题。HDFS 是 Hadoop 原生的存储系统，经过 10 年来的发展，HDFS 已经成为大数据生态的存储标准，但我们也看到 HDFS 虽然不断优化，但是 NameNode 单点瓶颈，JVM 瓶颈仍然影响着集群的扩展，从 1 PB到 100+ PB

欢迎关注我的公众号: 『诗品算法』 禁止一切未经本人 @ 琦琦许可的转载 一、楔子 害，写个这么严肃的技术话题还需要楔子么？这不是让大家放松一下嘛！毕竟是我的处女作，还是要来个看似一本正经的开场白和自我介绍的。 大家好，我是混迹于奋斗X之都——杭州的互联网大龄脱发女程序员一枚，大家可以关注我的公众号： “诗品算法” 。我会尽量保持每个月甚至每周更新一次的频率，在此立证（更新慢你也不能打我，只能用唾沫星子淹死我了哈哈）。 下面进入正题，带你领略蘑菇街有（坎）趣（坷）的从0到1的增量学习历程。 二、背景 在online deep learning炒得尤其火热的今天，我们知道，实时性就是互联网的生命和活力所在。笔者前几天跟一个阿里的朋友吃饭，朋友说，ODL现在是他们组最容易出成果的方向，众人愕然，ODL？哪篇论文里的？随即一拍大腿，原来是deep online learning。。。 试想，如果你刷抖音时，平台捕获到了你最近偏好旅行的即时兴趣，随即在很短时间内给你推荐了旅行相关的内容，你是不是会持续嗑药般地滑动下去？从而产生了心理学中所谓的无限“心流”，但我并不推崇这种类似沉迷游戏般的"心流"，这种带有引号的“心流”仅仅是感官的愉悦，与精神的满足与自我的成就感无关，与至高的纯粹的甘美的快乐无关，与灵魂真正的安宁与幸福更是无关，因这并不会让你获得实质性的进步。扯远了

当今时代，企业数据越发膨胀。数据是企业的价值，但数据处理也是一种技术挑战。在海量数据处理的场景，即使单机计算能力再强，也无法满足日益增长的数据处理需求。所以，分布式才是解决该类问题的根本解决方案。而在分布式领域，有两类典型产品，分别是分布式存储和分布式计算。用户只有将两者的特性充分利用，才可以真正发挥分布式架构的存储和计算能力。 本文介绍 SequoiaDB（分布式存储）和 Spark（分布式计算）两款产品的对接使用，以及在海量数据场景下如何提高统计分析性能。 01 SequoiaDB 与 SparkSQL 介绍 SequoiaDB 是一款开源的金融级分布式关系型数据库，支持标准 SQL 和事务功能，支持复杂索引查询、与 Hadoop、Hive、Spark 都有较深度的集成。SequoiaDB 在分布式存储功能上，较一般的大数据产品能提供更多的数据切分规则，包括：水平切分、范围切分、主子表切分（类似 partition 分区）和多维切分方式，用户可以根据不用的场景选择相应的切分方式，以提高系统的存储能力和操作性能。 Spark 近年来发展特别迅猛，使用 SparkSQL 做大数据处理和分析的开发者越来越多。SparkSQL 是 Spark 产品中一个组成部分，SQL 的执行引擎使用 Spark 的 RDD 和 Dataframe 实现。 SparkSQL 和另外一款流行的大数据

本文主要介绍Serverless计算相关技术与其在华为云数据湖探索服务（后文简称DLI）中的技术落地。Serverless是DLI将计算能力服务化和产品化关键技术，与传统IAAS和PAAS技术不同，DLI运用Serverless技术向客户提供了一种高效易用易扩展的计算框架，使得客户更能聚焦业务，避免牵扯集群运维的细枝末节。本文将从以下几点解读Serverless技术： 1. serverless计算简介 2. 云计算架构演进—从IaaS到Serverless 3. Serverless计算应用场景与潜力 4. DLI Serverless 计算 serverless计算简介 图 Serverless与传统云计算比较 无服务器计算（Serverless）是一种新型的云计算范式，在业界也被称为FaaS（函数即服务），它有别于传统的IaaS（基础设施即服务）和PaaS（平台即服务）技术，旨在帮助开发者摆脱减少甚至免去底层基础架构管理上的诸多烦扰。Serverless计算服务允许客户在不构建一个复杂的基础设施的情况下开发，运行和管理应用程序。在2014年10月先由 http:// hook.io 提供给业界，接着AWS推出Lambda，2016年Google Cloud Functions，Microsoft Azure Functions对外提供服务

导语 | 随着直播电商行业的兴盛，有赞业务高速发展。但同时数据仓库中存储资源和计算资源消耗也非常高，甚至一度超过了整个平台业务的增速，显然不是一个可持续发展的态势。本文是对有赞技术副总裁，腾讯云最具价值专家TVP——沈淦老师在云+社区沙龙online的分享整理，为大家介绍有赞在数据中台成本治理上的实践，与大家一同交流。 点击查看完整直播回放 一、背景介绍 1. 数据中台机器资源情况 从整体的资源角度看，有赞数据中台机器数量在 1500 台左右，其中大部分是物理机，也有一部分是虚拟机，同时有 100 个左右的应用、4 万个核，数据规模在 15 PB 左右。 从规模上来看属于不大不小的一个数据集群。从业务的特征上看，离线计算、实时计算、平台应用、在线服务等都依赖于这些资源。其中离线机器的成本占了将近 50% ，其他的部分相对来讲占的是小头。 2. 数据成本增速超业务 在我们上半年的治理中，主要是针对离线计算场景，实时计算的部分目前在规划启动中。 根据目前的业务情况来看，数据中台资源上投入成本的增速比我们整个业务发展的增速还要快，这就导致了它的不可持续性，这也是我们进行成本治理的一个主要原因。 3. 问题剖析 分析下来，在成本方面我们主要面临的问题有以下这几个方面。 （1）资源水位低 一是整体的资源水位比较低，平均CPU使用率为 11% ，内存为 30% 左右。具体到场景中，离线的平均

作者|Veysel Kocaman 编译|VK 来源|Towards Data Science 自然语言处理(NLP)是许多数据科学系统中必须理解或推理文本的关键组成部分。常见的用例包括文本分类、问答、释义或总结、情感分析、自然语言BI、语言建模和消歧。 NLP在越来越多的人工智能应用中是越来越重要。如果你正在构建聊天机器人、搜索专利数据库、将患者与临床试验相匹配、对客户服务或销售电话进行分级、从财务报告中提取摘要，你必须从文本中提取准确的信息。 文本分类 是现代自然语言处理的主要任务之一，它是为句子或文档指定一个合适的类别的任务。类别取决于所选的数据集，并且可以从主题开始。 每一个文本分类问题都遵循相似的步骤，并用不同的算法来解决。更不用说经典和流行的机器学习分类器，如随机森林或Logistic回归，有150多个深度学习框架提出了各种文本分类问题。 文本分类问题中使用了几个基准数据集，可以在nlpprogress.com上跟踪最新的基准。以下是关于这些数据集的基本统计数据。 简单的文本分类应用程序通常遵循以下步骤： 文本预处理和清理 特征工程(手动从文本创建特征) 特征向量化(TfIDF、频数、编码)或嵌入(word2vec、doc2vec、Bert、Elmo、句子嵌入等) 用ML和DL算法训练模型。 Spark-NLP中的文本分类 在本文中，我们将使用通用句子嵌入

文章目录 Pregel框架： 一：Spark GraphX Pregel： 二：Pregel计算过程： Pregel函数源码及各个参数解析： 三：案例：单源最短路径 第一步：调用pregel方法： 第二步：第一次迭代： 第三步：第二次迭代： 第四步：不断迭代，直至所有顶点处于钝化态 案例代码如下： Pregel框架： 一：Spark GraphX Pregel： Pregel是google提出的用于大规模分布式图计算框架 图遍历(bfs) 单源最短路径（sssp） pageRank计算 Pregel的计算有一系列迭代组成 Pregel迭代过程 每个顶点从上一个superstep接收入站消息 计算顶点新的属性 在下一个superstep中向相邻的顶点发送消息 当没有剩余消息时，迭代结束 二：Pregel计算过程： Pregel函数源码及各个参数解析： def pregel [ A : ClassTag ] ( // 图节点的初始信息 initialMsg : A , // 最大迭代次数 maxIterations : Int = Int . MaxValue , // activeDirection : EdgeDirection = EdgeDirection . Either ) ( vprog : ( VertexId , VD , A ) => VD , sendMsg :

点击蓝色“ 有关SQL ”关注我哟 加个“ 星标 ”，天天与10000人一起快乐成长 很多朋友会觉得写 CRUD 很无聊，翻来覆去就那么点花样。接触不到新鲜的技术，感觉自己要被这个时代淘汰了。于是怨天尤人，连基本的 SQL 都写不好了。 这可能是眼界与见识的问题。SQL 在行业内还是相当重要的，当然你说 CRUD 那点东西玩几个月就会了，没有新奇感。从技术角度来看，是这样，我承认。但换成业务角度来说，这又不是一回事了。这要细讲，我可以讲上三天三夜，所以留到以后的文章再说。 在 OLTP 系统中，CRUD 能做的事情，越来越少了。大部分都由前端框架封装好了。搞c#的同学有 Entity Framework, Java 系的同学有 Spring 全家桶。这些框架可以说，基本把 CRUD 同学的职位给抢掉了 2/3, 剩下纯搞 CRUD 的同学就偷着乐吧，也没几天了，想吃啥想喝啥，别委屈了自己。 真正能让 SQL 人凭手艺，还在 CRUD 行当里吃香的，喝辣的，技术上取决于你掌握了多少种数据库，SQL写得多快，要不然就是要享受福报了。 好在上帝关闭一扇窗的同时，他又打开了一道门。这道门便是 数据仓库 。 数据和银行的存款是一样的，越积越多，多得我们得千方百计思考该怎么用它。我们刚开始入行的时候，接触的数据库应用，十有八九都是业务系统，比如订单系统，生产系统和人事系统。这是早就很多

项目介绍 项目整体介绍 1.项目模型搭建 此项目为数据仓库项目,主要是做离线计算的 项目模型:项目分为流量域和业务域两个主题域,为了方便管理这么多数据,又将每个主题域划分为五个层级,分别是ODS层,DWD层,DWS层,ADS层及DIM层,分层的原因为解耦,复用,便于管理,下面我分别介绍一下项目中他们的应用场景 1.1 ODS层 ODS层:源数据层,分为流量域ODS层及业务域ODS层 流量域ODS层:数据来源于日志服务器(用户行为日志数据(APP端和WEB端)),日志服务器将数据生产到Kafka,然后使用Flume日志采集工具消费Kafka中的数据并将数据采集到Hdfs集群,在Hive中将数据加载到ODS层的Hive表中,这样就完成了原始数据的采集 业务域ODS层:数据来源于业务系统中的关系型数据库mysql,采用sqoop抽取工具将数据从mysql导入到Hdfs中,再在Hive中将数据加载到ODS层相应的表中 1.2 DWD层 DWD层:数据明细层,同样分为流量域DWD层及业务域DWD层 流量域DWD层:将数据在ODS层进行ETL操作(先对ODS层数据进行清洗,过滤(过滤掉缺失重要字段信息,重要字段信息为空或者json格式不正确的数据),降维等操作),再抽取到DWD层 业务域DWD层:抽取ODS层每天的增量数据,与DWD层每天的全量数据进行合并

警报一直是整个监控系统中的重要组成部分，Prometheus监控系统中，采集与警报是分离的。 警报规则在 Prometheus 定义 ，警报规则触发以后，才会将信息转发到给独立的组件Alertmanager ，经过 Alertmanager r对警报的信息处理后，最终通过接收器发送给指定用户，另外在 Alertmanager 中没有通知组的概念，只能自己对软件重新Coding， 或者使用第三方插件来实现。 注意，这个通知组不是Alertmanager中的group概念，下面会详细讲 Group ，不要混淆哦。 前面已经介绍过一些关于 Alertmanager 知识点，本章开始针通过安装 Alertmanager 组件，对配置文件做详细说明，同时介绍 Prometheus 的警报规则的定义，最后使用Email、Wechat（Robot）、Dingtalk（webhook）来接受警报通知。 一、Alertmanager工作机制 在Prometheus生态架构里，警报是由独立的俩部分组成，可以通过上图很清晰的了解到 Prometheus 的警报工作机制。其中 Prometheus 与 Alertmanager 是分离的俩个组件。我们使用Prometheus Server端通过静态或者动态配置 去拉取 pull 部署在k8s或云主机上的各种类别的监控指标数据，然后基于我们前面讲到的