Apache Spark

SparkSQL在机器学习场景中应用 第四范式已经在很多行业落地了上万个AI应用，比如在金融行业的反欺诈，媒体行业的新闻推荐，能源行业管道检测，而SparkSQL在这些AI应用中快速实现特征变换发挥着重要的作用 SparkSQL在特征变换主要有一下几类 1. 多表场景，用于表之间拼接操作，比如交易信息表去拼接账户表 2. 使用udf进行简单的特征变换，比如对时间戳进行hour函数处理 3. 使用时间窗口和udaf进行时序类特征处理，比如计算一个人最近1天的消费金额总和 SparkSQL到目前为止，解决很好的解决离线模型训练特征变换问题，但是随着AI应用的发展，大家对模型的期望不再只是得出离线调研效果，而是在真实的业务场景发挥出价值，而真实的业务场景是模型应用场景，它需要高性能，需要实时推理，这时候我们就会遇到以下问题 1. 多表数据离线到在线怎么映射，即批量训练过程中输入很多表，到在线环境这些表该以什么形式存在，这点也会影响整个系统架构，做得好能够提升效率，做得不好就会大大增加模型产生业务价值的成本 2. SQL转换成实时执行成本高，因为在线推理需要高性能，而数据科学家可能做出成千上万个特征，每个特征都人肉转换，会大大增加的工程成本 3. 离线特征和在线特征保持一致困难，手动转换就会导致一致性能，而且往往很难一致 4. 离线效果很棒但是在线效果无法满足业务需求 在具体的反欺诈场景

对象存储概念及特性 在介绍 QingStor®️对象存储内部的的架构和设计原理之前，我们首先来了解一下对象存储的概念，也就是从外部视角看，对象存储有什么特性，我们应该如何使用。 对象存储本质上是一款存储产品，与其他的存储，如文件存储、块存储，功能是类似的，主要的功能都是数据的读和写。最大的不同在于对象存储是把数据作为对象进行管理，这是它最主要的特征，所有的数据在这里面都当做一个对象处理。 对象存储有一些非常鲜明的特点： 它的结构是扁平的，不像文件存储那样有目录层级，在读写数据时不需要对目录进行层层查找和打开。 对象存储具备海量数据存储的能力，这里的海量指的是不仅仅是几百 GB 的量，而是说几百 T 甚至上 PB 的级别。 对象存储适用于非结构化数据的存储，非结构化具体指的是不对数据的类型和格式做任何假设，不管是简单的文本，还是图片、视频、音频都可以存在对象存储里，当做对象来处理。 对象存储通过 Restful 接口对外提供服务，也就是 HTTP 协议，这使得对象存储的访问非常方便，随时随地可以进行数据的上传和下载。 QingStor®️对象存储核心优势 ![0_1591683403636_1.png]( https://community.qingcloud.com/assets/uploads/files/1591683404995-1-resized.png

直接上图： 来源： oschina 链接： https://my.oschina.net/u/4310671/blog/4330742

作者： 李呈祥，花名司麟 ，阿里云智能EMR团队高级技术专家，Apache Hive Committer， Apache Flink Committer，目前主要专注于EMR产品中开源计算引擎的优化工作。 Spark社区在 Spark Packages 网站中索引了许多第三方库，这些第三方库由不同的开发者贡献，作为Spark生态圈的一部分，扩充了Spark的使用范围和使用场景，其中很多对于我们日常的使用可能有帮助，我们准备开启一个系列文章介绍Spark Packages中一些有意思的第三方库，作为系列的第一篇，本文主要介绍Optimus，一个基于PySpark的简单易用的数据准备工具。 本文的部分内容源自Optimus官网和相关介绍文章，原文链接参考文末引用部分。 在Spark（Pyspark）的支持下，Optimus允许用户使用自己的或一组 来源： oschina 链接： https://my.oschina.net/u/4324558/blog/4310289

在开发过程中，收到这样一个问题反馈，在网站上传 100 MB 以上的文件经常失败，重试也要等老半天，这就难为需要上传大规格文件的用户了。那么应该怎么做才能快速上传，就算失败了再次发送也能从上次中断的地方继续上传呢？下文为你揭晓答案~ 温馨提示：配合 Demo 源码 一起阅读效果更佳 整体思路 第一步是结合项目背景，调研比较优化的解决方案。 文件上传失败是老生常谈的问题，常用方案是将一个大文件切片成多个小文件，并行请求接口进行上传，所有请求得到响应后，在服务器端合并所有的分片文件。当分片上传失败，可以在重新上传时进行判断，只上传上次失败的部分，减少用户的等待时间，缓解服务器压力。这就是分片上传文件。 大文件上传 那么如何实现大文件分片上传呢？ 流程图如下： 分为以下步骤实现： 1. 文件 MD5 加密 MD5 是文件的唯一标识，可以利用文件的 MD5 查询文件的上传状态。 根据文件的修改时间、文件名称、最后修改时间等信息，通过 spark-md5 生成文件的 MD5。需要注意的是，大规格文件需要分片读取文件，将读取的文件内容添加到 spark-md5 的 hash 计算中，直到文件读取完毕，最后返回最终的 hash 码到 callback 回调函数里面。这里可以根据需要添加文件读取的进度条。 实现方法如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

6月14日，计算平台事业部与阿里云开发者社区联合举办的 首期大数据+AI Meetup即将重磅开启 ，来自阿里、Databricks、快手、网易云音乐的国内外多位技术专家齐聚一堂，与你探讨大数据及 AI 领域的热门话题！ Meetup 精华看点 Flink 1.11、Spark 3.0、Alink 1.1.1 等大数据热门开源软件核心开发者帮你圈出最新版本重点 实时数仓、数据湖、HSAP 架构能干啥一次讲清楚 更有一线生产环境实战，春晚快手项目、网易云音乐 Flink + Kafka 落地实践的独家宝贵经验分享 全场超豪华嘉宾阵容，直播间已准备多种精美礼品，现场送送送 如何观看 时间：6月14日 10:00 — 18:00 直播预约链接： https://developer.aliyun.com/live/2894?spm=a2c6h.12873587 来源： oschina 链接： https://my.oschina.net/u/4382640/blog/4308957

6月14日，计算平台事业部与阿里云开发者社区联合举办的 首期大数据+AI Meetup即将重磅开启 ，来自阿里、Databricks、快手、网易云音乐的国内外多位技术专家齐聚一堂，与你探讨大数据及 AI 领域的热门话题！ Meetup 精华看点 Flink 1.11、Spark 3.0、Alink 1.1.1 等大数据热门开源软件核心开发者帮你圈出最新版本重点 实时数仓、数据湖、HSAP 架构能干啥一次讲清楚 更有一线生产环境实战，春晚快手项目、网易云音乐 Flink + Kafka 落地实践的独家宝贵经验分享 全场超豪华嘉宾阵容，直播间已准备多种精美礼品，现场送送送 如何观看 时间：6月14日 10:00 — 18:00 直播预约链接： https://developer.aliyun.com/live/2894?spm=a2c6h.12873587 来源： oschina 链接： https://my.oschina.net/u/4263556/blog/4310290

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

这一章主要想聊聊： TsFile索引块的组成 索引块的查询过程 索引块目前在做的改进项 索引块 索引块由两大部分组成，其写入的方式是从左到右写入，也就是从文件头向文件尾写入。但读出的方式是先读出TsFileMetaData 再读出 TsDeviceMetaDataList 中的具体一部分。我们按照读取数据的顺序介绍： TsFileMetaData TsFileMetaData属于文件的 1 级索引，用来索引 Device 是否存在、在哪里等信息，其中主要保存了： DeviceMetaDataIndexMap：Map结构，Key 是设备名，Value 是 TsDeviceMetaDataIndex ，保存了包含哪些 Device（逻辑概念上的一个集合一段时间内的数据，例如前几章我们讲到的：张三、李四、王五）以及他们的开始时间及结束时间、在左侧 TsDeviceMetaDataList 文件块中的偏移量等。 MeasurementSchemaMap：Map结构，Key 是测点的一个全路径，Value 是 measurementSchema ，保存了包含的测点数据(逻辑概念上的某一类数据的集合,如体温数据)的原信息，如：压缩方式，数据类型，编码方式等。 最后是一个布隆过滤器，快速检测某一个 时间序列 是不是存在于文件内(这里等聊到 server 模块写文件的策略时候再聊)

问题描述 Hive ORC table常规小文件过多问题，于是用Spark写了一个Application来自动的Merge分区数据，思路很简单 大概就是 insert overwrite table partition (分区 XXX) select * from table where (分区 XXX) 当然已经把该dataframe repartition到想要的目标并发度，来控制最终分区下的文件个数 但是发现生成的文件个数虽然是对的，但是最后整个分区的Size竟然几乎翻倍。 排查过程以及结论 怀疑是Spark SQL没有压缩或者压缩格式不对 https://stackoverflow.com/questions/48759909/how-to-check-if-zlib-compression-is-enabled-in-hive-tables 用这个链接的方式自查一下 发现 hive 生成的文件默认是zlib 而spark生成的文件默认是snappy 这个导致了最终文件大小相差较大 来源： oschina 链接： https://my.oschina.net/u/4303818/blog/4287399