数据湖可以很好地帮助企业应对当前数据场景越来越多、数据结构越来越复杂、数据处理需求越来越多样化的问题。阿里云从2018年开始布局数据湖，推出CloudNativeDataLakeAnalysisDataLakeAnalytics（DLA），从数据湖管理（帮助客户高效管理和构建数据湖）、ServerlessSpark（提供高性价比的大规模计算）,ServerlessSQL（提供高性价比的在线交互式分析）帮助客户挖掘数据价值。本文分享相关的技术挑战和解决方案。一、数据湖的机遇与挑战数据湖可以很好地帮助企业应对当前数据场景越来越多、数据结构越来越复杂、数据处理需求越来越多样化的问题。根据Gartner2020年发布的一份报告，39%的用户目前正在使用数据湖，34%的用户正在考虑在一年内使用数据湖。2018年起，阿里云开始布局数据湖，推出了云原生数据湖分析DataLakeAnalytics（简称：DLA）产品，结合对象存储OSS，从弹性扩展、付费等方面打造有效数据。即用型和服务型竞争产品。通过采用存储和计算分离的模式，存储和计算按需付费，用户只需为实际产生价值的计算付费；DLA深度定制云原生弹性能力，实现作业级弹性，一分钟弹跳300个节点。与传统的数据分析方案相比，云原生数据湖分析DLA在成本、弹性、交付能力等方面有了很大的提升。在云端，已有数千家企业使用数据湖服务来满足数据应用。比如友盟+的U-DOP数据开放平台，基于友盟+在大数据领域多年积累的经验，形成了一个以APP、WEB、小程序、广告为主的平台。基于营销、社交分享和推送的多端主体数据采集和处理能力，为客户形成标准化的多端数据资产。尤其是利用数据湖的灵活性来应对双十一高峰期的业务变化。例如，通过对搜索关键词的变化实施分析，改变首页的广告推荐信息，对不同渠道的活跃用户和下单用户进行分析和梳理，及时调整优惠策略，吸引更多客户新购买并重复购买。数据库与大数据融合的趋势正在加强。传统的数据库用户和DBA也可以使用和维护大数据系统，以集成的方式解决大数据问题。具体来说，DLA体现在数据库中的数据与大数据的无缝结合，比如DLA提供的一键建仓功能；DLAServerlessSQL兼容MySQL协议和部分语法。在DLAServerless产品形式下，开发者只需要使用平台接口，比如使用DLASQL的JDBC接口提交SQL，使用DLASpark的OpenAPI提交Spark作业。开发者只需关注业务逻辑本身，无需关心平台的复杂逻辑。很多使用开源组件遇到的痛点都可以轻松解决：入门门槛高。Hadoop生态系统往往需要同时使用多个组件，如Yarn、HDFS、Spark、Hive、Kerberos、Zookeeper等，开发者需要了解所有组件，因为在开发过程中经常会接触到它们。开发维护难开发者在开发过程中会遇到各种组件带来的使用问题，开发者需要了解所有这些组件来处理这些问题。这些都增加了开发人员的负担。稳定性很难保证。开源组件必须经过精心调优，并配备合适的硬件资源配置才能良好运行，并且需要修复许多错误。缺乏云自适应性能优化。云上的OSS、PolarDB等组件都是云原生组件。开源组件对这部分的改造适应不够，没有充分发挥更高的性能。DLA从三个方面帮助客户挖掘数据价值：数据湖管理（帮助客户高效管理和构建数据湖）、ServerlessSpark（提供高性价比的大规模计算）、ServerlessSQL（提供高性价比的在线交互分析）。整体架构如下图所示。接下来，本文将从这三个方面描述相关的技术挑战和解决方案。2如何管理和建设数据湖？数据湖中数据管理的难点主要体现在两个方面：如何在OSS上为数据湖中已经存储的数据高效构建元数据。如何在湖中高效存储非OSS数据。与数据湖管理相关的主要功能包括元数据管理、元数据发现、数据库存储与建仓、实时数据存储等。接下来重点介绍“海量文件元数据自动构建”和“入湖建仓数据管理技术”两大关键技术。1海量文件元数据自动构建技术当使用OSS作为数据湖存储时，存储的数据文件具有以下特点：格式丰富：包括CSV、Text、JSON、Parquet、Orc、Avro、hudi、DeltaLake等格式，其中CSV和Text还包含多种自定义分隔符等。文件数量百万级：OSS具有更好的扩展性和性价比，用户存储在OSS中的文件数量将达到百万级。文件动态上传：存储在OSS上的数据文件具有动态持续上传的特点。如何快速增量地修改新文件的元数据。为了在OSS上高效构建海量数据元数据，阿里云DLA提出并实现了“海量文件元数据自动化构建技术”。具体技术如下图所示，核心解决两个问题：万表万分区的识别，以及元数据更新的增量感知。上万张表，上万个分区，标识用户OSS上的文件数量达到百万级别。这些文件不仅有不同的格式，如JSON、CSV、Text等，而且由于业务属性不同，同一格式的特定schema字段也不同。该技术支持通过文件模式识别器和文件分类器自动生成数万张表和万张分区。其中，以文件模式识别器为例，识别JSON单个文件耗时0.15s，识别CSV单个文件耗时0.2s。通过可插拔的智能采样策略和分布式策略，百万级文件的模式识别可以达到分钟级。文件分类器通过树状结构进行聚合、剪枝、压缩，对百万级文件进行分类识别耗时约290ms。增量感知更新用户会不断上传文件到OSS。自动元数据构建不仅将属于已创建表的文件的架构更改更新为现有表，还可以为独立添加的文件创建新表。这里，一方面“文件模式识别器”通过获取OSS上文件的增删改查来识别变化的文件，同时“文件分类器”识别新增的文件模式和表已创建以生成变更策略。目前支持4种策略：增加分区、增加字段、不改变字段、不感知文件删除，未来可以不断增加新的策略。2入湖建仓数据组织技术将DataBase和消息日志服务的数据统一存储在数据湖存储OSS中进行管理，满足计算加速、数据仓库建设等业务需求归档，冷热分离。DLA湖中建仓数据组织技术包括三种数据组织管理模式：镜像模式、分区模式、增量模式。三种模式可以匹配友好地支持这些业务场景。镜像模式下，源数据库的一个Database下的所有表的数据每次都完全同步到数据湖存储OSS。同步过程中，源库的负载增长可以控制在10%以内。这里主要使用全局统一的数据分片调度算法。保持数据湖中的数据与源数据库一致。针对归档场景，分区模式支持按日全量和增量同步源库数据到数据湖，并按时间分区组织，方便归档管理。该模式可实现小时级延时。增量模式该模式采用行列混合存储技术、commitlog、索引管理技术，实现T+10min数据入湖。其中，通过delta增量文件和异步compaction技术解决小文件问题；通过delta增量文件和索引技术，支持数据库场景更新和删除日志的增量实时写入；通过commitlog记录分区文件的映射关系，解决传统Catalog管理模式下百万级分区性能慢的问题。3.云原生数据湖平台需要对接云基础设施。整体DLA是多租户架构，分区域部署，每个区域的用户共享一套控制逻辑。一个虚拟集群VC是一个逻辑隔离单元。平台支持ServerlessSpark、ServerlessSQL等引擎打造云原生服务。如上图所示，平台面临的主要挑战是：高效的资源供给、安全防护、访问数据源的带宽保障。1.资源高效供给云原生平台基于阿里云基础ECS&ACK&ECI，对接阿里云IAAS资源池。区域可以跨可用区调度资源，保证资源供应。支持一分钟轰炸300个节点，保证单个客户5w大Region的计算节点资源。2安全防护用户可以编写任意代码在平台上运行，这可能是有意的恶意攻击。如果没有保护，平台将面临安全风险。在安全性方面，我们使用以下技术来保证安全性：一次性密钥：每个作业任务都会去TokenServer申请一个临时的Token，当Job失败时Token会过期。如果有攻击，平台会直接让Token过期，然后拒绝访问Meta等服务。防止DDOS和注入攻击：所有访问平台服务的请求都会连接到安全防护中心，如果检测到任何攻击或注入行为，安全防护中心将直接关闭网络端口。计算容器隔离：计算节点之间使用阿里云自研的安全容器，容器本身可以实现与虚拟机同等级别的安全隔离。安全白名单：用户之间的网络相互完全隔离。ENI虚拟网卡：开通VPC需要在自己的账号下配置安全组和虚拟交换机（VSwitch）。配置完成后，结算节点容器会分配VSwitch网段对应的用户VPC的IP，挂载用户的安全组。3高通量网络带宽访问OSS服务是通过高通量带宽服务。使用ENI技术访问自持VPC与在自持VPC中的ECS上部署计算引擎访问自持VPC中的数据是一样的，带宽也是VPC内网的带宽。4ServerlessSpark服务的技术挑战ApacheSpark是目前社区最流行的开源引擎。不仅具备流式、SQL、机器学习、图等计算能力，还可以对接丰富的数据源。然而，面对数据湖场景，传统的集群版Spark方案，除了前面提到的数据管理困难、运维成本、计算资源弹性不足、企业级能力弱等，还面临接入OSS性能不佳，操作复杂难以调试等问题。借助第二章提到的数据湖管理机制，可以很好地解决数据管理问题。借助第三章提到的多租户安全平台，DLASpark实现了全新的云原生Serverless产品形态，很好地解决了弹性、运维成本和企业级需求等问题。本章进一步展开Spark访问OSS和多租户UI服务的性能优化。1Spark访问OSS优化社区版问题开源版Spark访问OSS数据默认使用HadoopFileFormat接口直接连接OSSFileSystem。在实践中，发现该方法存在性能较差、难以保证一致性等问题。(1)Spark访问OSS性能不佳的核心原因是OSSKV模型和HDFS文件树模型的差异。FileFormat算法最初是基于HDFS文件系统设计的。而OSS等对象存储本质上是采用KV模型来解决扩展性问题。KV模型与HDFS文件系统有很大的不同。比如RenameDirectory接口，在HDFS中只是指针操作，而在KV中，需要重命名所有子文件和目录的KV，性能开销大，不能保证原子性。HadoopFileOutputFormat写入数据时，先写入临时目录，最后写入最终目录。在将临时目录转换为最终目录的过程中，需要进行文件树合并，合并过程中有大量的Rename操作。(2)一致性难以保证。在FileFormatv1算法中，所有的文件树合并操作都在AppMaster中单点执行，效率非常低，尤其是在动态分区场景下。为了解决AppMaster的单点问题，社区提供了算法2，其核心思想是将合并过程与Task并行执行，这会在一定程度上提高性能。但是如果Job执行失败，一些成功的Tasks会往最终数据目录写入数据，造成脏数据问题。SparkOSS访问优化（一）基于MultipartUpload实现FileOutputFormat针对Spark访问OSS的特点，我们新实现了HadoopFileOutputFormat接口，如上图所示。算法的改进重点是优化合并操作，合并的核心是解决文件何时可见的问题。OSS提供MultipartUpload接口，即断点续传功能。文件可以分段上传。如果上传未完成，则拼接的文件是不可见的。有了这个特性，我们就可以让Task直接把数据写到final目录下，只有job成功了，文件才能finally可见。这种方式不需要先写入临时目录，大大减少了元数据操作。对于失败任务写入的临时碎片，我们可以通过在作业结束时执行Abort操作来删除，这样也减少了空间占用。对于Spark典型的ETLBenchmarkTerasort，在1TB输入数据的情况下，DLAFileOutputFormat的执行时间缩短了62%，性能提升了163%。对于动态分区场景，社区算法1失败，但算法2可以成功执行，DLAFileOutputFormat算法性能较算法2进一步提升124%。(2)OSSMetadataCache过程中Spark读取OSS，在ResolveRelation阶段，Spark会遍历OSS目录，解析表结构和分区结构，解析Schema。这个过程中也会有大量的元数据操作，OSS对象的同一个Metadata会被多次访问。为了解决这个问题，我们实现了OSS元数据的缓存。第一次访问的OSS对象的元数据会缓存到本地。如果后面访问该对象，会直接读取本地缓存。这种方法最大限度地减少了对OSS元数据的访问。缓存机制可以将ResolveRelation的性能提升100%左右。对于典型的Spark查询场景，该机制可以提升60%的整体性能。2多租户UI服务UI服务对于开发者来说非常重要。开发人员依靠UI服务对生产作业进行作业调试和故障排除。好的UI服务可以加快研发效率。HistoryServer的痛点Spark社区提供了HistoryServer，为Spark历史作业提供UI和日志服务。在实际应用中，会遇到很多痛点。典型的有：(1)Eventlog空间开销大。HistoryServer依靠Spark引擎将所有运行的Event信息记录到FileSystem中，然后在后台回放和绘制UI页面。对于复杂的作业和长时间的作业，Eventlog的量可以达到数百GB甚至TB。(2)复杂作业和长作业不支持复杂作业或者长作业的Eventlog很大，HistoryServer会解析失败，甚至OOM。加上空间开销大，用户一般只能关闭Eventlog。(3)回放效率低，时延高。HistoryServer通过后台ReplayEventlog的方式还原SparkUI，相当于重放了Spark引擎的所有事件。开销很大，而且会有延迟。尤其是在作业很多或者复杂的情况下，延迟可以达到几分钟甚至十几分钟的级别。DLA多租户SparkUISparkUI服务是DLA平台自研的多租户UI服务。针对社区解决方案进行了深度优化：(1)GotoEventlogDLASpark去除了Eventlog依赖。作业结束时，SparkDriver只是将UI的Meta转储到OSS，在作业结束前保存页面元信息。与Eventlog相比，这部分信息会大大减少。即使是非常复杂的工作也只是在MB级别。UiServer读取OSS上的UIMeta并反序列化显示SparkUI页面。(2)UIServer的横向扩展UIServer主要负责分析历史UIMeta，提供Stderr和Stdout日志服务。轻量级无状态，可实现水平扩展，支持数万客户同时在线服务。UIServerURL使用加密令牌作为参数。token代表用户身份和jobid，UIServer基于此实现多租户服务。(3)本地日志的自动滚动对于长时间的作业，Stderr或Stdout信息会随着时间的推移而累积，最后甚至可能炸毁磁盘。DLASpark安全容器内置后台进程，实现日志滚动，保存最近最有价值的日志。ServerlessSQL服务的五个技术挑战DLAServerlessSQL是目前托管在LinuxFoundation下的基于PrestoDB的云原生数据湖引擎。阿里巴巴也是Presto基金会的成员，一直在为Presto的优化做贡献。PrestoDB引擎本身就具有优秀的特性：全内存计算带来的极致速度。支持完整的SQL语义带来的强大表现力。简单易用的插件机制让我们可以对任何数据源进行关联查询。强大的社区让我们用后无后顾之忧。然而，社区PrestoDB是一个单租户引擎。它假设你是在一个公司内部使用它，所以在算力隔离、高可用等方面没有太多的投入，这就很难直接将它作为云原生服务的引擎。一个问题：如果一个用户提交大量的大查询，可能会占用集群的所有资源，导致其他用户无法使用。单个Coordinator无法保证整个服务的可用性。我们做了一系列的优化和改造，以云原生的形式服务于所有用户。今天我们将重点介绍多租户隔离技术和多协调器的两个主要特性。首先我们来看一下DLAServerlessSQL的整体架构：我们围绕PrestoDB核心集群构建了接入层、统一元数据等服务，让用户使用起来稳定方便。接下来，我们将在多租户隔离技术和多协调器技术的介绍中详细分析。1多租户隔离技术PrestoDB原生支持资源组，可以支持不同资源组之间一定程度的CPU和内存限制，但是它有一些问题阻碍我们基于它实现算力隔离：GlobalSchedulinglevel：即使一个租户使用过多的算力资源，也不会被及时惩罚，只会阻止新的查询。Worker调度级别：所有租户的分片都调度在同一个队列中。如果一个租户分裂太多，就会影响到其他租户。我们的算力多租户方案如下：我们在集群中引入了一个ResourceManager模块，从所有的Coordinator收集所有租户的资源使用信息，ResourceManager将收集到的资源使用信息与我们预设的算力阈值进行比较，计算哪些租户应该受到处罚，然后将处罚信息通知所有Worker。在调度时，Worker会参考ResourceManager通知的惩罚信息，来判断哪些租户的查询被调度，哪些租户的查询不被调度。这样，不同租户之间的算力就会被隔离。我们测试过，如果一个租户过度使用资源，它会在最多1.3秒内受到惩罚，从而释放资源给其他租户。“直到对租户的所有查询执行完成后才会到来。只有当元数据和计算能力隔离时，我们才能安全地使用一个集群来服务我们所有的用户。2Multi-Coordinator在Presto的社区版本中，Coordinator是一个单一的point，这带来两个问题：潜在可用性：Coordinator一旦宕机，整个集群将有5~10分钟不可用，无法实现无缝升级，升级过程中影响所有用户的查询使用，我们采用下面的架构方案：首先，我们在Presto的Coordinator之上放置了一个新的FrontNode模块，让用户可以连接到这个模块，而不是直接连接到我们底层的Coordinator，那么我们到底有多少个Coordinator呢？现在哪个Coordinator提供对用户的服务对用户是完全透明的，让架构更加灵活，方便我们在底层扩展Coordinator。iving用户的查询，FrontNode会以RoundRobin的形式将请求发送给底层的多个Coordinator，让多个Coordinator分担压力，但是整个集群中还是有一些全局的事情需要一个人来完成单Coordinator，比如Presto的Worker状态监控，OOMKiller等，所以我们引入了一个Zookeeper来做Coordinator选举。选举后，主Coordinator的职责将类似于社区的Presto：全局的Worker状态监控，OOMKiller和分配给它的executionQueries；Coordinator的职责相对较轻：只负责执行分配给它的查询。如果其中一个Coordinator因任何问题宕机，Zookeeper会在几秒钟内发现问题并重新选举master。用户只需重试受影响的查询。我们正在进行的一项尝试是自动重试查询。对于确定是系统原因导致的故障，我们会做自动重试。这样的Coordinator对用户影响不大。通过多Coordinator架构，我们实现无缝升级是非常简单的。升级时，我们只需要主动从集群中移除某个Coordinator/Worker，对其进行升级，升级完成后再加入集群即可。感知，因为升级过程中始终有一个正常工作的集群为用户提供服务。比如我们从Coordinator升级，整个集群情况是这样的：通过多租户隔离技术、多Coordinator架构等优化，我们基于PrestoDB构建了一个阿里云云原生数据湖serverlessSQL引擎，可以服务所有用户。六云原生数据湖的端到端最佳实践如上图所示。DLA提供端到端的解决方案。面对OSS数据开放带来的管理和入湖困难，DLA数据湖管理可以帮助您一站式构建安全的数据湖。提供统一开放的Meta服务管理OSS数据，支持数据库表权限。使用元数据爬取功能，一键创建OSS元数据信息，轻松自动识别CSV/JSON/Parquet等格式，创建数据库表信息供后续计算引擎使用。一键同步RDS/PolarDB/MongoDB等数据库数据至OSS存储，构建冷热数据分层的业务架构，对多源海量数据进行数据洞察和分析。支持流式构建Hudi格式，满足T+10分钟的时延要求，大幅提升分析的端到端时延。无服务器SQL分析可帮助您开箱即用地使用数据湖。用户无需购买任何资源，即可运行标准SQL语法查询数据。支持数据湖存储OSSCache加速，性能提升10倍。支持RDS、PolarDB、ADB、MongoDB等十种数据源分析。与传统的Presto、Impala方案相比，性价比提升10倍。基于无服务器的Spark计算可帮助您独立使用数据湖。用户无需购买任何资源，即可使用云原生Spark服务，支持数PB的OSS数据清洗，机器学习，用户可编程，玩转数据湖。每分钟可以弹出500个节点参与计算。与传统自建Spark方案相比，性价比提升3倍。由于DLA涉及的技术点较多，本文将介绍一些技术细节。更多欢迎关注云原生数据湖分析DLA：https://www.aliyun.com/product/datalakeanalytics【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点击在这里可以看到作者更多的好文章
