생산을 지향하는 데이터 시스템

지난 10년 동안 데이터 전문가가 사용할 수 있는 도구는 거의 완전히 바뀌었습니다. 오늘날의 최신 데이터 스택을 살펴보면 대부분의 도구(dbt, Looker, Snowflake, Fivetran, Hightouch, Census)는 2012년에 상용화되지 않았습니다. 전체 카테고리(ELT, Reverse ETL, 클라우드 웨어하우스) 및 프레임워크(데이터 활성화, 데이터 메시) , 데이터 패브릭, 데이터 계약)이 생성되었습니다. (또는 경우에 따라 수십 년 된 SWE 관행이 데이터 팀에 의해 재발견되었습니다.) Twitter + Substack 추종자, 오픈 소스 프로젝트, 경력 및 회사가 흥망성쇠했습니다. 기회는 풍부합니다.

데이터 전문가가 회사의 방향에 영향을 미칠 수 있는 가능성과 표면적은 10년 전보다 훨씬 더 커졌습니다. 불행하게도 잘못될 수 있는 표면적도 마찬가지로 빠르게 증가했습니다. 도전 과제는 낮은 수준의 기술 SLA에서 높은 수준의 시스템, 문화, 표준 및 조직 설계에 이르기까지 다양합니다. 새로운 도구는 매우 강력합니다. 기업은 그 어느 때보다 빠른 속도로 데이터 시스템을 구축하고 중단할 수 있습니다.

저는 지난 5년 동안 데이터 팀 내의 기술 분야와 데이터가 지원하는 비즈니스 분야 전반에 걸쳐 데이터 시스템에 대한 세 가지 추세를 관찰했습니다. 저는 많은 회사에 일반화되는 예를 통해 이러한 경향을 설명하고 귀하의 팀에 일반화되는 방식으로 기회, 문제 및 솔루션을 설명하려고 합니다. 트렌드, 기회, 문제 및 솔루션:

생산을 지향하는 시스템

• 요약 : 귀중한 데이터 작업 및 출력은 점점 더 중요해지는 사용 사례/생산 등급에서 소비됩니다.
• 기회 : 데이터 팀의 결과는 훨씬 더 크고 영향력 있는 표면 영역에 분산될 수 있습니다.
• 문제 : 데이터 출력이 더 중요한 사용 사례에서 사용되기 때문에 초기에 매우 가벼운 방식으로 설정된 워크플로우의 해당 "강화"가 없습니다.
• 솔루션 : 경량 흐름이 "프로덕션"으로 승격되는 경로를 만들고 시스템이 프로덕션 등급으로 이동함에 따라 시스템을 강화하는 데 소요되는 시간을 축하합니다.

• 요약 : 처음에 특정 목적을 위해 의도된 데이터 출력은 점점 더 많은 팀과 사용 사례에서 무의식적으로 채택되고 있습니다.
• 기회: 특정 사용 사례를 위해 설계된 통찰력은 더 많은 팀에서 더 나은 의사 결정 및 결과를 이끌어낼 수 있습니다.
• 문제 : 정확히 동일한 사양을 가진 두 팀이 없으며 한 사용 사례에 대한 개선 사항이 다른 곳에서 사용되지 않습니다.
• 솔루션 : 소비자/생산자 약정 + 종속성에 대한 가시성 생성, 비즈니스 로직 중앙 집중화.

• 요약 : 데이터는 여정 전반에 걸쳐 여러 단계에서 변환될 수 있으며 비즈니스 논리는 다양한 도구에 있습니다.
• 기회 : 최신 데이터 도구를 사용하면 이해 관계자가 데이터에 액세스하고 라스트 마일 변환을 수행하여 더 빠르게 이동하고 차단을 해제할 수 있습니다.
• 문제 : 스택 전체의 비즈니스 논리로 인해 재현이 불가능하고 마지막 마일 변환은 다른 데이터 소비자에게 도움이 되지 않습니다.
• 솔루션 : 비즈니스 논리를 삽입할 수 있는 영역을 줄이고, 라스트 마일 변환에 대한 "수명" 정책을 만들고, 표준화 문화를 구축하고 교차 기능 코드베이스에 대한 액세스를 축하합니다.

2019년 여름 . 스파이크 셀처의 부상은 멈출 수 없지만, 아직 모르고 있는 엄마와 대중 주류 판매점 주인이 있습니다. 귀하는 B2C 주류 마켓플레이스의 분석 엔지니어입니다. 귀하의 계정 관리자(알코올 소비 전문가)는 Claws가 상점에서 구입할 수만 있다면 선반에서 날아갈 것임을 알고 있습니다. 이것은 더 나은 재고가 고객, 소매업체 및 회사에 이익이 되는 애매한 시장 파레토 개선 윈/윈/윈입니다. 귀하는 귀하의 네트워크에 있는 주류 판매점에서 판매하지 않는 최고 판매 품목을 알아내는 임무를 받았습니다.

1. 내부용(BI tool / Looker)

초기 쿼리는 작성하기 쉽습니다. 상점 테이블이 있습니다( market_id시장별 최고 판매 SKU 및 모든 상점에 대한 일일 인벤토리 피드 포함). 모든 매장에는 일일 재고 피드가 있습니다. 다음과 같이 각 매장에서 판매하지 않는 최고 판매 품목을 얻습니다.

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

...초기 계정 관리자는 프로세스 전반에 걸쳐 대시보드에서 피드백을 제공합니다.

참고: BI 도구는 데이터 팀 인프라입니다. 통찰력/사용 사례/제품이 데이터 팀의 영역을 벗어나지 않았습니다. 실수는 결과가 적고 피드백은 + 즉각적일 가능성이 높습니다.

2. 내부용(내부 도구/Salesforce)

그러나 영업/고객 성공/계정 관리 팀은 하루 종일 Looker에서 보내는 것이 아니라 Salesforce에서 하루 종일 보냅니다. 두 개의 브라우저를 열어두는 것은 고통스러운 일입니다. 이것은 교과서 역방향 ETL 사용 사례입니다. 데이터를 사용할 위치에 두십시오 . 이것은 몇 년 전에는 어려웠지만 지금은 사소합니다. 역방향 ETL 공급자에 서명하고 하루 안에 데이터 포인트를 A에서 B로 이동합니다.

매장 에서 취급하지 않는 가장 많이 팔리는 품목 이 이제 Salesforce에 있습니다. 데이터 팀은 마찰이 적은 방식으로 다른 팀의 컨텍스트를 추가했습니다. 이것이 바로 데이터 활성화의 핵심입니다. 다른 팀이 익숙한 도구를 사용하여 작업을 더 잘 수행할 수 있도록 지원합니다. 더 많은 계정 관리자가 더 많은 누락된 재고 항목을 확인하고, 더 많은 매장에 전화를 걸고, 더 많은 상위 SKU가 주류 판매점에 들어가고, 더 많은 판매가 발생합니다. 모두가 이깁니다.

...한 계정 관리자는 맥주 및 와인 매장에서 가장 많이 판매되는 품목 목록에 주류 품목이 있음을 알게 됩니다. AM은 비즈니스 컨텍스트를 사용하고 매장에서 법적으로 취급할 수 없는 항목을 추천하는 것은 건너뜁니다. 인간의 의사 결정 계층을 통해 추가 비즈니스 논리가 추가되었습니다.

참고: Salesforce는 데이터 팀 인프라가 아닙니다. 통찰력과 사용 사례는 데이터 팀의 영역을 떠났지만 회사는 그렇지 않았습니다. 고객이 직면하는 것은 없습니다. 실수는 결과가 낮지만 피드백이 보장되지는 않습니다. 추가 논리가 추가되었습니다(인간의 판단을 통해).

3. 외부 사용(마케팅 자동화)

Salesforce 구현은 유용하지만 본질적으로 여전히 상당히 수동적입니다. 계정 관리자와 주류 판매점 주인은 그대로 전화에 너무 많은 시간을 보냅니다. 대부분의 주류 판매점은 일주일에 한 번 재고 주문을 합니다. AM은 데이터 및 마케팅 운영의 도움을 받아 매주 자동화된 이메일을 통해 커뮤니케이션을 간소화합니다.

몇 개의 열이 더 필요하면 원시 테이블이 Hubspot/Iterable/Braze로 역 ETL'd됩니다. CRM 담당자가 이메일 캠페인을 마무리하고 "가지고 다니지 않는 인기 품목"이라는 제목의 이메일 캠페인이 시작됩니다.

...이메일을 담당하는 CRM 직원은 가장 많이 팔리는 품목(개수 기준) 중 일부가 술에 취했다는 사실을 알게 됩니다. 이는 회사 브랜드 비전/고객이 원하는 사용 사례와 일치하지 않습니다. 대부분의 이메일 시스템은 추가 논리 계층을 허용합니다. CRM 직원은 자신의 판단을 사용하여 50ml 이하의 항목을 필터링합니다.

참고: 통찰력과 사용 사례는 데이터 팀과 회사의 영역을 떠났습니다. 이제 데이터 팀 출력이 고객을 향합니다. 실수는 더 큰 결과를 가져오고 피드백은 올바른 이해 관계자에게 올바르게 전달될 가능성이 적습니다. 추가 비즈니스 논리가 추가되었습니다(CRM 계층의 라스트 마일 변환을 통해).

4. 외부 사용(생산 응용)

데이터 팀은 AM 및 CRM 팀의 의견을 듣습니다. 일부 주류 판매점은 꽤 구식이며 이메일을 확인하지 않습니다. 다른 주류 판매점은 새로운 학교이며 시장에서 유행하는 것에 대한 이메일을 받기 위해 일주일 내내 기다리기를 원하지 않습니다. 이 그룹은 모든 소매업체가 실행하는 프로덕션 앱에 "가지고 다니지 않는 인기 품목"을 넣기 위해 소매 애플리케이션 팀을 순환하기로 결정합니다. 데이터 팀은 출력을 AWS S3 버킷으로 옮기고 프로덕션 엔지니어링에서 선택합니다. 이제 주류 판매점 직원은 계정 관리자나 이메일 마찰 없이 이 목록을 매일 볼 수 있습니다. White Claw와 Whispering Angel은 미국의 모든 매장에 진출합니다.

...한 소매업체가 소매업체 CX에 불만을 제기했습니다. 휴일 이후 Smirnoff 페퍼민트 보드카 재고를 일부러 중단했습니다. 말 그대로 L90 최고 판매 품목일 수 있지만 매우 계절적이며 추천 목록에서 보고 싶어하지 않습니다. 이 피드백은 프로덕션 엔지니어링 팀에 전달되며, 해당 팀은 지난 시즌 아이템을 식별하고 제거하기 위해 애플리케이션 계층에서 로직을 조정합니다.

참고: 통찰력과 사용 사례는 데이터 팀과 회사의 영역을 떠났습니다. 데이터 팀 출력은 고객을 향합니다. 실수는 더 큰 결과를 가져오고 피드백은 올바른 이해 관계자에게 전달될 가능성이 적습니다. 추가 로직이 추가되었습니다(프로덕션 애플리케이션 계층의 비즈니스 로직을 통해).

마지막 가설: 인벤토리 피드 소비를 담당하는 엔지니어링 팀(소매업체 애플리케이션을 담당하는 팀과 다름)이 새로운 인벤토리 스키마로 마이그레이션합니다. 그들은 "가지고 다니지 않는 상위 항목" 프로젝트의 단일 단계, 데이터 팀이 자신의 작업 위에 묵묵히 구축한 종속성 또는 다른 사람들이 데이터 팀의 작업 위에 구축한 종속성을 인식하지 못합니다. 그들은 초기 테이블을 삭제합니다. NULLLooker, Salesforce, Hubspot 및 생산 소매업체 애플리케이션으로의 흐름입니다. 데이터 팀이 제품을 망쳤습니다.

좋은 일과 나쁜 일 모두 일어난 일을 요약해 보겠습니다.

"데이터 활성화" 이전에 경력을 시작한 데이터 전문가의 관점에서 방금 일어난 모든 일(엔딩 제외)은 놀랍습니다! Looker 대시보드로 시작한 것은 모든 단계에서 입증된 비즈니스 가치와 함께 프로덕션 애플리케이션으로 빠르게 전환되었습니다. 제안된 제품이 이미 사용자에 의해 검증된 마지막 단계까지 SWE 리소스가 필요하지 않았습니다.

데이터 전문가의 영향과 경력 궤적은 그들이 영향을 미칠 수 있는 표면 영역에 의해 제한됩니다. 2012년 비즈니스 인텔리전스 분석가는 Tableau + 내부 프레젠테이션으로 제한되었습니다. 오늘날 CAN 의 데이터 전문가는 Salesforce에 행을 입력하고, 마케팅 이메일을 트리거하고, 프로덕션 서비스 및 애플리케이션에서 사용할 데이터 제품을 구축합니다. 이것은 멋진 소식입니다!

단점: 10년 전의 데이터 전문가는 "야, 데이터가 이상해 보인다"라는 메시지에 익숙했습니다. 최악의 시나리오는 보드 데크에 잘못된 메트릭을 넣는 것이었습니다. 오늘날 데이터 팀은 Pagerduty가 설정된 경우 Salesforce, Hubspot 및 프로덕션 애플리케이션이 손상되었다는 Pagerduty 알림으로 깨어날 수 있습니다 . 데이터 활성화는 데이터 팀이 깨뜨릴 수 있는 위험을 높였습니다.

이 가상의 인스턴스에서 상점 및 계정 관리자는 오류가 수정될 때까지 하루나 이틀 동안 짜증을 낼 것입니다. 모든 것을 고려하면 이 오류는 상대적으로 비용이 적게 듭니다.

그렇다고 해서 비용이 많이 들지 않는다는 의미는 아닙니다! 고객 이탈을 예측하는 데이터 과학 출력을 상상해 보십시오. 그 가능성이 특정 임계값을 넘으면 5달러 프로모션 코드가 전송됩니다. 이제 모델이 부적절하게 재훈련되거나 재보정되거나 실제로 무엇이든 된다고 상상해 보십시오. 동일한 데이터 활성화 파이프를 사용하여 실수로 수백만 달러의 프로모션 코드를 보낼 수 있습니다.

최신 데이터 스택을 사용하면 데이터 출력을 생산해야 하는지 또는 입력을 구축한 팀이 출력이 어떻게 소비되고 있는지 알고 있는지 여부에 관계없이 데이터 출력을 매우 쉽게 생산할 수 있습니다. 이러한 도구는 더 중요한 사용 사례로 승격되므로 초기 쿼리 또는 파이프라인을 강화할 필요가 없습니다. 초기 출력을 만든 사람들의 동의나 가시성이 필요하지 않습니다.

추가 비즈니스 로직을 기억한다면:

• 계정 관리자는 자신의 판단에 따라 맥주/와인 상점에 주류 SKU 추천을 건너뛰었습니다.
• CRM 담당자는 브랜드 고려 사항으로 인해 SKU <= 50ml를 제거했습니다.
• 소매업체 애플리케이션 팀은 고객 피드백으로 인해 시즌성이 높은 SKU를 제거했습니다.

그렇다면 이러한 문제를 해결하기 위해 무엇을 할 수 있습니까?

시스템은 프로덕션 경향이 있습니다.

끔찍한 이야기, 일반화된 문제, 프로덕션 시스템에 대한 기술 솔루션은 데이터 트위터와 하위 스택에 걸쳐 설득력 있게 작성되었습니다. 솔루션은 대부분 SWE가 수십 년 동안 알고 있는 모범 사례입니다(또는 Zach Kanter 가 다른 방식으로 말했듯 이 현상 유지 데이터 엔지니어링은 모범 사례가 없는 소프트웨어 엔지니어링일 뿐입니다 ). 데이터 팀을 위해 저에게 가장 잘 맞는 몇 가지 요소/원칙은 다음과 같습니다.

데이터 팀은 입력을 제어하지 않습니다 (h/t Nick Schrock )

데이터 출력은 인간 또는 알고리즘이 책임을 지는 여부에 관계없이 조직에서 많은 결정의 기초가 됩니다. 그러나 데이터 팀은 소프트웨어 엔지니어가 하는 방식으로 입력을 제어하지 않습니다. 데이터 팀은 QA에 투자하여 계산을 방어해야 합니다. 과거의 문제뿐만 아니라 아직 발생하지 않은 문제에 대해서도. 이 테스트에는 다음이 포함되어야 합니다.

• 단일 행의 유효성( int예상하는 경우 int, <50을 예상하는 경우 <50)
• 집계 행의 유효성(세부성 가정, 행 수에 대한 비즈니스 컨텍스트, 어제와 관련된 행 수, 합계, 평균, p90, 중앙값과 같은 집계 분포)
• 데이터의 존재/부실(마지막으로 테이블이 업데이트됨)

오류 비용은 스테이징에서보다 프로덕션 시스템에서 기하급수적으로 높습니다. 가능한 한 빨리 오류를 포착하고 가정을 테스트하는 데이터 테스트 파이프라인 및 개발 + 배포 패턴을 만듭니다.

이러한 솔루션은 올바른 도구(우리는 Great Expectations 를 좋아함 )를 선택하고 노력 하는 데이터 팀이 구현할 수 있는 솔루션입니다 . 그것이 문제의 20%입니다. 나머지 80%의 조직적 + 커뮤니케이션 문제는 시스템이 중단되는 원인입니다. 전사적 솔루션은 다음과 같습니다.

프로덕션 등급 데이터 배기 생성

또는 의도적으로 데이터를 생성합니다 . 데이터 과학이 강력하다고 믿는 회사는 기계 학습 및 고급 분석 사용 사례를 지원하기 위해 의도적으로 프로덕션 데이터를 생성해야 합니다(h/t Yali Sasoon). 이를 위해서는 엔지니어와의 협력이 필요하며, 힘들게 추출하는 것이 아니라 의도적으로 데이터를 생성할 수 있도록 전사적으로 조정해야 합니다.

생산 경로 생성 및 축하

회사는 생산 등급을 향해 작업을 강화하기 위한 지침이나 시간을 마련하지 않고 개발 환경에서 빠른 반복을 너무 자주 축하합니다. 이 작업을 축하하고 시스템 강화를 위한 명시적인 교차 기능 시간 및 소유권을 개척하십시오.

맹목적인 연합을 지향하는 시스템

다시 한번 — 이 문제를 축하합시다! 많은 사람들이 데이터 팀 출력에 대해 서로 다른 비즈니스 사용 사례를 찾는다면 제대로 하고 있는 것입니다. 그러나 10년 전에 일부 임시 대시보드가 ​​보드 데크로 만들 수 있었던 것과 같은 방식으로 해당 임시 쿼리가 사용자 모르게 프로덕션 애플리케이션으로 만들 수 있습니다.

이벤트 기반 오케스트레이션을 위한 단일 컨트롤 플레인 활용

Fivetran, dbt 및 Hightouch는 모두 cron 일정 및 UI를 통해 작업을 예약할 수 있습니다. 이를 통해 암시적 종속성에 대한 가시성을 표면화하지 않는 방식으로 오케스트레이션을 구축할 수 있습니다. Hightouch가 exp_fb_click_ids매일 오전 8시에 UI를 통해 이동할 예정이라고 상상해 보십시오. Fivetran과 dbt는 해당 종속성에 대한 가시성이 없으며 Hightouch의 코드베이스 업스트림에 기여하는 것도 아닙니다.

대신 오케스트레이션 도구(Dagster/Prefect/Airflow)를 단일 제어 평면으로 사용하십시오. 도구 간의 종속성을 병합하고 특정 시간까지 업스트림 작업이 성공하기를 바라지 않고 이전 단계 성공을 기반으로 실행되는 전체적인 DAG를 만듭니다. 재결합 .

다운스트림 사용 사례에 대한 데이터 팀 내보내기의 일대일 매핑 생성

데이터 팀은 dbt가 프로젝트 구성 을 제안하는 방식에 익숙해야 합니다 . 일반적으로 준비 계층은 소스 입력에 대한 일대일 관계를 매우 명확하게 만드는 방식으로 구성되고 이름이 지정됩니다. 출력에 유사한 패턴을 사용합니다. Salesforce 기회 및 계정 개체가 스테이징에서 dbt 테이블을 나타내는 것과 마찬가지로 데이터 내보내기가 하나의 사용 사례에만 사용된다는 것도 분명해야 합니다.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

층염을 요약하는 대신 Jean-Michel Lemieux의 훌륭한 스레드 와 정의 로 다시 안내하겠습니다 . 일반적인 조언은 저에게 효과가 있었던 일부 데이터 세부 사항과 함께 그의 것입니다.

계층염에 대한 기술적 정의는 팀이 속도를 최적화하면서 가장 편안한 곳에 코드를 넣는 것과 전체 소프트웨어 시스템에 대한 장기적인 관점을 고려할 때 속한 곳에 코드를 넣는 것입니다.

라스트 마일에서 비즈니스 로직을 주입할 수 있는 영역을 줄입니다.

Hightouch 및 Census는 SQL 변환을 허용합니다. Fivetran 은 . 대부분의 데이터 활성화 소비자(Sales/CX CRM, CDP)는 SQL 또는 로우/코드 없는 비즈니스 논리 계층을 허용합니다. 가능하면 이러한 도구에 비즈니스 로직을 작성하지 마십시오. 다운스트림 사용 사례에 대한 데이터 팀 내보내기의 일대일 매핑을 따르는 경우 역방향 ETL은 항상 다음과 같을 수 있습니다.

select * from exp_table_for_single_use_case;

비즈니스 논리의 변경 사항은 라스트 마일이 아닌 해당 dbt 모델에 적용되어야 합니다.

라스트 마일 변환에 대한 "Time To Live" 정책 생성:

데이터 팀은 라스트 마일 변환을 완전히 제거할 수 없습니다. 이해 관계자가 데이터 팀에 의해 차단된 것처럼 느끼기를 원하지 않습니다. 항상 핫픽스를 도입하거나 dbt PR + Snowflake 새로 고침보다 빠른 비즈니스 로직을 반복해야 할 필요가 있습니다.

보다 일반적으로, 귀하의 비즈니스 이해관계자는 귀하가 알지 못하는 맥락을 가지고 있습니다. 그들이 데이터 를 어떻게 변경하는지 확인 하고 싶습니다 . 분석 엔지니어가 놓친 계절별 SKU, 수량, 매장 분류 로직을 다시 생각해 보십시오. 비즈니스 이해관계자가 업무를 개선할 수 있는 세상을 만드세요!

"Time To Live" 정책은 중앙 집중화를 향한 중력적 후퇴입니다. 라스트 마일 변환을 허용하지만 이를 검토하고 데이터 팀과 비즈니스 이해 관계자에게 적합한 케이던스에서 비즈니스 논리를 중앙 DBT/데이터 과학 계층으로 다시 가져옵니다.

교차 기능 코드베이스에 대한 표준화 + 축하 액세스 문화 구축

사람들은 기본적으로 가장 편한 도구로 비즈니스 로직을 작성합니다. CRM 직원의 경우 Hubspot / Iterable / Braze일 수 있습니다. 데이터 팀이 무분별한 비즈니스 논리를 방지하는 가장 좋은 방법은 다른 도구의 라스트 마일 변환을 제한하는 것뿐만 아니라 다른 사람들 을 도구 에 초대 하는 것 입니다.

이것은 ️️️ 걸릴 수 있습니다. 비 데이터 팀 구성원이 SQL로 논리를 작성하고 dbt PR을 만드는 것에 대해 걱정하는 데는 여러 가지 이유가 있습니다. 내가 보장할 수 있는 것은 이 논리 가 작성되고 데이터 팀이 게이트키프를 수행하는 경우 가시성 외부에 작성된다는 것입니다. 데이터 팀이 코드베이스에 대한 기여를 교육하고 장려할 수 있다면 코드가 가장 속한 곳에 작성되도록 초대합니다.

비행기 착륙:

지금은 데이터 리더가 되기에 좋은 시기입니다. 데이터 에코시스템 개발의 지난 10년은 자사 및 타사 도구에서 데이터의 이동 및 조작을 상품화했습니다. 꿈과 신용 카드 가 있는 유능한 분석 전문가 한 명이 내부 보고, 내부 도구, 마케팅 자동화 및 프로덕션 애플리케이션을 강화할 수 있습니다. 이것은 기업과 데이터 전문가에게 객관적으로 놀라운 소식입니다.

• 최신 데이터 스택을 사용하면 데이터 팀이 생산 엔지니어링 권한이나 가시성 없이 생산해야 하는지 여부에 관계없이 무엇이든 생산할 수 있습니다.
• 최신 데이터 스택을 사용하면 비즈니스 이해관계자가 최종 마일 비즈니스 로직을 추가하여 데이터 팀의 허가나 가시성 없이도 생산 워크플로를 강화할 수 있습니다.

어느 시점에서 데이터 제품은 프로덕션 애플리케이션을 손상시킵니다. 보내지 말았어야 할 마케팅 이메일이 전송됩니다. CRM 팀은 데이터 팀을 비난하고 데이터 팀은 프로덕션 엔지니어링 팀을 비난합니다. 내가 배운 가장 중요한 교훈 중 하나이지만 여전히 매일 어려움을 겪고 있습니다 . 긴장된 방/Zoom에 들어가서 우리 모두가 같은 팀에 있다는 것을 모두에게 상기시키는 능력은 초능력입니다. 이것이 데이터 시스템을 프로덕션에 적용하는 방법에 대한 실제 요약입니다.

다음과 같은 문화를 만들 수 있다면:

• 생산 엔지니어는 데이터가 어떻게 사용될 것인지에 대한 의도와 흥분으로 데이터 배출을 생성합니다.
• 데이터 팀 구성원은 사용 사례를 찾고, 피드백을 요청하고, 이해 관계자에게 "이봐, 내가 보낸 데이터로 실제로 무엇을 합니까?"라고 묻습니다.
• SWE는 임시 데이터 흐름을 프로덕션 등급으로 끌어올리기 위해 데이터 팀 모범 사례 및 표준을 멘토링하고 향상시킬 수 있습니다.
• 데이터 팀 구성원은 비즈니스 논리, 논리가 속한 프레임워크를 추가하는 방법에 대해 비즈니스 이해 관계자를 지도하고 향상시킬 수 있습니다.
• 모든 팀은 다른 사람들을 코드베이스에 초대하고 전체 회사 아키텍처에 대한 장기적인 관점을 장려합니다.

Ian Macomber는 회사가 지출을 줄이는 데 도움이 되는 최초이자 유일한 법인 카드인 Ramp의 데이터 과학 및 분석 엔지니어링 책임자입니다. 이전에는 Drizly에서 분석 및 데이터 엔지니어링 부사장이었습니다.

네 번째 트렌드도 있습니다! Data Systems Tend Towards Calculation 에 대해 계속 지켜봐 주십시오 . 이 기사는 한 기사에 다 담기에는 너무 많았습니다.