大数据分析与列数据库
数据库与大数据分析平台集成
数据库与大数据分析平台集成随着互联网的发展和技术的进步，大数据已经成为现代企业分析和决策的重要依据。
为了更好地利用大数据进行分析和预测，企业需要将数据库与大数据分析平台进行集成。
本文将探讨数据库与大数据分析平台集成的意义、实现方法以及集成后的效果。
一、集成的意义数据库与大数据分析平台的集成可以帮助企业将存储在数据库中的海量数据与分析平台相连接，实现数据的实时流转，从而提供更加准确、全面的数据分析和预测结果。
通过集成，企业可以对大数据进行更深入的挖掘和分析，以找到隐藏在数据中的商业价值和市场趋势，从而为企业的决策提供更加准确和有力的支撑。
二、实现方法1. 数据同步将数据库中的数据与大数据分析平台进行同步，可以采用定期增量同步或实时同步的方式。
定期增量同步是指在一定时间间隔内，对数据库的数据进行更新，然后将更新后的数据同步到大数据分析平台。
实时同步则是指在数据库数据更新时，立即将更新的数据同步到大数据分析平台。
数据同步可以保证两个系统中的数据始终保持一致，使得分析过程更为准确和可靠。
2. 数据转化与清洗在将数据从数据库同步到大数据分析平台之前，需要进行数据转化和清洗的过程。
数据转化是将数据从数据库中的结构化格式转化为大数据分析平台可读取的非结构化格式，如将关系型数据库中的数据转化为基于Hadoop的分布式文件系统中的数据格式。
数据清洗则是对数据进行去重、筛选和格式规范化等操作，保证数据的质量和准确性。
3. 数据分析与挖掘在数据同步和清洗完成之后，可以利用大数据分析平台的强大功能对数据进行深入的分析和挖掘。
大数据分析平台具有分布式计算和存储能力，能够处理海量数据并实现复杂的算法运算。
通过数据分析与挖掘，可以提取出数据中的关键信息和潜在规律，帮助企业做出更准确的决策。
三、集成后的效果数据库与大数据分析平台集成后，企业可以获得以下几方面的利益：1. 数据驱动决策通过数据库和大数据分析平台的集成，企业可以将决策过程变为数据驱动的过程。
大数据分析知识：数据存储与管理——数据仓库、云计算和数据库
大数据分析知识：数据存储与管理——数据仓库、云计算和数据库随着技术的不断发展，越来越多的数据产生并蓄积，如何进行有效管理和利用已成为人们关注的焦点之一。
本文将从数据存储和管理的角度出发，分别介绍数据仓库、云计算和数据库的概念、特点及其在大数据领域的应用。
一、数据仓库数据仓库（Data Warehouse）是指从各个数据源中提取数据并经过处理后存储到一个统一且独立的数据集合中，以方便用户进行分析和决策的系统。
数据仓库通过将数据分析和查询分离，实现了数据决策支持系统的高效运行，从而提高数据的利用率。
数据仓库的特点：1.面向主题：数据仓库是面向主题的，即数据集中一般针对某个主体领域或数据分析任务。
例如，销售数据仓库、人力资源数据仓库等。
2.集成性：数据仓库具有集成性，可以将不同类型的数据源通过ETL（Extract-Transform-Load）的方式进行标准化、转换和加载，并保证数据之间的一致性和完整性。
3.时间性：数据仓库关注历史数据的存储和分析，并提供不同时间维度的数据展示方式，为决策者提供多样化的选择。
数据仓库在大数据领域的应用：1.数据分析和挖掘：通过数据仓库中的数据进行多维分析和数据挖掘，为决策者提供全面的数据支持。
2.企业级统一视图：数据仓库可以实现企业级统一视图，使决策者可以获得一份全面的数据报告。
3.交互式查询：数据仓库提供交互式的查询功能，用户可以根据需要自定义查询条件和维度，获得满足自己需求的数据结果。
二、云计算云计算（Cloud Computing）是指通过网络以服务方式提供计算资源的一种模式。
云计算基于分布式计算、虚拟化技术和自动化管理，通过网络实现数据处理和存储，通过服务模式进行资源使用和计费。
云计算的特点：1.弹性伸缩：云计算可以根据需求进行弹性伸缩，为企业和个人提供更加灵活的资源使用方式，从而降低IT成本、提高效率。
2.服务化：云计算基于服务的方式提供资源，用户可以根据需要选择提供商和服务类型，并根据实际使用量进行计费，降低了技术和资金门槛。
数据库新技术及发展趋势
数据库新技术及发展趋势随着信息时代的到来，数据库技术也在不断发展和创新。
新技术的应用不仅提升了数据库的性能和容量，还改变了数据库的管理和使用方式。
本文将介绍一些当前数据库领域的新技术，并探讨其发展趋势。
一、云计算与数据库云计算是近年来快速发展的技术，其将计算资源和存储资源通过互联网提供给用户使用。
数据库作为云计算的重要组成部分，也在不断发展。
1.1 云数据库云数据库是基于云计算平台的数据库服务，用户无需购买和维护硬件设备，只需通过网络访问云上的数据库。
云数据库具有高可用性、弹性扩展和灵活性等特点，成为企业数据管理的新选择。
1.2 数据库即服务（DBaaS）数据库即服务是云计算的一种模式，用户无需关注数据库的底层技术和运维工作，只需通过简单的接口就能快速创建和管理数据库。
DBaaS提供了灵活的数据库服务，使用户能够专注于业务逻辑的开发。
二、大数据与数据库大数据的快速发展对数据库提出了新的挑战和需求。
为了应对大数据的存储和处理需求，数据库技术也在不断创新和改进。
2.1 分布式数据库分布式数据库将数据分布在多个节点上进行存储和处理，提高了数据库的可伸缩性和容灾性。
分布式数据库能够处理大规模数据，并支持并行查询和分布式事务。
2.2 列式数据库传统的关系型数据库以行为单位存储数据，而列式数据库以列为单位存储数据。
列式数据库适用于大数据场景，能够提高查询性能和压缩比率。
列式数据库在大数据分析和数据仓库等领域有广泛的应用。
三、人工智能与数据库人工智能技术的发展也对数据库提出了新的要求和挑战。
数据库需要支持大规模数据的存储和处理，并能够处理复杂的查询和分析需求。
3.1 图数据库图数据库以图的形式存储数据，并提供了高效的图查询和分析功能。
图数据库适用于处理复杂的关系和图结构数据，广泛应用于社交网络分析、推荐系统和欺诈检测等领域。
3.2 内存数据库内存数据库将数据存储在内存中，提供了低延迟和高并发的数据访问能力。
内存数据库适用于实时数据处理和高性能应用场景，如金融交易系统和实时监控系统。
大数据分析平台与传统数据库的性能比较探究
大数据分析平台与传统数据库的性能比较探究随着互联网技术的不断发展，数据量呈现爆炸式增长，数据分析已成为企业发展中不可或缺的组成部分。
而大数据分析平台与传统数据库的性能比较也成为了一个备受关注的话题。
本文将探讨这两者的性能比较，并分析它们各自的优缺点。
一、大数据分析平台大数据分析平台（Big Data）是一种基于分布式计算模型的数据处理平台。
它可以帮助用户提高数据分析的效率和准确性，并为用户提供可视化的分析结果。
大数据分析平台主要由以下组件构成：1.计算集群：由大量计算机节点组成，可同时执行多个任务，缩短数据处理时间。
2.存储系统：多个存储单元组成，用于存储海量数据，保证系统的可扩展性和高可靠性。
3.分布式文件系统：类似于Hadoop的分布式文件系统（HDFS）。
它将文件切分成多个块，存储在不同的节点上，使得文件的读写速度更加快速。
4.分布式计算框架：类似于MapReduce的分布式计算框架，用于实现并行计算和数据处理。
5.数据分析工具：支持数据分析、可视化分析等。
根据目前市场上的数据分析平台，主流的大数据分析平台有Apache Hadoop、Spark、Flink等。
优点：1.具有非常强大的数据处理和计算能力，适合处理海量的数据。
2.高度可扩展性，可以对系统进行相应扩展以满足数据处理的需求。
3.具有较高的容错性，能够在某些计算节点出现故障的情况下，仍能保证系统的正常运作。
缺点：1.对于一些数据量较小的场景，使用大数据分析平台反而会造成资源浪费。
2.由于其分布式架构的复杂性，需要较高的技术水平才能进行系统的维护和管理。
3.数据处理也需要耗费大量的计算资源。
二、传统数据库传统数据库是一种基于关系型模型的数据处理平台。
它的数据存储方式为表格形式，通过SQL语言进行数据操作和查询。
现如今应用比较广泛的数据库有MySQL、Oracle、SQL Server等。
优点：1.易于使用，有成熟的交互式管理工具，可以通过简单的命令或者GUI界面完成对已有数据表的操作。
大数据与数据库
2.4大数据预处理
对采集到的原始数据所进行的诸如“清洗、填补、规格化”等操作，旨在提高数据质量， 为后期分析工作奠定基础。
数据清理：利用ETL等清洗工具，对有遗漏数据(缺少感兴趣的属性)、噪音数据(数据中存在 着错误、或偏离期望值的数据)、不一致数据进行处理。
数据集成：将不同数据源中的数据，合并存放到统一数据库的，存储方法，着重解决三个 问题：模式匹配、数据冗余、数据值冲突检测与处理。
数据转换：对所抽取出来的数据中存在的不一致，进行处理的过程。它同时包含了数据清 洗的工作，即根据业务规则对异常数据进行清洗，以保证后续分析结果准确性。
数据规约：指在最大限度保持数据原貌的基础上，最大限度精简数据量，以得到较小数据 集的操作，包括：数据方聚集、数据压缩、数值规约、概念分层等。
2.5大数据存储
非结构化数据主要是指没有固定的数据结构，且不方便用数据库二维逻辑来表现的数据。非结构 化数据没有预定义的数据模型，因此，它覆盖的数据范围更加广泛，涵盖了各种文档。如存储在文 本文件中的系统日志，文档、图形图像以及音频和视频等数据都属于非结构化数据。
1.3大数据的特征
大数据的数据产生方式为主动生成数据， 其数据采集密度方面为利用大数据平台，可 对需要分析事件的数据进行密度采样，精确 获取事件全局数据，数据源方面可以利用大 数据技术，通过分布式文件系统、分布式数 据库等技术对多个数据源获取的数据进行整 合处理，在数据处理方式方面，较大的数据 源、响应时间要求低的应用可以采取批处理 方式集中计算，响应时间要求高的实时数据 处理采用流处理的方式进行实时计算，并通 过对历史数据的分析进行预测分析。
2.2大数据的关键技术
大数据的关键技术
大数据采集 大数据预处理 大数据存储及管理 大数据处理 大数据分析及挖掘 大数据可视化 大数据安全与隐私保护
大数据分析数据库
大数据分析数据库随着信息化时代的来临，数据已成为了一种非常宝贵的资源，更是现代企业进行决策的重要依据。
随着数据量的不断增加，人们对数据的处理方式也不断发生变化，目前最流行的数据处理方式就是使用大数据分析数据库。
本文将从大数据分析数据库的概念、功能、应用以及未来发展等方面进行探讨。
一、概念大数据分析数据库是一种能够处理海量、多样化和复杂化数据的数据库系统。
它不仅能够存储大数据，还能够快速有效地进行数据挖掘、数据分析和数据可视化等相关工作，以帮助企业解决复杂问题和制定决策。
与传统的关系型数据库相比，大数据分析数据库的优势在于能够承载非结构化数据和半结构化数据，并快速进行处理。
二、功能大数据分析数据库采用多种技术手段，包括机器学习、自然语言处理、数据挖掘、图形处理、并行计算等。
它能够完成以下几个功能：1、存储大规模数据大数据分析数据库可以存储成百上千的数据，包括结构化、半结构化和非结构化数据。
这些数据可以来自各种渠道，例如传感器、社交媒体、传输协议和数据传输。
通过使用分布式系统，大数据分析数据库能够快速处理大规模数据。
2、数据挖掘数据挖掘是大数据分析数据库的主要功能之一，它可以帮助企业发现数据中隐藏的模式、趋势和关系。
通过挖掘数据，企业可以更好地了解自己的业务，并制定更好的决策。
3、可视化分析大数据分析数据库可以通过图表和可视化方式来显示数据，以帮助企业更好地理解数据。
这种分析方式将数据转化为可视化元素，从而让数据更具体化和易于理解。
三、应用大数据分析数据库已成为企业进行数据分析和决策的标配。
以下是大数据分析数据库在不同行业中的应用：1、金融行业金融行业的数据量非常巨大，因此大数据分析数据库在金融行业中具有重要作用。
它能够变现金融数据中的复杂性，并帮助金融机构进行风险控制和决策制定。
2、零售业在零售业中，大数据分析数据库可以帮助企业更好地理解消费者观念，并提供更好的客户体验。
通过分析顾客的购买历史和行为，企业可以制定更精准的营销策略，同时提高转化率和忠诚度。
大数据存储与分析技术在数据库中的应用实践案例
大数据存储与分析技术在数据库中的应用实践案例随着互联网和计算设备的迅速发展，我们正处于一个数字化时代。
企业、政府和个人生成和收集了大量的数据，这些数据包含了宝贵的信息和洞察力，对于业务决策和创新非常重要。
然而，传统的数据库技术已经无法满足海量数据的存储和处理需求。
因此，大数据存储与分析技术成为了当今业界关注的焦点。
本文将介绍几个大数据存储与分析技术在数据库中的应用实践案例，以展示它们的重要性和成功。
这些案例涵盖了不同行业和领域，充分说明了大数据存储与分析技术的多样化应用。
首先，我们来看看电子商务领域。
互联网电商平台面临着海量的用户数据和交易数据。
这些数据对于电商企业来说非常重要，可以帮助他们了解用户的喜好和购物习惯，以便进行个性化推荐和精准营销。
许多大型电商平台已经部署了大数据存储与分析技术，通过分析用户的浏览历史、购买记录和点击行为，为用户推荐定制化的产品。
这不仅提高了用户体验，还增加了电商企业的销售额。
其次，金融领域也是大数据存储与分析技术的重要应用领域之一。
金融机构每天处理大量的交易数据、市场数据和客户数据。
这些数据包含了重要的金融信息和趋势，对于风险控制、投资决策和客户关系管理至关重要。
通过利用大数据存储与分析技术，金融机构能够更快速和准确地发现潜在的风险信号、掌握市场趋势和优化投资组合。
例如，一些银行利用大数据存储与分析技术构建了风险模型，可以实时监控交易活动并及时发现异常行为。
这种技术的应用可以及时预警可能的金融风险，提高金融机构的安全性和稳定性。
在医疗领域，大数据存储与分析技术也发挥了重要作用。
医疗行业不断产生大量的病历、检查报告和生物医学图像等数据。
这些数据对于临床决策、疾病预测和治疗方案制定非常重要。
通过利用大数据存储与分析技术，医疗机构可以更好地利用这些数据，提高医疗质量和效率。
例如，医院可以通过存储和分析大量的病历数据，发现患者的病情变化和病情趋势，提前预测并防止并发症的发生。
列式数据库的研究
列式数据库的研究列式数据库是一种用于存储和管理海量数据的数据库技术。
与传统的行式数据库相比，列式数据库以列为单位存储数据，而不是以行为单位。
由于其独特的存储方式和数据结构，列式数据库在处理大规模数据分析和实时查询方面具有显著的性能优势。
传统的行式数据库使用行存储的方式，它们将一行数据的所有字段存储在一起。
这在查询指定行的数据时速度较快，但在进行聚合查询和更新操作时会遇到性能问题。
因为在行式存储下，需要扫描整行数据来计算聚合结果，而且每次更新操作都需要将整行数据写入磁盘。
当数据量非常大时，这种操作会导致性能下降。
相比之下，列式数据库按照列存储数据，每列的数据连续存放在一起。
这种存储方式使得列式数据库在聚合查询、大规模数据分析和快速查询方面表现出色。
由于数据存储在列中，只需要读取需要的列数据即可，大大减少了磁盘的读取量。
此外，列式数据库还能够高效地进行压缩，进一步减少存储空间占用。
1.存储和压缩技术：在列式数据库中，数据存储和压缩是关键技术。
研究者通过设计高效的存储结构和压缩算法，使得列式数据库能够在有限的存储空间下存储更多的数据。
其中，列存储和位图压缩是列式数据库中常用的技术。
2.查询和优化算法：列式数据库需要设计高效的查询和优化算法来实现快速的数据查询和分析。
研究者通过优化查询计划、并行化查询操作和使用高级索引等方式来提高查询性能。
此外，还可以利用预处理和缓存技术来减少查询的延迟。
3.数据一致性和事务管理：列式数据库通常被用于大数据分析场景，需要能够处理复杂的数据一致性和事务管理问题。
研究者通过设计高效的并发控制和事务管理机制，来保证数据的一致性和可靠性。
4.分布式存储和处理：随着大数据技术的发展，列式数据库的研究也开始关注分布式存储和处理。
研究者致力于设计高效的分布式存储和处理框架，以应对海量数据的存储和计算需求。
总之，列式数据库的研究旨在提高大规模数据分析和实时查询的效率和性能。
通过存储和压缩技术、查询和优化算法、数据一致性和事务管理以及分布式存储和处理等方面的研究，列式数据库可以更好地支持大数据应用，满足企业和科研机构对于高效数据分析和查询的需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
大数据分析与列数据库近年来随着数据量的激增，对于数据分析的需求也日益迫切，传统的RDBMS已经远远不能满足企业对大数据分析的需求，虽然很多厂商都声称自己具有列数据库的特性，但是绝大多数都不具备处理真正大数据的能力，在今年8月份，Google 在VLDB 2012大会上发表了<< Processing a Trillion Cells per Mouse Click>>论文[1]，展示了Google新的大数据分析技术PowerDrill, 本文将借用这篇论文的实验数据，结合笔者的上一篇Hadoop文件格式[2]的内容介绍更多大数据分析中列数据库的核心原理, 希望读者能对列数据库的原理有更多了解，也希望对将来Hadoop在针对数据分析方面能够有更多优化, 并对一些忽悠的厂商和空喊口号的技术有辨别能力。
列文件格式和压缩在常见的列数据库技术中，一个总是被混淆的概念是面向列储存和面向列的压缩(Column storage and Columnar compression, 见参考资料[3]) , 面向列储存指的是将同类数据放在一起，这类数据在物理磁盘和物理内存上表现为连续空间，也就是我们熟称的”将不同列分开放”(这个描述并不准确但是更容易理解), 而面向列的压缩是指将不同的数据以更小的代价存放在磁盘或内存中，它往往包括非常高效的编码和解码技术(Encoding and Decoding) , 比如Run Length Encoding , BitVector Encoding ,真正的列数据库中会包括与这些压缩格式相对应的延迟物化技术(later Materialization), 高效的压缩格式和延迟物化特性是真正列数据库和伪列数据库之间查询性能和集群吞吐能力的最主要差别.高效压缩之Run length EncodingRun length Encoding将同一列的连续数据压缩成它的实际数值和这个数值出现的连续次数，比如AAABBBBBCCCCCCC 这样一个包含15条数据的某列数值，run length encoding 会将它压缩成一个三元数组(实际值,起始位置,个数)，比如上面的数值会压缩成[A,1,3][B,4,5][C,8,7]的格式,从而使原始的数据无论在磁盘还是内存中都可以占用更少的空间，由于run length encoding 的特性，数据往往需要重新排序从而得到更好的结果，在实际生产环境中,性别，年龄，城市等选择性非常高的列往往都是run length encoding处理的对象.在列数据库中数据往往会经过多层排序，比如第一层排序为性别，第二层排序为年龄，第三层排序为城市, 即使那些本来选择性不算高的列，在排序之后的小范围区间内也可能使类似的记录满足run length encoding 的压缩条件，从而使记录更加适合压缩.高效压缩之Bit-Vector EncodingBit-vector encoding 是数据仓库中最常用的优化手段,行数据库中使用的一般为bitmap index, 它一般只针对单个列而且是额外的存储结构，列数据库中的bit-vector encoding 主要针对数据本身而且含有较少的唯一值才进行编码，在这种编码中,会先储存所有出现过的值，然后使用bit 数字1来表示实际这个数值是否出现在列中，其他bit位用0来表示. 比如某个chunk的数值为:A A C C D D AB EBit-Vector encoding会使用ABCDE这样的字典来储存实际的值，然后使用:110000100 : 对应bit-string 值A000000010 : 对应bit-string 值B001100000 : 对应bit-string 值C000011000 : 对应bit-string 值D000000001 :对应bit-string 值E在上面的例子中，每一个bit-string 的值没有为8的倍数，所以后面的bit位就被浪费掉了.当唯一值越多，需要编码的数值越多，则整个向量空间越稀疏并且消耗就越大，这是行数据库中bitmap index 低效且不可伸缩的关键因素(包括Hive 0.8 引入的bitmap index也是如此).在列数据库中，因每一部分数据块单独存放(PowerDrill 假设一个数据块大概存放2千万条记录), 并且每个数据块都只维护自己的少量唯一值，所以Bit-Vector encoding所消耗的空间无论是磁盘还是内存都极少并且不会有伸缩方面的问题. 在处理Bit-Vector encoding 的计算时，比如对应上面例子某个查询需要知道字符串为B的个数时，只需要将bit-string B进行位操作即可得到, 这比普通的hashmap 计数器的计算方式会快上几个数量级. Bit-Vector Encoding一般并不要求数据本身排序，但是近来有研究表明不管是对数据表的列顺序还是列顺序一定情况下行数据的重新排序都会使Bit-Vector Encoding使用更少的磁盘和内存空间[6][7]. Google PowerDrill通过实验证明对行数据重新排序会对查询性能有1.2倍到2.8倍的提升，并且内存比不排序的情况下消耗更少.Trie EncodingTrie数据结构一般也叫prefix trees, 一般用在数据类型为string并且排序之后有明显倾斜的数据分布的列，比如URL , 家庭住址, 这些字段的前缀经过排序之后在局部区域往往都有很高的压缩比，在最近的Hbase 里面也使用了这种方式压缩rowKey 的部分，Google PowerDrill也同时使用Trie Encoding压缩由”字典表”和”字典表所在位置”所组成的文件格式及其对应的内存数据结构.其他编码方式和压缩编码和解码不同于压缩，编码和解码一般针对特殊数据和特殊的类型，一般消耗的CPU也远远小于压缩所消耗的CPU，更多时候需要对数据重新排序才能取得更好的压缩比，这种排序既包括列的选择性高低也包括在局部地区重新调整行的顺序. 除了上面提到的Power Drill 常使用的Run length Encoding , Bit-vector encoding ,Trie Encoding 之外, 常见的编码还包括:l 针对字符或文本的”Dictionary Encoding”:比如email 地址, 家庭地址. 这种编码一般不需要排序，主要为了节省储存空间和少量内存空间，对查询处理时间有所提升.l 针对固定间隔类型数据的”Delta Encoding” : 比如日期，时间，时间戳和等间距长的数据类型，一般不需要排序，针对特殊应用，比如定时输出数据的监控系统（主机负载，网络流量等）,这种编码无论磁盘还是内存的压缩率都极高,并且对应查询处理时间也有明显提升.l 有时候为了编码会将两个或多个字段进行组合,使用Trie Encoding 或者”变长间隔编码”进行处理，这些编码只在非常特殊的数据类型或者数据倾斜下使用，有时候只减少磁盘空间而对查询时间没有提升，甚至使用不当会增加CPU解码的负担而提升效果较小.Run length Encoding和Bit-Vector Encoding一般对某些列压缩会减少储存3-4个数量级，对内存提升也有2-3个数量级，Dictionary Encoding和Trie Encoding一般对磁盘空间减少大概20倍，对内存空间大概减少5倍，根据Google PowerDrill的实验，在常见的聚合查询中这些特殊的编码方式会对查询速度一般有2-3个数量级不等的提升.上面描述的只是最简单的情况，实际生产环境中要比这复杂的多，run length encoding , Bit-Vector Encoding 和Dictionary Encoding在何时使用的情况比较好判断，有些其他的编码方式则会出现时间和空间转换比率的权衡问题，比如run length encoding对于连续出现次数小于几十以下的情况提升就不明显，还有Dictionary Encoding在建立字典表的时候对于重复次数小于多少次的字符串就不储存在字典表中，以免压缩比率提升不大反而解压缩的消耗反而大增.至于具体的阈值怎么取舍，根据不同的集群硬件情况，数据分布情况，需要作出不同的调整.压缩对编程语言垃圾回收也非常有提升，因为在物理内存上更加连续，使得gc 的处理时间缩短, 操作系统page cahe 换入换出更快,具体可以查看参考资料[3]压缩往往是针对原始二进制数据,对不同数据类型的提升差别不大，生产系统中一般同时使用编码解码和压缩. 常用的压缩算法包括gzip,bzip,LZO,snappy 等，在Google PowerDrill 的实验中，对已经使用特殊编码和解码的数据继续压缩对内存和处理效率已经提升不大，甚至有可能为了减少内存空间而增加查询处理的延迟，google权衡考虑cpu的消耗，内存提升效率，解压缩的速度而使用了一个修改版的LZO 压缩算法, 并称相比较已经编码和解码的数据，修改版的LZO压缩还能提高1.4倍到2倍的磁盘空间和10%的内存空间，同时解压缩速度比google开源的snappy要快。
为了避免对应的查询处理延迟问题，Google 同时使用一个2层缓存，将更加常用的热点数据不压缩只编码，将较少使用的温热数据压缩，为了保证缓存的有效利用，根据不同的数据访问频次会在2层缓存中交换以节省内存消耗.Skip List数据结构在主要以查询为主的数据仓库中，某些列的唯一值会远远多余其他列，比如性别，年龄，城市，商品类别，这些唯一值更少的列往往会作为查询的过滤条件，所以最早的C-Store论文[8]提出Projections的概念，将那些经常作为过滤条件并且可以过滤掉大部分值的列作为排序字段，这些字段以不同的组合组成不同的先后顺序，比如一种Projections以性别为第一排序字段，城市为第二排序字段，这在那些主要关注性别和城市的查询时候会过滤掉大部分的数据，对于那些关注年龄和商品类别的查询，可以创建另外一个以年龄为第一排序字段，商品类别为第二排序字段的Projections. 完全从磁盘和内存压缩的角度来讲，以选择性高低为排序顺序一般会得到最大压缩比，但是查询并不一定用到这些高压缩比的字段，所以选择Projections 的排序字段一般会选择那些唯一值较少但是又经常作为过滤条件的字段.根据Google 的实际生产系统经验，那些经常过滤的字段一般业务人员很容易通过领域知识得出，所以只需要按照这些过滤字段的选择性排序即可. 作为C-Store的商业版本Vertica 可以使用实际的线上生产系统的负载来帮助用户选择更加合适的高效过滤字段组成Projections，从而避免因选择不当而造成系统资源浪费.Google PowerDrill论文中习惯性叫Projections的排序字段为”组合范围分区”(composite range partitions),这不同于常见的RDBMS中的分区，首先，RDBMS的分区主要有范围分区，值分区，哈希分区或前面三种的组合，RDBMS分区主要为了性能的提升和数据管理的简化（比如分区索引，分区删除，修复和备份），这种分区往往都是物理上进行切分，列数据库中的Projections主要是为了压缩效率，查询性能和提高系统的吞吐能力，使用高级压缩功能可以使磁盘容纳更多数据，更少的内存代表系统可以同时执行更多的查询，并且Projections的分区并不是物理分区而仅仅是逻辑分区，在一个集群的每台机器上都可以存放多个数据块,比如PowerDrill中的每块数据含有2千万条数据, 这样系统可以实时的加载数据因为数据会平分到多个数据块(类似于Hbase 里面的Distributed Log Split原理)，对于RDBMS的物理分区来说，数据加载往往会落到一个或少数几个热点的分区导致这些分区的数据不能实时的加载. 除了性能，集群吞吐和加载速度，具有Projections概念的列数据库还具有Join操作的优化，高可用性，随意伸缩性，容易恢复等特点，如果读者感兴趣可以参考2005年的C-Store论文[8]除了Google PowerDrill使用的这种Projections过滤数据，多年来也有多种RDBMS使用不同的方式过滤数据，比如Netezza , Oracle 11g 的PAX 样式的文件格式(HIVE里面的RCFile原理类似,如果RCFile 有过滤功能也会一样),在一个小块里面的同一列往往聚合在一起（一个数据块一般4M-8M大小不等），然后提供最大值最小值来判断查询条件，这种文件格式不能使用上面提到的高级压缩功能，然后过滤效果比较低效（大部分原因在于不重新排序），同时因为过滤数据低效所以缓存使用率不高，另外一种为BrighHouse(开源版本为InfoBright),Google Dremel , (IBM 的CIF[9]如果有的话也会是这个原理)文件格式为列的数据块放在连续空间，每个数据块为1M并且头部带有当前数据的最大最小值，这种格式同样因为不具备多重排序而过滤效果一般，当查询只含有一个过滤条件时，过滤效果只会比Projections 的排序效率略差(它是范围判断，不是唯一值判断)，但是当查询含有2个或2个以上过滤条件时，这些过滤条件会组成大量的”可能需要扫描字段”从而导致过滤效果低下，进而导致缓存使用效果低下，单个查询效率低下和集群吞吐下降.所以Projections的Skip List数据结构对比其他类似数据格式的数据过滤功能主要有以下好处:1. 过滤效果最好,尤其是多个过滤条件下的过滤效果.2. 它能根据实际的生产系统的负载调节过滤的字段，从而进一步提高实际环境中的过滤效果.PowerDrill 会使用生产系统的统计数据将经常访问的列和那些列中经常读取的数据块分割在两个子区间中，一个放在内存，一个放在磁盘.3. 根据PowerDrill的实验结果，Skip List平均会过滤掉92.41%的数据，这部分过滤掉的数据对单个查询的影响并不是主要因素，但是对整个集群的吞吐能力却有非常大的提升.4. 它是在大数据块的连续磁盘空间上进行过滤，避免了磁盘随机读取的高延迟消耗.5. 数据是随机分割进某一区域块的，避免了少数几个区域在数据实时装载，查询，负载平衡的过程中形成热点区域.6. 它的大小与延迟物化的性能有关系.延迟物化(later materialization)在2006年的” Integrating Compression and Execution in ColumnOriented Database Systems”论文中，描述了如何直接在已经编码的数据上不解码直接进行操作，每个不同的encoding的处理方式都不太一样，这里介绍Dictionary Encoding的方式: 在数据排序之后将所有出现的字符写入一个前缀的字典表，然后在实际的数值上用字典表中的数字代替，比如”家用电器电饭煲”代表1(假设为16个bit的short 类型),”手机数码数码相机”代表2. 在计算这些商品销售的个数的时候，查询引擎只是简单的将字典代号中的个数相加, 这与使用hashmap或类似数据结构的处理方式完全不同，假设使用hashmap处理，会首先判断”家用电器电饭煲”这个元素在不在hashmap中，如果在则将其对应的计数器加一，如果不在则将这个元素放入hashmap中，然后将这个元素对应的计数器赋值为1.根据PowerDrill的实验数据，即使将所有的数据都放入内存中，主要由于延迟物化的特性，PowerDrill也会比行处理速度或者Dremel的处理速度快上2到3个数量级延迟物化能极大的提升处理速度的原因在于它是缓存感知的(CacheConscious),在处理单个chunk的数据时(一个chunk一般包含几万到几十万不等的同类型单元数值)，所有的数据都是在CPU L2 Cache里面的，不会产生cpu cache miss的情况，这与hashmap的处理方式完全不同，hashmap大多数情况无法将所有元素放入CPU L2 Cache中(现在cpu 的L2 cache 大小一般为128K-256K)，导致cpu cache miss非常高.另外由于chunk的数据大部分都是排序过的,所以实际的计数操作会更快.为了实现延迟物化,必须对单个chunk的大小有所限制，所以对应的skip list数据结构必须尽量平分所有的chunk块,由于所有数据本身已经是经过平分的，所以这一点不难做到(相对于物理分区当遇到数据倾斜的情况chunk大小就无法保证了), 最大的chunk所包含的单元值不能超过CPU L2 Cache的值，比如CPU L2 Cache的大小是256K.如果你的前缀字典压缩表使用的是Integer类型表示实际数值，那么单个chunk包含的单元值个数最好不要超过5W个，如果数据块中某一列的唯一值个数不超过65536个，那么一般使用2个byte大小的short 类型来表示前缀压缩字典表中的实际数值,单个chunk的大小就最好不要超过10W个.不同的encoding会有不同的要求，但是总体原则是不能超过L2 Cache的大小.这里描述的是最简单的延迟物化, 对于不同的encoding和decoding, 延迟物化都需要有对应的API接口,对应不同的操作类型比如sum,count,avg也需要有对应的API接口,所以延迟物化的实现都很复杂, 当数据不能使用对应的延迟物化特性时，查询引擎必须先将数据解码才能完成计算，这种情况一般发生在使用UDF或者需要同另外一个没有对应encoding的表做join的情况下.如果延迟物化在一个查询的全部过程中都可以使用，一般的解码动作会发生在执行计划的最后一步，对于中间步骤比如group by,union,join数据会一直保持编码的格式，从而减少内存的需求和提升查询的速度.对Hadoop的影响目前的大数据分析hadoop已经成为了事实上的工业标准,列数据库的相关研究无疑会对未来hadoop的各个方面产生重大影响.比如未来的硬件会以更大容量的机械磁盘为主，SSD不会对需要扫描大量数据的查询分析有任何帮助，更大的内存也会提升系统的性能和吞吐能力. 在笔者的上一篇文章中已经提到的hadoop中真正的列文件格式[1]应该具有的特性,目前最好的列文件格式是正在开发中的Trevni [11].文件格式对目前NameNode和JobTracker/ResourceManager的内存瓶颈也会有极大的帮助.Trevni 的说明书上[12]写着希望Trevni的block size为1GB, 在未来如果实现了skip list数据结构，Trevni的block size会更大.这会帮助目前的NameNode至少将内存的需求降低一个数量级以上，并且集群的吞吐能力和计算能力都会得到非常大的提升.最近公布的Cloudera Impala和Apache Drill 作为Google Dremel项目的克隆都受到了极大的关注，不久的未来Trevni会作为高性能的文件格式集成进hadoop 生态圈中. 同时目前最为接近Google PowerDrill 目标的开源项目则是Spark和Shark, 一个由UC Berkeley实验室开发的开源项目[4][5],它拥有不同于map reduce的执行引擎和一个主要基于内存的计算模型，在不久前发布的版本中，Shark已经具备一个放在JVM堆外的内存列数据结构，这比目前Hive 或者Java MapReduce所使用的内存数据结构要小的多，目前Berkeley和Yahoo的开发人员还在开发内存中的列压缩数据结构，这会进一步减少内存的占用空间和gc时间，也为未来实现延迟物化奠定基础，更多信息可以参考[13][14].有兴趣的同学不妨多关注这几个项目.参考资料[1] 浅析Hadoop文件格式/cn/articles/hadoop-file-format[1]Processing a Trillion Cells per Mouse Click/pvldb/vol5/p1436_alexanderhall_vldb2012.pdf[2]/2011/02/06/columnar-compression-database-storage/[3]/2012/12/02/are-column-stores-really-better-at-compression/[4]UC Berkeley的spark项目/[5] UC Berkeley的shark项目/[6] Reordering Columns for Smaller Indexes /abs/0909.1346[7] Reordering Rows for Better Compression: Beyond the Lexicographic Order/abs/1207.2189[8] C-store: A column-oriented dbms. In VLDB 2005[9] IBM Column-Oriented Storage Techniques for MapReduce /~jignesh/publ/colMR.pdf[10] Integrating Compression and Execution in ColumnOriented Database Systems[11] Trevni文件格式https:///jira/browse/AVRO-806[12] Trevni Spec /docs/1.7.3/trevni/spec.html[13]/2012/12/13/introduction-to-spark-shark-bdas-and-amplab/[14] /2012/12/13/spark-shark-and-rdds-technology-notes/。