parquet

本文以流式数据入库的场景为基础，介绍引入 Iceberg 作为落地格式和嵌入 Flink sink 的收益，并分析了当前可实现的框架及要点。 应用场景 流式数据入库，是大数据和数据湖的典型应用场景。上游的流式数据，如日志，或增量修改，通过数据总线，经过必要的处理后，汇聚并存储于数据湖，供下游的应用（如报表或者商业智能分析）使用。 上述的应用场景通常有如下的痛点，需要整个流程不断的优化： 支持流式数据写入 ，并保证端到端的不重不丢（即 exactly-once）； 尽量减少中间环节 ，能支持更实时（甚至是 T+0）的读取或导出，给下游提供更实时更准确的基础数据； 支持 ACID ，避免脏读等错误发生； 支持修改已落地的数据 ，虽然大数据和数据湖长于处理静态的或者缓慢变化的数据，即读多写少的场景，但方便的修改功能可以提升用户体验，避免用户因为极少的修改，手动更换整个数据文件，甚至是重新导出； 支持修改表结构 ，如增加或者变更列；而且变更不要引起数据的重新组织。 引入 Iceberg 作为 Flink sink 为了解决上述痛点，我们引入了 Iceberg 作为数据落地的格式。Iceberg 支持 ACID 事务、修改和删除、独立于计算引擎、支持表结构和分区方式动态变更等特性，很好的满足我们的需求。 同时，为了支持流式数据的写入，我们引入 Flink 作为流式处理框架，并将

参考文章： kudu介绍 文章内容来源于官网文档： http://kudu.apache.org/docs/index.html 一、kudu介绍 Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的成员之一(incubating)，专门为了对快速变化的数据进行快速的分析，填补了以往Hadoop存储层的空缺。 1 功能上的空白 Hadoop生态系统有很多组件，每一个组件有不同的功能。在现实场景中，用户往往需要同时部署很多Hadoop工具来解决同一个问题，这种架构称为混合架构 (hybrid architecture)。比如，用户需要利用Hbase的快速插入、快读random access的特性来导入数据，HBase也允许用户对数据进行修改，HBase对于大量小规模查询也非常迅速。同时，用户使用HDFS/Parquet + Impala/Hive来对超大的数据集进行查询分析，对于这类场景， Parquet这种列式存储文件格式具有极大的优势。 很多公司都成功地部署了HDFS/Parquet + HBase混合架构，然而这种架构较为复杂，而且在维护上也十分困难。首先，用户用Flume或Kafka等数据Ingest工具将数据导入HBase，用户可能在HBase上对数据做一些修改。然后每隔一段时间(每天或每周)将数据从Hbase中导入到Parquet文件

参考文章： Kudu的性能测试 1. kudu和parquet的比较 　上图是官方给出的用Impala跑TPC-H的测试，对比Parquet和Kudu的计算速度。从图中我们可以发现，Kudu的速度和parquet的速度差距不大，甚至有些Query比parquet还快。然而，由于这些数据都是在内存缓存过的，因此该测试结果不具备参考价值。 2. kudu和Hbase的比较 图是官方给出的另一组测试结果，从图中我们可以看出，在scan和range查询上，kudu和parquet比HBase快很多，而random access则比HBase稍慢。然而数据集只有60亿行数据，所以很可能这些数据也是可以全部缓存在内存的。对于从内存查询，除了random access比HBase慢之外，kudu的速度基本要优于HBase。 3、超 大数据 集的查询性能 　　Kudu的定位不是in-memory database。因为它希望HDFS/Parquet这种存储，因此大量的数据都是存储在磁盘上。如果我们想要拿它代替HDFS/Parquet + HBase，那么超大数据集的查询性能就至关重要，这也是Kudu的最初目的。然而，官方没有给出这方面的相关数据。由于条件限制，网易暂时未能完成该测试。下一步，我们将计划搭建10台Kudu + Impala服务器，并用tpc-ds生成超大数据，来完成该对比测验。 来源

1.Shark Shark是基于Spark计算框架之上且兼容Hive语法的SQL执行引擎，由于底层的计算采用了Spark，性能比MapReduce的Hive普遍快2倍以上，当数据全部load在内存的话，将快10倍以上，因此Shark可以作为交互式查询应用服务来使用。除了基于Spark的特性外，Shark是完全兼容Hive的语法，表结构以及UDF函数等，已有的HiveSql可以直接进行迁移至Shark上Shark底层依赖于Hive的解析器，查询优化器，但正是由于SHark的整体设计架构对Hive的依赖性太强，难以支持其长远发展，比如不能和Spark的其他组件进行很好的集成，无法满足Spark的一栈式解决大数据处理的需求。 2.SparkSQL 1.SparkSQL介绍 Hive是Shark的前身，Shark是SparkSQL的前身,SparkSQL产生的根本原因是其完全脱离了Hive的限制。 SparkSQL支持查询原生的RDD。 RDD是Spark平台的核心概念，是Spark能够高效的处理大数据的各种场景的基础。 能够在Scala中写SQL语句。支持简单的SQL语法检查，能够在Scala中写Hive语句访问Hive数据，并将结果取回作为RDD使用。 2.Spark on Hive和Hive on Spark Spark on Hive： Hive只作为储存角色

上一次我们谈到了各种类型的数据库，今天我们来谈谈在大数据，尤其是Hadoop栈下的数据和文件的存储。 我们知道为了解决大数据的存储和处理问题，google最先设计了推出了Map/Reduce的算法，而hadoop就是Google的map/reduce的开源实现。Hadoop主要由分布式的文件系统HDFS（参考Google的GFS）和Map/Reduce计算这两块。但随着Spark等更强大的计算引擎的出现，很少再有人使用Hadoop的Map/Reduce来做计算了，但是对于海量数据/文件的存储，除了HDFS，还真没有更多更好的选择。所以我们就来看看在Hadoop下，文件存储的各种选项。 原始文本文件 首先，我们什么都不需要做，HDFS提供分布式的文件存储，那么我们就直接把原始的文本文件存储在HDFS上就好了。通常我们会使用诸如txt，csv，json，xml等文本格式的文件存储在HDFS上，然后由各种计算引擎加载，计算。 HDFS是按照块来存储文件的，缺省的设置一个块的大小是64M，那么假定我的文本文件是1G，它会被分成16个分区，由计算引擎（Spark，Map/Reduce）来并行的处理，计算。 使用文本格式的主要问题是： 占用空间大 处理时有额外的序列化反序列化的开销，例如把日志中的文本‘12’转化为数字的12 所以这里就引入了两个解决方案： 压缩。 压缩是使用计算资源来换取存储

摘要：本文由阿里巴巴技术专家贺小令（晓令）分享，主要介绍 Apache Flink 新场景 OLAP 引擎，内容分为以下四部分： 背景介绍 Flink OLAP 引擎 案例介绍 未来计划 一、背景介绍 1.OLAP 及其分类 OLAP 是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。主流的 OLAP 可以分为3类：多维 OLAP ( Multi-dimensional OLAP )、关系型 OLAP ( Relational OLAP ) 和混合 OLAP ( Hybrid OLAP ) 三大类。 （1）多维 OLAP ( MOLAP ) 传统的 OLAP 分析方式 数据存储在多维数据集中 （2）关系型 OLAP ( ROLAP ) 以关系数据库为核心，以关系型结构进行多维数据的表示 通过 SQL 的 where 条件以呈现传统 OLAP 的切片、切块功能 （3）混合 OLAP ( HOLAP ) 将 MOLAP 和 ROLPA 的优势结合起来，以获得更快的性能 以下将详细介绍每种分类的具体特征。 ■ 多维 OLAP ( MOLAP ) MOLAP 的典型代表是 Kylin 和 Druid。 MOLAP 处理流程 首先，对原始数据做数据预处理；然后，将预处理后的数据存至数据仓库，用户的请求通过 OLAP server 即可查询数据仓库中的数据。 MOLAP 的优点和缺点

大数据常见英文词汇（待更新） words(单词) resilient 有弹性的 parallelize 并行化 procedure 过程 process 进程、处理 program 程序 schedule 日程安排 scheduler 调度程序 schema 架构 segment 段 operation 算子 convergence 汇聚 visualize 可视化 plugin 插件 transactional 事务性 integrity 完整 slot 窄缝，扁口;位置，时间，机会 a bunch of 一群 ELK elasticsearch 弹性搜索 logstash 日志存放 kibana vertical bar 竖条 dash board 仪表盘 Covariance 协方差 constraints 约束条件 repository 存储库 Parquet 镶木地板 specify 指定 immutable 不变的 block 块 greater than gt 大于 less than lt 小于 Phrases（词组） Streaming data processing （基于实时）数据流的数据处理 interactive query （基于历史数据的）交互式查询 batch data processing （复杂的）批量数据处理 URI (Uniform