共计 3403 个字符，预计需要花费 9 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
前言
当波及到企业剖析场景时，所应用的数据通常源自多样的业务数据，这些数据系统大多采纳以行为主的存储构造，比方领取交易记录、用户购买行为、传感器报警等。
在数仓及剖析畛域，海量数据则次要采按列的形式贮存。因而，将数据从行级转换成列级存储是建设企业数仓的根底能力。传统形式是采纳 Extract-Transform-Load (ETL) 来将业务数据转换为适宜数仓的数据模型，然而，这依赖于独立于数仓外的 ETL 零碎，因此保护老本较高。
但随着云计算时代的到来，云数据仓库具备更强扩展性和计算能力，也要求改变传统的 ELT 流程。火山引擎 ByteHouse 是一款基于开源 ClickHouse 推出的云原生数据仓库，为用户提供极速剖析体验，可能撑持实时数据分析和海量数据离线剖析，同时还具备便捷的弹性扩缩容能力，极致剖析性能和丰盛的企业级个性。
凭借其弱小的计算能力，能够全面反对 Extract-Load-Transform (ELT) 的能力，从而使用户免于保护多套异构零碎。
具体而言，用户能够将数据导入后，通过自定义的 SQL 语句，在 ByteHouse 外部进行数据转换，而无需依赖独立的 ETL 零碎及资源。这样，用户只须要采纳对立的 SQL 形式来实现数据转换操作。
在本文中，咱们将重点介绍 ByteHouse 遇到的挑战，以及如何通过 3 大能力建设实现齐备的 ELT 能力。
痛点以及挑战
咱们先从一个简略的 SSB(start-schema-benchmark) 场景登程，其中蕴含：
- 1 个事实表: lineorder
- 4 个维度表：customer, part, supplier, dwdate
在 SSB 的查问剖析中，咱们发现大部分的查问都波及到事实表和维表的 join，因而能够通过 Transform 的步骤，将事实表“打平”。
打平所用到的 SQL 如下:
insert into ssb_flat
select * from
lineorder l
join customer c on l.lo_custkey = c.c_custkey
join part p on l.lo_partkey = p.p_partkey
join supplier s on l.lo_suppkey = s.s_suppkey
where l.lo_orderdate = <bizdate>之后的查问剖析能够通过对 ssb_flat 的单表扫描来躲避很多 join 操作，其性能能有显著晋升。这个“打平”的过程，就是“Transform”的一种。
理论生产场景中的“Transform”的 case 会更多也更简单。然而通过以上这个“打平”的过程，咱们能够剖析出这类操作在数据库上的普遍性痛点。变换操作跟一般查问相比，有几个大的区别:
- 变换操作执行工夫久，整体重试老本高
- 变换操作没有返回值，咱们只关怀他胜利或者失败
- 变动操作读写量大，占用资源
具体来说：
- 首先对于 ByteHouse 来讲，其善于的长期查问工夫都在秒级，查问两头出故障个别都间接返回谬误，交由上游重试。而在 ETL 场景下，一个工作如果执行了 50 分钟，因为某些起因故障了，重试相当于前 50 分钟的资源都被节约了，显然不能被承受。
- 其次，因为 ETL 没有返回后果，客户端须要放弃一个 idle 的长链接，很有可能因为配置起因超时，同时大量的并发工作也会吃掉失常的链接资源。
- 最初，因为 ETL 工作读写量大，多个工作并发的时候，须要思考到资源的调配，以达到性能和隔离的均衡。
针对这三个痛点，ByteHouse 针对性的设计了三个性能，即长工作治理、异步提交和查问队列。
性能一：长工作治理
通常状况下，咱们能够用 settings max_execution_time 来管制一个查问的超时工夫，ByteHouse 提供了事务反对来保障读写操作的原子性。
然而并这不足以笼罩 ETL 工作的需要。在长时间的工作执行中，更容易遇到系统性故障，如节点 OOM 等。
在这种状况下，由客户端重试并不是个优雅的计划。在 ByteHouse 中，一个 SQL 查问会被转化为一系列的算子。咱们心愿晋升算子的容错能力以更好的应答长时间查问下的系统故障。目前的版本中，ByteHouse 曾经针对聚合，排序，关联等算子提供了 disk spill 性能。
具体来说，当某个算子无奈取得足够的内存时，咱们容许这个算子将一部分数据缓存在磁盘上，以此在资源缓和的状况下仍可能实现工作。例如在排序算子中，咱们引入了 external merge sort 的能力，并通过 max_bytes_before_external_sort 来管制内部排序能力。
在下图右边是未开启 spill 的排序查问打算，左边是开启 spill 的打算。
能够看到在开启 external sort 之后，ByteHouse 引入了 BufferingToFileTransform，MergingSortedTransform 两个算子。同样的，ByteHouse 里的聚合，关联算子都做了相似的优化例如 grace hash join 等。
接下来 ByteHouse 也打算针对 exchange 操作，进一步晋升 shuffle 操作的容错性。
性能二：异步提交能力
面对大量长耗时的 ETL 工作时，传统的同步执行的形式须要客户端期待服务端返回。这样很容易呈现客户端超时，进而影响后续工作执行的问题。
同时，在这种场景中，用户并不关怀单个工作或申请的相应工夫，只冀望工作能在特定工夫内实现，并对可靠性等要求较高。因而 ByteHouse 提供了异步提交的工作的能力。ByteHouse 用户当初能够通过 setting enable_async_execution 来提交一个异步工作。
ByteHouse 在收到这类工作之后，会返回一个异步工作 ID，例如 ff46fccf-d872-4c68-bdb2-c8c18fc178f5。之后客户端能够抉择间歇性轮训来取得工作的最终状态。ByteHouse 提供了 show async status ‘ff46fccf-d872-4c68-bdb2-c8c18fc178f5’ 的指令来取得状态。同时 ByteHouse 也提供了 kill query ‘ff46fccf-d872-4c68-bdb2-c8c18fc178f5’ 的指令来勾销某些异步的查问。
性能三：查问队列离线加工
面对大量申请时，当零碎超载，须要肯定的排队机制使 query 申请挂起，期待集群开释资源后再进行调度。ByteHouse 为此提供了查问队列能力。ByteHouse 能够容许用户从三个维度度来定义一个队列，即: 队列大小，总 CPU 占用率，和总内存占用率。
在 ByteHouse 中，Resource Manager 组件能够用来监听各个队列中的查问指标，失去队列的资源使用率。当用户向一个队列提交查问时，如果队列还未达到下限，ByteHouse 会将这个查问入队，否则回绝掉这个查问。尔后，ByteHouse 会时刻查看队列的资源利用率，当闲暇资源高过某个阀值时，Bytehouse 会将期待中的查问出队。
当某个处于期待期的查问被勾销时，ByteHouse 也会将其移出队列。利用查问队列，用户在编排 ETL 工作时不必放心底层资源过载，因而能够更加自在。之后 ByteHouse 也在打算减少优先级队列性能。届时，用户能够为 ETL 工作和即时查问创立不同队列优先级，这样 ELT 工作和即时查问能够跑在同一个计算组中而不会显著的相互影响。
总结
以上介绍了 ByteHouse 在反对 ETL 能力中的一些技术细节。其中长工作，异步提交曾经队列性能曾经在 preview 版本中上线。接下来，ByteHouse 也会持续扩大 ETL 能力，包含反对更多的 ETL 相干的转换函数、长工作容错、优先级队列等。
除了 ELT 能力之外，火山引擎 ByteHouse 基于独家自研的高可用引擎及查问优化器，能够为企业提供疾速、稳固、平安的查问服务和数据写入性能。在云原生架构下，火山引擎 ByteHouse 提供了极致扩大的对立数据分析平台，具备杰出的弹性伸缩和可扩展性，确保资源能够灵便地程度扩大；
同时，ByteHouse 反对多级资源隔离，为用户资源提供更安心的平安保障。火山引擎 ByteHouse 还从业务角度登程提供了残缺的运维监控和排障能力，帮忙企业实现业务云上托管，升高运维老本。欢送登陆火山引擎 ByteHouse 官网体验。
点击跳转 云原生数据仓库 ByteHouse 理解更多