作者|李昆
编辑|Vincent

CarbonData 开源后,受到全球大数据技术爱好者高度关注;截止到目前为止,全球已有 100+ 开发者参与了代码贡献,有 10+ 家企业上线生产系统。本次内容整理自华为技术有限公司大数据软件架构师李昆的演讲,主要介绍 CarbonData 应用实践以及 2.0 新技术规划,帮助大家更好地应用 CarbonData 技术。

除了本篇演讲内容之外,我们还整理上传了Apache CarbonData+Spark主题技术交流会所有讲师的演讲PPT+ 演讲视频,感兴趣的同学可以关注公众号并发送【CarbonData】,免费获取现场完整资料 。


更多精彩文章请添加微信“AI 前线”(ID:ai-front)

Apache CarbonData 是一种新的高性能数据存储,针对当前大数据领域分析场景需求各异而导致的存储冗余问题,CarbonData 提供了一种新的融合数据存储方案,以一份数据同时支持大数据分析的多种应用场景(如:“任意维度组合的数据查询分析、快速扫描、详单查询、数据更新删除等”),并通过多级索引、字典编码、列存等特性提升了 I/O 扫描和计算性能,实现百亿数据级秒级响应。

大家好,很高兴有这个机会和大家面对面的交流,这次我分享的是 CarbonData 在实践上的应用,CarbonData 如何调优、还有 CarbonData 2.0 的规划和一些经验分享。我的演讲分 4 部分,首先是我们为什么会想到这个项目,做这个项目的原因是什么;第二部分介绍一下 CarbonData 的原理;第三部分重点讲解应用场景,CarbonData 在哪些场景能够发挥最大价值,以及如何调节各种参数可将应用调到最优,最后一部分讲一下我们未来的计划。

为什么需要 CarbonData

现在很多企业正在做数字化转型,比如说车享集团做各种电商,车联网会有很多数据到它的数据中心,到数据中心之后有很多的应用,比如有传统的 BI 类的应用,有批处理、报表分析;也有做 AI 类的应用,比如做车联网的预测、电商推荐和实时分析、风控类的应用。

这里举些例子,如上图。上图是我们在电信领域的一些报表,比如统计 Whatapp 应用流量的使用情况,又比如上海市每个小区网络拥塞情况,或者是交通车流量情况。还有一些详单分析,在明细数据上进行过滤查询。

数据的挑战

应用中存在很多挑战,首先我们来看看数据的挑战。现在是数据的时代,很多传感器和设备都会源源不断地产生数据,所以数据量会非常大,正如我们经常会遇到的单表,具有百亿级的数据量;数据是多种维度的,维度很细,各种传感器、详细数据、明细数据里面有各种度量和维度,比如说经常有超过一百维的表格;数据的细粒度很细,比如有十亿的终端,它上面的地理位置有着 20 万个小区,一天存储的数据组合情况就很可观。

应用的挑战

在应用上的另一个挑战是如何与企业生产系统的要求做到比较好的对接,即如何与企业应用、传统的 JDBC、OBDC 应用做对接。各种应用的分析模型是非常灵活的,没有固定的模式,它不只有 BI 的 Query 分析,也有应用分析,还有全表查询,还有像搜索的模糊匹配。

总结其查询模式有三种类型:

  • 第一种是 full scan,例如基于全部数据做汇总统计分析;

  • 第二种是做点查询,比如说我以及知道自己需要查哪辆车,直接进行查该车的数据;

  • 第三种是处于中间的,既要过滤也要扫描,以及做统计计算和关联分析等,即所谓的 OLAP 分析。

如何构建数据平台

在一个企业里面,数据架构师是怎么选择相应的平台做数据产品呢?

选择 1:NoSQL Database

第一个选择是 NoSQL,它主要擅长做基于 key 的 put 和 get。所谓 key-value,即通过 key 查询 value;这方面,HBase、Cassandra、Redis 都比较不错,可以做到毫秒级的 get。key-value 的问题在于它是一键一值,一个 Key 查询一个 Value,时间大概是 5 毫秒。但如果是面向分析型应用,需要基于大范围的数据做计算,甚至全表扫描,它就会比较慢。

选择 2:parallel database

第二个选择是使用传统的 MPP 数据库,将数据库打散在每个节点上。数据的计算是并发的,并且有着 pipeline 计算模型,在数据量规模不大的情况下,它是一个比较合适的选择。它的问题在于一旦数据量过大,自身的 scalability 能否上去,比如很难超过一百个节点得规模。另外一个问题是容错性,当执行时长较长的任务时,当其中有机器宕机,计算不能从中间步骤恢复,而需要将整个任务重头执行。

选择 3:search  engine

第三个选择是做搜索引擎。搜索引擎是非常快的,因为它对每一列都建立了索引,适合多条件过滤,同时也能够做一些文本的分析;它的主要缺点是它不能完成复杂的计算,比如不能做多层级的聚集或者做关联 join;另外数据膨胀比较可观,因为每一列都做了索引;最后是它没有 SQL 支持,这很难对接企业数据应用和 BI 工具。

选择 4:SQL on Hadoop

最后一类选择是 SQL on Hadoop,是最近比较火的引擎。这类引擎聚焦在计算层,帮大家把分布式计算的问题给解决了。它们使用的存储方式是 Hadoop 文件,这种文件在使用之前都是列存的,是为批处理设计的文件格式,聚焦的是批处理所需要的全表扫描性能,但由于没有索引支持,所以对过滤条件查询支持很一般。

架构师如何选择?

架构师面临系统的时候有两个选择,第一个选择是把部分应用搬上大数据平台,但还有一些应用会用以前老的方式,比如用 MySQL、Oracle 等一些传统的数据库去解决;另外一种方案是某份数据为该应用选择一个最合适的存储,比如为该 APP1 选用 HBase,因其点查比较快;为报表类应用选择 Parquet,因其扫描比较快;要使用这个架构,在导入数据前需要做一个数据复制,将其复制成多份,每一份用一个系统存储,这样便可满足所有应用的性能要求。但是数据复制需要付出代价,它会带来存储成本的开销,并且需要维护数据的一致性。所以企业架构师还是比较痛苦的。

正是由于该原因,诞生了 CarbonData 项目。我们希望尽量使用一份数据去满足企业里面各种各样的需求,包括详单的过滤、海量数仓以及数据集式操作。

CarbonData 大数据生态

CarbonData 和 Spark 结合之后,可以在交互分析上打造一个相对于传统系统更好的体验。目前 CarbonData 和 Spark1.5、1.6、2.1 都做了集成,未来也会对 Spark2.2 做支持,可提供 SQL 接口,同时也支持 Spark dataframe API 接口。我们跟 Spark 做了一个深度集成,即对 catalyst Spark SQL 优化器做了深度优化,且实现了一些新语法,比如更新、删除、compaction 这些语法。

我们看一下它的用法,如上图所示,它与 Spark SQL 用法一样。除了 SQL 外,用 Dataframe 可以将某数据写成 CarbonData 表格,可从 Hive 或者 Parking、HBase 内导入,使用 database.write 实现入库。

查询方面是使用标准的 SparkSQL 语法。

更新与删除操作是 CarbonData 自己加的,可以实现批处理场景的数据更新和删除。如上图。

第一个例子,更新某一列,将 revenue 减 10(这个人可能被扣了 10 元钱工资);第二个例子是 join,将 join 的结果放入 product ,revenue 这两个列上,首先对 table 1、table 2 这两个表做 join,将做完的结果再 update 到 table1;最后一个例子是某个“123”用户,删除它的全部记录。需要说明的是,CarbonData 实现的增删改,是 OLAP 批处理的场景,而不是 OLTP,并不支持每秒几千次的增删改。

CarbonData 原理介绍

CarbonData 原理介绍分为三部分,第一部分是数据组织介绍,第二部分是索引,第三部分是扫描数据。

CarbonData 文件格式

上图右侧为 CarbonData 内部的文件格式,有 file header、有 file footer、有记录元数据中心,包括 schema 数据、偏移量数据等。我们重点看一下中间的 Blocklet 内容,Blocklet 是数据文件内的一个列存数据块。Blocklet 内部按列存储,比如说有 column 1 chunk、colume 2 chunk,每一列数据又分为 page,page 是最小的解码单元。另外一个特点是除了元数据信息以外,还有索引信息。索引信息被统一存在 Footer 内,它包括了 Blocklet 的索引,即主索引,它是 B 树里面所包含的 start key 和 end key 之间的范围值。同时也包括 Blocklet 级和 page 级统计信息,这些统计信息是非常有用的,通过这些信息可以跳过 Blocklet 和 page,避免不必要的 IO 和解码。

利用两级索引

上图介绍的是 CarbonData 与 Spark 结合利用索引的架构图。Spark 分成 Driver 和 Executor,与 CarbonData 相对应以实现两极的索引。在 Driver 侧,Spark 可以对每一个 Blocklet 文件进行过滤,以此得到它需要扫描的文件。很多情况下,我们可以在 Driver 侧就减少掉 95% 不必要的 Spark task,避免扫描不必要的文件, 当需要扫描的文件找到之后,Spark 便会下发 task。在 Executor 侧也会利用 Blocklet 索引去过滤文件内部的在 Driver 侧以减少磁盘 IO。


举例—完整的过滤查询过程

如上图,我们看一个具体的例子。“SELECT c3, c4 from T1 where c2=’北京’”,即选取所有北京的数据。

从上图我们可以看到下面有 4 个文件,在它的上面是 Driver 侧、Blocklet 文件级的索引根节点,4 个文件便是 4 个叶子节点。假设北京的数据只在第二个文件和第四个文件内,那么便只会命中这两个叶子节点,也代表着只有这两个文件是被命中的。

针对这个情况,Spark 就会下发两个 task 进行扫描操作,打开文件做扫描之前有个 Blocklet 索引,观察北京的数据在哪个 Blocklet 内。假设第一个文件在第三个 Blocklet 里面,就只命中这个 Blocklet,这个文件只有第一个 Blocklet 里面有北京的数据,得到这个信息,carbon reader 会只去读这个 Blocklet,如右边图,读的过程是读 C2 这一列,如果 C2 读出来没有北京的数据,那么直接过滤掉这个文件,如果有北京数据再继续读 C3、C4。因为这个 select  procheck 的是 C3、C4,整个过程是层层地避免去做不必要的 IO 计算,让查询能够更快。

扫描优化

如上图分析的是 Spark 2.1 之后做的集成。Spark2.0 之后有 whole stage 、whole job 和向量化,它在计算层有很好的技术,在存储层有很好的匹配。它有四个特性。大颗粒 IO 单元就是一次读取一个 Blocklet 中的某一个 Column Chunk,Blocklet 大概有一百万行的记录;跳跃解码只会按照 page 的顺序解码,有统计值,有 min max,根据过滤条件解码,减少不必要的解码解压缩,提上 CPU 利用率;与 Spark 对接需要做向量化解码和 Spark 向量化的处理;堆外内存,大报表生成业务需要扫描大量数据,因此会产生很多 GC,所以 Carbon 内部扫描之后会使用 offheap 内存保持数据,即把解码解压过程在堆外完成,以此减少 GC。

延迟解码

如上图所示,该图描述的是延迟解码特性,这个特性能提数据汇聚性能。比如这个例子,假设 C3 是个字符串,要在 C3 上做 groupby,string 是一个非常低效的 aggregation,如果我们能将 C3 从 string 变为 int 就能变成非常高效。所以我们做了一个全局字典特性,如果 C3 是 string,我们需要提前做 4 点编码,将所有的 string 变成 1,2,3,4 此类字典编码,然后在优化器看到这个 plan 之后, 使用延迟解码优化策略,用 int 值去做 GroupBy,最后当这个数据做完要交给用户之前,再将 int 值转成 string 值,这样便可提升 GroupBy 整个的性能。

前面介绍的那些内容,最终我们的落地点就是在 catalyst framework 内做集成。在 SQL 语法层面有一些语法的新增;Carbon 优化策略方面,在 Optimizer 内增加了延迟解码的规则,并且也希望未来和 CBO 做一些联合优化;在 Carbon Data Source 这一层的索引实际上是 Carbon 内部,所以可以利用 CarbonTableInputFormat 中的索引进行查询, Carbon 有新的语法可实现额外的 RDD,比如更新、删除这类 RDD。

总结

总结一下 CarbonData 技术上的 DNA。

查询方面,它主要实现了索引,索引有利于做 ad-hoc 过滤查询和维度组合的过滤查询,查询速度较快;它内部还有延迟解码和汇总统计向量化处理的操作。数据管理方面,比如实现增量入库、更新,删除,做一些维表的每天批量更新;它还能够做闲时的 compaction 合并,compaction 合并完之后同时将一些小的文件合并掉,可提升它的查询效率。

大规模和部署这两个优势是因为 carbon 是基于 hadoop 的文件,具有 Hadoop 高可用和高可扩展性的优势。

应用场景和调优介绍

下面重点介绍一下应用场景和调优手段。今天主要讲两个场景,一个是详单分析的场景,即明细数据分析、查询;第二个是传统数仓 BI 类应用。

详单分析

所谓详单分析,就是日志事件处理的分析、通过车联网传感器的反馈、用户行为分析、银行的流水表分析等这些都是明细数据查询。查询有以下几个方面的特点,首先它的数据量非常大,入库速度要求很高,生产上的经验大于每秒每节点的十万条记录,单表存储量很大,且因该类数据很宝贵,存储时间为一年以上,导致成本极高,所以对压缩率的要求也很高,压缩率越高,成本越小,然后可以保存更多的明细数据,用来以后做精细学习、AI 学习,以上都是数据的资产。

查询方面也有很多种应用,一种是剥离条件,需要给用户提供界面使用,用户勾选一些条件,界面就能返回一些结果。而有些却需要做模糊查询,比如身份证号码做匹配,或者把经常出现的 ID 变成一些真实的值,比如替换掉用户 ID,使之最终输出的是一些明细数据或者是对最终结果轻量的汇总。


详单分析的优化手段

详单分析的调优手段:

第一,过滤查询要快,即要选择合适的列和合适的顺序去建索引,调整 Blocklet 大小(因为 Blocklet 是最小读的单元),Blocklet 调小之后,点查速度会加快,它的目标是提升 pruning 效率,减少 IO。

第二,要求入库要快,建索引的同时不能做太大范围的索引,因为建大范围索引会导致入库减慢,我们在这个方向上做了一个 LOCAL_SORT 的入库方案,把建索引局限在某一台机器上,避免建索引时候做 shuffle;另外一个是不做全局字典,只需要对最后结果做即可,避免生成字典的扫描过程。

第三,压缩要高,使用自适应的 Encoding,系统会根据数据特征自动选择合适最优编码方式。

索引调优主要利用这两个属性, SORT-COLUMNS 和 SORT-SCOPE。

SORT-COLUMNS 就是把使用最常用的过滤列放入里面,比如 C1 和 C2,假设 C1、C2 是最常用的,因索引有顺序,在业务设计的时候需要将最常用的过滤条件识别出来,按照顺序放入 COLUMNS 选项里面。这对常用的过滤条件有着较高效率。第二个是 SORT-SCOPE,我建议大家在默认情况下使用 LOCAL-SORT,LOCAL-SORT 可以保证入库速度较快。如果大家不介意入库速度快慢可以用 GLOBAL-SORT,GLOBAL-SORT 可以做全局的排序,查询更快,但是入库会更慢一些。

过滤性能测试

如上图,过滤性能测试。C1 到 C10 是条件过滤,CarbonData 建的索引将 C1 到 C10 放入 SORT-COLUMNS,其对比对象是 Parquet,Parquet 建立的分区列是 C1 列。在这 8 个查询中,打勾即为该查询的过滤条件,比如 Q1 查询有 4 个过滤条件,C1 到 C4 过滤条件都存在,我们可以发现这个情况下,Parquet 跟 CarbonData 都比较快,Parquet 用 C1 列作分区,响应时间也比较快,CarbonData 也比较快。但是从后面查询便可以看到,Parquet 查询时间就高了,因为后面查询 Parquet 没有给出 C1 列,Parquet 便用全表扫描的方式查询,而 CarbonData 因为列放在 SORT-COLUMNS 里面,具有一定程度的排序,可通过索引找到合适的数据块。从 Task 数可以明显看到,Parquet 需要全部文件下发 Task,而 CarbonData 明显少一些。

在详单分析场景下,第二个需要调整的是 Blocklet 大小,Blocklet 大小影响着 Carbon 读文件的最小 IO 单元,如果将其调小,可以使点查询的场景 IO 更快,当然这前提要求是点查询是精确的,查 10 行、或者 3、4 行记录,在这种场景下将 Blocklet 调小,或者全表扫描下将值调大,这样更有利于全表扫描向量化处理。Carbon 内部还做了一个 Blocklet 调度,将参数改为 true 时,Carbon 会按照 Blocklet 返回 spilt 给 Spark,即会按 Blocklet 进行 task 下发,所以当命中数据较少、CPU 有剩余的时候,按照 Blocklet 调度 task 利用更多的 CPU 可以提升读取并发度。

第三点是 Encoding 调优手段。字符串,默认使用的是 UTF-8 字符串编码,我们将该字符编码称之为 derastring,即将长度与内容分别压缩,因此使用 snappy 压缩会更加有效。当大家创建表的时候,建议使用全局字典,因为全局字典压缩更有效,比如把深圳、北京、上海的值变成 1、2、3,数字型的压缩不需要 string。我们将其他数值型列称为度量列,比如说 byte、short、int,内部实现默认使用 adaptiveEncoding,系统会对每个 page 根据统计信息自动选择最优的存储结构。比如 long 的数据,它的数据本身需要 long 去存储,但可能用 byte 就可存储了。

自适应编码

如上图所示。

第一个例子,C1 在 Schema 里面是 long 型,数据存储是 279357,最大值是 9,最小值是 2,该数据其实并不需要用 long,但是 Schema 写了 long,这种情况在实际存储的时候会转成 byte 型,甚至比它更小的 byte 去存,以此减少整个数据大小。

第二个例子是使用 long 存储很大的数字,但是最大值和最小值相差只有 31,因此实际差值可以用 byte 存储,这里实现了 AdaptiveDeltaEncodnig 方法,其实际存储值为 max-value,因减下来的数值为 0-31 之间可以用 byte 去存储。

第三个例子,对 double 型数值需要计算小数点尾数,scale 是后面精度值。double 是八字节,它是非常耗存储的类型,但是如果把它都乘 100 之后,它便变成了 short 类型,只需 2 个字节便可存储,在解压的时候除以 100 还原回去即可。

我们做了过一个测试,用 TPC-H LINEITEM 事实表,生成 1GB 的数据,对比压缩率。该数据是使用标准的 TPC-H 生成器生成。经过 AdaptiveEncodnig 之后,Carbon 对比 ORC、Parquet 都是最优的,对 int、double、date 都至少是最好的水平。举个例子,Short string 利用字典编码,字典编码以后都变成 1、2、3、4,这样的话,字典数据只需要 64kb 便可以存储,而 ORC 需要 5.5MB。

详单分析案例

我们看一个具体的案例,在电信、金融行业里面经常会遇到明细数据分析,在分析优化之前,老的系统需要用两个系统,Impala 和 HBase。HBase 做点查需要建立 4 个二级索引才可以完成业务需要的性能要求。Impala 用来做报表输出。这两个系统有各自的不足,Impala 没有办法很好的扩展,难以扩展上百个节点;HBase 要做很多二级索引,没有办法用 Yarn 在一个企业里面统一进行部署,只能是一个个集群单独维护。用 CarbonData 加 Spark 组合数据优化后,可以解决既要点查又要处理报表的情况,又可以做很好的扩展。

大数据集 Scale out 测试

如上图。大数据集 Scale out 测试结果。采用七十个节点,测 1 万亿数据,该测试场景是从 2000 亿测试到 1 万亿数据时候的性能表现,其中 Q1 是过滤查询,Q2 也是过滤查询,由于使用 CarbonData 索引,Q1 和 Q2 数据过滤查询时间不会因为数据量的增长而增长很多,数据量增长 5 倍,时间增长一倍不到。Q3 查询是 full scan 查询,表越大,全表扫描时间越长,它主要考察的是 Spark 能否进行计算。

前面讲解了详单分析场景,支持了大多数详单分析的场景,但是有一些基于详单的扩展场景目前还没有很好的支撑。例如下面这三个场景。

第一是实时详单需求,它能否分析 1 分钟前的数据,甚至分析十秒钟前的数据,例如在运维场景中需要实时查询 10 秒钟前发生的事件。未来针对这种场景 carbon 会和流计算引擎相配合,实现准实时分析。

第二是日志类分析,日志类分析包含很多非结构化、半结构化的数据,目前 carbon 只能通过扫描的方式去做模糊匹配,未来希望通过业界的文本索引库来增强这部分能力,比如利用 Apache Lucene 的索引能力。

第三时间序列分析。时间序列分析有几个特征,数据是严格按时间过来的,每条记录的时间有一定规律,在存储层面进行很多优化操作,比如利用时间特征做深度压缩,数据预汇聚,数据快速老化等。

数仓 BI 分析

第二种应用场景是数仓 BI 类分析,即每天出现的报表,比如经营报表、财务报表等。报表应用的特点是每天晚上入库,今天分析昨天的,所以入库速度要求不高,一般情况只要 6 点前入库完,8 点前把报表准备好就可以。但是表间关系很复杂,存储压缩率越高越好。workload 特点是有些分析可以事先确定,因为报表是之前业务方设计的,他知道要什么报表;它会做一些很复杂的查询,一些深度的多层子查询,我们见过最复杂的可能有几百行,因此它也考验扫描能力和优化器能力。

数仓分析的调优手段目标是侧重于计算和存储压缩能力。调整 SORT_COLUMNS 顺序,提升压缩率,NDV 较低的列排序在前面,其压缩会更好,可减少读取数据量;利用分区做 Partition pruning,例如针对天做报表可以使用时间 range 分区,以及对每天报表做定期的 compaction,避免小文件的产生。计算方面要打开 Carbon 向量化 Reader,与 Spark 向量化处理相结合,可以实现更高性能的汇聚、排序等计算操作;另外还有一些调整内存和并发度的选项,如 spark.sql.shuffle.partitions,建议设置为节点数 *2,可以使汇聚计算更快。对 Join 的优化有一个 bucket 特性,两个表如果在一个 Key 上,比如在 USERID 上面做 Join,可以在 USERID 上建立 bucket,做 join 时可以避免大量 shuffle。

针对 BI 汇聚场景,还可以使用 carbon 的全局字典特性,通过 dictionary-include 的属性把你所要的列作为字典列 INCLUDE 进来,一般我们会选择那些需要做 Groupby 的而且基数(NDV 值)不高的列,因为建立全局字典是有代价的,如果 NDV 值太高(比如 100 万),入库时占用内存可能太大。而根据我们经验,一般的 GroupBy 列都是基础比较低的。向量化读是设置参数 carbon.enable.vector.reader 为 true。最后,在 Compaction 文件合并方案,可以设置让 carbon 在入库同时自动做 compaction,也可以使用 ALTER TABLE COMPACT 命令手动触发 compaction,达到合并文件和索引的目的,使查询更快。

数仓 BI 案例

如上图,该案例是电信里面的案例。电信经常做流量分析报表,在传统架构里,一般都会选择传统书库,当业务数据量不大时,可以较好满足要求,但带来问题:一是成本较高,需要包含磁盘阵列、光交换机等硬件,

二是因为对硬件有以来,架构无法支撑云化部署,

三是在部分场景随着数据量增加查询性能无法满足业务要求。

当时我们有一个产品就是遇到了这些问题,数据库就没有很好的办法适应,后来我们把这个数据库换成 Spark 加 Carbon 的架构。

首先它不需要使用传统磁盘阵列,这样对上云非常有好处,也不需要绑定特殊的硬件;

第二,整体性能获得提升,大概有 3-8 倍的性能提升,最后成功迁移 15 个业务,现在每 15 分钟、1 小时、一天增量加载数据,最快可查到 15 分钟前的数据,同时因为 carbon 索引可以减少 IO 读取,由此使并发查询能力也得到提升。系统切换后,业务响应时间明显缩短,希望后续将更多业务搬迁到 carbon 上来。

未来计划

回顾一下 CarbonData 提出的最初愿景是尽量融合一份数据完成更多的业务,使总体使用成本更低。除了 SQL、传统的报表分析之外,在大数据时代还有很多分析对存储提出了更高的要求,包括时间序列分析、位置分析、文本检索、机器学习等,例如 IOT 时代越来越多的传感器,各种各样的时间序列数据都会传到数据中心,数据中心需要各种各样的时间序列分析、图分析、空间位置、轨迹、车轨迹的分析以及文本的检索。当前我们的解决方案是每一个领域、每一个应用都有一个库去对应,企业的做法是不断对数据做 ETL,从一个数据库中搬到下一个库,这中间需要很多次业务建模、业务适配,这整个是一条很复杂的数据流水线,在一些时候这是唯一的方案,但在有些时候就把简单问题复杂化了,不利于企业充分利用资源,也不利于快速推出新业务,更无法做关联分析,跨库分析等新业务。

CarbonData 2.0 目标

CarbonData2.0 希望基于沿着融合数据的道路上更近一步,用一份存储来支持多业务系统,包括 SQL 的分析、时间序列分析、位置轨迹、文本检索、图和机器学习。这里面有些领域,存储的优化可以加速领域内的某些关键操作,把一个业务所需要的操作都加速了,那么这个业务的数据就能统一方案一起了。具体在系统特性方面,未来要考虑实时事件流式准实时入库,分钟级事件、历史事件批量入库这两种入库方案。

存储分三层:

第一层是界面分析的语言,每一个领域有自己的术语表达,比如轨迹的点、距离的位置分析、文本的模糊匹配,这个界面是基于 SQL 做领域的扩展。

第二层是数据组织层,对不同领域做不同索引和预处理,让它更好地适应这个领域,提前将数据组织好,这里我们抽象了一个 DataMap 数据结构,来更好的满足各领域对索引的要求。

最下面一层是文件格式本身,CarbonData 目前是列存,为了支撑更多查询和分析。数据格式本身是也是需要扩展的。这些特性会随着未来 CarbonData 的版本陆续推出。

最后,非常感谢大家来参加这次 meetup,Apache CarbonData 1.2 版本目前也正在社区跳票中,预计 9 月下旬会正式发布,欢迎大家试用和反馈建议。相信通过开源社区的力量,Carbon 未来会给业界提供更优秀的数据解决方案,帮助大家解决更多业务问题。


讲师介绍

李昆,Apache CarbonData committer,华为技术有限公司大数据软件架构师。2004 年加入华为,长期从事电信协议、数据可视化、用户行为分析等系统研究和开发工作。近年致力于大数据技术研究,参与 Hadoop、Spark、Alluxio 等开源社区,2016 年作为 CarbonData PMC 成员参与 Apache CarbonData 项目孵化,寻求大数据与云计算的创新机会点。


今日荐文

点击下方图片即可阅读




LinkedIn 的机器学习实践




课程推荐

斯达克学院(StuQ)倾心打造《3个月掌握Python机器学习》大课,专为对机器学习感兴趣、想从事相关职业的零基础学员打造,带领学员全面系统地掌握Python机器学习的相关知识,并能够胜任Python机器学习中级工程师及以上的工作。现团购价只要1999,感兴趣请添加小助手详细咨询。

Apache顶级项目CarbonData应用实践与2.0新技术规划介绍 2017-09-22
Tagged on: