共计 7598 个字符，预计需要花费 19 分钟才能阅读完成。
作者： 周宇睿 阿里云高级技术专家
本文将介绍 MaxCompute 在半结构化数据方面的一些思考与翻新， 介绍会围绕上面四点开展：
1. 半结构化数据简析
2. 传统计划优劣比照
3.MaxCompute 半结构化数据解决方案
4. 收益剖析
半结构化数据简析
首先来介绍一下什么是半结构化数据。
半结构化数据是绝对结构化数据和非结构化数据而言的，所以先来看一下什么是结构化数据和非结构化数据。
结构化数据的概念大家都比拟相熟。传统的关系型数据库是用表的形式对数据进行组织，表的外部定义了字段的数量、类型，以及各种各样字段的属性信息，这些定义自身就蕴含了丰盛的信息。因为在结构化数据的场景中，字段属性被当时严格地定义，所以数据库也好，各种数据引擎、存储引擎都能够通过这些定义取得的信息，有针对性的对数据进行解决。这些解决包含但不限于建设索引，对数据进行排序，对数据进行列存化，也包含向量化执行等等，从而达到一个升高存储老本，晋升拜访效率的目标。通常来说，结构化数据能够达到十分好的数据读写性能，它的存储效率、压缩效率也能够做得十分好，然而它的灵活性会受到很大的限度。在很多的数据库或者数据仓库当中，如果想扭转数据表的构造，通常来说是一个十分高风险的操作，可能会带来很多额定的数据管理老本。
相比之下，非结构化数据自身也是一个很容易了解的概念，咱们日常生活中会接触到的，比如说视频、音频、图片、文章等等，都能够算作是一个比拟典型的非结构化数据。非结构化数据外面很一个很重要的特色就是没有一个清晰的对立的协定对这些数据外部的构造进行束缚，数据自身的内容也没有对立的法则。非结构化数据具备的劣势就是简直是有限的数据灵活性。当然这种有限的灵活性自身也是会有代价的，就是因为没有方法当时对数据自身的构造进行解析，因而很在大部分场景外面，数据引擎没有方法对数据结构进行无效的信息提取，所以一般来说非结构化数据的存储效率和拜访性能都是比拟差的。
说分明了结构化数据和非结构化数据，咱们再回过头来看看什么是半结构化数据，半结构化数据最重要的一个特色就是数据外部一般来说会蕴含数据自身的一个构造信息，咱们会说它是一个自蕴含的数据结构。通过当时的一个约定的协定，咱们能够很容易地对数据结构这个数据进行解析和数据内容的提取。
相比于传统的结构化数据，半结构化数据并没有受到来自内部的、来自数据仓库或者数据库的这种表级别的强束缚。因而一般来说，半结构化数据会更加的灵便，它能够更好地依据具体的用户场景，用户需要进行动静的变动。也正是因为这个特色，通常来说半结构化数据会有多层嵌套的构造，比如说 Json，Xml，都是很典型的半结构化数据。从非结构化数据到半结构化数据，最初再到结构化数据，数据的灵活性是在一直降落的，然而数据的存储效率、拜访性能也在一直地晋升。半结构化数据在某种程度上能够说是兼顾了两种类型的长处，一方面它具备比拟好的灵活性，另外一方面通过协定自身的结构化的束缚，也为高效率的拜访和解析提供了帮忙。
半结构化数据是一种通用的数据传输和存储构造，被宽泛地应用在日志剖析、IoT 设施的信息采集、挪动设施的事件上报，以及主动驾驶等多样化的数据场景中。这也体现了半结构化数据的一个很大的特点，就是它的通用性十分好。同时因为半结构化数据自身的灵活性，它们能够在大部分数据场景上面承载和传递丰盛的原始数据的信息。因为其解析协定非常简单，也可能反对咱们疾速地对数据进行解析和拜访。所以一般来说，半结构化数据自身就是一个十分丰盛的数据信息的载体。另一方面，比方 Json、Xml，具备十分丰盛和欠缺的数据生态，咱们能够很不便地在各种语言、各种框架、各种平台上面对这些数据进行解析、生产和生产。多平台的通用性也让半结构化数据这种协定成为了事实上的一种数据的通信规范，能够宽泛地承受和应用。从数据仓库解决的角度来说，半结构化数据自身的这种灵活性，也会给上游的业务部门以及两头的数据中台和上游的数据生产决策部门的独立运行，提供一个很好的缓冲。在一个比拟大的公司或者团队中，上游是产生数据的业务部门，两头是负责数据处理保护的数据仓库的数据中台部门，还有上游负责决策和生产的决策部门，通常是独立运行的，有着截然不同的运行模式和指标。半结构化数据以其灵活性和易解析的个性能够很好地帮忙各个部门进行独立的业务演进，防止因为上游部门频繁的业务迭代带来昂扬的跨部门沟通以及数据保护的老本。
传统计划优劣比照
在传统的数据仓库中，半结构化数据解决方案分为 schema on read 和 schema on write 两种模式。实质上来讲的就是数据引擎在数据读写的哪一个环节对数据结构进行解析。schema on read，顾名思义就是在数据导入的过程中不对数据做任何解析和解决，间接将数据进行存储，而后只有在数据拜访的时候会依据用户具体的申请，依赖引擎的动静解析能力对数据进行解析。因为在数据写入的过程中咱们没有对数据自身做出任何束缚，因而 schema on read 的计划一般来说会提供比拟好的数据灵活性。和 schema on read 相同，schema on write 计划就是咱们在数据写入的时候，就须要依据当时定义好的构造对数据进行解析，将这种半结构化数据的构造转换成传统的结构化数据，而后再导入到数据仓库当中。相比于 schema on read，schema on write 的灵活性较差，然而可能提供更好的存储和拜访性能。
当用户将数据写入到数据仓库中，因为没有对数据进行任何解析，间接是以字符串的形式导入到数据仓库的，因而是以一种行式的数据结构进行存储的。当用户要对这个数据进行查找和解析，比方上图的案例，用户心愿统计年纪在 18 岁以上的用户数量的时候，须要先提取年纪在 18 岁以上这个特色，因为在数据写入的时候没有提前对数据进行拆分，所以须要对整个数据进行全表扫描，拿到了所有的数据之后进行解压解码，而后取得具体的 JSON 数据结构，再进一步地依据用户的需要对这个 JSON 构造进行解决，最终取得年龄字段。在整个执行链路当中，一方面数据的存储开销十分大，另外一方面整个查问效率因为须要 full scan，还须要破费额定的 CPU 进行解压，同时对这个 JSON 的数据结构进行解析，所以它的数据解析效率，拜访性能都是十分差的。
同样的一个查问申请，在 schema on write 的场景外面，咱们能够只对用户的年龄字段进行读取，而后间接进行数据解压解码，取得残缺的数据结构，再进行数据的解析和查问，它的存储效率和查问效率都会更高。
然而 schema on write 的计划也不是白璧无瑕的。一般来说，采纳 schema on write 计划的时候，会假设上游业务部门不会对这些字段进行频繁的改变，整个数据结构处于一个绝对稳固的状态。如果上游的业务部门处于一种疾速迭代、疾速适应的阶段，那么可能会一直地有减少字段、批改字段的需要。
在上游业务疾速迭代的状况下，如果依然抉择应用 schema on write 计划，上游的数据中台或者数据保护部门就须要一直地依据上游业务部门的改变，对数表的构造进行适配，一直地、频繁地执行表字段的减少或者批改，这将消耗微小的业务保护老本。因而咱们思考有没有可能在容许上游业务部门频繁迭代、自在迭代的状况下，既取得比拟好的查问效率和比拟低的存储老本，又尽可能地升高数据仓库或者数据保护部门的数据保护老本。
这也就是咱们提出来的数据仓库半结构化数据场景的一个外围的需要。心愿可能同时兼顾数据查问的高性能、数据存储的低成本以及数据演进的灵活性。联合 schema on write 和 schema on read 的劣势，一方面在数据写入的过程中进行数据结构的提取和转换，同时也反对对数据读取过程中动静的自适应的拜访，从而达到一个升高存储老本和放弃灵活性的成果。
MaxCompute 半结构化数据解决方案
MaxCompute 是一个实用于数据分析场景的企业级的云服务数仓，以 serverless 的架构提供疾速的全托管的在线的数据仓库服务。它打消了传统数据平台在扩展性和弹性方面的限度，可能最小化用户运维投入，能够使用户以较低的老本高效地剖析和解决海量数据。随着以后数据收集伎俩的不断丰富，各个行业数据的大量积攒，数据规模曾经增长到了传统的数据库或者软件行业无奈承载的 PB 甚至 EB 的级别。MaxCompute 提供了离线和流式的数据接入，可能反对超大规模的数据计算和查问减速能力，能够为用户提供包含面向多种计算场景的数据仓库解决方案以及剖析建模的服务。MaxCompute 还提供欠缺的数据导入计划和分布式计算的模型。用户不须要关怀具体的分布式计算和保护细节，就能够实现大数据分析。通常来说 MaxCompute 实用于 100GB 以上存储规模的计算需求量，最大能够到 EB 级别。MaxCompute 在阿里巴巴团体外部失去了大规模的利用，实用于大型互联网企业的数据仓库和 BI 剖析，网站的日志剖析，电子商务场景的交易剖析，以及用户特色和趣味的开掘。
上图展现了 MaxCompute 半结构化数据的一个具体场景。用户会将前端的业务数据和业务日志，通过实时或者分批次的形式导入数据仓库，而后与业务数据进行联合。从用户的诉求来看，他们心愿可能最大限度地缩小入仓过程中数据转换的链路，并晋升数据导入的实时性。另一方面数据中台也会对数据进行定时的监控，保证数据品质，同时进行定时的报警触发。在数据的上游，多个不同的业务部门会对数据有不同的解析需要，用户会通过交互式剖析、减速查问的形式生成可视化的数据报表。
在该场景中，上游的业务部门和两头的数据中台，还有上游的数据生产决策部门有着各自比拟独立的数据需要，在这里半结构化数据就能够成为连贯和缓冲各部门不同诉求的一个十分天然的抉择。用户在引入半结构化数据的同时，一方面能够容许上游业务依据本身的需要独立演进，疾速迭代，中台的数据保护老本也能够降到最低，同时上游各个不同生产部门各自的数据生产需要也能够失去很好的满足。
用户在将半结构化数据导入数据仓库的过程当中，发现在一个绝对较短的周期，比方几个小时、几天甚至几周这样一个周期内，用户的数据结构基本上来说是保持稳定的，也就是说在一个较短的工夫内，用户的字段的类型和数量是简直放弃不变的。因而在短周期而且空间相邻的数据当中，有机会去提取这些绝对稳固的公共数据结构，而后将这些半结构化数据通过列存化的形式来升高存储老本并晋升存查问效率。
在长周期的业务迭代中，比方几周甚至几个月的迭代周期外面，业务部门可能会依据具体的业务场景进行绝对迟缓平滑的业务迭代，能够通过引擎本身带有的这种动静自适应的能力，去适应和发现长周期当中字段类型或者字段数量的变动，从而达到一个比拟综合的半结构化数据的解决方案。
在如上的数据中能够通过对这个数据的扫描提取进去一个所有数据都具备的公共的数据类型，它两头会有四个字段，每个字段会有一个明确的类型，而后通过这个提取的类型，能够将原始的用户数据以及收集到的这个类型，同样地输出给数据转换器，数据转换器就能够将这个数据进行很好的列存化。实现在数据导入数据仓库的过程中，就对数据进行动静的解析，实现数据列存化的过程。
MaxCompute 底层采纳的是 AliORC 列存来进行数据的存储。AliORC 是阿里云本人研制的一个高性能的基于开源 Apache ORC 的数据格式，它可能人造地很好地对这种嵌套构造进行反对，可能在数据结构、数据文件的文件格式层面就很好地去保留不同节点之间的互相映射以及嵌套的信息。当要对某一个比拟深的节点进行探查或者裁剪的时候，能够很天然地将这种 JSON 的门路和这种嵌套构造的节点进行一一映射，而后来做出一个很好的、很天然而高效率的列裁剪。
如上述例子，能够首先通过一个后面提到的 schema 提取的工作，将它提取成一个具备嵌套特色的数据结构，最终将它转化成一个基于 AliORC 的列存构造，将每列的数据进行间断的寄存，甚至是嵌套类型外部的子节点，也能够把它进行列存化，实现间断寄存从而取得更好的压缩性能以及更好的查问性能。
现实状况下用户的所有数据都具备比拟好的稳定性和一致性，然而因为半结构化数据自身自有的这种灵活性的特点，很多场景上面脏数据是难以完全避免的。后面的例子假如所有的用户字段提供的数据类型都是十分洁净，十分对立的，但在事实的生产环境中，很有可能会因为代码的 bug，或是数据传输过程中的谬误，导致数据的类型并不完全一致。比方上图中标红的第三个 age 字段，后面两个 JSON 数据中 age 字段都是整型，然而在第三行数据当中，age 字段忽然变成了一个字符串类型。在这种场景上面，没有方法很好地进行一个对立的公共类型的提取，因为整型和字符串类型很多时候并不是一个相互兼容的类型。在这种状况下，咱们会将这种数据保留成一种外部的二进制数据结构，在这种二进制的构造当中，不仅会保留这个字段具体的数据信息，也会保留它的数据类型的信息。在这个例子外面将前两行数据的 age 字段，同时记录了它的数据类型，也就是它的整型信息，也记录了它的具体的值的信息。而后在第 3 行数据当中，记录的它是一个 string 类型，这样就达到了尽可能残缺地保留用户数据的目标。因为从平台的角度来说，平台很难判断用户的这个类数据类型的变动到底是出于业务类型的考量、业务天然的演进，还是一个由 bug 导致的谬误，所以从数据平台的角度，还是须要可能尽可能残缺地保留用户信息。另一方面，这种应用独立的二进制的形式来保存信息的形式也尽可能地保障了数据列存的效率。可能最大限度地保障不同的字段依然是通过列存的形式进行存储的。在数据拜访的时候也尽可能地针对不同字段进行列裁剪。而且某一个列当中呈现了脏数据，并不会对其它列的数据类型和数据存储拜访效率造成影响。因而最大限度地将脏数据类型和一般数据类型进行了隔离。
另外一种比拟辣手的场景就是稠密数据类型的解决。在一些场景中，每一行用户数据中可能都会存在一些字段，这些字段呈现的频率很低。如果应用后面这种公共类型提取的计划，将这些呈现频率很低的字段依然提取为一个独立的列，就会导致底层存储格局上列的数量有限收缩，列存自身的效率就会变得非常低。因而在数据进行这种类型提取的过程当中，也须要对字段的频率进行统计。对频率较低的字段进行一个对立的演绎解决，将它们放到一个对立的非凡字段当中。在数据拜访的过程当中，如果用户查找到了一些在列存化字段当中不存在的列，那么就会在非凡字段当中进行查找。通过这种解决，咱们心愿可能最终获得一个兼顾效率和灵活性的均衡。
接下来看一看数据引擎是怎么在具体的查问过程中进行自适应的查找的。后面提到，用户数据的构造在一个较长的周期外面是可能会一直地演进和变动的，因而在理论存储的过程中，不同的列存文件，其数据可能会受到用户业务长期演进的影响，因而不同的列存文件理论存储的用户数据的 schema 可能是不完全一致的。比方后面提到的这个 SQL 查问的例子，在这个查问过程中，用户要查问年龄这一列，而后将它 cast 成 int 类型之后，去查问所有大于 18 岁的用户的数量。在这样一个场景中，会先对这个 SQL 查问进行一个解析，而后把它做成一个 logical plan。在这个 plan 当中会有多个不同的算子，在最上游的这种聚合算子或者查问算子，它们都是一个强类型的算子，会冀望输出的数据是一个整型。然而在底层的 table scan 读上来的时候，它其实是一个动静数据类型，并没有方法晓得这个时候读上来的理论是一个什么类型，因而在两头须要减少一个动态数据转换的能力，将数据读上来的任何类型，通过一种 best effort 的形式转化成须要的数据类型，再去进行下一步的数据处理。如图中所演示的，会首先对这个数据文件进行列裁剪，读取进去 age 这个年龄字段。然而大家能够看到，在这个样例当中，不同的数据文件，读出来的 age 字段的类型是不一样的，有的文件外面可能读出来是字符串类型，有的文件读出来是整型，有的文件读出来是 binary 的二进制类型。因而数据引擎就须要依据理论读上来的类型动静判断要不要在两头减少一个数据转换的算子，对立将数据转换成 int 类型，之后再交由上游的 filter 算子进行数据的解决，从而实现一个自适应的数据处理的能力。
收益剖析
最初来看一下数据查问方面的收益。比照了后面提到的三种计划，一种是齐全应用 JSON 字符串的形式，一种是 JSON 列存化的形式，另外一种就是原生的列存的形式。大家能够看到无论是数据在做 table scan 过程中读取的数据量，还是整个数据的查问工夫，查问性能都会有靠近一个数量级的晋升。
相比于原生的列存，Json 列存化的计划依然存在一些晋升的空间。在剖析之后发现这外面存在的空间次要的起因还是在 Json 列存化进行数据解析的过程当中，没有方法齐全地将日期类型等等很好地转换成对应的原生的列存类型，这也是下一步的工作当中须要改良的方向。
最初对 MaxCompute 这个半结构化数据的列存化计划进行一个总结。首先，MaxCompute 半结构化列存计划是开箱即用的，不须要用户侧做任何革新。它能够最大限度地保障用户只有进行失常的数据导入，就能够享受到半结构化列存计划带来的红利，而后最大限度地升高用户侧革新带来的额定的数据保护老本。另外，通过在写入的时候对数据类型进行动静解析，可能最大限度地去利用数据结构之间的相似性，提取相邻数据之间的公共构造，对数据列存化。同时也对脏数据或者稠密数据等场景进行了兜底，保障用户在各种场景下的半截刻画数据都能够尽可能地享受到的列存化计划带来的劣势。同时通过这种数据的列成化以及数据引擎动静的拜访能力，可能最大限度地晋升数据的查问效率，达到靠近于原生列存的查问效率。最初，通过应用外部的列式存储，可能最大限度地升高存储老本，从而达到升高存储老本的目标。
问答环节
Q：设置了列的类型就能够间接应用吗？
A: 是的，阿里云 MaxCompute 在间接提供了一个叫做 JSON 的数据类型，用户只有设置了这个列的数据类型之后，就能够间接享受到提供了这个列式半结构化、列存化的这么一个带来的这种红利和劣势，在用户在导入的过程中，或者用户在数据查问的过程中，都不须要进行任何额定的数据保护和操作。
Q：数据在列存的过程中怎么保护？
A：JSON 数据的咱们在存储的过程当中并不会间接治理这个 JSON 外部的数据结构，就是说在数据的源数据存储过程中，并不会间接去了解说这个数据当中到底有多少构造，因为用户的构造可能是非常复杂，也会一直地演进的。因而只是在数据存储的过程中，在文件级别会保留 Json 的这个数据结构。而后会依赖数据结，数据引擎在拜访过程中的这么一个动静的能力去对 JSON 的内部结构进行提取。
Q：阿里云 MaCompute 反对私有化部署吗？
A：反对的。
