如何基于ApacheDoris与ApacheFlink快速构

　　随着大数据应用的不断深入，企业不再满足离线数据加工计算的时效，实时数据需求已成为数据应用新常态。伴随着实时分析需求的不断膨胀，传统的数据架构面临的成本高、实时性无法保证、组件繁冗、运维难度高等问题日益凸显。为了适应业务快速迭代的特点，帮助企业提升数据生产和应用的时效性、进一步挖掘实时数据价值，实时数仓的构建至关重要。
　　本文将分享如何基于HomeApacheDoris和ApacheFlink快速构建一个极速易用的实时数仓，包括数据同步、数据集成、数仓分层、数据更新、性能提升等方面的具体应用方案，在这之前，我们先可以先了解一下传统的数据架构如何设计的、又存在哪些痛点问题。实时数仓的需求与挑战
　　上图所示为传统的数据架构，如果我们从数据流的度分析传统的数据处理架构，会发现从源端采集到的业务数据和日志数据主要会分为实时和离线两条链路：在实时数据部分，通过Binlog的式，将业务数据库中的数据变更（CDC，ChangeDataCapture）采集到实时数仓。同时，通过FlumeKafkaSink对日志数据进实时采集。当不同来源的数据都采集到实时存储系统后，便可以基于实时存储系统来构建实时数仓。在实时数仓的内部，我们仍然会遵守传统数仓分层理论，将数据分为ODS层、DWD层、DWS层、ADS层以实现最大程度的模型复用。在离线数据部分，通过DataX定时同步的式，批量同步业务库RDS中的数据。当不同来源的数据进到离线数仓后，便可以在离线数仓内部，依赖SparkSQL或HiveSQL对数据进定时处理，分离出不同层级（ODS、DWD、ADS等）的数据，并将这些数据存在个存储介质上，般会采用如HDFS的分布式文件系统或者S3对象存储上。通过这样的式，离线数仓便构建起来了。与此同时，为了保障数据的致性，通常需要数据清洗任务使离线数据对实时数据进清洗或定期覆盖，保障数据最终的致性。
　　从技术架构的度对传统数据技术栈进行分析，我们同样会发现，为了迎合不同场景的需求，往往会采用多种技术栈，例如在湖仓部分通常使用的是Hive、Iceberg、Hudi等数据湖；面向湖上数据的Adhoc查询一般选择Impala或Presto；对于OLAP场景的多维分析，一般使Doris或Kylin、Druid。除此之外，为应对半结构化数据的分析需求，例如日志分析与检索场景，通常会使ES进行分析；面对高并发点查询的DataServing场景会使HBase；在某些场景下可能还需要对外提供统的数据服务，这时可能会使基于PrestoTrino的查询关，对户提供统一查询服务。其中涉及到的数据组件有数十种，高昂的使用成本和组件间兼容、维护及扩展带来的繁重压力成为企业必须要面临的问题。
　　从上述介绍即可知道，传统的数据架构存在几个核心的痛点问题：传统数据架构组件繁多，维护复杂，运维难度非常高。计算、存储和研发成本都较高，与行业降本提效的趋势背道而驰。同时维护两套数据仓库（实时数仓和离线数仓）和两套计算（实时数据量和实时计算任务），数据时效性与一致性无法保证。
　　在此背景下，我们亟需个极速、易用、统一、实时的数据架构来解决这些问题：极速：更快的查询速度，最大化提升业务分析人员的效率；易用：对于用户侧的使用和运维侧的管控都提供了极简的使用体验；统：异构数据与分析场景的统一，半结构化和结构化数据可以统存储，多分析场景可以统一技术栈；实时：端到端的高时效性保证，发挥实时数据的价值。如何构建极速易用的实时数仓架构
　　基于以上的需求，我们采取ApacheDoris和ApacheFlink来构建极速易用的实时数仓，具体架构如下图所示。多种数据源的数据经过FlinkCDC集成或FlinkJob加处理后，库到Doris或者HiveIceberg等湖仓中，最终基于Doris提供统的查询服务。
　　在数据同步上，通过FlinkCDC将RDS的数据实时同步到Doris；通过RoutineLoad将Kafka等消息系统中的数据实时同步到Doris。在数仓分层上，ODS层通常选择使用明细模型构建，DWD层可以通过SQL调度任务对ODS数据抽取并获取，DWS和ADS层则可以通过Rollup和物化视图进行构建。在数据湖上，Doris持为Hive、Iceberg、Hudi以及DeltaLake（todo）提供联邦分析和湖仓加速的能。在数据应用上，ApacheDoris既可以承载批量数据加工处理的需求，也可以承载高吞吐的Adhoc和高并发点查询等多种应场景。解决方案如何实现数据的增量与全量同步
　　1。增量及全量数据同步
　　在全量数据和增量的同步上，我们采取了FlinkCDC来实现。其原理非常简单，FlinkCDC实现了基于Snapshot的全量数据同步、基于BinLog的实时增量数据同步，全量数据同步和增量数据同步可以动切换，因此我们在数据迁移的过程中，只需要配置好同步的表即可。当Flink任务启动时，优先进历史表的数据同步，同步完后动切换成实时同步。
　　2。数据一致性保证
　　如何保证数据一致性是大家重点关注的问题之一，那么在新架构是如何实现的呢？数据致性般分为最多次、少次和精确次三种模型。
　　最多次（AtMostOnce）：发送仅发送消息，不期待任何回复。在这种模型中，数据的产和消费过程中可能出现数据丢失的问题。少次（AtLeastOnce）：发送不断重试，直到对收到为。在这个模型中，产和消费过程都可能出现数据重复。精确次（ExactlyOnce）：能够保证消息只被严格发送次，并且只被严格处理次。这种数据模型能够严格保证数据产和消费过程中的准确致性。FlinkCDC通过FlinkCheckpoint机制结合Doris两阶段提交可以实现端到端的ExactlyOnce语义。具体过程分为四步：事务开启（FlinkJob启动及Doris事务开启）：当Flink任务启动后，Doris的Sink会发起Precommit请求，随后开启写事务。数据传输（FlinkJob的运和数据传输）：在FlinkJob运过程中，DorisSink不断从上游算获取数据，并通过HTTPChunked的式持续将数据传输到Doris。事务预提交：当Flink开始进Checkpoint时，Flink会发起Checkpoint请求，此时Flink各个算会进Barrier对和快照保存，DorisSink发出停StreamLoad写的请求，并发起个事务提交请求到Doris。这步完成后，这批数据已经完全写DorisBE中，但在BE没有进数据发布前对户是不可的。事务提交：当Flink的Checkpoint完成之后，将通知各个算，Doris发起次事务提交到DorisBE，BE对此次写的数据进发布，最终完成数据流的写。
　　综上可知，我们利用FlinkCDC结合Doris两阶段事务提交保证了数据写入一致性。需要注意的是，在该过程中可能遇到一个问题：如果事务预提交成功、但FlinkCheckpoint失败了该怎么办？针对该问题，Doris内部支持对写数据进回滚（Rollback），从保证数据最终的致性。
　　3。DDL和DML同步
　　随着业务的发展，部分户可能存在RDSSchema的变更需求。当RDS表结构变更时，户期望FlinkCDC不但能够将数据变化同步到Doris，也希望将RDS表结构的变更同步到Doris，户则无需担RDS表结构和Doris表结构不致的问题。
　　LightSchemaChange
　　目前，ApacheDoris1。2。0已经实现了LightSchemaChange功能，可满DDL同步需求，快速持Schema的变更。
　　LightSchemaChange的实现原理也比较简单，对数据表的加减列操作，不再需要同步更改数据文件，仅需在FE中更新元数据即可，从而实现毫秒级的SchemaChange操作，且存在导入任务时效率的提升更为显著。在这个过程中，由于LightSchemaChange只修改了FE的元数据，并没有同步给BE。因此会产BE和FESchema不致的问题。为了解决这种问题，我们对BE的写出流程进了修改，具体包含三个。数据写：FE会将Schema持久化到元数据中，当FE发起导任务时，会把最新的Schema一起发给DorisBE，BE根据最新的Schema对数据进写，并与RowSet进绑定。将该Schema持久化到RowSet的元数据中，实现了数据的各解析，解决了写过程中Schema不致的问题。数据读取：FE成查询计划时，会把最新的Schema附在其中起发送给BE，BE拿到最新的Schema后对数据进读取，解决读取过程中Schema发不致的问题。数据Compaction：当数据进Compaction时，我们选取需要进Compaction的RowSet中最新的Schema作为之后RowSet对应的Schema，以此解决不同Schema上RowSet的合并问题。
　　经过对LightSchemaChange写出流程的优化后，单个SchemaChang从310毫秒降低到了7毫秒，整体性能有近百倍的提升，彻底的解决了海量数据的SchemaChange变化难的问题。
　　FlinkCDCDML和DDL同步
　　有了LightSchemaChange的保证，FlinkCDC能够同时持DML和DDL的数据同步。那么是如何实现的呢？
　　开启DDL变更配置：在FlinkCDC的MySQLSource侧开启同步MySQLDDL的变更配置，在Doris侧识别DDL的数据变更，并对其进解析。识别及校验：当DorisSink发现DDL语句后，DorisSink会对表结构进验证，验证其是否持LightSchemaChange。发起SchemaChange：当表结构验证通过后，DorisSink发起SchemaChange请求到Doris，从完成此次SchemaChange的变化。
　　解决了数据同步过程中源数据致性的保证、全量数据和增量数据的同步以及DDL数据的变更后，一个完整的数据同步案就基本形成了。如何基于Flink实现多种数据集成
　　除了上文中所提及的基于FlinkCDC进行数据增量全量同步外，我们还可以基于FlinkJob和Doris来构建多种不同的数据集成方式：将MySQL中两个表的数据同步到Flink后，在Flink内部进多流Join完成数据打宽，后将宽表同步到Doris中。对上游的Kafka数据进清洗，在FlinkJob完成清洗后通过DorisSink写Doris中。将MySQL数据和Kafka数据在Flink内部进多流Join，将Join后的宽表结果写Doris中。在Doris侧预先创建宽表，将上游RDS中的数据根据Key写入，使Doris的部分列更新将多列数据分别写到Doris的宽表中。如何选择数据模型
　　ApacheDoris针对不同场景，提供了不同的数据模型，分别为聚合模型、主键模型、明细模型。
　　AGGREGATE聚合模型
　　在企业实际业务中有很多需要对数据进行统计和汇总操作的场景，如需要分析网站和APP访问流量、统计用户的访问总时长、访问总次数，或者像厂商需要为广告主提供广告点击的总流量、展示总量、消费统计等指标。在这些不需要召回明细数据的场景，通常可以使用聚合模型，比如上图中需要根据门店ID和时间对每个门店的销售额实时进行统计。
　　UNIQUEKEY主键模型
　　在某些场景下用户对数据更新和数据全局唯一性有去重的需求，通常使用UNIQUEKEY模型。在UNIQUE模型中，会根据表中的主键进Upsert操作：对于已有的主键做Update操作，更新value列，没有的主键做Insert操作，比如图中我们以订单id为唯一主键，对订单上的其他数据（时间和状态）进行更新。
　　DUPLICATE明细模型
　　在某些多维分析场景下，数据既没有主键，也没有聚合需求，Duplicate数据模型可以满足这类需求。明细模型主要用于需要保留原始数据的场景，如日志分析，用户行为分析等场景。明细模型适合任意维度的Adhoc查询。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有Key列）。如何构建数仓分层
　　由于数据量级普遍较大，如果直接查询数仓中的原始数据，需要访问的表数量和底层文件的数量都较多，体现在日常工作中就是SQL异常复杂、计算耗时增高。而分层要做的就是对原始数据重新做归纳整理，在不同层级对数据或者指标做不同粒度的抽象，通过复用数据模型来简化数据管理压力，利用血缘关系来定位数据链路的异常，同时进一步提升数据分析的效率。在ApacheDoris可以通过以下多种思路来构建数据仓库分层：
　　微批调度
　　通过INSERTINTOSELECT可以将原始表的数据进行处理和过滤并写入到目标表中，这种SQL抽取数据的行为一般是以微批形式进行（例如15分钟一次的ETL计算任务），通常发生在从ODS到DWD层数据的抽取过程中，因此需要借助外部的调度工具例如DolphinScheduler或Airflow等来对ETLSQL进行调度。
　　Rollup与物化视图
　　物化视图本质是一个预先计算的过程。我们可以在Base表上，创建不同的Rollup或者物化视图来对Base表进行聚合计算。通常在明细层到汇总层（例如DWD层到DWS层或从DWS层到ADS层）的汇聚过程中可以使用物化视图，以此实现指标的高度聚合。同时物化视图的计算是实时进行的，因此站在计算的角度也可以将物化视图理解为一个单表上的实时计算过程。
　　多表物化视图
　　ApacheDoris2。0将实现多表物化视图这一功能，可以将带有Join的查询结果固化以供用户直接查询，支持定时自动或手动触发的方式进行全量更新查询结果，未来还将进一步支持更加完善的自动增量刷新。基于多表物化视图这一功能的实现，我们可以做更复杂的数据流处理，比如数据源侧有TableA、TableB、TableC，在多表物化视图的情况下，用户就可以将TableA和TableB的数据进行实时Join计算后物化到MV1中。在这个角度上来看，多表物化视图更像一个多流数据实时Join的过程。
　　如何应对数据更新
　　在实时数据仓库构建的过程中，还需要面临高并发写入和实时更新的挑战。如何在亿级数据中快速找到需要更新的数据，并对其进更新，直都是数据领域不断追寻的答案。
　　1。高并发数据更新
　　在ApacheDoris中通过UniqueKey模型来满足数据更新的需求，同时通过MVCC多版本并发机制来实现数据的读写隔离。当新数据写入时，如果不存在相同Key的数据则会直接写；如果有相同Key的数据则增加版本，此时数据将以多个版本的形式存在。后台会启动异步的Compaction进程对历史版本数据进清理，当户在查询时Doris会将最新版本对应的数据返回给户，这种设计解决了海量数据的更新问题。
　　在Doris中提供了MergeonRead和MergeonWrite两种数据更新模式。
　　在此我们以订单数据的写入为例介绍MergeonRead的数据写入与查询流程，三条订单数据均以Append的形式写Doris表中：数据Insert：首先我们写入ID为1，2，3的三条数据；数据Update：当我们将订单1的Cost更新为30时，其实是写条ID为1，Cost为30的新版本数据，数据通过Append的形式写Doris；数据Delete：当我们对订单2的数据进删除时，仍然通过Append式，将数据多版本写Doris，并将DORISDELETESIGN字段变为1，则表示这条数据被删除了。当Doris读取数据时，发现最新版本的数据被标记删除，就会将该数据从查询结果中进过滤。
　　MergeonRead的特点是写速度比较快，但是在数据读取过程中由于需要进多路归并排序，存在着大量非必要的CPU计算资源消耗和IO开销。
　　因此在1。2。0版本中，ApacheDoris在原有的UniqueKey数据模型上增加了MergeonWrite的数据更新模式。MergeonWrite兼顾了写入和查询性能。在写的过程中引了DeleteBitmap数据结构，使DeleteBitmap标记RowSet中某是否被删除，为了保持UniqueKey原有的语义，DeleteBitmap也持多版本。另外使了兼顾性能和存储空间的RowBitmap，将Bitmap中的MemTable起存储在BE中，每个Segment会对应个Bitmap。
　　写入流程：DeltaWriter先将数据Flush到磁盘批量检查所有Key，在点查过程中经过区间树，查找到对应的RowSet。在RowSet内部通过BloomFilter和index进行效查询。
　　当查询到Key对应的RowSet后，便会覆盖RowSetKey对应的Bitmap，接着在Publish阶段更新Bitmap，从保证批量点查Key和更新Bitmap期间不会有新的可RowSet，以保证Bitmap在更新过程中数据的正确性。除此之外，如果某个Segment没有被修改，则不会有对应版本的Bitmap记录。查询流程：当我们查询某版本数据时，Doris会从LRUCacheDeleteBitmap中查找该版本对应的缓存。如果缓存不存在，再去RowSet中读取对应的Bitmap。使DeleteBitmap对RowSet中的数据进过滤，将结果返回。
　　该模式不需要在读取的时候通过归并排序来对主键进行去重，这对于高频写入的场景来说，大大减少了查询执行时的额外消耗。此外还能够支持谓词下推，并能够很好利用Doris丰富的索引，在数据IO层面就能够进行充分的数据裁剪，大大减少数据的读取量和计算量，因此在很多场景的查询中都有非常明显的性能提升。在真实场景的测试中，通过MergeonWrite可以在保证数万QPS的高频Upset操作的同时实现性能310倍的提升。
　　2。部分列更新
　　部分列更新是一个比较普遍的需求，例如广告业务中需要在不同的时间点对同一个广告行为（展示、点击、转换等）数据的更新。这时可以通过AggregateKey模型的replaceifnotnull实现。具体建表语句如下：CREATETABLEIFNOTEXISTSrequestlog（sessionidLARGEINTNOTNULLCOMMENTid，imptimeDATEREPLACEIFNOTNULLCOMMENT展示，展示数据更新impdataVARCHAR（20）REPLACEIFNOTNULLCOMMENT，clicktimeDATEREPLACEIFNOTNULLCOMMENT点击，点击数据更新clickdataVARCHAR（20）REPLACEIFNOTNULLCOMMENT，convtimeDATEREPLACEIFNOTNULLCOMMENT转化，转换数据更新convdataVARCHAR（20）REPLACEIFNOTNULLCOMMENT）AGGREGATEKEY（sessionid）DISTRIBUTEDBYHASH（sessionid）BUCKETS1PROPERTIES（replicationallocationtag。location。default：1）；
　　具体更新过程如下：
　　（1）更新展示数据mysqlinsertintorequestlog（sessionid，imptime，impdata）VALUES（1，20221220，imp）；QueryOK，1rowaffected（0。05sec）｛label：insert31a037849e2748f69b00b852d106eaaa，status：VISIBLE，txnId：385642｝mysqlselectfromrequestlog；sessionidimptimeimpdataclicktimeclickdataconvtimeconvdata120221220impNULLNULLNULLNULL1rowinset（0。01sec）
　　（2）更新点击数据mysqlinsertintorequestlog（sessionid，imptime，impdata）VALUES（1，20221220，imp）；QueryOK，1rowaffected（0。05sec）｛label：insert31a037849e2748f69b00b852d106eaaa，status：VISIBLE，txnId：385642｝mysqlselectfromrequestlog；sessionidimptimeimpdataclicktimeclickdataconvtimeconvdata120221220impNULLNULLNULLNULL1rowinset（0。01sec）
　　（3）更新转化数据ysqlinsertintorequestlog（sessionid，clicktime，clickdata）VALUES（1，20221221，click）；QueryOK，1rowaffected（0。03sec）｛label：insert2649087d8dc046bda39d367af1f93ab0，status：VISIBLE，txnId：385667｝mysqlselectfromrequestlog；sessionidimptimeimpdataclicktimeclickdataconvtimeconvdata120221220imp20221221clickNULLNULL1rowinset（0。01sec）mysql
　　同时部分列更新还可用于支持画像场景的宽表列实时更新。
　　另外值得期待的是ApacheDoris的UniqueKey模型也即将实现部分列更新的功能，可以通过ApacheDorisGitHub代码仓库及官网，关注新版本或新功能的发布（相关地址可下滑至文章底部获取）。如何进一步提升查询性能
　　1。智能物化视图
　　物化视图除了可以作为高度聚合的汇总层外，其更广泛的定位是加速相对固定的聚合分析场景。物化视图是指根据预定义的SQL分析语句执预计算，并将计算结果持久化到另一张对用户透明但有实际存储的表中，在需要同时查询聚合数据和明细数据以及匹配不同前缀索引的场景，命中物化视图时可以获得更快的查询性能。在使用物化视图时需要建Base表并基于此建物化视图，同张Base表可以构建多个不同的物化视图，从不同的维度进统计。物化视图在查询过程中提供了智能路由选择的能力，如果数据在物化视图中存在会直接查询物化视图，如果在物化视图中不存在才会查询Base表。对于数据写入或更新时，数据会在写入Base表的同时写入物化视图，从让Doris保证物化视图和Base表数据的完全致性。
　　智能路由选择遵循最匹配原则，只有查询的数据集物化视图集合时，才可能物化视图。如上图所示智能选择过程包括选择最优和查询改写两个部分：
　　选择最优在过滤候选集过程中，被执行的SQL语句通过Where条件进判断，Where条件为advertiser1。由此可，物化视图和Base表都有该字段，这时的选集是物化视图和Base表。GroupBy计算，GroupBy字段是advertiser和channel，这两个字段同时在物化视图和Base表中。这时过滤的候选集仍然是物化视图和Base表。过滤计算函数，如执count（distinctuserid），然后对数据进计算，由于CountDistinct的字段userid在物化视图和Base表中都存在，因此过滤结果仍是物化视图和Base表。选择最优，通过系列计算，我们发现查询条件论是Where、GroupBy还是AggFunction关联的字段，结果都有Base表和物化视图，因此需要进最优选择。Doris经过计算发现Base表的数据远于物化视图，即物化视图的数据更。
　　由此过程可，如果通过物化视图进行查询，查询效率更。当我们找到最优查询计划，就可以进查询改写，将CountDistinct改写成Bitmap，从完成物化视图的智能路由。完成智能路由之后，我们会将Doris成的查询SQL发送到BE进分布式查询计算。
　　2。分区分桶裁剪
　　Doris数据分为两级分区存储，第一层为分区（Partition），目前支持RANGE分区和LIST分区两种类型，第二层为HASH分桶（Bucket）。我们可以按照时间对数据进分区，再按照分桶列将个分区的数据进行Hash分到不同的桶。在查询时则可以通过分区分桶裁剪来快速定位数据，加速查询性能的同时实现高并发。
　　3。索引查询加速
　　除了分区分桶裁剪，还可以通过存储层索引来裁剪需要读取的数据量，仅以加速查询：前缀索引：在排序的基础上快速定位数据ZoneMap索引：维护列中minmaxnull信息Bitmap索引：通过Bitmap加速去重、交并查询BloomFilter索引：快速判断元素是否属于集合；Invert倒排索引：支持字符串类型的全文检索；
　　4。执行层查询加速
　　同时ApacheDoris的MPP查询框架、向量化执行引擎以及查询优化器也提供了许多性能优化方式，在此仅列出部分、不做详细展开：算子下推：Limit、谓词过滤等算子下推到存储层；向量化引擎：基于SIMD指令集优化，充分释放CPU计算能力；Join优化：BucketShuffleJoin、ColocateJoin以及RuntimeFilter等；行业最佳实践
　　截止目前，ApacheDoris在全球范围内企业用户规模已超过1500家，广泛应用于数十个行业中。在用户行为分析、AB实验平台、日志检索分析、用户画像分析、订单分析等方向均有着丰富的应用。在此我们列出了几个基于Doris构建实时数据仓库的真实案例作为参考：
　　第1个案例是较为典型的基于Doris构建实时数仓，下层数据源来自RDS业务库、件系统数据以及埋点日志数据。在数据接过程中通过DataX进离线数据同步以及通过FlinkCDC进实时数据同步，在Doris内部构建不同的数据分层；最后在上层构建不同的数据应，如助报表、助数据抽取、数据屏。除此之外，它还结合了的应平台构建了数据开发与治理平台，完成了源数据管理、数据分析等操作。
　　使用收益：业务计算耗时从之前的两时降低到三分钟。全链路的更新报表的时间从周级别更新到分钟级别。Doris度兼容MySQL，报表迁移无压力，开发周期从周级别降至天级别。
　　第2个案例是在某运营服务商的应用，其架构是通过FlinkCDC将RDS的数据同步到Doris中，同时通过RoutineLoad直接订阅Kafka中接入的日志数据，然后在Doris内部构建实时数仓。在数据调度时，通过开源DolphinScheduler完成数据调度；使PrometheusGrafana进数据监控。
　　使用收益：采FlinkDoris架构体系后，架构简洁、组件减少，解决了多架构下的数据的冗余存储，服务器资源节省了30，数据存储磁盘占节省了60，运营成本幅降低。该案例每天在户的业务场景上，持数万次的户的在线查询和分析。
　　第3个应用是在供应链企业，在过去该企业采取了Hadoop体系，使用组件较繁多，有RDS、HBase、Hive、HDFS、Yarn、Kafka等多个技术栈，在该架构下，查询性能无法得到有效快速的提升，维护和开发成本一直居高不下。
　　使用收益：引入Doris之后，将RDS的数据通过FlinkCDC实时同步到Doris，服务器资源成本得到了很的降低。数据的查询时间从Spark的25时，缩短到分钟，查询效率也提升。在数据的同步过程中，使了FlinkCDCMySQL全量加增量的数据同步式，同时还利Doris的LightSchemaChange特性实时同步Binlog的DDL表结构变更，实现数据接数仓零开发成本。总结
　　凭借ApacheDoris丰富的分析功能和ApacheFlink强大的实时计算能力，已经有越来越多的企业选择基于ApacheDoris和Flink构建极速易用的实时数仓架构，更多案例欢迎关注SelectDB公众号以及相关技术博客。后续我们仍会持续提升ApacheDoris在实时数据处理场景的能力和性能，包括Unique模型上的部分列更新、单表物化视图上的计算增强、自动增量刷新的多表物化视图等，后续研发进展也将在社区及时同步。在构建实时数据仓库架构中遇到任何问题，欢迎联系社区进行支持。同时也欢迎加入ApacheDoris社区，一起将ApacheDoris建设地更加强大！
　　作者介绍：
　　王磊，SelectDB资深大数据研发专家、ApacheDorisContributor、阿里云MVP，具有超10年大数据领域工作经验，对数据治理、数据湖和实时数仓有深入理解和实践，人气技术畅销书《图解Spark大数据快速分析实战》、《offer来了：Java面试核心知识点精讲（原理篇架构篇）》作者。