技术选型： hive on spark+hadoop2.7+sqoop1.4+oracle11g+mysql5.7+DolphinScheduler+Superset 项目描述：建设离线数仓，对业务数据进行整合，按照产品、客户、供应商、成本、员工、回访、运营等模块 按照各个维度进行分析。 ODS 层 数据内容：ERP、财务总账、 数字人力(人力资源管理系统) 、MES(车间管理系统) 、SRM(供应 商管理系统)、PLM(产品生命周期管理系统) 等系统同步采集 数据来源：使用 Sqoop 从 Oracle 中同步采集 存储设计：Hive 分区表，avro 文件格式存储，保留 3 个月，采用压缩比较高的 gzip DWD 层 数据内容：存储所有业务数据的明细数据 (构建事实表) 数据来源：对 ODS 层的数据进行 ETL 解决一些数据质量问题和数据的完整度问题 存储设计：Hive 分区表，orc 文件格式存储，保留所有数据，采用 snappy 压缩 DWS 层 数据内容：存储所有事实与维度的基本关联、基本事实指标等数据构建客户主题、供应商主题、 产品主题、市场主题、运维主题、工单主题、不良品主题、回访主题、费用主题、派单主题 数据来源：对 DWD 层的数据进行清洗过滤、轻度聚合以后的数据 存储设计：按照统计周期进行分区，orc 文件格式存储，保留所有数据 ST 层 数据内容：存储所有报表分析的事实数据 数据来源：基于 DWB 和 DWS 层，通过对不同维度的统计聚合得到所有报表事实的指标 DM 层 数据内容：存储不同部门所需要的不同主题的数据 数据来源：对 DW 层的数据进行聚合统计按照不同部门划分 DIM 层 数据内容：存储所有业务的维度数据：日期、地区、用户、产品、机构、供应商信息等维度表 数据来源：对 DWD 的明细数据中抽取维度数据 存储设计：Hive 普通表，orc 文件 + Snappy 压缩+全量采集 个人职责：1.负责将存储在关系型数据库中的业务系统数据导入 hdfs 上。 2.根据原始数据表，批量创建 hive 表，设置分区、存储格式。 3.根据业务关联关系以及分析指标，建立数仓模型。 4.实现数据模型中的各个数仓分层的数据建模，建表。 5.负责实现每个分层的数据抽取、转换、加载。 6.负责编写 shell 实现 sqoop 脚本批量导入数据。 7.负责编排 sqoop 导入数据的任务调度。 8.负责使用 sparksql 进行数据应用层指标进行分析。 9.解决项目中 ThriftServer 资源不足 GC 问题、ThriftServer 单点故障、数据倾斜、数据采集不 一致等突发问题。 10.对集群中资源优化与代码开发优化。

技术架构: Nginx-1.12.2+Flume-1.7.0+Kafka-0.11.0+Spark2.1.1 +Mysql-5.7.16+ZooKeeper-3.5.7+Hadoop-2.7.2 项目背景：公司的各种 app 总安装量过亿,但是运营很长时间,用户的行为数据的积累几乎为 0,最后呈现的数据 就几张莫名奇妙的报表。对于一个互联网公司,对所有的数据有绝对的控制权,才是最合适的。针对于这种前提 下, 决定创建一个私有化部署的产品,可以部署在客户的内网，技术选型上选择热门的开源技术，同时在数据处 理从采集、传输、查询的各个环节提供普适易用的接口，降低客户的开发代价。 项目架构设计: 1 全端数据采集 因为一个用户在同一个产品上的行为，需要在多个来源进行采集，这些来源包括 IOS、安卓、Web、 H5、*、业务数据库、客服系统等。不仅仅需要采集到，还需要能够将同一个用户在不同来源的数 据进行打通。 针对这样的场景，决定采用全端的数据采集方案，需要包括主流的客户端平台和 Restful 风格的数据导 入 API，全埋点与可视化埋点等埋点辅助手段。最后还需要提供 ID-Mapping 方面的解决方案。 2 数据接入 将采用开源的 Nginx +Flume+Kafka 来实现数据的接入。 选择 Nginx 来接收通过 API 发送的数据,并且将之写到日志文件上。 主要考虑到它的高扩展与高可 靠,易于集成,并且在我们测试下,Nginx 单机可以轻松做到每秒接收 1 万条请求。 考虑到一条请求通常 不止一条用户行为，可以认为很轻松就能做到数万 TPS。 对于 Nginx 打印到文件的日志,会由 Flume 读取和处理 Nginx 日志 ,并将处理结果发送到 kafka。 在 Flume 这个过程中,还会对数据进行格式的效验,属性类型的识别与相关的元数据的操作。 与 ID-Mapping 的处理也是这个阶段完成。字段的解析和扩展的工作,基于 IP 判断国家、省份、城市、 基于 UserAgent 判断游览器、操作系统等，也是这里实现。 Kafka 的选择，作为数据接入与数据处理流程之间的缓冲，同时作为近期数据的一个备份作用。另 外，这个阶段也对外提供 API，客户可以直接从 kafka 中将数据引走,进入自己的计算流。 3 数据储存 存储是建立在 HDFS 上,但是为了满足秒级导入和秒级查询，我们将存储分为 WOS 和 ROS 两部分， 分别为写入和读取进行优化，并且 WOS 中的数据会逐渐转入 ROS 之中。对于 ROS，选择了 Parquet(面 向分析型的列式存储格式)。根据业务具体的查询需求，对数据的分区方式做了很细致的优化。首先按 照日期和事件的名称对数据做Partition，同一个Partition内，会有多个文件，文件大小尽量保持512MB 左右，这里会开启一个 MapReduce 任务,定期合并 Parquet 中每个 Partition 内的碎文件。 虽然 Parquet 是一个查询性能很好的列式存储，但是它是一个不能实时追加的，因此在 WOS 部分， 选择 Kudu。在向 Kudu 中写数据时，选择类似与 0/1 切换的方案，即同一时间只写入一张表，当这张 表的写入达到阈值时，就写入新表中，而老表则会开始转为 Parquet 格式。 4．查询引擎 采用 SparkSQL 的方式访问 Kudu 与 Parquet 数据共同构建的 View，完成对应的聚合和聚散。这 里采用 Redis 进行精细的缓存。 5．元数据与监控 采用 Mysql、ZooKeeper 来维护元数据。主要包括维度字典，数据概括，预测的配置、任务调度、 权限等信息。 6．数据模型 Event+User 模型 每一条 Event 数据对应用户的一次事件，由用户 ID、Event 名称、自定义属性三部分组成。User 则主要描述用户是什么样的人。ID 和自定义属性组成。 个人职责：1.负责将各个来源的数据源的日志数据进行抽取并对其标准化进行存储。 2.对采集的数据进行数据格式的效验,属性类型的识别,并将数据进行分区和读写分离操作。 3.维护管理 Kudu,完成 0/1 切换的方案。 4.实现数据模型中的各个数仓分层的数据建模，建表。 5.负责实现每个分层的数据抽取、转换、加载。 6.负责编写 shell 实现 sqoop 脚本批量导入数据。 7.负责编排 sqoop 导入数据的任务调度。 8.负责使用 sparksql 进行数据应用层指标进行分析。 9.解决项目中 ThriftServer 资源不足 GC 问题、ThriftServer 单点故障、数据倾斜、数据采集不 一致等突发问题。 10.对集群中资源优化与代码开发优化。

项目背景: 金融公司涉及的业务领域众多，公司多年积累了大量复杂的业务数据，在发现问题，分析问题，解 决问题的过程中，其中协调前、中、后台以及科技部门等多方面配合来开展业务口径与逻辑开发目前无法做到。 技术架构: debezium-connector-mysql-1.2.0+kafka_2.11+flink-1.12.2+flink-sql-connector-mysql-cdc1.2.0.jar+ hbase-2.0.5 零售业务实时指标统计: 面向零售业务设计实时数仓，需要获得开户统计、客户服务、APP 运营几个主题的统计指标，根据实时 数据 处理架构和数据仓库分层的设计，面向零售业务的实时数仓可以分为以下几个流程 ODS 层: Debezium 实时采集客户信息表、渠道表等维度相关维度表的 CDC 日志，通过 FlinkCDC 采 集主流的数据业务流水表等主表，建立实时数仓的 ODS 层。 DWD 层: Flink SQL 对 ODS 层，进行数据清洗，过滤、脱敏、打宽等处理。同时以客户账户粒度进行 数据合流，实现 DWD 层的建立。 DWS 层：基于 DWD 层的数据进行汇总，通过分析业务需求，将 DWD 层的数据按照主题进行划分， 汇总出渠道服务主题宽表、业务部运营主题宽表、交易产品主题宽表等公共指标宽表，建立 DWS 层 ADS 层：对于一部分用户账户粒度的业务指标，可通过 DWD 层的明细直接计算得到，部分粗粒度的 业务指标比如 APP 渠道服务客户人数、投顾产品阅读人数等，可以通过 DWS 层计算获得。 工作经历 最终计算结果接入到 NoSQL 数据库将数据统一提供给下游系统或通过 BI 系统展示。 基金投顾实时指标统计: 基金投顾场景的数据有三个特点： 第一，涉及的数据规模比较小 第二，数据在开盘时间提供给公司内部人员查看 第三，数据对准确性的要求特别高 针对数据量小的特点，我们将数据指标结果输出到 mysql 关系数据库；针对开盘时间将数据供给内部 人员查看的特点，我们开启实时任务的启停策略，将更多的资源留给夜间跑批的任务来使用；针对数据准确 性要求很高的特点，我们通过夜间离线跑批的方式对数据进行修正，以保证数据的准确性。 实时 ETL-资金流水场景： 此场景主要满足业务人员在开盘期间快速查询客户某个时间段内的交易流水明细数据。它需要解决三个 问题： 第一，资金流水明细，总共几十亿的数据，数据量很大的情况下，如何做到快速查询？ 第二，开盘时间内满足业务人员查询，且非开盘时间内数据量较小，是否采用定时调度？ 第三，资金流水一定不能出错，如何保证数据的准确性？ 针对数据量大的特点，我们最终选择通过 Hbase 组件来存储数据，通过合理设计 rowkey 与建立 region 分区，达到快速查询指定时间段内的资金流水明细情况；针对非开盘时间内交易数据量很小的特点， 开启任务的定时启停策略，将更多的资源留给夜间跑批任务；针对数据准确性要求高的特点，通过离线数据 修正的方法来达到准确性的要求。 个人职责: 1.与上游系统与下游应用同事沟通协作，推动各类需求在数据模型中的落地和 ODS 的采集。 2.负责编写 Flink 代码构建主题域合并数据流，构建主题事实表。 3.负责各业务线系统的信息调研、表与字段的映射关系梳理，根据业务及日常需求来优化模型。 4.根据业务需要,进行实时数据建模,设计、开发、优化实时数据开发工具和流程。 5.负责离线数仓与实时数仓的数据比对，保证数据准确性。 6.负责项目性能监控、分析、调优等工作，保障系统正常运行。