企业数据中台搭建

整合公司碎片化的数据系统

随着公司业务的复杂化，各领域的分析系统、BI系统层出不穷。由于历史原因，这些系统使用的技术架构、供应商和数据定义都各不相同，导致运维成本高昂，Metrics和KPI不统一。为了应对这个挑战，我作为架构师，在技术层面负责将所有BI系统整合并迁移到公司的大数据集群（Cloudera Hadoop）。在项目过程中，我负责的内容包括：

• 数据链路的规划、基于Kettle的PoC的开发。
• 数据批处理的压测。
• 脱敏机制的设计，脱敏的UDF的开发。
• 数仓分层设计、数据质量监控体系的开发。

为了协调各个供应商的数据跑批，合理规划集群的资源分配，我使用了一个react.js的开源架构，开发了集群任务运行图：

统一供应商的技术规范

由于供应商过多，使用技术不统一，供应商对敏感数据、密钥文件的存放和权限管理不规范。为了解决这一问题，我基于自动化运维工具Ansible对集群的所有gateway节点进行统一初始化，利用DevOps来规范所有大数据ETL的开发和部署。
在节点上统一预装了包括大数据计算引擎（MR/impala/Spark）的驱动和运行环境，Azkaban，Kerberos的keytab文件等，对文件目录的权限进行了设置，并编写了开发部署的指导手册。

变革公司的报表系统

将数据驱动的理念推广到全国各家门店，同时避免商业报表系统的Licence成本，为了达成这个变革目标，我作为架构师，利用企业微信的Restful API、ECharts、Luckysheet和Web.py等技术，完成了一个PoC：将报表系统移植到企业微信中。利用企业微信全员使用的特点，近乎零成本地将报表系统向全店铺开。
后来我又作为项目经理，利用企业微信的推送机制，与业务部门紧密合作，按照每个时间段店铺运营的特点，在需要的时间向需要的店铺员工推送需要的报表。(下图是其中一张报表的示意，数据并非真实！)

此外，我还主持开发了数据自助下载系统（SelfQuery），梳理公司总部的全部报表，根据日志分析报表的使用情况，淘汰一部分不必要的报表，将一部分“过度设计”的报表，替换成原始数据的自助下载链接。

完善本地数据和总部数据系统的对接机制

作为架构师，研究总部基于AWS的数据湖接口，并利用grpc、boto3等Python library开发了对接的程序，实现CN侧数据中台和GHQ数据湖的联通。

分析数仓搭建

分析数仓项目是面向公司数据科学团队，基于Hadoop和Hive打造的一个分析数仓项目。

• 使用Kettle、Azcopy和Python boto3 设计开发ETL。使用Azkaban调度。
• 利用Apache Zeppeln构建的数据科学开发环境。
• 数据质量监测系统的inhouse开发。

该项目的一个难点在于数据科学家使用到的很多数据的源头是业务部门手工维护的Excel文件。由于是手工维护，数据质量问题不小。
在项目中我的一个突出贡献是基于Python的一个开源单元测试类库，改造成一个面向大数据数仓的数据质量监控系统，能基于业务规则对数据进行校验，允许数据科学家自助提交测试规则。并利用该系统对项目进行验收，后期又发布成微服务，供ETL系统调用，对每日的增量数据自动进行数据质量的检查。

大数据平台云迁移

计算与存储的分离

Hadoop架构的核心功能有两个，其一分布式计算，其二分布式存储。这两个功能在资源消耗上的模式是迥然不同的。

• 存储服务对磁盘空间的消耗是渐进式的，稳定增长的。
• 而计算引擎对CPU、内存的消耗是爆发式的，一次机器学习的运行可能瞬间耗尽所有内存资源。

传统的Hadoop架构中，slave节点是既负责存储又用于计算的，由于资源消耗模式的不同，很难做到在集群空闲的时候缩容以节省成本。
于是就有了计算与存储分离的概念。既然两个功能的资源消耗模式不同，就应该在架构层面分离两者的资源。
目前主流的做法是将存储层构建在云平台的存储服务中，比如Azure云的Datalake Storage、腾讯云的COS对象存储。而计算层也可以直接使用云服务中的预置组件，比如云中的Spark集群。

腾讯云EMR

腾讯云EMR全称Elastic MapReduce，就是一个典型的PaaS大数据平台。EMR利用腾讯云的对象存储服务COS代替HDFS存储数据。在COS之上可以部署Iceberg、Hudi等逻辑存储层。
EMR提供独立的计算集群可以方便伸缩。计算集群支持的引擎有MapReduce、Spark、Impala、Presto、Clickhouse等。

迁移

迁移期间会有两个大数据集群同时运行，对企业产生巨大的云资源成本，所以迁移的一个要点就是“快”。
为了实现“快”字，整个迁移和验收流程必须最大程度的实现自动化。 我在分析型数仓项目中开发的自动化数据质量校验，在这一次的迁移中再一次起到了关键的作用。
迁移项目并没有使用传统的hadoop distcp模式，原因是两个集群Hadoop版本差距太大，元数据库有太多不一致的地方，且网络打通有难度。所以迁移方案利用了源系统中parquet格式存储的特点，传输parquet文件。
每当传输完一张表的所有parquet文件后，自动调用脚本在新集群利用create table和load inpath语句恢复出表结构和表的内容，然后调用数据质量监控微服务进行数据质量校验，并记录日志，所以能最大程度做到集群迁移的自动化。