编者按
踏上一带一路的新丝路，北京百分点信息科技有限公司从2016年开拓海外业务，以大数据技术为基础，结合中国先进的数据治国理念，用数据智能推动社会进步。三年时间，百分点海外团队在非洲某国实施大数据项目并取得阶段性验收，在提升客户数据治理能力的同时，结合百分点国内大数据项目优秀实践，积累了一套大数据项目实施的5大体系+20道工序的理论方法。
一、项目思路
在国内，大数据应用已经深入各个行业，不管是业务人员或是技术人员，对于大数据的技术优势以及在业务中发挥的重要作用都非常了解。同时，各个行业发展迅猛，行业业务专家层出不穷。在项目中，客户方有业务专家和技术专家把关业务痛点、业务需求，与承建方的业务、技术专家一同参与系统建设，保证系统的顺利落地。
但在较为落后的第三世界国家，对于业务的了解处在蒙昧阶段，很难有比较清晰明确的业务需求，同时对于基本的IT技术掌握程度较低，大数据更是闻所未闻，对于中方提供的技术方案，很难理解其中的优势以及能够带来的价值。
所以在项目建设过程中，我们需要将国内先进的管理思路传导给客户，简明扼要地展示技术优势，同时配合成熟的系统建设方法，主导从需求到系统运营的系统全周期建设，建立高效运行并且能持续运营的系统，利用数据智能帮助客户提升业务和管理能力。
总结来说，如何快速确定底层数据情况，帮助系统设计人员确定系统功能边界，如何高效地进行数据接入，如何设计合理的数据模型支持上层应用，如何保证数据安全，如何持续运营以发挥数据价值，都是数据中台建设的重中之重。
二、项目实施
- 整体方案
整个项目依照百分点数据项目建设流程进行，主要包括：数据接入、数据治理、数据开发、数据资产和数据服务5大体系和20道工序，保证从数据接入到数据服务的完整流程落地。
- 需求调研
在系统建设初期的需求调研阶段，数仓工程师需要承担的任务，主要有业务系统调研和业务数据分析，基于业务确定系统应用需求范围之后，设计数据需求。
2.1 业务系统调研
在业务系统调研过程中，由于客户技术能力所限，很难将系统的业务流程和数据解释清楚，所以我们主要采用调研问卷、E-R图和数据字典等方式进行系统分析。
（1）调研问卷
调研问卷主要帮助我们了解系统概况，主要包括：
是否有电子化系统
系统是B/S还是C/S架构
业务系统主要功能
与中心机房的网络情况
系统数据的存储方式
增、全量数据量
是否有备份库
可以用何种方式提供数据
有了以上信息，我们能够对所需接入数据有个基本的了解，判断数据接入可行性以及所需的软硬件条件。
（2） E-R图
E-R图主要帮助我们在客户技术人员无法说明系统业务逻辑的情况下，了解系统的业务流程，通过表与表之间的主外键关系，结合对国内相关业务的了解，推测业务数据流向，从而作为之后模型设计的输入。
（3）数据字典
数据字典是业务调研过程中最重要的资料，有了数据字典之后，我们才能进行下一步的业务数据分析工作。在收集数据字典的过程中，我们会尽量与客户的测试环境进行比对，确保拿到的数据字典是最新版本，避免因为版本更新问题，影响系统功能设计和数据接入流程的开发。
2.2 业务数据分析
业务数据分析主要包含两个部分：
（1）数据项分析
数据项分析基于客户提供的数据字典，对业务核心属性进行确认，确保上层业务功能有相应的数据可以支撑
（2）数据质量分析
数据质量分析，基于客户提供的测试或脱敏数据，对关键属性进行空值、规则等判断，确保数据本身具有实际的业务意义，以便之后的业务分析。
2.3 数据需求设计
对于整体系统的功能，我们从系统的两端入手：首先参考国内优秀的建设方案和思路，基于当地实际业务情况，规划系统可能的整体功能；同时调研可接入系统的业务数据和业务流程，对整体功能进行裁剪和补充，形成符合当地的需求蓝图。
确定系统功能之后，我们将系统功能对应的数据应用需求分为以下几类：
（1）报表展现类
主要以维度和指标为主，利用报表或者大屏做业务指标分析或宏观态势监控。
（2）人物事件分析类
主要以“对象-关系”方式进行实体、事件、文档及相互关系、以及时间、空间的分析。
（3）数据比对类
主要以多数据集比对为主，发现不同数据集之间的相互匹配的数据。
（4）网络信息分析类
主要以互联网爬取信息为主，通过文本分析服务，发现热点事件，热点话题，热点人物等信息。
（5）数据共享类
主要以各部门之间数据交换共享为主，保证数据共享过程中的稳定和安全。
按照以上不同的数据应用需求，结合百分点自有的产品以及使用的大数据开源组件，我们构建了数据中台的5大信息库：
（1）专题业务库（MySQL）
以基于维度的指标汇总，按照不同业务专题构建的分析库，方便高分大屏和CBI（百分点智能BI）系统进行报表展示。
（2）动态本体库（ES+Neo4j）
利用百分点 DEEP FINDER产品，构建知识图谱，以API方式为上层应用提供对象-关系分析，从繁杂的图谱中发现类似的行为模式以及关键信息。
（3）比对资源库（PostgreSQL）
利用比对分析系统，构建常用的基础比对资源数据，与各个部门提供的数据进行可视化比对，发现匹配的对象，进行进一步分析。
（4）网络信息库（ES）
网络爬取的数据，通过流式数据处理，导入以ES为存储的网络信息库，利用规则、文本分析，情感分析等分析方法，发现热点事件、热点话题和信息传播关键节点，进行后续处理。
（5）共享资源库（MySQL）
利用百分点数据共享交换平台，构建数据资源，对外提供安全、清晰的数据资源目录，同时提供文件、数据库、API等多种对接方式进行内外部数据交换。
- 项目设计
3.1 框架思路
完成了信息库的设计，下一步就是建模、数据集成处理、调度以及监控，上述任务均在大数据平台（BD-OS）中完成。BD-OS作为基于大数据开源组件的一站式数据处理平台，提供了数据接入、数据建模、ETL开发、流式开发、数据调度、数据监控、数据治理等模块，满足数据处理全链路的所需功能。
我们采用了流批一体的经典Lambda架构，分别处理实时接入的网络数据和批量接入的业务数据；同时，我们采用分层设计，将数据仓库层分为：STG层、ODS层和DW层，保证每一层清晰的数据处理逻辑。整体数据流图如下：
部分整体分为三层：
（1）数据源层
按数据来源分：包括爬虫抓取的网络数据，内网环境业务系统数据，以及外网环境业务系统数据。
按数据格式：分为数据库和文件。
按数据传输频率：分为流式和批量（T+1）传输。
（2）数据接入层
流式数据的接入：我们主要利用Kafka作为存储媒介，通过Spark Streaming进行数据处理，流式作业可以以jar包的形式通过BD-OS上传服务器，从而实时监控进程的执行情况。
批量数据接入：对于内网数据，我们直接使用BD-OS的数据导入功能进行接入；对于外网数据，考虑到系统数据交换的功能以及对外数据链路的安全性，我们使用数据共享交换平台进行数据的导入。
多媒体数据接入：对于视频或图片等多媒体数据，我们使用OSS（对象存储）来进行管理。对象存储中包含两种存储组件：Hbase和Ceph。根据两者存储特性的不同，我们首先判断多媒体文件的大小，对于1M内的小文件，存入Hbase；超过1M的大文件，存储至Ceph，对外通过统一的API进行访问，通过文件的key来调用，提升多媒体文件的存储和读取效率。
（3）数据层
STG：用来接收文件形式的源头数据并临时存放。该部分的数据文件，除了业务系统批量导出的数据，还包含流式处理中需要进行批量统计的数据。
ODS：以Hive表形式来存放源头数据。ODS作为数据中台主体部分的最底层，存储包含存放在STG层（临时数据存放层）的文件数据，以及通过sqoop同步数据库数据。当数据入表之后，数仓工程师就可以方便地使用SQL进行数据处理，降低门槛。
DW：根据不同的数据应用，我们采用了不同的建模方式，在DW层中建立了三类模型，数据均存储在Hive中。选择Hive的原因，一是方便传统数仓工程师使用SQL和UDF进行数据处理；二是批量数据处理要求的时效性不高但数据量大，Hive的特性可以满足需求。
DW-CSM：标准化模型，采用范式建模，将底层数据按照参与人、地址 、事件、物品、组织、关系六大主题域进行整合。这样做的好处，一是将繁杂的源头系统的数据做拆分组合，使得业务逻辑更加清晰；二是在拆分组合的过程中，进行标准化处理，保证数据中台内部码值和规则的统一，对外提供统一的数据标准；三是上层的动态本体，同样是对象-关系的模式，底层数据拆分之后，可以方便地集成至本体中，无需在导入本体过程中做额外的处理。在底层业务系统数量多，业务繁杂，同时需要不断集成新系统的情况下，范式建模能够帮助数据人员理清业务关系，统一数据标准，经过不断地业务沉淀，最终可以建立行业模型。在这个部分，我们将网络爬取数据单独存放在ES中，方便之后的网络信息库应用，这部分数据直接一一映射，不做其他的处理。
DW-CDM：维度模型，采用维度建模，按照上层的分析统计需求，建立维度表和事实表。为了提升查询效率，我们使用标准的星型模型，同时由于Hive表关联效率较低，我们在生成事实表时，对性别，年龄段等枚举值维度做了退化处理，即用码值名称代替code存储在事实表中，避免在数据处理过程中需要关联过多维度表导致处理效率低下，影响用户体验。该部分模型主要支持多维分析和大屏的数据应用。
DW-CBM：业务资源模型，采用宽表建模，将关键信息进行整理合并，形成属性信息完整的宽表，方便之后的数据比对和内外部数据共享。宽表的优点是查询效率极高，一次查询无需关联；缺点是灵活性很差，不适应频繁的表结构变更，对于比对和数据共享需求来说，所需的主要信息变化很小，使用宽表，能够大大提升比对和数据共享的效率。
另外，为了服务上层应用，我们单独搭建了本体模型。
Ontology：本体模型，采用本体建模方式，构建对象-关系的本体模型，来反映真实世界。对象信息主要存储在ES中，而关系信息主要存放于Neo4j。这样既能支持全文检索来发现对象的关键信息，又可以通过图的挖掘发现相同的行为模式，其中对象又可以分为：实体，事件，文档。
实体：业务主体：包括人，车，物理地点等等。
事件：由业务主体实施的行为，基于事件可以进行时间和空间的分析。
文档：文本类信息，单独将文档拆分出来的原因，是文档会有特殊的处理方式，比如文本分析，话题抽象，情感分析等等。
3.2 设计思路
3.2.1 批量部分
（1）数据接入
数据接入的两种方案概述：
目前海外项目中批量数据接入主要有两种方案。一种是使用BD-OS自带的数据导入功能，一种是使用数据共享平台。这两种方案均有各自的优缺点，可以根据不同的业务场景按需采用。
BD-OS自带的数据导入功能，实际上是集成了Hadoop生态的Sqoop组件。这种方式的优点在于Sqoop是将导入命令翻译成为MapReduce程序，与Hive集成较好，对导入到指定的分区表具有较好的支持。缺点只支持导入Hive或者是HDFS文件，并且由于与BD-OS绑定，通常会部署在内网中。对于生产环境都会进行内外网隔离，导致使用此方案时无法接入外网数据数据。
数据共享平台核心功能有两点，一点是资源共享，主要在于提供数据服务（通常是API），另外一点就是数据交换，本部分内容重点讨论数据交换这点。数据共享平台的数据交换功能实际上是集成了阿里的开源离线数据同步工具DataX，它的优势在于支持的数据源丰富多样，比如某个项目中不需要数据接入到Hive，而是直接接入到Phoenix，就可以使用数据共享交换系统的数据交换功能。另外相对于上一种方案，它相对比较轻量级，不需要部署整个大数据平台BD-OS，因此通常也用于在生产环境上部署到DMZ网络区域中，用于接入外网数据。它的缺点就是在于目前DataX对于Hive分区表支持不太完善，仅仅支持一次导入到一个分区表。
两种方案详细介绍：
我们先看一下BD-OS导入功能的界面：
由上述选项可以看出BD-OS的导入功能支持增量、全量导入，支持编写查询SQL，可以选择是否覆盖，另外对于导入的队列、每次读取数据条数等等有较为细节的控制。
再看一下数据共享交换的界面：
可以看出与BD-OS导入功能对比，数据交换功能对于数据读取条数等资源占用控制相关没有提供更为细节的控制。但是也提供了SQL支持，字段映射设置、增量\全量同步、是否覆盖、另外还提供了前置后置脚本功能。
数据交换功能还提供了API用于其他ETL工具集成，调用API可以获取到任务的执行状态。
总结：
在数据导入的增量\全量，是否覆盖、支持SQL等常用的需求点上，BD-OS的数据导入功能和数据共享平台交换功能都提供了对应的支持，这两种方案主要的区别还是在于体量级别以及其他的细节需求点上，实际项目中按需分别采用或者两者都使用均可。
（2）数据治理
数据治理部分，主要包括：元数据管理、数据标准管理、数据质量稽核评估。
a. 元数据管理
随着被接入系统的数据越来越多，相应的元数据也愈加丰富多样，因此对于元数据的管理尤为重要。我们通过BD-OS来进行元数据的自动整合和管理，主要从表，脚本和工作流等方面进行元数据管理。
b. 数据标准管理
为提升数据开发的效率，规范整体的开发流程，基于数据中台开发规范，我们通过BD-OS来定义一套标准体系，包括命名标准，数据元标准，编码标准和字段标准。在进行后续模型开发时，可以直接引用对应的数据标准。
c. 数据质量稽核评估
数据接入之后，数据质量是非常重要的指标，数据质量的好坏，直接影响数据后续使用的效果和产生的价值。针对关键信息，我们会确认数据的格式之后准确性，然后将具体的检查点配置在BD-OS中。
数据规则校验
数据格式校验
通过BD-OS的数据质量稽核功能，我们针对关键表配置了数据质量稽核任务，通过稽核任务监控，我们可以清晰的看到每个稽核规则执行的结果。
同时，对于每张表，我们可以配置字段级的校验任务，根据结果得到数据质量分数。
（3）数据建模
应用BD-OS模型开发模块，开发可以通过可视化配置的方式进行层级/主题域划分，按照分层对逻辑模型配置逻辑表和表字段，生成对应的物理模型并进行物理表管理；也可以直接在数据库中创建物理表后，通过逆向工程生成对应的逻辑模型。海外项目中将模型分层划分为STG、ODS和DW层，实现对数据的标准化处理和规范化管理，满足应用端对数据的业务需求。
（4）数据开发
STG
STG层主要临时存储源系统数据文件，一般通过两种方式同步文件，一种是共享交换平台的周期性任务同步数据文件，另一种是流式数据处理后的结构化数据文件。海外项目中通常将两种方式的数据文件存放在HDFS系统中，以便BD-OS文件加载至Hive数据表中。
ODS
ODS层会对各业务系统数据进行汇聚，保留业务系统全量的原始数据，并作为数据仓库建设的数据源，以便数据仓库中查询到所有业务数据，为后面的DW层数据建设做准备。海外项目中，以Hive表形式存储ODS层数据，其包括STG层文件数据和BD-OS数据接入的源系统数据，并添加一些标识性的属性字段，如系统名称、数据插入时间等；并且按照源数据表业务逻辑和数据量大小采取增量或者全量的数据抽取方式。
DW
DW层的目标是建设一套覆盖全系统、全历史的业务数据体系，可以利用这套数据体系还原和查看系统任意时刻的业务运转状态。应用BD-OS的ETL开发功能，将ODS层的数据按照数据仓库模型，结构化的存储起来，为上层分析应用提供易理解、易使用、易扩展的结构化数据。在海外项目中，一般按照上层应用的不同业务需求，采用不同的建模方式。
DW-CSM：作为数据中台建模中的数据底座，采用范式建模的方式，对项目中全系统数据进行整合，将各个系统中的数据以整个项目角度按照主题进行相似性组合和合并，并进行一致性处理。海外项目中，按照项目需求和源系统数据业务流程，将业务数据拆分为参与人、地址、事件、物品、组织、关系六大主题域，同时也满足上层的动态本体模型构建。项目开发中，应用BD-OS数据工厂下的数据开发模块，通过编写hive sql脚本抽取ODS层数据，并在抽取过程中对数据清洗加工，具体有如下几种操作：
（1）数据质量检查：数据质量检查会过滤掉垃圾数据和不规范数据，确保数据质量足够好，能够帮助业务人员理解真实的业务情况。
垃圾数据删除：测试数据和虚拟用户等数据，需要在系统中删除，以免对业务数据产生影响。
错误数据删除：由于系统错误而产生的错误数据需要删除，例如错误的用户状态，或错误的金额等等。该部分需要源头系统确认。
重复数据删除：对于源头系统已确认的重复数据，或者是在ETL过程中产生的重复数据，需要删除以消除对真实业务数据的影响。
（2）数据转换：来自不同源头系统的数据，需要经过一系列转化，使数据业务含义统一。
编码转换：来自于不同源头系统的编码，对于相同的业务含义，会有不同的编码定义，例如从A系统的数据，用0，1，2定义性别，从B系统来的数据，用M，F，Others定义性别，需要对这些编码进行转换，使得对相同的业务含义，有相同的编码与之对应。
按照应用需求的数据类型转换：按照上层应用对数据的特殊要求，对ODS层数据进行处理，例如经纬度类型转换，ODS层的地理经度和纬度字段，处理为可写入ES geo_point类型的数据格式。
（3）元数据字段添加：在上层应用动态本体建模中，需要知道每条数据的实体标识、事件时间，所以需要在每个DW表中添加实体名称，事件时间等字段。
DW-CDM：该层用于支持多维分析和大屏的数据应用，因此需要满足用户如何更快速进行需求分析，且需要良好的查询响应性能，故从分析决策的需求出发构建维度模型。海外项目中，一般采用星型模型构建事实表和维度表的关联关系。大致分为以下步骤：
选取业务流程，按照系统数据和相关业务选择对应的分析决策需要的业务过程；
定义业务粒度，按照分析需要细分的程度选择对应的粒度；
选取相关维度，按照定义的业务粒度，设计维度表，包括维度属性；
选择事实，按照分析需求确定需要计算的指标。
项目实施中，采用星型模型对各个维度做大量的预处理，如按照维度进行预先的排序、分类和统计，能够极大地提升数据仓库的处理能力；同时维度建模围绕业务模型，可以直观地展现业务流程，方便用户快速开发指标和自定义创建指标，以支持多维分析的业务需求。另一方面，为了满足大屏需求，基于维度建模指标表和维度表，结合大屏指标具体业务需求，设计开发满足大屏指标展示的结果表，并通过BD-OS数据导出功能将结果表数据导出至Mysql数据表，大屏应用通过API读取Mysql结果表数据后不再需要任何处理直接展示，提高大屏指标展示体验效果。
DW-CBM：该层用于支持数据比对和数据共享的应用需求，为满足应用端快速查询和查询的易操作性。海外项目中，一般采用宽表模型设计构建业务分析相关的大宽表，通常在BD-OS中基于DW-CSM层数据将业务实体相关的维度、描述信息、指标等关联后存储在一张表中，例如把人员的基本信息、编号、出生日期、新进人员标识、特殊人员标识、相关案件数量等信息合成一张表存储，再将Hive中宽表数据同步至ES中。应用端可按照业务需求在ES中任意查询对应的数据信息，并且不需要进行表数据关联，提高查询效率。
Ontology
本体库采用本体建模方式，与数据仓库建模不同，数据仓库建模主要考虑的是数据的存储方式和应用端使用的便捷程度，同时考虑存储；而本体的建模，主要考虑创建的模型是否能够表达真实世界的情况，例如在数据仓库范式建模中，是站在项目全系统面向主题的抽象，而本体模型是按照对象和关系表达真实世界。项目中，基于DW-CSM层各主题数据进行抽象分类，按照业务需求端的对象和关系进行数据映射。例如在DW-CSM层，参与人主题下有人员、新进人员、特殊人员三张独立的表，每张表中会以编号作为人员标识，但是在本体模型中，会将三张表数据按照编号融合为一条数据，即人员实体的对象数据。应用端按照本体模型的设计查询和扩展对象和关系数据展现业务场景。
（5）数据应用
基于上述模型，我们就可以灵活地支持设计好的数据应用需求：
DW-CSM：经过人地事物组织关系的标准化拆分后，为网络信息库提供账号和帖子数据，为动态本体库提供对象和关系数据；
DW-CBM：经过基于业务数据整合之后，为共享资源库提供业务数据，为比对资源库提供常用基础数据；
DW-CDM：生成维度表和事实表之后，为专题业务库提供维度和指标数据。
特别地，由于当地IT技术落后，各个部门之间的信息通路不畅，数据共享开始作为客户重点建设内容。我们依托百分点数据共享交换平台，管理、审计、订阅数据资源，对外提供安全高效的数据共享交换服务。
3.2.2 流式部分
（1） 数据接入
流式数据以Kafka为存储媒介，通过数据处理引擎持续不断地消费，进行实时的指标统计和数据存储。数据接入方案主要有两种：
利用大数据操作系统（BD-OS）的数据接入功能，实时的将数据从Kafka接入到HDFS，也可以直接接入Hive表中。
通过Spark Streaming实时消费Kafka中的数据，进行数据加工处理后写入动态本体和ElasticSearch中，方便上层应用进行数据的分析和全文检索。
（2）数据处理
流式数据大部分是网络社交媒体数据和行为事件类数据，比较突出的特征是数据量大，其次单条消息的业务价值有限，实时性要求不高。因此采用了具有微批处理功能的Spark Streaming，可以提升整体吞吐量，并且每批次的数据量可控。
这类数据的清洗加工工作直接在流里完成，主要功能有静态维度表关联，数据打标和保证数据完整消费等。
静态数据关联：数据流通过在启动时初始化静态维度表，将数据缓存到内存中，当有数据流过时，进行数据关联操作。
数据打标：在流中为数据打上时间标识，通过事件发生时间，数据接入时间，数据处理时间和数据写入时间等标识整条数据的完整生命周期和事件路径。
保证数据的完整消费：在数据处理完成后手动提交offset，做到数据最少一次消费。在数据处理过程中，梳理完整的数据异常管理机制，将错误数据输出到Kafka中存储。对数据格式正常，但因网络波动等原因导致未写入最终存储的数据实施数据回写，保证数据完整消费。
实时流程序的运行依托于大数据操作系统（BD-OS），通过平台来进行整个任务的调度和监控。将相关jar包和配置文件传到平台上，之后在流任务开发模块中进行启动的具体参数配置和外部文件依赖等操作。
（3） 数据应用
流式数据最终写入动态本体和ElasticSearch，分别进行数据分析统计和内容全文检索。将行为事件类数据写入动态本体，通过知识图谱构建实体和实体，实体和事件之间的关系，方便业务系统扩线分析。网络社交媒体相关的内容数据，采用ElasticSearch存储，支持模糊搜索和关键词精确匹配，便于分析；相关内容文件存储在OSS（对象存储服务）中，可根据数据ID标识获取具体的文件，图片和视频支持直接在前端展示。
- 系统运营
对于数据项目，系统上线，只是万里长征第一步，接下来需要通过系统运营，让系统持续发挥作用，同时收集更多的数据提升系统价值。
4.1 数据接入跟踪
针对每个单位的每个系统，我们跟踪每一个细节业务数据在系统落地的情况，从数据接入的各个环节，到数据处理到达的各个层级，都有非常准确的状态标示。通过状态的跟踪，我们可以清楚地了解到每个部分数据接入情况，以及是否还有有价值但未接入的数据可以持续接入分析。
4.2 数据使用跟踪
对于每一类数据，我们会按月统计使用情况，从而判断数据热度。对于热度较高的数据，保证数据服务的稳定和高效；对于热度较低的数据，必要时将资源下架，以节省系统资源。
（1）内部数据服务使用统计
（2）外部数据服务使用统计
4.3 系统维护
由于客户现场IT支持能力缺失，我们配置的很多自动化告警措施无法正常运行，为了保证系统的稳定运行，现场运维人员制定了系统的巡检表格，每天由专人来进行系统巡检，发现问题之后，根据故障处理流程，通知客户，处理故障，排查原因，从根本上解决问题，并持续监控一段时间，最终产出事故报告，形成问题处理的闭环。
数据运营是系统是否能够顺利落地并持续产生价值的非常重要的工作。同时，利用已有数据不断地产生价值，可以推动未接入数据部门参与到数据平台建设中，集成更多的数据，从而使数据发挥更大的价值，产生良性循环。
结语
海外数据中台项目，历经三年的卧薪尝胆，砥砺前行，系统逐步落地运行，开花结果。在项目实施过程中，我们积累了很多实施经验：
-
专业、耐心地引导：要发挥专业优势，从业务场景上给客户引导，耐心地了解客户真正的痛点，有的放矢地设计出真正能发挥价值的系统。
-
近距离感受炮火：不能因为上万公里的距离使需求的传递打折、失真，要站在客户的身边，与客户一起分析需求，明确客户的当务之急。
-
充分估计困难：疫情下诸多因素使得海外项目面临重重风险，在项目实施过程中，需要充分识别风险，并按照周、月、里程碑等粒度来监控，确保项目顺利进行。
-
高效远程协作：为了提升远程协作效率，需要做好设计文档的维护，研发需求、任务和缺陷的管理，同时进行实时地远程视频沟通，保证信息准确、及时的传递。
- 多走一步：海外项目人员需要不断扩展自己的职责范围，多走一步，有计划有条理地互相补位，缓解人员轮换的压力，在艰难环境下实现节本增效。
最后，在项目执行过程中，我们不断地总结沉淀，积累经验教训和实施的最佳实践。我们按照地区进行解决方案、交付工艺和技术栈的沉淀，然后与其他地区进行交流互补，互相促进提升，使得交付的质量和效率不断提升，形成一套标准的项目实施套路，让后续的新项目有章可循。该数据项目实施的方法论，在系统落地、成本节约、团队协作、流程优化、以及持续运营方面，都取得了很好的效果，有很高的参考价值。