在互联网时代，每天都会产生海量的数据，去哪儿网成立至今，积累了海量的用户出行数据，每一次旅行机票记录，酒店记录，门票记录等等，这些数据都存储到数据库中，现在流行的 Mysql 数据库，一般情况下单表容量在 1kw 以下是最佳状态，如果将所有的历史记录都存储到 DB 中，那么每张表的大小将超过 10 亿级，根据不同维度的查询将是一个梦魇，比如通过订单号查询，根据用户加状态查询等等，数据库将不堪重负，慢查询可能导致整个库不可提供服务。常用的解决方案是把这些数据存储到一个备用的数据库或者异构的数据结构中，来提升我们的查询效率。数据同步系统就是做这件事的，将数据从一个数据源导入另外一个数据源，提供同构或者异构、低延迟的的数据的同步，提供高可用的数据同步服务，并且保证数据最终一致性。

B站增量数据湖的实践方案与未来展望。

作为汽车之家自研的分布式任务调度系统，调度系统定义了大数据计算和处理的逻辑与规则，对所有任务的执行顺序进行编排管理，实现了任务的有序和高效执行。本文详细介绍了之家分布式任务调度系统的思想以及架构设计。

为了消灭数据孤岛，企业往往会把各个组织的数据都接入到数据湖以提供统一的查询或分析。本文将介绍流利说当前数据接入的整个过程，其间遇到的挑战，以及 delta 在数据接入中产生的价值。

1）携程酒店每天有上千表，累计十多亿数据更新，如何保证数据更新过程中生产应用高可用；

2）每天有将近百万次数据查询请求，用户可以从粗粒度国家省份城市汇总不断下钻到酒店，房型粒度的数据，我们往往无法对海量的明细数据做进一步层次的预聚合，大量的关键业务数据都是好几亿数据关联权限，关联基础信息，根据用户场景获取不同维度的汇总数据；

3）为了让用户无论在app端还是pc端查询数据提供秒出的效果，我们需要不断的探索，研究找到最合适的技术框架。

对此，我们尝试过关系型数据库，但千万级表关联数据库基本上不太可能做到秒出，考虑过Sharding，但数据量大，各种成本都很高。热数据存储到ElasticSearch，但无法跨索引关联，导致不得不做宽表，因为权限，酒店信息会变，所以每次要刷全量数据，不适用于大表更新，维护成本也很高。Redis键值对存储无法做到实时汇总，也测试过Presto，GreenPlum，kylin，真正让我们停下来深入研究，不断的扩展使用场景的是ClickHouse。

B站千亿级数据同步，每天100T+数据导入是如何实现的？本文将介绍Apache SeaTunnel在哔哩哔哩的实践。

针对变化万千的业务需求，采用合适的设计模式是可以轻松应对的。

本文将探索多种优秀设计模式的混编来解决复杂场景的问题，实现1+1>2的效果。应用实践离不开基础，所以文章将以基本概念、设计初衷出发，逐层讲解混编设计模式的落地。

随着有赞的业务发展，数据同步的场景越来越多，主要是 MySQL、Hive 与文本文件之间的数据同步，Sqoop 已经不能完全满足需求。在2017年初，我们已经无法忍受 Sqoop 给我们带来的折磨，准备改造我们的数据同步工具。

基础数据的维护对于提升测试效率是很重要的一个环节，这里介绍一种数据库表粒度的数据同步方法来实现测试环境基础数据的维护。

业务系统查询，涉及多表关联查询，条件维度较大且有模糊匹配需求，索引无法覆盖，导致查询性能较低。

离线存在大量零散的无用数据，人工治理成本很高。有赞是如何识别并自动化下线的呢？

本文主要针对严选交易DB如何进行数据源独立以及在数据源切换整体流程的解决方案以及实施迁移的过程中遇到的一些问题解决思路作为经验分享给大家，希望对后续业务团队在进行相关工作开展有所帮助。

中通快递创建于2002年5月8日，是一家以快递为核心业务，集跨境、快运、商业、云仓、航空、冷链、金融、智能、兔喜社区生活服务、中快数字营销等生态版块于一体的综合物流服务企业。2021年，中通快递全年业务量达到223亿件，同比增长31.1%。全网服务网点30,400+个，转运中心99个，直接网络合作伙伴5700+个，自有干线运输车辆10,900辆（其中超9000辆为高运力甩挂车），干线运输线路约3700条，网络通达99%以上的区县，乡镇覆盖率超过93%。科技中通大数据中心支撑了公司的业务，现在有了两个IDC，Hadoop集群规模达到了上千台，存储达到了18PB+，线上日活任务数2w+，目前，仍处在快速增长期。

如下图展示了一个快递的生命周期，五个字概括就是收发到派签。首先，客户通过线上或线下的方式和快递员取得联系，填写寄件人等信息，将快递A交给快递员。快递A经过称重、打单、扫描、包装等步骤，由快递员送往发件网点，此过程称为揽收。然后，发件网点的快递员将快递A进行建包、装包、装车，由发件网点发出，发往首转运中心。快递A经首转运中心被运输到末转运中心。快递A到达末转运中心后，快递员根据三段码的解析将快递A递交到收件网点，收件网点对快递A进行拆包和分拣，此过程包括发件和到件。快递A被分拣完，由快递员进行派件，最终快递A被送达到收件客户手里，收件客户完成签收。在快递A整个生命周期内，每个业务流程都会产生大量的数据，我们利用这些数据，可以追踪快递A的轨迹，分析快递A的运送时效，分析快递A的退改签等业务。当然，做上述事情的前提是，我们需要一个稳定的、计算高效的、海量存储的基础大数据平台。

用 go-mysql-elasticsearch 实现数据同步的本地化实践。

随着业务的增长，数据库会成为我们业务系统的瓶颈，这时我们就会想到分库分表这种手段，以此降低单数据库的负担。

网校的服务策略团队，专注于学员分班、师资调度、客服机器人等算法方向，该类业务场景下，需要实时获取用户的行为特征，通常是将行为日志以及相关数据库的Binlog写入kafka，再通过Flink消费Kafka数据产生实时行为特征或者统计指标后提供交互，这个过程中需要做几件事情，比如Preprocessing（预处理），Pre-aggregated（预聚合），在线训练过程中还需要关联一些维表或者聚合特征，这些特征可能会全量加载到计算节点里面，也有可能需要历史数据二次计算，就需要一个实时的OLAP平台和高并发的点查服务，形成一个交互过程，最后将实时产生的特征推到算法模块中。这个过程难点在于确定一个既可以提供实时的OLAP还能提供高并发点查服务数据库。