Apache Spark

文章目录 1 摘要 2 1 简介 3 2 ZooKeeper服务 3.1 2.1 服务概述 3.2 2.2 客户端API 3.3 2.3 ZooKeeper保证 3.4 2.4 原语的例子 4 3 ZooKeeper应用 5 4 ZooKeeper 实现 5.1 4.1 请求处理器 5.2 4.2 原子广播 5.3 4.3 副本数据库 5.4 4.4 C/S交互 6 5 测评 6.1 5.1 吞吐量 6.2 5.2 请求延迟 6.3 5.3 屏障的性能 7 6 相关工作 8 7 结论 9 致谢 10 参考文献 摘要 本文描述分布式应用的协调服务：ZooKeeper。ZooKeeper是关键基础设施的一部分，其目标是给客户端提供简洁高性能内核用于构建复杂协调原语。在一个多副本、中心化服务中，结合了消息群发、共享注册和分布式锁等内容。ZooKeeper提供的接口有共享注册无等待的特点，与事件驱动的分布式系统缓存失效类似，还提供了强大的协调服务。 ZooKeeper接口提供了高性能服务实现。除了无等待特性，还提供了对于客户端请求消息FIFO执行顺序保证，以及改变ZooKeeper状态的所有请求的线性化保证。这样的设计保证了对于本地服务的读请求，可以用高性能处理管道实现。论文中给出了目标负载，2:1到100:1的读写比例，可以处理每秒1万到10万的事务。由于其高性能

讲师： 王太泽 第四范式特征工程数据库负责人 曾在百度担任资深研发工程师 一直致力于解决机器学习模型从离线到在线特征一致性问题和性能问题。 时间： 6月23日 19：00 观看直播方式： 扫描下方二维码入群，或届时进入直播间（回看链接） https://developer.aliyun.com/live/43347?spm=a2c6h.12873587.0.0.127052c22xBiZl 直播介绍 SparkSQL在机器学习场景中应用模型从批量到实时面临的问题 SparkSQL 转换成实时执行成本高 离线特征和在线特征保持一致困难 离线效果与在线效果差距大 我们是如何解决这些问题 相对传统实现方式我们优势 SparkSQL实时上线demo 来源： oschina 链接： https://my.oschina.net/u/4332395/blog/4320117

Spark Streaming 接任意数据源作为 Stream 问题出发点 工程中遇到流式处理的问题时，多采用Spark Streaming 或者 Storm 来处理；Strom采用Spout的流接入方式，Streaming采用Stream的流接入方式，为了方便本地测试，所以选择了spark streaming，但是官方仅支持如下几种方案，当遇到其他高吞吐数据量作为流时，就需要主角 Receiver 登场： 实现关键类 Receiver ： Receiver是spark内部实现的一套机制，通过自定义一个类继承Receiver即可实现自定义数据源，再通过ssc的receiverStream接口即可实现数据转RDD的操作，即可像Kafka，Flume等正常操作Spark Streaming。本质上通过receiverStream得到的是ReceiverInputDStreaming。 class MyReceiver(storageLevel: StorageLevel) extends NetworkReceiver[String](storageLevel) { def onStart() { // Setup stuff (start threads, open sockets, etc.) to start receiving data. // Must start new

​  ​ 在《[什么的是用户画像]( https://mp.weixin.qq.com/s/169tCtjgUiDNeHIKLtGO9w )》一文中，我们已经知道用户画像对于企业的巨大意义，当然也有着非常大实时难度。那么在用户画像的系统架构中都有哪些难度和重点要考虑的问题呢？ # 挑战 - ## 大数据 随着互联网的崛起和智能手机的兴起，以及物联网带来的各种可穿戴设备，我们能获取的每一个用户的数据量是非常巨大的，而用户量本身更是巨大的，我们面临的是TB级，PB级的数据，所以我们必须要一套可以支撑大数据量的高可用性，高扩展性的系统架构来支撑用户画像分析的实现。毫无疑问，大数据时代的到来让这一切都成为可能，近年来，以Hadoop为代表的大数据技术如雨后春笋般迅速发展，每隔一段时间都会有一项新的技术诞生，不断驱动的业务向前，这让我们对于用户画像的简单统计，复杂分析，机器学习都成为可能。所以整体用户画像体系必须建立在大数据架构之上。 ![]( https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200525090411478

引言 Service Mesh 是目前社区最为炙手可热的技术方向，去年双11在蚂蚁金服得到全面的应用，并平稳顺滑的支撑了大促服务。作为目前规模最大的 Service Mesh 集群，本文从监控的领域对 Service Mesh 落地进行经验总结，主要从以下几方面进行介绍： 云原生监控，介绍蚂蚁金服 Metrics 监控的落地； 用户视角分析，介绍从应用 owner 的角度对这一基础服务设施的体验以及 SRE 从全站服务的稳定性对监控提出的要求； 未来的思考，介绍后续发展方向； 云原生监控 云原生应用的设计理念已经被越来越多的开发者接受与认可，今年蚂蚁金服应用服务全面云原生化，对我们监控服务提出更高的要求。目前 Metrics 指标监控服务也逐渐形成体系，如下图所示基于社区原生 Prometheus 采集方案在蚂蚁金服监控场景下落地。 怎么采集 蚂蚁金服监控采集 AGENT 是部署在物理机上，支持多个采集插件，如下图，包括执行命令、日志、HTTP 请求、动态 SQL 采集、系统指标采集、JVM 采集以及进程监控等，同时支持多个解析插件自定义解析、单行文本解析、Lua 脚本解析、JSON 解析以及 Prometheus 解析等。 在Service Mesh 监控落地中，业务方参考业界标准输出 Metrics 指标数据，监控采集该物理机不同 Pod、App 和 Sidecar 的各项指标

Shuffle概念 shuffle，是一种多对多的依赖关系，即每个Reduce Task从每个Map Task产生数的据中读取一片数据，极限情况下可能触发M*R个数据拷贝通道（M是Map Task数目，R是Reduce Task数目）。 Shuffle描述着数据从map task输出到reduce task输入的这段过程。shuffle是连接Map和Reduce之间的桥梁，Map的输出要到Reduce中必须经过shuffle这个环节，shuffle的性能高低直接影响了整个程序的性能和吞吐量。 因为在分布式情况下，reduce task需要跨节点去拉取其它节点上的map task结果。这一过程将会产生网络资源消耗和内存，磁盘IO的消耗。 通常shuffle分为两部分： Map阶段的数据准备和Reduce阶段的数据拷贝处理。 一般将在map端的Shuffle称之为 Shuffle Write ； 在Reduce端的Shuffle称之为 Shuffle Read 。 Spark 的 Shuffle 过程与 MapReduce 的 Shuffle 过程有着诸多类似，一些概念可直接套用，例如，Shuffle 过程中， 提供数据的一端，被称作 Map 端，Map 端每个生成数据的任务称为 Mapper；对应的， 接收数据的一端，被称作 Reduce 端，Reduce 端每个拉取数据的任务称为

在人口流量红利不再，获客成本越来越高的时代，精益创业、MVP 的概念已经深入人心，精细化运营也是大势所趋，而这些背后本质上都依赖数据化运营，那如何根据现有业务，快速从 0 开始打造一个契合业务的数据产品呢？本文将以某二手交易平台业务为基础，讲述整个数据平台从 0 到 1 的演进与实践，希望对大家能有所启发。 1、背景 在某二手交易平台开始大数据平台建设之前，整个数据从需求提出到研发流程再到数据报表、数据产品，也是经历过一段非常混沌的时期，而且效率和质量往往很难得到保障，主要表现为以下几个方面： （1）可用性差 比如经常出现计算延迟、异常，数据指标也常常数据对不上，很多相似的指标不清楚具体差异在哪，即使同一个指标也可能不同的同学开发的而对不上。另外数据波动无感知，比如日志格式出错，结果第二天才发现有问题。 （2）维护成本高 成百上千的日志模块，不知从何维护，出了问题也不知道从哪里可以追溯到源头和负责人。 （3）业务快速迭代，精细化、数据化运营需求和研发资源之间的矛盾 2、目标与方案 （1）目标 数据可管理、可维护、可扩展、高可用 及时、准确、直观的呈现业务数据与问题 降低使用门槛，提升使用效率 （2）方案 数据仓库化 数据平台化 3、数据仓库建设 结构化 层次化 主题化 模型化：用户模型/事件模型 ETL ETL 是整个数据仓库的核心，正如业界流传的一句话：Garbage In,

摘要： 脏数据对数据计算的正确性带来了很严重的影响。因此，我们需要探索一种方法，能够实现Spark写入Elasticsearch数据的可靠性与正确性。 概述 Spark与Elasticsearch（es）的结合，是近年来大数据解决方案很火热的一个话题。一个是出色的分布式计算引擎，另一个是出色的搜索引擎。近年来，越来越多的成熟方案落地到行业产品中，包括我们耳熟能详的Spark+ES+HBase日志分析平台。 目前，华为云数据湖探索（DLI）服务已全面支持Spark/Flink跨源访问Elasticsearch。而之前在实现过程中也遇到过很多场景化问题，本文将挑选其中比较经典的分布式一致性问题进行探讨。 分布式一致性问题 问题描述 数据容错是大数据计算引擎面临的主要问题之一。目前，主流的开源大数据比如Apache Spark和Apache Flink已经完全实现了Exactly Once语义，保证了内部数据处理的正确性。但是在将计算结果写入到外部数据源时，因为外部数据源架构与访问方式的多样性，始终没能找到一个统一的解决方案来保证一致性（我们称为Sink算子一致性问题）。再加上es本身没有事务处理的能力，因此如何保证写入es数据一致性成为了热点话题。 我们举一个简单的例子来说明一下，图1在SparkRDD中（这里假设是一个task），每一条蓝色的线代表100万条数据

在产品精细化运营时代，经常会遇到产品增长问题：比如指标涨跌原因分析、版本迭代效果分析、运营活动效果分析等。这一类分析问题高频且具有较高时效性要求，然而在人力资源紧张情况，传统的数据分析模式难以满足。本文尝试从0到1实现一款轻量级大数据分析系统——MVP，以解决上述痛点问题。 文章作者：数据熊，腾讯云大数据分析工程师。 一、背景及问题 在产品矩阵业务中，通过仪表盘可以快速发现增长中遇到的问题。然而，如何快速洞悉问题背后的原因，是一个高频且复杂的数据分析诉求。 如果数据分析师通过人工计算分析，往往会占用0.5-1天时间才能找到原因。因此，人工计算分析方式，占用人力大，且数据分析效率低。 另外，产品版本迭代与业务运营活动，也需要对新版本、新功能、新活动进行快速数据分析，已验证效果。 因此，在产品矩阵业务精细化运营中，存在大量的数据分析诉求，且需要快速完成。 在传统的数据分析模式下，对于每个需求，一般需要经历3-5天才能解决问题。除此之外，该模式还需要大量数据分析师对接需求。因此，在数据分析师人力紧缺情况下，该模式无法满足产品增长的数据分析诉求。 二、解决办法 在传统数据分析模式失效情况下，急需开拓新的数据分析模式，以快速满足产品增长的数据分析诉求。 为此，笔者和项目小团队从0到1实现一款轻量级大数据分析系统——MVP，希望通过MVP数据分析，驱动产品从"Minimum Viable

Apache Kylin v3.1.0 已于上周正式发布，其中包含了许多值得一试的新功能，本文选择了 Presto 查询下压引擎、Flink 构建引擎、Kylin on Kubernetes 解决方案、新版 Hive 全局字典、增强的 Cube 迁移服务这五项重点功能进行介绍。 Presto 查询下压引擎 之前版本的 Kylin 提供了查询下压功能，该功能对于 Hive 数据源的下压有比较好的支持，但是对 Hive 以外的具有不兼容语法的数据源，用户就容易遇到因为种种方言不兼容而导致查询下压失败的问题。 为了解决这个问题，Kyligence 贡献了基于 Data Source SDK 开发的 Presto 查询下压引擎，该功能通过 Calicte 完成了Kylin 和 Presto 方言翻译，大大提升了查询下压的成功率。 Presto 下压引擎的使用文档请参考 : http://kylin.apache.org/docs/tutorial/query_pushdown.html 崭新的 Flink 构建引擎 Flink Engine 由腾讯贡献到 Kylin 社区（KYLIN – 3758）。在过去版本中，Kylin 只支持 MapReduce 和 Spark 两种构建引擎，为了扩大 Kylin 生态，进一步提升构建速度，Kylin v3.1.0引入了 Flink 作为构建引擎