作者
刘凯廷 百草味-信息数据中心负责人
朱齐天 百草味-信息数据中心-数据部负责人
内容框架：
- 百草味公司及业务简介
- IDC 自建大数据平台的痛点
- 上云大数据架构选型
- 云原生数据湖架构解析
- 核心模块设计与实施
- 未来展望
- 总结
一、百草味公司及业务简介
百草味是以休闲食品研发、加工、生产、贸易、仓储、物流为主体，集互联网商务经营模式、新零售为一体的全渠道品牌和综合型品牌。百草味以“让更多的人吃上放心健康的食品”为使命，以“食品安全布道者，行业模式探索者”的角色，专注休闲食品，在全球优质原产地探寻美味，于全链路探索更健康的休闲方式与更好的用户体验，在全渠道无限触达消费者。聚焦消费者，百草味不断探索产品解决方案，完善涵盖坚果、果干、肉类、糕点、糖果等全品类休闲食品供应链，目前拥有全品类零食产品1000+SKU；持续革新零售模式，实现电商、商超、新零售、流通、进出口全网覆盖，为1亿多用户和更多消费者带来更好购物体验。此外，百草味打通了物流体系，建立起覆盖全国华东、华北、华中、华南、东北五大区域的十七大仓储物流中心，树立起世界领先的现代智能化物流标杆。未来，百草味将持续耕耘全品类休闲食品，在强大的研发、供应链、物流链以及新零售基础上，领跑中国休闲食品走向全新格局，实现“成为受全世界尊重的食品企业”愿景。
二、IDC 自建大数据平台的痛点
在上云之前，百草味的大数据部署在IDC机房，基于CDH自建的Hadoop集群。选择采用了较为通用的Hadoop架构和组件，基本能满足数仓常规的数据汇聚、计算和使用需求。架构图如下：
但随着业务发展的需要，对接的第三方系统越来越多，不同的场景对数据时效性和精准性要求差异较大，比如：日经营数据T+1的延迟业务部门是接受的，但是输送给CRM的用户交易信息就需要秒级的响应以满足用户登记和积分的变更。不同业务的差异性以及实时性的要求都对我们这个大数据平台的灵活性和稳定性带来了新的挑战。
为了满足业务的需求，整个团队一直处于疲于奔命的状态。为了提升系统的灵活性和稳定性，以及的研发和运维效率，我们首先梳理当前这套 IDC 自建 Hadoop 平台的主要痛点问题：
1. 运维困难、成本高
- 升级和扩容周期长、操作繁琐、风险大：需要到现场进行扩容操作，有选择性的停掉 DataNode 节点，加上磁盘，循环操作后 Rebalance，HDFS 的一次 Rebalance 耗时较久，频繁的元数据变更对 NameNode 也会产生较大压力。
- 运维成本高：集群本身的核心服务都是要满足 HA，但是像开源 Presto 这种组件是有单点故障的，很多情况下需要额外写监控程序频繁监控机器进程来做补救操作。
- 开源组件多，相互之间的兼容和管理越来越复杂，组件升级和改动对系统稳定性带来较大风险。
2. 数据开发、运维难度大，任务稳定性差
- 开发难度比较高：组件越来越多，且组件间依赖关系复杂，大部分开源的开发组件都支持SQL，这是非常友好且灵活的，很多情况下，复杂的业务逻辑需要上千行 SQL，给代码的开发和维护带来很大挑战。
- 问题排查效率低：由于技术和工具的储备不够，线上问题排查非常麻烦。比如排查一个数据倾斜就需要花半天的时间，再比如由于上游落盘文件数多，导致下游一个任务数万个 MapTask 产生，这都给任务的稳定性和出现问题后的排查效率带来很大的困难。
- 计算任务稳定性差，由于机房的网络抖动、磁盘故障等问题会导致流任务出现报错、反压等情况而经常挂掉。
3. 缺乏健全的安全体系
- 只有机器级别的账号权限，用户登录机器后服务和数据的安全性不可控。对一些常用的权限组件进行了尝试，kerberos、ranger 等。但学习和接入成本较高，始终没有投产。
- 数据权限控制上也没有很好的能够精细到行列级别控制的方案，无法满足公司对数据安全的要求。
- IDC 机房的安全性不满足集团的合规要求
- IDC 机房自身的安全性和稳定性得不到保障。
- 没有很好的容灾方案，一旦机房出现问题，对企业的业务和数据都将是致命的打击。
由于以上的种种痛点，尤其是 IDC 机房在安全和容灾方面的风险受到集团合规部门的很大挑战，所以我们决定迁移到云厂商提供的更安全稳定的平台上。
三、上云大数据架构选型
架构演进目标
基于上文分析的一些痛点和问题，我们将这次上云架构演进的目标确定如下：
- 通过上云解决基础设施和数据合规性风险（安全、稳定）。
- 简化架构，缩短数据链路，降低复杂度，提升开发和运维效率。
- 提高系统可扩展性，在资源扩缩容、组件升级等方面有完善的方案。
- 引进权限体系，提升数据安全性。
架构设计原则
基于我们的目标及企业自身的业务和技术环境，我们设定了以下的一些架构原则：
- 核心模块使用开源技术：自主可控，不被厂商技术绑定，同时沉淀团队技术实力。
- 使用全托管服务：将繁重的运维工作交给厂商解决，我们可以专注在业务上。
- 使用批流一体降低链路和开发复杂度：尽量使用统一的引擎来实现数据链路和业务逻辑，降低开发和运维成本，提高效率和技术深度。
- 采用存算分离架构：同时拥有更好的数据安全性和资源的扩展性。
方案选型
在云厂商以及大数据平台方案的选型上，我们主要对比了 AWS 和阿里云提供的数据湖方案。
方案一：AWS 数据湖方案
AWS 有较为成熟完善的数据湖方案，基于 S3 做统一数据湖存储，Lake Formation 元数据管理和权限控制，Glue 做数据 ETL，Athena 和 Redshift 做数据计算和分析。组件间耦合度很低，一个组件专干一个事情，很好的保证了灵活性和性能。
其主要的问题是，相关的产品都是自研的。不满足我们使用开源引擎和不被绑定的原则。提供的 EMR 的产品尽管是开源的，但是是半托管的服务，运维的工作基本还是需要我们自己来承担。
方案二：阿里云云原生数据湖方案
阿里云的数据湖方案，在基于 OSS 的统一存储之上，提供了开源和自研两条路线。自研是以 MaxCompute 为主的数仓引擎。开源是包含了 EMR 的半托管模式和DDI/CDP/Starburst 等全托管模式。除此之外，有数据湖构建 DLF 这样的产品帮助企业快速构建和管理数据湖，结合数据湖加速相关的技术组件，在性能上也有所保障。阿里云的这套数据湖方案整体上还是比较完善的。
选型结论
结合我们这次架构演进的目标和要遵循的一些原则，我们最终决定基于阿里云的数据湖方案来构建百草味的新一代云上大数据平台。一方面在存算分离、开源体系和全托管模式等架构上能够满足我们的诉求；另一方面，我们公司其他的很多业务也发生在阿里云生态里，未来的整合会更方便。
四、云原生数据湖架构解析
结合百草味具体的业务和数据系统的现状，我们基于阿里云的数据湖整体架构最终设计如下：
统一存储：对象存储 OSS
在存储上，我们没有继续使用 HDFS，一方面是 HDFS 会影响集群的扩缩容效率，另一方面 HDFS 的 Namenode 的高可用和稳定性方面都给运维带来很大的挑战。因此我们选择了阿里云上的对象存储 OSS 作为数据湖的统一存储。
阿里云对象存储 OSS 是数据湖的统一存储层，它有12个9的可靠性，可存储任意规模的数据，可对接业务应用、各类计算分析平台，非常适合用来存储企业大规模和快速增长的数据。相对于 HDFS 来说，OSS 可以存储海量文件，并且通过冷热分层、高密度存储、 高压缩率算法等先进技术极大降低单位存储成本。同时 OSS 对 Hadoop 生态友好，基于 JindoFS 的协议转换能力，可以无缝对接阿里云各种大数据计算引擎。
数据湖构建与管理：数据湖构建 DLF
在实现了存储层的统一之后，统一的数据管理和权限控制也是我们非常关心的问题。阿里云的数据湖构建（Data Lake Formation）作为数据湖构建和管理的核心组件，为我们解决了数据入湖、统一元数据管理、统一权限控制等关键问题。
DLF 通过统一元数据服务提供数据湖内数据的管理视图，企业可以通过该服务管理和检索企业的数据，同时无缝对接云上的各类大数据计算和分析引擎。DLF 权限管理模块基于用户和用户组提供列级别的精细化权限控制能力，降低数据安全管理的难度和风险。此外，DLF 还提供了多种数据源的数据入湖和清洗模板，支持以全量和实时增量的方式将数据同步至数据湖中。
数据湖格式：Deltalake
在数据的存储格式上，我们选择使用 Databricks 公司提供的 Delta Lake 格式。该格式支持数据的增量更新和消费，从而避免了使用 Lamda 架构的两条链路来支持离线和实时的数据计算。
数据分析计算引擎：DDI 数据洞察+EMR-Presto 交互式分析
在数据计算和分析层面，我们主要使用 Spark 做离线计算、用 Spark Streaming 做实时计算、用 Presto 做交互式的联邦分析（有一些实时性要求非常高的数据，我们直接从关系数据中读取）。
阿里云的 Databricks 数据洞察（DDI）产品，提供了全托管及商业版的 Spark 服务。在保证软件产品功能和性能领先的基础上，提供了全托管免运维的服务，同时有极高的 SLA 保证，让我们可以更专注在业务模块的开发上。
在交互式分析方面，我们选择使用 EMR 提供的 Presto 服务。Presto 是一个开源的分布式 SQL 查询引擎，适用于 GB 到 PB 级别的大数据交互式分析。同时由于我们部分数据需要从业务的关系数据库直接拉取，使用 Presto 的多 Catalog 和 Connector，可以快速支持跨数据源的联邦分析。阿里云的EMR服务可以帮助我们快速拉起和管理 Presto 集群，并且通过 DLF 可以无缝访问 OSS 数据湖中的数据。
数据开发与调度
在数据开发方面，我们团队继续沿用熟悉的 Zeppelin Notebook 和 Airflow。 EMR Studio 是 E-MapReduce 最新推出的用于开源大数据开发场景的集群类型，提供交互式开发、作业提交、作业调试和工作流一站式数据开发体验。能够无缝对接 EMR 计算集群，自动适配多种计算引擎协同工作。覆盖了大数据处理 ETL、交互式数据分析、机器学习和实时计算等多种应用场景。EMR 的 Data Studio 针对开源的 Zeppelin 和 Airflow 上做了系统化集成以及组件功能的优化和增强。一方面可以从 EMR 上快速构建起 Zeppelin 和 Airflow 的服务，同时拥有更稳定和易用的数据开发界面。
至此，我们从数据的存储与管理，到计算引擎的使用与开发，介绍了百草味这次大数据上云的全新架构。下面我们再具体介绍数据、代码、调度等迁移上云的实施过程，以及新架构上的数据开发运维的落地细节。
五、核心模块设计与实施
Hadoop数据和任务迁移
第一部分涉及的是历史数据的搬迁，从 IDC 的 Hadoop 集群迁移到阿里云的 OSS 上，同时要完成元数据从集群内的 Hive Metastore 到云上 DLF 的统一元数据服务的迁移。
1. HDFS 数据上云，写入 OSS
HDFS数据的迁移，我们使用了阿里云 JindoFS 组件提供的 distcp 功能，通过一行命令完成所有数据文件的迁移。
2. 元数据迁移，Hive 表迁移至 DLF
DLF 产品提供了元数据迁移的功能，只要配置好 HMS 所在的 RDS/Mysql 数据库的连接方式，就可以一键运行命令，将 HMS 的元数据同步至 DLF 元数据服务中。
3. 任务迁移
我们在新老集群里都是用 Zeppelin Notebook 作为主要的开发工具，所以任务迁移只需要线下集群的代码迁移过来就可以了。 Zeppelin 支持使用 SQL、Scala、Java、Python等多种语言进行数据开发，使用非常灵活。
以下是我们的一些代码管理目录和示例：
4. 调度迁移
在调度方面，由于我们迁移的时候，EMR Studio 的 Airflow 组件还没有正式发布，所以我们使用了 EMR 提供的 Workflow 进行调度。它也支持以 DAG 的形式进行任务依赖的管理和调度。后续等 Airflow 发布后，我们会考虑迁移到 Airflow上。
业务数据入湖，DLF 批量/增量入湖
在完成了历史数据和任务迁移之后，我们要开始接入业务系统的数据。从业务上我们主要有两类接入方式，一类是原始数据的同步，分历史数据的批量导入和实时数据的增量导入，另一类是需要在导入的过程中做一些相对复杂的计算逻辑。针对这两种方式，我们分别采用 DLF 的数据入湖和 DDI Spark 的 ETL 来实现。
如下图所示，我们在 DLF上 配置了全量和增量入湖的任务，直接从 RDS 入湖转换成 Delta Lake 格式。实时入湖的链路，底层通过 Spark Streaming 订阅并解析 RDS 的 binlog，将数据更新至 Delta lake 表。可以做到分钟级近实时的数据可见性。
DLF 提供了任务级别的监控，当任务失败时，可以将失败告警以短信、邮件或钉钉群的形式通知到运维人员；针对实时的任务，还可以配置任务延时监控，当数据同步延时超过指定时间时，也会触发告警。这大大提高了我们的运维效率。
DLF 监控
针对一些需要做数据计算的复杂入湖任务，我们使用 Spark 做 ETL 任务，在任务节点上编写具体的计算逻辑。但这部分任务相对较少，需要我们自己做任务状态的监控和管理。
基于 Deltalake 的批流一体数据处理
在 Delta lake 格式下，结合使用 DLF 的实时入湖和 DDI 的 Spark Streaming 技术，我们可以获得分钟级近实时的数据流。使用 Spark Streaming 消费 Delta 的增量数据后，我们将数据 Sink 到在线库（如 TableStore、RDS 等），可以快速给下游的 BI 和业务系统提供最新的数据做分析与决策。同时基于 DDI Spark，我们可以对 Delta Lake 中的数据做离线计算和分析。
联邦分析
在联邦分析方面，由于全托管的 Presto 目前还没有正式发布，我们暂时通过 SparkSql 来实现。我们基于 Databricks，通过简单百来行代码，完成整库或指定表的注册，完成逻辑统一后就可以进行联邦的数据分析。
六、未来展望
目前我们初步完成了大数据平台上云的建设以及业务的迁移，但离我们的理想形态还有很长的路要走。一方面，业务的发展也对我们平台在安全性和性能等方面提出更高的要求，另一方面阿里云的相关产品也在不断完善和发布中，我们会适时引进新的产品和功能。目前有以下几个方面我们正在跟阿里云的同学们一起建设中：
- 多引擎支持多场景数据分析
当下选择的 OSS 作为统一存储，上层的计算层主要 Databricks 数据洞察提供 Spark 引擎做离线和实时的计算分析。因为在线下做数据需求我们是强依赖 Presto 的，OLAP 场景下 Spark 跟 Presto 还是有些差异，阿里云上有半托管的 EMR Presto 产品形态，同时也将推出全托管的 Presto 服务，我们后续会综合考虑需求和产品的发布时间，增加 Presto 的组件。
- 数据权限管理体系
现有权限管理功能刚刚发布，我们正在接入中。
- 存储优化
在存储的数据治理和优化方面，阿里云也提供了很多建议，我们后续会进一步实施。
- OSS 开了多版本之后，存储成本会高很多，另一方面也会影响计算性能，其实 delta这种文件存储也已经做了一层多版本控制。所以要使用 OSS 的生命周期管理消除多版本带来的副作用。
- 分层存储：DLF 产品将推出表和分区级别的数据冷热度分析，同时利用 OSS 的分层存储来进一步优化存储的成本。
- 小文件合并：线下集群的小文件合并是非常透明的，但是 OSS 没有提供这种功能，希望后面可以在 DLF 数据湖管理相关模块中有所体现。
七、总结
本文介绍了百草味的大数据平台从 IDC 自建 Hadoop 集群迁移到阿里云云原生数据湖过程中的思考和实践，目前我们还在不断建设和优化过程中。
最后，非常感谢阿里云数据湖和 Databricks 团队，他们在大数据领域的专业能力和过程中的高效反馈，在我们这次新架构的规划和落地中起到了关键作用。
欢迎试用
对数据湖构建感兴趣的客户都可以测试，测试加入钉钉群（如下），并在群内@扬流
